At a K-12 online learning provider, 2025 to now

Booking tutoring in the student's own clock

Students can ask for a one-to-one video tutoring session. My booking engine picks a tutor and a time that suits the student's own time zone, sends the calendar invitation within seconds, and hands anything it is unsure about to a staff member.

Role
Built the booking engine and its checks
Time
July 2026 to now
Tools
Airtable, JavaScript
Outcome
A straightforward request is typically booked, invitation sent, in about 13 seconds

Problem

I work at a K-12 online learning provider: schools in the US and abroad partner with us so their students can take courses online. One thing we offer is live tutoring. A student who is stuck can ask for a one-to-one video session with a tutor, at a time that suits them. Because students live in many time zones, “4 p.m.” means something different for each of them.

Requests used to come in through a form that only asked which weekdays a student was free, and staff matched them to tutors by hand. That was slow, and it was easy for a session to land at the wrong hour for the student.

Constraints

  • It had to run inside the tools the team already used: a shared spreadsheet-style database (Airtable) whose automations run JavaScript, plus a shared calendar. There was no separate test copy, so every change went straight to the real system.
  • Staff had to be able to see every decision the engine made, override it, and run it again.
  • A student must never be sent the wrong time. If the engine is not sure, it asks a person instead of guessing.

What I built

A booking engine. Each time a student sends a request, it works through it step by step:

  1. Work out the student’s time zone and which course they need help with.
  2. List the tutors who can teach that course.
  3. Pick a tutor and a free time within the next two weeks.
  4. Send a calendar invitation to the student and the tutor, showing the time in the student’s own clock.

If anything looks doubtful, such as an unknown course, a time outside the student’s day or a tutor without a meeting room, the engine stops and raises a “flag” with a plain reason. Nothing flagged is booked until a staff member approves it. That makes it safe to keep adding checks: if a check is wrong, the worst that happens is one extra review.

Two safety nets run alongside it. A monitor looks for double-booked tutors every 15 minutes and alerts staff; it never moves a session on its own. A hold stops any invitation that is missing the student.

The diagram in words
  1. Student, Request form, Requests, Engine, Any flag?
  2. Solid path: Invitation writer, Student on the invitation?, Shared calendar, then Student (Thursday 4:00 p.m.) and Tutor (Thursday 10:00 a.m.).
  3. Dashed path from Any flag?: Staff review, then "re-run" back to Engine.
  4. Dashed path from Student on the invitation?: "hold and alert" to Staff review.
  5. Double-booking monitor, under Shared calendar: "every 15 min, alert only" to Staff review.

How I proved it worked

  • Tested quietly first. It ran in “shadow mode”, recording what it would have booked without sending anything, then with test invitations that went to no one, before going live in July 2026.
  • Chose the booking window from real data. The starting setting allowed bookings two months ahead. In the first weeks, no student asked for a time more than a week ahead, so I set it to two weeks: more than double what was needed, and short enough that a mistyped year is caught at once. A request outside the window is flagged, never quietly moved to another date.
  • Checked the time-zone math twice. Requested times arrive written in one “home” time zone, and the engine converts them to the student’s zone. I wrote that conversion a second time, separately, and ran both over two months of real requests. They agreed on every request from outside the home zone.
  • Kept sessions inside the student’s day. Early on, a few sessions were booked before 9 a.m. in the student’s own clock, so I added a “student hours” rule: the engine finds a time within the student’s day, or flags the request and says why.

Outcome

  • A straightforward request is typically booked, invitation sent, in about 13 seconds.
  • More than 9 in 10 requests made from the button inside the learning app pass every check and are booked by these fixed rules; the rest wait for a staff member to review.
  • In daily use since August 2026.

What I would do next

  • Offer same-day sessions, sized from how many tutor hours are actually free.
  • Write clearer reasons on flagged requests, so a reviewer can act in one step.
  • Agree the time-zone hand-off with the team that runs the request form. If the form starts sending local times while the engine still converts them, every session outside the home zone would shift by hours, so both sides must change together.

The demo it pairs with

Scheduler sandbox. Ask for a session in your own time zone and watch the engine turn down times one by one, with its reasons. Switch on shadow mode to see a booking decided but not sent.

Scheduler sandbox

Made-up dataFull screen

A request comes in. The engine books a tutor and a time in the student's own clock, or sends it to a person with a plain reason. Today in the demo is Mon 5 Oct; bookings open for two weeks.

Up to three times, in your own clock

What the engine did

  1. Request in: Algebra 1, 2 preferred times, zone Halifax.
  2. Zone: Halifax, UTC-3 today. Every time is turned into UTC before it is compared.
  3. Tutors for Algebra 1, fewest bookings first: Kesi (4 booked), Delphine (5 booked), Galen (5 booked), Jory (5 booked).
  4. Time 1: Mon 12 Oct, 6:00 pm your time, stored as 2026-10-12T21:00Z.
  5. Kesi: not working then (2:30 am Tue in Kolkata).
  6. Delphine: not working then (10:00 pm Mon in Lisbon).
  7. Galen: already has a session then.
  8. Jory: not working then (3:00 pm Mon in Denver).
  9. Time 2: Tue 6 Oct, 10:00 am your time, stored as 2026-10-06T13:00Z.
  10. Kesi: not working then (6:30 pm Tue in Kolkata).
  11. Delphine: not working then (2:00 pm Tue in Lisbon).
  12. Galen: not working then (6:00 am Tue in Los Angeles).
  13. Jory is free. This is the booking.
  14. Invitation written twice: Tue 6 Oct, 10:00 am for you in Halifax, Tue 6 Oct, 7:00 am for Jory in Denver.

Times and tutors tried

Time 1 Mon 12 Oct, 6:00 pm, stored as 2026-10-12T21:00Z

Time 2 Tue 6 Oct, 10:00 am, stored as 2026-10-06T13:00Z

Choose a slot to see its reason.

Result

Booked, invitation sent

Algebra 1 with Jory, Room N1.

Your copy, Halifax

Tue 6 Oct, 10:00 am

UTC-3

Jory's copy, Denver

Tue 6 Oct, 7:00 am

UTC-6

Stored once as 2026-10-06T13:00Z. Each reader sees it in their own clock.