From zero to ~16% trial booking: designing and shipping live-session booking inside the app

SpeakX had self-serve lessons. It didn't have a human on the other side.

SpeakX's core product was AI-led English practice: lessons, drills, speaking exercises. It worked well for habit formation but plateaued on the harder problem: getting users to actually speak to another human, which is what drives confidence and retention. A small live-ops team had been running 1:1 and small-group sessions over external tools, but there was no way to discover or book those sessions inside the app.

The hypothesis going in was that a live human session, surfaced at the right moment, would become both an engagement surface (a reason to come back) and a monetisation surface (a paid product post-trial). The first job was just to find out whether trial users, the cohort with the loosest commitment, would book one at all if we made it possible.

There was no baseline. The Control bucket didn't have the feature at all.

This is where I want to be honest. The A/B test wasn't measuring "does this design beat that design". It was measuring "does this surface, which doesn't exist today, get used at all." Control was the world without booking. A was the world with it. So the lift number on its own is meaningless; what matters is the absolute rate and whether downstream behaviour held up.

On Jul 23, of 1,303 A-bucket trial users, 22.4% loaded the booking page, 15.8% completed a booking, and 2.4% used the "Watch Now" jump-in option. On Jul 24, the next 619 users came in at 20.0% load and 12.6% booking. The companion engagement test confirmed the part I cared most about: D1/D2 active-exercise rates stayed roughly flat between A and Control. Booking didn't pull users away from lessons; it added a layer on top.

The hard constraint wasn't design. It was tutor supply.

• Live sessions are capacity-bound. Unlike an AI lesson which scales infinitely, a live session needs a tutor on the other end at a specific time. We had a small roster and finite hours. The booking design had to pace demand, not just maximise it: show only available slots, never let a user pick a time we couldn't fulfil.
• Trial users are the lowest-commitment cohort. If we asked too much (long onboarding, payment up front, verification), they'd bounce. Booking had to feel as light as scheduling a haircut.
• No-shows would burn tutor goodwill. A booked-but-empty slot costs a tutor as much as a booked-and-attended one. Confirmation and reminder design had to do real work.
• Cross-platform parity. Android and iOS users had to land at the same booking outcome. No deep-link or platform-specific shortcuts.

Users think in days of their week. Supply is structured around tutor calendars. The design had to translate.

I shadowed [X] live-ops booking conversations being handled manually over chat. The pattern was identical every time: the user opened with a day, not a time. "Can I do something on Saturday?" Not "What's the next slot?" The supply side, by contrast, was built around tutor availability windows: a tutor picks Tuesday 6–9pm, the system surfaces that block.

Then I ran a quick desk study of how users in adjacent categories (fitness classes, salon apps, doctor consults) were booking. The winners almost always led with a date strip and treated time slots as the second decision, not the first. The losers led with a list of providers or sessions and forced the user to filter their way to a day.

The reframe. Don't show users a list of sessions sorted by tutor availability. Show them a calendar, let them pick a day, then surface only the slots that are still open on that day. Hide the supply structure behind an interface shaped like the user's mental model.

A calendar shaped like a week, supply hidden underneath, one confirmation that did real work.

The shipped flow was three screens:

• An entry surface inside the home tab: a card titled "Practise live with a tutor" with the next open day pre-loaded as a preview, so users didn't have to imagine what was on the other side of the tap.
• The booking screen itself: date strip, slot list for the selected date, slot cards showing tutor name, session focus (free conversation, interview prep, etc.), and duration. Greyed-out days carried a small "fully booked" label so empty states didn't feel like errors.
• A confirmation modal: booked time, "add to calendar" link, and a countdown that turned into a "Join now" button when the session was 15 minutes out.

The trade-off I accepted explicitly: capacity. We knew demand might outstrip supply, especially in evening slots. The calendar pattern paced bookings honestly (if a day filled up, it filled up) but it meant some users would see "fully booked" and walk away. I argued this was the right failure mode: a "fully booked" state is honest and trains expectations, while a no-show on a slot we couldn't actually staff would have burned the tutor relationship and the user's trust at the same time. We tracked "fully booked" impressions as a signal to grow the tutor roster, not as a UX bug to design around.

What shipped, what got cut, and what made it to v2.

What shipped in v1. The calendar-first booking screen, slot list with availability logic, confirmation modal with countdown, and "Watch Now" jump-in for sessions within 15 minutes. Push and in-app reminders fired at T-60min and T-10min. Android and iOS launched together.

What didn't. Tutor profiles with bios and ratings were descoped. The live-ops team didn't have curated copy ready, and rough auto-generated bios would have hurt trust more than helped. Recurring bookings (book the same slot every week) slipped to v2; the data model supported it but the UI and edge cases (cancellation, re-scheduling, partial recurrence) were a separate design problem.

v2 targets. Tutor profiles, recurring slots, post-session feedback feeding tutor ranking, and a "remind me when this tutor opens new slots" subscription for users who wanted a specific tutor.

What I'd do differently. What I'll carry forward.

What I'd do differently. I'd have shipped tutor profiles in v1, even rough ones. The single most-asked question in moderated testing was "who is this person?", and we shipped without an answer. The booking rate held up anyway, but I think it would have been higher, and I think the no-show rate would have been lower, if users had felt they were booking a person rather than a slot.

What I underestimated. How much pacing the design itself was doing. I'd thought of "show only open slots" as a UX nicety; it turned out to be the load-balancer for tutor capacity. When demand spiked on Jul 23, the calendar absorbed it gracefully: full days went grey, users moved to adjacent days, no error states fired. The design was operating as a supply mechanism without anyone configuring it as one.

What I'll carry forward. When you're shipping a 0→1 surface, the only honest framing is the absolute number, not a lift. ~16% of trial users booking a live human session in a category they'd entered for AI lessons was a real signal, not because it beat a baseline, but because it was a behaviour the product had never produced before. Lift stories are cleaner. Launch stories are truer.