WS1.2 — Admin Workflow Maps

WS1.2 — Admin Workflow Maps

Purpose: Step-by-step maps of 6 real admin workflows, annotated with screen paths, click counts, information gaps, external tool dependencies, and error-prone points. These maps are the measuring stick against which navigation candidates will be evaluated. Source data: Capability Map, Navigation Interview Report, Redesign Plan (Section 1.2) Date: March 2026

How to Read These Maps

Each workflow documents:

Element What it means
Trigger What initiates the workflow
Steps Numbered actions with screen paths, information needed, and information available vs. missing
Screen count Total distinct screens/pages the admin must visit
Click estimate Navigation clicks — section changes, page loads, modal opens, tab switches (does not count form field interactions)
External tool dependencies Steps that require leaving the admin backend entirely
Error-prone points Where the interview identified mistakes happen, cited by question number
Pain quotient Critical / High / Medium / Low based on frequency, impact, and interview evidence

Screen paths use the exact routes from the Capability Map (e.g., /lessons-new/index). Where a step requires navigating to a detail/edit view of a specific record, the path is shown as /lessons-new/update?id={id}.

Workflow 1: Set Up a New Semester

Trigger

New semester approaching (occurs 2-3 times per year). The admin must configure all content, enrollment settings, TA assignments, schedules, and communications before the semester goes live.

Interview Evidence

Step-by-Step Flow

Step 1 — Create the new semester record

Step 2 — Deactivate the previous semester

Step 3 — Set up Video Lessons (per level)

Step 4 — Set up Submissions / Assessments (per level)

Step 5 — Set up Resources (per level)

Step 6 — Set up Live Sessions (per level)

Step 7 — Set up Tutorials (per level)

Step 8 — Set up MCQ Questions and Quizzes

Step 9 — Set up Recordings library

Step 10 — Upload Welcome Package (21 documents)

Step 11 — Update Email Management templates

Step 12 — Configure Tags for the new semester

Step 13 — Configure Teacher Assignment Criteria

Step 14 — Move TAs to the new semester and set up schedules

Step 15 — Configure Operations for bulk tasks

Step 16 — Verify everything — manual cross-check

Summary

Metric Value
Screen count 19+ distinct screens (Semesters, Semester create/edit x2, Video Lessons index + create, Submissions index + create, Resources index + create, Live Sessions index + create, Tutorials index + create, MCQ Questions index + create, Quizzes index + create, Recordings index + create, Welcome Package, Email Management index + edit, Tags index, Teacher Assignment Criteria, TA list, TA Schedules, Operations)
Click estimate 50-80+ navigation clicks (each content section requires: sidebar click to section, click to create, save, repeat per level/item; plus the verification pass)
External tool dependencies 3 — Vimeo (video/recording URLs), Google Sheets (TA schedule overview), InfusionSoft (tag sync verification)
Error-prone points 4 critical: (1) Forgetting to deactivate old semester — Q1; (2) Missing a content category during setup — Q1, Q8; (3) Leaving a welcome package document out of the 21-document upload — Q1; (4) Failing to update semester-specific content in email templates — Q1
Pain quotient Critical — This is the single most dreaded workflow. Q8: the admin explicitly delays it because it's "time-consuming, error-prone, requires extensive double-checking." No cloning, no checklist, no bulk operations for most content types. Every semester is built from scratch.

Ideal Flow

The admin opens a Semester Hub page that shows the full setup status of the new semester at a glance — a checklist of all 8 content types with green/amber/red status indicators for each level. From this hub, the admin clicks a "Clone from Previous" button that copies all content from the last semester (lessons, submissions, resources, tutorials, recordings, quizzes, welcome package, email templates) into draft state, ready for review and selective editing. The admin works through the checklist tab by tab, confirming or modifying cloned content, and each save updates the checklist status in real time. Live sessions are configured once as a recurring weekly pattern and auto-generated across the semester date range. When all checklist items are green, the admin clicks "Activate Semester" — which simultaneously sets the new semester to is_current = 1, deactivates the old semester, and triggers the registration and welcome email pipeline. The entire workflow is guided, sequenced, and self-verifying.

What's consolidated vs. current state: 19+ screens collapse into a 1-3 screen hub. 16 steps collapse into a clone-review-activate sequence. The verification pass (Step 16) is eliminated because the checklist IS the verification. External dependencies drop from 3 to 0-1.

Opportunities

  1. Content Cloning Engine — Copies all content (or selected content types) from one semester to the next in draft state, ready for review. Eliminates the manual re-upload of videos, submissions, resources, tutorials, recordings, and quizzes that the admin dreads and delays (Q1, Q8: "manually uploading all semester content is time-consuming and error-prone"). Type: Feature addition.

  2. Semester Template System — Saves a semester's full configuration as a reusable template, including content structure, email templates, tag setups, and TA assignment criteria. Allows rapid setup for recurring program structures (e.g., standard Year 1 semester vs. summer intensive). Builds on cloning but adds cross-semester persistence. Type: Feature addition.

  3. Auto-Activation Based on Dates — Automatically transitions is_current status based on the configured start date, eliminating the manual deactivation step that has caused data corruption (Q1: "leaving old semester active corrupts student profiles"). Includes a safety confirmation 24 hours before activation. Type: Feature addition.

  4. Setup Checklist Dashboard — A single-page status view showing all 8 content types across all 6 levels, with completion indicators (configured / partially configured / not started). Replaces the manual verification pass that currently requires revisiting every content section (Step 16: "no semester setup checklist or dashboard showing completion status"). Type: Nav change + feature addition.

  5. Welcome Package Persistence — Welcome package documents persist across semesters and can be individually edited, replaced, or carried forward, rather than requiring all 21 documents to be re-uploaded from scratch (Q1: "welcome packages must be re-uploaded individually each semester"). Type: Feature addition.

  6. Bulk Content Upload — Upload multiple items of the same content type at once (e.g., all Level 1 resources via multi-file upload, or all lesson metadata via CSV). Reduces the per-item create-save-repeat cycle that dominates Steps 3-9. Type: Feature addition.

  7. Recurring Live Session Scheduler — Define a recurring weekly pattern (e.g., Level 1 on Tuesdays at 7pm) and auto-generate all session instances for the semester date range, rather than creating each session individually (current state: "no way to set up a recurring weekly schedule"). Type: Feature addition.

Workflow 2: Handle a Student Support Issue

Trigger

A student emails or reports a problem — could be billing-related, access-related, content-related, or scheduling-related. The admin must find the student, diagnose the issue, act, and resolve.

Interview Evidence

Step-by-Step Flow

Step 1 — Receive the support request

Step 2 — Find the student in the system

Step 3 — Open the student profile

Step 4 — Diagnose: Is this a billing issue?

Step 5 — Diagnose: Is this a billing edge case (family plan, scholarship, deferment)?

Step 6 — Diagnose: Is this a submission/grading issue?

Step 7 — Diagnose: Is this an appointment/scheduling issue?

Step 8 — Take action based on diagnosis

Step 9 — Verify resolution

Step 10 — Respond to the student

Summary

Metric Value
Screen count 5-7 backend screens + 2-3 external tools (Students list, Student profile, Student Report, Appointments, TA Schedules; plus Stripe, Google Sheets, email client)
Click estimate 15-25 clicks depending on issue type (initial navigation to student: 3-4 clicks, each diagnostic section: 2-3 clicks, action steps: 3-5 clicks, verification: 2-3 clicks)
External tool dependencies 3 — Stripe (any billing issue), Google Sheets (family plans, scholarships, deferments), Email client (all communication)
Error-prone points 3: (1) Deactivating student in backend but forgetting to cancel Stripe subscription, or vice versa — Q3; (2) Not checking Google Sheets for special billing arrangements before making changes — Q5; (3) Missing context because semester history isn't on the student profile — Q2
Pain quotient High — This is the most frequent workflow (happens daily/weekly). The information fragmentation across backend, Stripe, and Google Sheets means every support interaction requires 3+ tool switches. The admin is the only person who knows the full picture because the system doesn't consolidate it. Support staff cannot handle billing questions independently (Q5).

Ideal Flow

The admin receives a support request — ideally through an in-app issue queue that surfaces on their dashboard rather than email. They click the student's name to open a consolidated student entity page with tabs: Profile, Submissions, Payments, Appointments, History. The Profile tab shows current level, TA, group, semester status, sign-up date, and activation status. The Payments tab shows Stripe subscription status, payment history, plan type (standard / family / scholarship / deferment), and outstanding balance — all pulled from Stripe in real time, no tab-switching required. The Submissions tab shows all submissions with grades, TA feedback, and review status. The History tab shows every semester the student has been enrolled in, with level, outcome, and TA per semester. From this single page, the admin can take any resolution action — deactivate + cancel subscription as a linked single action, reset progress, adjust level, or add a case note. The case note creates an audit trail visible to any staff member who handles a follow-up.

What's consolidated vs. current state: 5-7 backend screens + 2-3 external tools collapse into 1-2 screens with zero external tools. Diagnosis steps 4-7 (billing, edge cases, submissions, appointments) become tab switches within a single page. The linked deactivation+cancellation eliminates the most dangerous error-prone point.

Opportunities

  1. Consolidated Student Entity Page — A single page with tabbed views (Profile, Submissions, Payments, Appointments, History) that replaces the current fragmented approach of visiting 5+ screens and 2+ external tools to build a full picture of a student. Directly addresses the admin's top wish (Q2: "a consolidated student profile showing level, TA, gender, semester history, submission count, and payment status"). Type: Nav change + feature addition.

  2. Stripe Data Integration on Profile — Real-time display of subscription status, payment history, plan type, and failed payments within the student's Payments tab. Eliminates the most friction-heavy external tool dependency (Q5: "payment/billing data is the highest-friction gap"). Enables support staff to answer billing questions without admin escalation. Type: Data integration.

  3. Linked Deactivation — A single "Deactivate Student" action that simultaneously sets user_activation_status = 0 in the backend AND cancels the Stripe subscription. Includes a confirmation dialog showing both actions. Eliminates the most dangerous error-prone point in the system (Q3: "student deactivation requires a separate manual step in Stripe"). Type: Feature addition.

  4. Case Notes / Audit Trail — Ability to add timestamped notes to a student's profile recording what action was taken, by whom, and why. Creates institutional memory so that follow-up interactions have context — currently all support history lives in the admin's memory or scattered email threads. Type: Feature addition.

  5. Student Issue Reporting System — In-app mechanism for students to report problems, surfacing issues in the admin dashboard as an actionable queue. Replaces the current email-only channel and makes issue tracking systematic (Q7: "student-reported app issues" on dashboard wish list). Type: Feature addition.

  6. Support Staff Billing Access — View-only billing tab on student profiles available to support staff roles, enabling them to diagnose and answer payment questions without escalating to the admin. Directly addresses the bottleneck where the admin is the only person who can see the full picture (Q5: support staff "cannot handle billing questions independently"). Type: Feature addition + data integration.

Workflow 3: Close a Semester / Promote Students

Trigger

Semester end date approaching. The admin must review student performance, handle edge cases, execute promotions, set up payments for continuing students, and deactivate departing students. This spans 2-4 weeks.

Interview Evidence

Step-by-Step Flow

Step 1 — Review EOC (End-of-Course) assessment tracking

Step 2 — Pull student performance reports

Step 3 — Identify edge cases requiring manual review

Step 4 — Handle automation email errors

Step 5 — Execute standard promotions (automated)

Step 6 — Execute manual/discretionary promotions

Step 7 — Handle Level 0 students who didn't submit assessments

Step 8 — Set up Stripe payments for continuing students (PREMATURE — this is the pain point)

Step 9 — Handle payment corrections

Step 10 — Deactivate departing students (backend)

Step 11 — Cancel Stripe subscriptions for departing students

Step 12 — Update promoted students report

Step 13 — Prepare the new semester (links to Workflow 1)

Summary

Metric Value
Screen count 8+ backend screens + 2-3 external tools (Student Report, Student profiles x many, Students Management, Operations, Promoted Students, Users list; plus Stripe, Google Sheets, email client)
Click estimate 40-70+ clicks (reviewing reports: 5-8, individual student profile visits for promotions: 2-3 per student x N students, Stripe navigation: 10-20 for payment setup/corrections, deactivation: 2-3 per student x N students)
External tool dependencies 3 — Stripe (payment setup, corrections, cancellations — the dominant external tool), Google Sheets (EOC assessments, special pricing), Email client (correction communications)
Error-prone points 5 critical: (1) Setting up Stripe payments before promotions are final — Q3; (2) Forgetting to cancel Stripe when deactivating a student, or vice versa — Q3; (3) Automation sending incorrect emails to edge-case students — Q3; (4) Teacher grading inconsistencies triggering wrong automation — Q3; (5) Missing a student during manual promotion/deactivation with no bulk tools — Q8
Pain quotient Critical — The most error-prone workflow. The premature payment setup problem is structural — the workflow's sequencing is fundamentally broken. Every error cascades into manual corrections across two systems. The admin explicitly avoids/delays this workflow (Q8).

Ideal Flow

The admin opens a Semester Close Workflow page that presents the close process as a sequenced pipeline with four phases: (1) EOC Review — teachers submit assessments directly in the backend; the system auto-flags edge cases (students near the 12-submission threshold, grades between 3.0-3.5, teacher discretion overrides) and presents them as an exception list for admin review. (2) Promotion — once all EOC assessments are submitted and edge cases resolved, the admin triggers bulk promotion across all levels with a single action; the system shows a preview of who will be promoted, held, or flagged, and the admin confirms. (3) Payment Setup — only unlocked AFTER promotions are finalized; the system auto-generates Stripe subscriptions for continuing students based on their new level and existing payment plan (standard, family, scholarship, deferment), with a review screen before execution. (4) Deactivation — for departing students, a bulk deactivation action that simultaneously cancels Stripe subscriptions. Each phase gates the next, preventing the premature payment setup problem. An email send log shows exactly which automated emails went to which students at each phase.

What's consolidated vs. current state: 8+ backend screens + 2-3 external tools collapse into a 2-3 screen sequenced workflow. The 13 manual steps collapse into 4 gated phases. The structural sequencing problem (payments before promotions) is eliminated by design. External dependencies drop from 3 to 0.

Opportunities

  1. In-System EOC Assessment — Teachers submit end-of-course assessments (pass/fail recommendation, narrative notes, discretion flags) directly in the backend rather than in Google Sheets. The system auto-compares teacher assessments against automation criteria and highlights discrepancies. Eliminates the manual cross-referencing of two data sources (Q3: "the entire pass/fail decision-making process happens outside the system"). Type: Feature addition.

  2. Sequenced Close Workflow — A gated pipeline where each phase (EOC Review, Promotion, Payment Setup, Deactivation) must be completed before the next unlocks. Structurally prevents the premature payment setup problem that is the single biggest source of cascading errors (Q3: "setting up Stripe payments before promotions are finalized creates corrections"; Q8: admin "avoids/delays" this workflow). Type: Feature addition.

  3. Bulk Promotion Across All Levels — A single bulk action that promotes all qualifying students across all Year 1 levels (0-1, 1-2, 2-3, 3-4) and Year 1-to-Year 2, with a preview and confirmation step. Currently, bulk promotion only exists for Year 1-to-Year 2 via CSV; all other promotions must be done one student at a time (Step 5-6: "no batch promotion for students within Year 1 levels"). Type: Feature addition.

  4. Linked Deactivation + Payment Cancellation — A single "Deactivate Departing Students" action that simultaneously deactivates backend accounts and cancels Stripe subscriptions, with a preview list and confirmation. Eliminates the most dangerous error in the close workflow (Q3: "if the admin deactivates 15 students in the backend but only cancels 14 subscriptions in Stripe, one student continues being charged"). Type: Feature addition + data integration.

  5. Promotion-Gated Payment Setup — Payment setup is architecturally blocked until all promotions are finalized and confirmed. The system auto-generates the correct subscription for each continuing student based on their post-promotion level and existing plan type. Eliminates the cascade of corrections that currently occurs when students opt out or teachers change decisions after payment setup (Q3, Q8). Type: Feature addition.

  6. Edge Case Flagging — Automatic identification of students near decision thresholds: 11 submissions (one away from qualifying), last grade between 3.0-3.5 (near the 3.5 cutoff), teacher grade inconsistencies (sub-3.5 on submission 12+ despite instructions). Presents these as an exception list for admin review rather than requiring manual scanning (Q3: "teachers sometimes assign sub-3.5 grades on submission 12+ despite instructions, triggering incorrect repeat emails"). Type: Feature addition.

  7. Email Send Log Per Student — A record of every automated email sent to each student during the close process (promotion notification, repeat notification, payment confirmation), with timestamps and content. Enables the admin to see exactly what happened when incorrect emails are sent and to issue targeted corrections (Step 4: "no email send log per student"). Type: Feature addition.

Workflow 4: Daily Monitoring / Operations

Trigger

Daily admin check — the admin logs in each day to monitor system health, check for issues, and respond to emerging problems. This is the most frequent workflow.

Interview Evidence

Step-by-Step Flow

Step 1 — Check the Dashboard

Step 2 — Check TA submission response times

Step 3 — Check student submission progress

Step 4 — Check for failed payments

Step 5 — Check appointment utilization (Year 2)

Step 6 — Check TA schedules and coverage

Step 7 — Review daily notes / follow-ups

Step 8 — Check for new student emails / support requests

Summary

Metric Value
Screen count 4-5 backend screens + 2-3 external tools (Dashboard, TA Reports, Student Report, Appointments, TA Schedules; plus Stripe, Google Sheets, email client)
Click estimate 12-18 clicks for the full monitoring circuit (dashboard: 0 — it's the landing page, navigate to each report: 2-3 clicks each, appointments: 2-3 clicks, Stripe and Sheets: external)
External tool dependencies 3 — Stripe (failed payment monitoring), Google Sheets (TA schedule overview), Email client (support requests)
Error-prone points 2: (1) Missing a failed payment because it's only visible in Stripe — Q5, Q7; (2) Missing a student falling behind because there's no alert — Q7
Pain quotient High — While individual steps are quick, the fundamental problem is that the dashboard provides zero actionable information. The admin must manually visit 4-5 screens and 2-3 external tools to build a picture that a well-designed dashboard would surface in one view. Every monitoring check is a manual scan rather than an alert-driven response. The admin described the current dashboard as useless (Q6).

Ideal Flow

The admin logs in and lands on a smart operations dashboard that shows everything requiring attention today. The dashboard is organized into alert panels: Failed Payments (pulled from Stripe, showing student name, failure reason, retry status — clickable to the student's payment tab), TA Response Times (flagging TAs with submissions pending >48 hours, with a count of overdue reviews — clickable to the TA's submission queue), Students Falling Behind (students whose submission pace puts them at risk of not reaching the 12-submission threshold, based on current week vs. expected progress — clickable to the student profile), Appointment Utilization (Year 2 students who haven't booked their weekly appointment — clickable to the booking view), and Student Issues (in-app reported problems from students, replacing the email-based system). Each alert panel shows a count badge and links directly to the resolution context — no intermediate navigation required. The daily notes feature remains, enhanced with follow-up reminders.

What's consolidated vs. current state: 4-5 backend screens + 2-3 external tools collapse into 1 screen with zero external tools. The 8-step manual monitoring circuit becomes a single page load. The admin shifts from reactive (manually hunting for problems) to proactive (system surfaces problems automatically).

Opportunities

  1. Alert Engine with Configurable Thresholds — A rules-based alert system that surfaces exceptions on the dashboard based on configurable thresholds (e.g., TA response time >48 hours, student submission pace below expected, appointment utilization below 70%). Replaces the manual scanning of 4-5 screens that currently constitutes the daily monitoring circuit (Q7: full wish list of alerts the admin wants). Type: Feature addition.

  2. Failed Payment Detection — Real-time surfacing of Stripe payment failures on the dashboard, showing student name, failure type (card declined, expired, insufficient funds), retry count, and a direct link to the student's payment profile. Eliminates the need to check Stripe as a separate tool during daily monitoring (Q5: "all payment data requires going to Stripe"; Q7: "failed payment alerts" on wish list). Type: Data integration.

  3. TA Response Time Tracking — Automated tracking of how long each TA takes to review student submissions, with a flag when any submission has been pending for more than 48 hours. Shows on the dashboard as an alert with the TA name, number of overdue submissions, and oldest pending submission age (Q7: "TA submission response time alerts — flagging >48 hours"). Type: Feature addition.

  4. Submission Pace Monitoring — Per-student tracking that compares actual submission count against expected pace based on current week of the semester. Flags students at risk of not reaching the 12-submission threshold in time, enabling early intervention rather than end-of-semester surprises (Q7: "students falling behind on submissions"). Type: Feature addition.

  5. Student Issue Queue — An in-app mechanism for students to report problems, replacing the email-based support channel. Issues appear on the dashboard as an actionable queue with status tracking (new / in progress / resolved), reducing the admin's dependence on email monitoring and creating a record of all support interactions (Q7: "student-reported app issues" on dashboard wish list). Type: Feature addition.

  6. Appointment Utilization Metrics — Dashboard panel showing Year 2 appointment booking rates: how many students booked their weekly appointment, who hasn't booked yet, and overall utilization percentage. Eliminates the manual cross-referencing of the appointment list against the Year 2 student roster that currently happens across two separate screens (Q7: "Year 2 appointment utilization for the week"). Type: Feature addition.

Workflow 5: Manage Appointments / Scheduling

Trigger

Rescheduling requests from students or TAs, TA availability changes, public holiday additions, or weekly schedule verification. Can happen daily during active semester.

Interview Evidence

Step-by-Step Flow

Step 1 — Receive rescheduling request or availability change

Step 2 — Check the affected appointment(s)

Step 3 — Check the TA's availability for alternative times

Step 4 — Cancel the existing appointment

Step 5 — Create the replacement appointment

Step 6 — If this is a TA availability change: Update TA schedule

Step 7 — If this is a holiday: Add to the appropriate holidays list

Step 8 — Update external TA schedule spreadsheet

Step 9 — Notify affected parties

Summary

Metric Value
Screen count 4-6 backend screens + 2 external tools (Upcoming Appointments, TA Schedules, Public Holidays, Students Management → Live Session Holidays; plus Google Sheets, email client)
Click estimate 12-20 clicks for a full rescheduling (find appointment: 2-3, check TA schedule: 3-4, cancel: 2, create new: 4-5, update holidays if applicable: 3-5)
External tool dependencies 2 — Google Sheets (TA schedule overview), Email client (notifications)
Error-prone points 3: (1) Forgetting to update BOTH holiday systems for a public holiday — Q6; (2) Creating an appointment at a time the TA isn't actually available (schedule viewed on a different screen) — Q2; (3) Forgetting to update the Google Sheets schedule after a backend change — Q2
Pain quotient Medium — Individual rescheduling tasks are manageable, but the split holiday system is a design flaw that causes real errors. The lack of a calendar view forces constant screen-switching and external spreadsheet dependency. The workflow is more tedious than it is risky, but the holiday split is a genuine error source.

Ideal Flow

The admin opens a cross-TA calendar view that shows all TAs' availability, all 1:1 appointments, and all group live sessions in a unified weekly or monthly view. The calendar is filterable by gender (for gender-matched scheduling), by level, and by individual TA. When a reschedule is needed, the admin clicks the existing appointment and selects "Reschedule" — a single action that opens an inline panel showing the TA's available slots for the week. The admin picks a new slot, confirms, and the system automatically cancels the old appointment, creates the new one, and sends a notification to the student and TA. For holidays, there is a unified holiday system: the admin adds a holiday once, selects whether it affects appointments, live sessions, or both, and the system applies it across all relevant schedules. No dual entry, no split navigation. The external Google Sheets schedule is eliminated because the calendar view IS the consolidated schedule.

What's consolidated vs. current state: 4-6 backend screens + 2 external tools collapse into 1-2 screens with zero external tools. The 9-step reschedule process (find appointment, check TA schedule, cancel, create new, update holidays, update Sheets, notify) becomes a 3-step inline action (click appointment, pick new slot, confirm). The split holiday system is unified.

Opportunities

  1. Cross-TA Calendar View — A visual calendar showing all TAs' availability, appointments, and live sessions in a single view, with filtering by gender, level, and individual TA. Eliminates the need for the external Google Sheets schedule and the one-TA-at-a-time backend view (Q2: "no calendar view of all live sessions and 1:1 appointments across all TAs"; "TA schedules require a separate spreadsheet for a full weekly overview"). Type: Nav change + feature addition.

  2. Unified Holiday Management — A single holiday system where the admin adds a holiday once and selects its scope (appointments only, live sessions only, or both). Replaces the current split between public holidays under Appointments and live session holidays buried under Students Management (Q6: "holidays should apply to all live sessions, not just appointments"; "holidays are split between two locations"). Type: Nav change.

  3. Reschedule as Single Action — A "Reschedule" button on any appointment that opens an inline panel with the TA's available alternative slots, then handles cancellation of the old appointment and creation of the new one as a single transaction. Eliminates the current 3-step cancel-navigate-create process that requires cross-referencing information from two separate screens (Steps 4-5: "no reschedule as a single action — must cancel and then create a new appointment"). Type: Feature addition.

  4. Automated Change Notifications — Automatic email or in-app notification to affected students and TAs when an appointment is rescheduled, cancelled, or when a holiday is added. Eliminates the manual email step that currently ends every scheduling change (Step 9: "no automated notification for appointment changes"). Type: Feature addition.

  5. Schedule Impact Preview — When modifying a TA's weekly availability (adding or removing slots), the system shows a preview of which existing appointments would be affected by the change, enabling the admin to handle rescheduling proactively rather than discovering conflicts after the fact (Step 6: "no way to see the impact of the schedule change — how many existing appointments are affected"). Type: Feature addition.

  6. Gender-Filtered Calendar View — Calendar filter that shows only male or female TAs and their schedules, supporting the gender-matched scheduling requirements. Enables quick identification of available slots within the correct gender pool when rescheduling or assigning new students (Q2 cross-ref; interview follow-up question on TA gender filtering). Type: Feature addition.

Workflow 6: Onboard / Manage a TA

Trigger

A new TA is joining the team, or the semester is transitioning and TAs need to be moved to the new semester with updated schedules and student assignments.

Interview Evidence

Step-by-Step Flow

Step 1 — Create the TA account (new TA only)

Step 2 — Configure the TA's weekly schedule

Step 3 — Update the external TA schedule spreadsheet

Step 4 — Set up student groups for the TA

Step 5 — Assign students to the TA's groups

Step 6 — For semester transitions: Move the TA to the new semester

Step 7 — Verify TA's students and appointment slots

Step 8 — Check TA Reports for baseline

Summary

Metric Value
Screen count 6-8 backend screens + 1 external tool (TA list, TA create/edit, TA Schedules, Student Groups, Teacher Assignment Criteria, Appointments, TA Reports; plus Google Sheets)
Click estimate 20-35 clicks (account creation: 4-5, schedule setup: 10-15 for multiple slots, group setup: 4-6, student assignment: 3-5, verification: 4-6)
External tool dependencies 1 — Google Sheets (TA schedule overview)
Error-prone points 3: (1) Forgetting to update Google Sheets after setting up the schedule in the backend — Q2; (2) Not cloning schedules because it's impossible, leading to manual re-entry errors (wrong times, missed slots) — Q1; (3) Repeat students not being assigned to their previous TA because there's no auto-assignment for this — Q1
Pain quotient Medium — The workflow is straightforward for a single new TA but becomes painful during semester transitions when ALL TAs need their schedules re-entered (multiplied by the number of TAs). The inability to clone schedules turns a simple transition into hours of repetitive manual entry.

Ideal Flow

The admin opens a TA entity page — a single page with tabs for Profile, Schedule, Students, Groups, and Performance. For a new TA, the page shows an onboarding checklist across the top: account created, schedule configured, groups assigned, students assigned, welcome materials sent. The admin works through each tab to complete setup. For the Schedule tab, the admin can either build a new schedule from scratch or click "Clone Schedule" to copy another TA's availability pattern or the same TA's schedule from the previous semester — then adjust individual slots as needed. For student assignment, the system auto-suggests repeat students who were with this TA last semester and flags them for one-click assignment. The Students tab shows current student load with capacity indicators, enabling balanced distribution. For semester transitions, a "Transition to New Semester" action carries forward the TA's schedule, groups, and student assignments into the new semester context, with a review step before confirmation. The Performance tab shows response times, submission review stats, and student outcomes — giving the admin a complete operational view of each TA.

What's consolidated vs. current state: 6-8 backend screens + 1 external tool collapse into 1-2 screens with zero external tools. The verification step (Step 7) that currently requires visiting 3 separate screens becomes a single-page view. Schedule setup time drops from 15+ individual slot additions to a clone-and-adjust workflow.

Opportunities

  1. Schedule Cloning — Copy a TA's weekly availability from the previous semester, or copy another TA's schedule as a starting template, then adjust individual slots. Eliminates the manual re-entry of 15+ weekly slots per TA during every semester transition (Q1: "TA appointment schedules cannot be cloned"; the admin must "manually re-enter" each TA's schedule). Type: Feature addition.

  2. Repeat Student Auto-Assignment — System identifies students who were assigned to a specific TA in the previous semester and auto-suggests them for assignment to the same TA, with one-click confirmation. Maintains student-teacher continuity without manual tracking (Q1: "repeat students aren't auto-assigned to previous teachers"). Type: Feature addition.

  3. TA Onboarding Checklist — A visible checklist on the TA entity page showing all setup steps (account, schedule, groups, students, welcome materials) with completion status. Provides a clear "done" signal and prevents forgotten steps — currently there is no way to see what remains after account creation (Step 1: "no onboarding checklist"). Type: Feature addition.

  4. TA Dashboard (Workload and Performance) — A Performance tab on the TA entity page showing: average submission response time, number of pending reviews, student count vs. capacity, student outcomes (pass/fail rates), and appointment utilization. Creates visibility into TA effectiveness and workload balance that currently requires visiting 3+ screens and has no response-time tracking (Step 7-8: "no unified TA dashboard showing all of this in one place"; Q7: TA response time alerts). Type: Feature addition.

  5. Consolidated TA Entity Page — A single page with tabs (Profile, Schedule, Students, Groups, Performance) that replaces the current workflow of visiting the TA list, TA profile, TA Schedules page, Student Groups page, and TA Reports page as separate screens. Each tab links to actionable views — schedule slots can be managed inline, students can be assigned from the Students tab, groups can be configured from the Groups tab (Steps 1-8 currently span 6-8 screens). Type: Nav change.

  6. Semester Transition Wizard for TAs — A guided "Move to New Semester" action that carries forward a TA's schedule, group structure, and student assignments into the new semester, with a review-and-confirm step. Replaces the manual process of updating the TA's profile, re-entering their schedule, recreating groups, and re-assigning students across multiple screens (Q1: "teachers must be manually moved to new semesters"; Step 6: "no move to new semester action"). Type: Feature addition.

Summary Comparison Table

Dimension WF1: Semester Setup WF2: Student Support WF3: Semester Close WF4: Daily Monitoring WF5: Scheduling WF6: TA Onboarding
Screen count 19+ 5-7 8+ 4-5 4-6 6-8
Click estimate 50-80+ 15-25 40-70+ 12-18 12-20 20-35
External tool count 3 (Vimeo, Sheets, InfusionSoft) 3 (Stripe, Sheets, Email) 3 (Stripe, Sheets, Email) 3 (Stripe, Sheets, Email) 2 (Sheets, Email) 1 (Sheets)
Error-prone step count 4 3 5 2 3 3
Pain quotient Critical High Critical High Medium Medium
Frequency 2-3x / year Daily-weekly 2-3x / year Daily Weekly 2-3x / year + ad hoc
Automation potential High (content cloning, semester checklist, auto-activation, schedule cloning) Medium (consolidated profile, Stripe integration, linked deactivation) High (sequenced promotion → payment workflow, linked deactivation, bulk tools) High (smart dashboard, Stripe alerts, TA response tracking, submission monitoring) Medium (calendar view, unified holidays, schedule cloning) Medium (schedule cloning, repeat student auto-assignment, TA dashboard)

Cross-Cutting Observations

1. Google Sheets appears in 5 of 6 workflows. It serves as the shadow database for: TA schedules, family payment plans, scholarship tracking, deferment tracking, and EOC assessment outcomes. Any navigation redesign that doesn't account for the data currently living in Sheets will only partly reduce friction.

2. Stripe appears in 3 of 6 workflows. Every workflow involving money (student support, semester close, daily monitoring) requires leaving the backend. Billing integration would collapse multiple external-tool steps into inline actions.

3. No workflow has a "completion view." Semester setup has no checklist. Semester close has no status dashboard. Daily monitoring has no alert surface. TA onboarding has no progress tracker. Every workflow requires the admin to hold the full picture in their head and manually verify each step. This is the most consistent pattern across all 6 workflows.

4. The two Critical workflows (Setup and Close) are mirror images. Setup is about building from nothing with no cloning. Close is about unwinding and transitioning with no linked actions. Both suffer from the same root cause: the system treats each entity independently and never orchestrates entities together into a workflow.

5. Candidate evaluation implications: