TutorComp: From Advisor-Led Booking to Self-Serve Scheduling

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.

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.

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.

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 was not a rough sketch. 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.

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 is what let 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.

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. Seeing the true commitment, dozens of sessions on named dates, before spending credits is what let learners commit to a long recurring booking with confidence.

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, matching the mental model learners already used to plan their week. Scheduling is the part testing would go on to sharpen.

Both modes, end to end, are easier to read in motion than in stills. The clips below walk each flow from choosing a tutor through to a booked schedule.

I recruited a separate group of 20 learners for moderated prototype sessions. The group included people new to TutorComp and returning learners. Each person completed four tasks across Recurring and Flexi, from choosing a tutor to reviewing a booking. I watched where they paused, what they expected after each action and when they asked for help.

Learners completed bookings on their own, which validated the self-serve model and the tutor decision. The friction was concentrated in scheduling and feedback. In Recurring, learners scanned a long list of weekly patterns while also checking a timetable. The volume of options slowed comparison.

In Flexi, several learners selected a time and moved to the next step because they expected the product to save the selection. They had missed a separate Add Selected button. Learners also searched between two areas to check progress and earlier choices. Some completed the interaction and still wanted an advisor to confirm the decision before they spent credits.

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, not just a message: 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.

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.