TutorComp, session scheduling redesign

01 · Outcome

Rollout results

>50%Self-scheduled bookings

The headline result: within four months of full rollout, more than half of bookings placed through the redesigned flow were completed by learners without an advisor, passing the pre-launch target. We calculated the rate as self-scheduled bookings divided by all bookings placed through the redesigned flow.

Advisor scheduling time

Fewer hours on booking coordination

Advisors logged fewer hours under the booking-coordination task after rollout. The product did not record exact handling time, so this result comes from advisor reports.

Source: advisor reports

Agent Assist usage

Use declined after launch

Agent Assist was the chat and callback support inside the booking flow. Weekly transcript reviews showed less use in the weeks after launch. During the same period, the share of self-scheduled bookings increased.

Source: weekly Agent Assist transcript reviews

Before release, the product manager (PM) and operations lead agreed on the measure of adoption: more than half of bookings placed through the redesigned flow needed to be self-scheduled. We counted a booking as self-scheduled when the learner completed it without an advisor placing it on their behalf.

During the transition, the team watched whether returning learners kept booking, as a check that the change was not costing us the people we most wanted to keep, and asked advisors to report time spent on coordination. The team did not have a defensible retention figure to report.

What the numbers meant operationally

The clearest win was operational rather than a single dashboard figure. Routine scheduling moved off the advisors who used to run it by hand, and advisors reported spending more of their time on academic guidance and the complex choices that needed a person. The self-serve rate is the metric we could defend precisely. The advisors' reports of how their day changed are softer evidence.

02 · Business problem

A high-touch service had become a booking bottleneck

TutorComp is an online tutoring service for learners who need one-to-one help in a school subject. Accounts could be managed by a learner or by a parent on their behalf; in this case study, "learner" refers to whoever handled booking on the account. In 2022, TutorComp assigned each learner an academic advisor. Advisors recommended tutors, coordinated sessions and stayed involved as learners built a relationship with a tutor.

Advisor support gave learners a person who knew their history and could answer questions about tutor fit. The same model required advisor involvement for routine scheduling because the product gave learners too little information to choose and book on their own.

When COVID-19 moved schooling online, remote learning pushed demand for one-to-one tutoring up sharply, and self-serve competitors let families book a tutor in minutes. TutorComp could not move at that pace. Every booking waited on a person, so how fast the business could grow was capped by how many advisors it could staff.

How a booking worked

1
The learner contacted an assigned advisor with a subject, tutor preferences and available times.
2
The advisor compared tutor expertise, fit and schedules, then sent suitable options back to the learner.
3
The learner reviewed the options and replied with a choice. Questions or schedule changes added another exchange.
4
The advisor placed the confirmed session against the learner's prepaid credits, the pool of sessions the learner had paid for in advance.

This support gave learners confidence when they chose a tutor for a new subject. Returning learners relied on advisors to remember a previous tutor and arrange the next session.

Advisors repeated the coordination loop for routine bookings, and each change required a new message or call. The PM and operations lead wanted learners to handle routine bookings while advisors focused on academic guidance and complex choices.

Product target

Move more than half of bookings through the redesigned flow to self-serve. Watch whether returning learners keep booking during the change.

My role

I led research and product design across the 12-week build. I worked with the PM and four engineers through testing, delivery and rollout.

Booking rules the product had to support

Every booking resolved the same dependency chain: the subject determined which tutors were eligible, the chosen tutor and their availability determined which times were open, and each booked time drew down prepaid credits. Advisors used to hold that chain in their heads. The product now had to make it legible to a learner working alone.

Credits and session types: learners bought session credits in advance. Recurring created a weekly schedule. Flexi let a learner choose individual dates. With no advisor tracking the balance, the interface needed to show credits used against the available balance, so learners could see the cost before confirming. For Recurring specifically, days per week and duration multiply into a credit cost a learner could easily overshoot, so the interface constrained that combination as it was being built rather than rejecting it after the fact.

Availability and booking results: a subject or tutor change could make an earlier time unavailable. Flexi saved each selected time as a separate booking, so one time could confirm while another failed. Learners needed to see the result for each selection.

03 · Discovery

Learners needed context and continuity

Many booking decisions happened outside the interface, during calls and email exchanges. I needed to understand how learners chose a tutor and how advisors filled gaps in the product. I interviewed 12 learners, including people new to TutorComp and people who had booked with the same tutor over time.

I also interviewed six academic advisors. They explained how they assessed subject experience, availability and fit when they made a recommendation. The product team had not documented much of this matching logic, even though learners depended on it.

I used the interviews to identify decision patterns and product risks. A larger study would be required to measure how common each pattern was across the learner base.

Confidence depended on context

Learners wanted to understand a tutor's subject experience, available times and credit cost before choosing. Advisors had supplied this information across calls and messages; the booking interface needed to place it beside the choice. This made the tutor profile, with experience, availability and credit cost in one place, the decision point in the flow.

Repeat bookings centred on continuity

Returning learners came back to continue with a tutor they trusted. Asking them to search through all tutors again ignored the relationship they had built. They needed a direct route to the previous tutor's schedule. This became the continuity-first path: returning learners see previous tutors before the full list.

Advisors supplied reassurance

Some learners understood the available options and wanted a person to confirm that a tutor or schedule suited their needs. Removing that route could turn uncertainty into an abandoned booking. This became in-flow Agent Assist, chat and callback kept inside the booking, rather than a removed advisor channel.

Coordination delayed booking

Learners waited for an advisor after each email or call. Advisors spent time checking routine schedules and relaying options, leaving less time for academic support and cases that required judgment.

Learner segment model

New self-starter

Aisha, 19, university student

2 months on the platform · ad-hoc sessions · high digital comfort

Continuity-seeker

Anika, 31, working professional

16 months · weekly recurring · medium digital comfort

Need

Confidence to choose alone

Continuity, plus help to act alone

Primary barrier

Can't see tutors, availability, or what happens after confirming

Doesn't know how to choose without a coordinator

Mental model

Ready to self-serve, blocked by visibility, not willingness

Advisor-first habit, calcified over 16 months of weekly sessions

Role of the advisor

A delay between intent and a booked session

A comfort layer that guarantees the booking is certain

Booking pattern

Ad-hoc sessions around a shifting lecture timetable

Same tutor, same weekly slot, predictable and recurring

Product risk

Hidden options force a dependence she doesn't want

Self-serve breaks trusted tutor continuity and hard-won confidence

Fig. 1 - Learner segment model. I organized the flow around confidence to choose and tutor continuity.

Product problem

The product needed to give learners enough context to choose a tutor and enough feedback to complete a booking without advisor coordination.

The flow also had to carry forward the parts of the service that learners valued: previous-tutor history, visible credit use and a route to human help. The team had 12 weeks to design and build the first release.

04 · Product strategy

We built a first prototype, V1, to test the booking flow

The PM, engineers and I scoped the first prototype, V1, around the mechanics shared across new and repeat bookings. We needed to test the dependencies between subject, tutor, schedule and credits before the team committed to the revised flow.

We started from a subject because tutor eligibility and availability depended on it. Learners then compared suitable tutors and chose one. For scheduling, Recurring set a weekly pattern and Flexi supported individual dates.

V1 scope decision

Built into V1: the complete path from subject selection to confirmation, including tutor comparison, Recurring and Flexi scheduling, credit use and booking feedback.

Deferred from V1: research had identified the need for a direct previous-tutor route. We left that entry point out of the first prototype so we could test the shared booking mechanics before adding the transition path.

Safeguard during testing: learners retained the existing advisor channel while we studied where product guidance or human reassurance remained necessary.

Stakeholder decision

Protecting retention over the fastest efficiency win

There was pressure to prove the efficiency case quickly by pulling advisors off routine scheduling as soon as the flow shipped. I argued against it. Discovery suggested that several of the most advisor-dependent learners were also long-standing ones. The interviews could not size how common that overlap was, but it pointed to enough retention risk that a hard cutover looked most likely to disrupt the learners the business could least afford to lose. I made the case to keep the advisor channel live through the trial and to build in-flow support rather than assume learners would adapt on their own. We accepted a slower, smaller day-one efficiency gain in exchange for not putting the retention of loyal learners at risk before the product had earned their trust.

12-week dual-track plan

Six two-week sprints. Discovery stays one step ahead of delivery.

Discovery · UX and PMDelivery · engineering

Sprint 1 · weeks 1–2Problem framing
DiscoveryLearner and advisor interviews (n=18)
DeliveryTech discovery spike
Sprint 2 · weeks 3–4V1 prioritization
DiscoverySynthesis, then prioritize the V1 bets
DeliveryData model and API design
Sprint 3 · weeks 5–6Foundations
DiscoveryDesign system and core self-serve flow
DeliveryScheduling logic and API build
Sprint 4 · weeks 7–8Testable V1
DiscoveryHi-fi prototype and test plan
DeliveryFront-end build wired to the API
Sprint 5 · weeks 9–10Validation and hardening
DiscoveryModerated usability testing (n=20)
DeliveryIntegration and QA hardening
Sprint 6 · weeks 11–12Revision and launchLaunch
DiscoveryRevisions and handoff
DeliveryFinal build, QA, then ship behind a flag

Fig. 2 - The 12-week dual-track plan. I kept research and prototyping one step ahead of engineering.

V1 learning agenda

Before testing, I turned the research findings and booking constraints into five areas to observe:

1
The amount of Recurring choice learners could compare with confidence.
2
The feedback learners needed after selecting a Flexi time.
3
The moments when learners still wanted advisor reassurance.
4
The way learners checked progress and revised an earlier choice.
5
The cost of deferring direct previous-tutor entry for returning learners.

Delivery model

I defined shared type, spacing, interaction states and controls before four engineers split the build. That work gave each part of the booking journey the same visual and interaction rules.

The PM and I resolved product questions each week. Engineering and operations reviewed booking rules and failure cases every two weeks, while I kept research and prototyping ahead of implementation.

V1: a working self-serve booking flow

V1 was a working product. It introduced the three patterns the product still runs on: a stepped wizard, the tutor profile at the decision point, and a calendar for scheduling. It ran the whole path, subject to tutor to schedule to confirm, with credit use visible throughout, so we could test the self-serve model end to end.

The V1 journey

Subject, tutor, schedule, confirm, with credits visible throughout.

My courses · subjectExisting or new subject. The tutor list is scoped by subject.

Session type?

Recurring

Select tutor
View slots
Pain point: Persistent side-pane timetable
Confirm booking

Flexi

Select tutor
Pick date
Pick time slot
“Add Selected”
Pain point: Loop repeats per slot
Confirm booking

Tutor profile overlay · both pathsTutor detail in context, one tap from either path.

Fig. 3 - The V1 journey, end to end. Subject, tutor, schedule, confirm, with credits visible throughout.

A stepped wizard, so no one booked blind. A booking couples four interdependent choices, subject, tutor, schedule and credits, that advisors used to sequence by hand. V1 made each its own step behind a persistent tracker, so a learner resolved one decision at a time and always saw what was done and what was left. Holding the screen to a single choice was meant to make an unassisted booking feel safe rather than like a half-filled form.

The tutor decision, moved out of the advisor call and into the product. Research had named the tutor profile as the moment confidence was won or lost, and advisors had been supplying that context over the phone. V1 put it in the flow: each card carried subject experience, availability, credit cost and sessions completed, and a View profile popup held full credentials and history. A learner could commit to a tutor without waiting for a human, and testing confirmed this was the part they moved through with confidence.

V1 session-type step: a numbered wizard tracker across the top, with Recurring and Flexi options shown as calendar previews — Fig. 4 - The V1 wizard. A numbered tracker held learners in one step at a time, opening on the Recurring or Flexi choice.

Fig. 5 - The V1 tutor decision. Sessions completed on every card, and a profile popup with credentials and history one tap away.

For scheduling, V1 offered two modes on the same structure, each with a view built for how that decision is actually made.

Recurring turned an abstract pattern into concrete dates. Committing to "every Monday and Tuesday" for months is hard to picture, so V1 rendered the chosen pattern into a real timetable, every dated session it would produce, listed beside the choice. The aim was to let learners see the true commitment, dozens of sessions on named dates, before spending credits on a long recurring booking.

A calendar for Flexi, because dates are spatial. Flexi learners choose individual sessions, and a date is far easier to judge against a month than a dropdown. V1 gave Flexi a real calendar with visible availability and a running list of what had been added, built around the week-by-week way learners described planning. Scheduling is the part testing would go on to sharpen.

V1 Recurring slots screen with a docked timetable panel listing every dated session a pattern produced — Fig. 6 - The V1 Recurring timetable. Picking a pattern rendered every dated session it produced into a live timetable, docked beside the choice.

V1 Flexi select-slot screen mid-selection: a date picked, its available times listed with one chosen, an Add Selected button, and a running list of booked sessions with credit-hours counted — Fig. 7 - The V1 Flexi calendar in use. Pick a date, choose one or more times, then Add Selected; each session lands in a running list with credit use counted.

05 · Testing and decisions

The model held; scheduling and feedback needed sharpening

Discovery showed that returning learners arrived with a tutor in mind. Because V1 deferred the continuity entry point, they repeated tutor discovery during testing and confirmed the cost of that scope decision.

Design response

For a subject with booking history, show previous tutors before the full list. Add Find a new tutor for learners who want a change.

Tradeoff / safeguard

Returning learners reach scheduling sooner. New tutor discovery remains available from the same screen.

The interaction changes, side by side

The three changes with the clearest before and after are Recurring scheduling, Flexi scheduling and how progress is tracked (Decisions 1, 2 and 4). Drag each divider to compare V1 with the revised design, or use Expand to compare in a larger popup.

Revised recurring scheduling showing preferences, three matching options, and timetable links — Fig. 8 - Recurring, before and after. The same preferred-day input now returns three strong matches instead of the full pattern list. Drag to compare.

V1 recurring scheduling showing the full pattern set and a persistent timetable — Fig. 8 - Recurring, before and after. The same preferred-day input now returns three strong matches instead of the full pattern list. Drag to compare.

Revised Flexi scheduling with direct chronological multi-selection and credit count — Fig. 9 - Flexi, before and after. Learners now add a time in one action and keep credit use visible. Drag to compare.

V1 Flexi scheduling with separate date, time, and Add Selected interaction — Fig. 9 - Flexi, before and after. Learners now add a time in one action and keep credit use visible. Drag to compare.

Revised progress tracking at the equivalent step: one vertical step rail already carrying the chosen tutor's name and session type, with a slot selected in the active step, each completed value paired with an Edit link — Fig. 10 - Progress tracking, same point in both flows: tutor chosen, a slot just selected. V1 splits that state across a stepper, a slot list and a separate summary that still omits the tutor; the revised rail carries every chosen value, including the tutor, in one place with an Edit link. Drag to compare.

V1 progress tracking at the slot-selection step: a horizontal stepper at the top, a slot chosen from the full pattern list, and a separate timetable sidebar, with a booking summary that still omits the chosen tutor — Fig. 10 - Progress tracking, same point in both flows: tutor chosen, a slot just selected. V1 splits that state across a stepper, a slot list and a separate summary that still omits the tutor; the revised rail carries every chosen value, including the tutor, in one place with an Edit link. Drag to compare.

Stakeholder decision

Making the case for hiding the timetable

The PM was concerned that moving the timetable out of constant view would leave learners unsure of their schedule. The session recordings showed the opposite: the always-visible timetable was part of what learners were struggling to track. I walked the PM through those recordings and reframed the decision around task completion rather than information availability. We agreed to move the full timetable behind a View timetable action, lowering the default load while keeping it one tap away.

Revised slots screen with the timetable moved into an on-demand modal opened from View timetable — Fig. 11 - The timetable, now on demand. The docked V1 timetable from Fig. 6 moved behind a View timetable action, lowering the default load while keeping it one tap away.

06 · Shipped system

New and returning learners took different paths

The shipped flow used the learner's subject history to choose a starting point. A learner booking a new subject entered tutor discovery and compared eligible tutors. A learner returning to an existing subject saw previous tutors first and could move from that relationship into scheduling.

After choosing a tutor, the learner built a weekly Recurring schedule or selected individual dates in Flexi. The product kept credit use, selected times and progress visible through confirmation. Because the booking service saved Flexi sessions one at a time, confirmation reported the result of each session rather than a single combined outcome.

Confirmation closed with a receipt: the tutor, schedule and credits spent stayed on screen, with a calendar download and a link to the learner's session list, so nothing about what had just been booked required a lookup elsewhere.

Help stayed inside the task and escalated only as far as a learner needed, from lightweight self-help up to a live advisor. Their subject, tutor and schedule choices remained in place at every step, including through an Agent Assist conversation.

Start a new subject

For a new subject, learners compare tutors who can teach it, then choose a weekly Recurring schedule or individual Flexi dates.

Revised new-subject tutor selection screen with the same tutor cards now inside a step rail that carries every chosen value forward — Fig. 12 - The new-subject path. The tutor decision from V1, now inside the step rail that carries subject, tutor and credits forward.

Continue with a previous tutor

Returning learners see previous tutors first for an existing subject. They can schedule directly from the card or choose Find a new tutor. This skips tutor discovery for repeat bookings and starts them a step closer to the calendar.

Previous-tutor continuity screen with direct scheduling actions and a path to find a new tutor — Fig. 13 - Continuity for returning learners. They can schedule with a previous tutor or find someone new.

Get help inside the flow

Learners can read a numbered walkthrough or watch a short video for the current step, then escalate to an Agent Assist chat or callback only if they still need a person.

Contextual help modal offering two self-help options, a numbered walkthrough or a short video, before a route to an advisor — Fig. 14 - Contextual help. Two lightweight options, a numbered walkthrough or a short video, before it escalates to an advisor.

Agent Assist modal offering live chat or a callback while the learner remains in control — Fig. 15 - Agent Assist. Learners keep their booking choices while starting a chat or requesting a callback.

Final scheduling architecture

Two connected paths, one product model.

My coursesSubject and credit-hour context. An existing subject or a new learning need.

splits into two paths

New subject or new tutor

A guided flow supports discovery.

Step 1: Preferences
Step 2: Tutor match
Step 3: Slot select
Step 4: Confirm

Existing subject continuity

Continue from a previous tutor card.

Maria T.Last tutor
Daniel L.Previous
Choose a different tutor

both share

Shared guardrailsSubject context · credit-hour balance · Agent Assist fallback

Confirmed booking, then add to calendar

Fig. 16 - Final scheduling architecture. New subjects enter discovery; returning learners start with previous tutors.

Revised walkthroughs

0:00

Video 1 - Revised recurring: three matching schedules, an on-demand timetable, straight to confirmation. Compare with V1 in Fig. 8.

0:00

Video 2 - Revised flexi: direct multi-selection with visible credit use. Compare with V1 in Fig. 9.

Accessibility handoff

Because a Flexi booking could confirm or fail one slot at a time, I never signalled status with colour alone. Each state carried text and an icon so it read without relying on colour vision. The handoff also documented WCAG 2.1 AA contrast, keyboard order, control labels and modal focus.

07 · Rollout and learning

The team started small, then expanded access

The 12-week design and build ended in April 2022. The team then moved into a staged rollout, starting with one learner cohort before expanding access.

Learners created real sessions and spent prepaid credits through the redesigned flow. A failure could leave a learner with only part of a Flexi schedule or send them back to an advisor. The team wanted evidence from real bookings before giving the full learner base access.

We separated rollout learning from outcome measurement. The first two weeks focused on failures, support questions and unclear instructions. Adoption tracking began when the full learner base could use the flow.

Two-week trial cohort

We used a controlled-access setting, called a feature flag, to give one learner cohort the new flow. For two weeks, the team reviewed failed or partial bookings and the questions learners sent through Agent Assist. We fixed edge cases before expanding access.

Full rollout and review

We began adoption tracking when the full learner base received access. Each week, we reviewed self-scheduled bookings and Agent Assist transcripts, and refined confirmations, empty states and instructions as recurring questions appeared.

08 · Reflection

What I would carry into the next build

Research aligned the team as well as the design

Recordings, advisor interviews and synthesis gave product, engineering and operations one view of the problem. That shared evidence kept tradeoff conversations practical, as when the session recordings settled whether to hide the timetable.

Model the service before drawing the flow

I revisited screens whenever a change affected tutor history, credits or support. Next time I would map those relationships before prototyping and use the map to guide each flow.

Simplicity is a product tradeoff

Every control I removed changed what was default, what was on demand and what reassurance learners still needed. The work was making those tradeoffs explicit enough to cut cognitive load without cutting confidence.

Plan the human fallback as an operating model

I kept the advisor channel live through the trial but treated it as a stopgap. Next time I would define the in-flow support path and how it is staffed and retired before the build, not during it.

Instrument and test the full experience earlier

V1 testing focused on tutor choice and scheduling, so I would add a round covering continuity, help escalation and partial Flexi failures before the trial cohort. Operational outcomes also rested on advisor reports, so I would instrument handling time, escalation rate and time-to-book from launch rather than reconstruct them later.

The larger lesson

Interface redesign alone does not bridge behaviour change. In interviews, some of the most advisor-dependent learners were also long-standing ones, and a few could navigate the new screens but still would not commit without a person. Agent Assist gave them a way through the shift without leaving self-serve; its use fell after launch as self-scheduling rose, though we could not isolate its exact contribution. Any product that replaces a human-mediated workflow has to design the transition as well as the destination.

TutorComp: from advisor-led booking to self-serve scheduling