Music school enquiry and scheduling automation

This is an anonymised product-design case study from AR Labs, the AI engineering lab founded by Richard M. Thompson. The client is a regional in-home music school in the United States, where dozens of teachers travel to students' homes to teach hundreds of students. We ran discovery and design: we mapped how an enquiry becomes a teacher match, a trial lesson and a standing weekly slot, found where that work breaks, and designed a workflow automation system that keeps the owner in charge of every pairing decision. It is written for music school owners and anyone weighing automation of enquiries and scheduling in a small service business. This page presents that design. It does not describe a system in use; nothing described here has been built.

The situation

Two people run the school's operations: the owner, who handles first contact, phone calls and every placement decision, and an administrator, who carries out the back-office work those decisions create. The school's core jobs are to turn new enquiries into students and to keep existing students scheduled as families pause, return or change their availability. The heaviest scheduling happens at the start of each school year, when much of the roster has to be re-placed.

A hosted lesson-management platform is the official record of lessons, attendance and invoices, but it is a passive one, updated by hand after each decision is made elsewhere. The work itself runs through Gmail, where coloured labels mark pipeline stages, scheduled send times the re-contact of families and snooze serves as the follow-up timer, together with spreadsheets, documents, Google Maps and the owner's memory.

The operational problem is that no single place holds a placement case. To place one student, the owner joins student availability, teacher availability, home locations, drive times, instrument and style fit, and the state of each conversation, and he does that join in his head.

How discovery was run

We followed our client delivery framework, which runs an engagement through gated stages: Discover and Define (understanding and scope), then Prototype and Validate, then Build, Launch and Evolve. Each gate, a point the work cannot pass until a condition is met, needs the client's sign-off. This engagement covered Discover and Define.

Discovery combined interviews with recordings of real work. The owner and the administrator each recorded their screens during ordinary admin days, and later the owner recorded a back-to-school scheduling session while narrating his thinking aloud. We extracted keyframes, had vision-capable AI agents (language models run in a loop with tools) describe each run of frames against a fixed set of process tags, and merged the results into timestamped workflow logs. The discovery method page describes the method in full.

Source logs were never edited to fit a conclusion, which mattered when the narrated session overturned an earlier reading. The silent recordings had suggested that lead intake was the main pain. The narrated session showed that it was the scheduling join, and the design moved its centre accordingly.

The current-state workflow

The figure shows how a placement gets made today, in five columns from where information comes from to what is booked. Every arrow is information a person carries: no two of these tools exchange data directly, and the owner is the point where they meet. The numbered marks are the five places the workflow breaks.

What discovery found

The narrated session was broken into several dozen observable events across about half an hour of work. The findings below are operational facts drawn from that session and the earlier recordings.

• The work is the joining. The owner switched between five working surfaces roughly twice a minute, and that rate is a floor, because the frame sampling misses quick glances.
• State lives in memory. Close to half the events depended on a fact held only in the owner's head: a teacher's day constraints, a family's preference, a decision pending on a trial, a next action spoken and not written down. An interruption cost the whole thread, and the work could not be handed to the administrator.
• Structure is destroyed on arrival. The owner had built his own availability form, which captures structured answers. Those answers were pasted into a spreadsheet cell as a text block, read by eye and re-typed into the scheduling document, so the same availability existed in three hand-made copies.
• Computation is thrown away. Drive times between lessons were looked up in Maps, used once and stored nowhere.
• Timers carry no reason. Follow-ups lived as snoozed email threads and notes that recorded when to act but not why or what to say.
• Errors are caught by luck. The session included a booking nobody could account for, a location mistake caught only on a double-take, and a mislabelled what-if scenario. Nothing validated any of it.
• AI drafting adds a checking step. The owner already used an AI assistant to draft replies, but the assistant could not see his data, so each draft needed correcting by hand.

The admin-day recordings added more: leads arriving by both email and text and matched by eye, details from phone calls re-typed, paused families re-contacted one at a time, and cancellation credits kept in typed notes with nothing watching the refund deadline.

The diagnosis

Lists of pain points invite a patch for each one. We instead asked what missing piece of machinery makes each failure recur, and named every problem as an absence. Four basic principles of a working system turned out to be broken underneath them all.

• One source of truth. Each fact should live in one authoritative place. Here a lead lived in the inbox, in text messages, in a spreadsheet and in memory at once. Geoffrey Moore draws a distinction between systems of record and systems of engagement in his white paper Systems of Engagement and the Future of Enterprise IT (AIIM, 2011). Here the two had swapped: an email client, a system of engagement, had become the operating record.
• Data flows instead of being carried. Michael Hammer, in Reengineering Work: Don't Automate, Obliterate (Harvard Business Review, July–August 1990), argued that work split across departments, with hand-offs between them, breeds delay and error, and that automating the old steps does not cure it. Here two people were the only link between five tools.
• Repetitive work is automated, not scaled. Google's site reliability engineering practice calls hand-run, repetitive work that grows with volume "toil". Here every new student added the same manual load as the last.
• The business does not depend on its owner. Michael Gerber's The E-Myth makes the case that a business should run on its systems, not on the founder's presence. Here the knowledge lived in two heads. Larry Greiner, in Evolution and Revolution as Organizations Grow (Harvard Business Review, July–August 1972; reprinted 1998), calls the end of a young company's first phase of growth a crisis of leadership, and growth itself brings it on: the informal methods that built the school are what cannot carry its next stage.

The nine structural problems, and where the design answers each:

Problem, named as an absence	What it causes	Answered in
No structured lead record	The same enquiry arrives by email and text and is merged by eye	Phase 1 record; Phase 2 intake matching
No queryable pipeline	Nobody can ask who is waiting on what without reading threads	Phase 1
No validation on data entry	Location and booking mistakes caught only by chance	Phase 1
Routing and geography held nowhere	Drive times re-looked-up and areas held in memory	Phase 1
No follow-up engine	Re-contact runs on snoozed emails with no reason attached	Phase 2
No structured post-trial step	The family summary is rebuilt by hand after every trial	Phase 2
No record of multi-party agreement	Who has agreed to a proposed time is tracked in the inbox	Phase 2
No ledger for credits and cancellations	Credits live in typed notes; deadlines are watched by memory	Phase 3
People are the integration layer	Every decision is re-keyed into the lesson platform	Phase 3

The designed future workflow

The design does not automate the placement decision. Placement is where the owner's knowledge of families and teachers creates the school's value, so the system's job is to bring the right information to that decision and to carry out the routine work around it. The figure keeps the five columns of today's workflow, so the two can be read side by side: solid lines are information the system now carries, and diamonds are decisions a person makes.

A human stays in the decision at fixed points, and the design treats them as fixed:

• The owner picks every pairing. The workspace ranks candidates and shows why each fits or needs checking; it never chooses.
• The owner approves every message. Outbound messages are prepared as drafts in his own Gmail, and he reads, edits and sends them as he does today, so his Sent folder stays the record. Reviewing an AI draft before sending was already his habit; the design builds on it.
• Nothing family-facing is automatic. The school's policy rules out reminder messages to families, so the design has no bots that talk to families.
• A booking is a human act until the platform can take a validated write. Through the first two phases, a person enters each booking into the lesson platform and records it against the case. A draft placement can never be mistaken for a booking.
• Uncertainty is surfaced, not guessed. A form or email that cannot be matched to a family with confidence goes to a queue for staff, and staff can pause any automation and re-run anything that failed.
• Money changes need approval. Billing corrections and payroll figures are prepared for staff to approve; payroll submission stays with staff.

Which system owns what

A second record that disagrees with the first would recreate the problem the design exists to remove, so each system was given one job.

System	Its job in the design
Shared record (the CRM)	Leads, placement cases and their state, availability, constraints, scenarios, decisions and next actions
Scheduling workspace	The daily view over that record, and the place where placements are drafted
Gmail	The content of every message and the channel it is sent through; approval happens there
Lesson platform	Enrolled students and booked lessons; a booking counts only when a person has entered it there
Existing spreadsheet and document	Inputs to the first data load, retired once the record safely holds what they held

The system architecture

The design uses three parts: an off-the-shelf CRM that holds the records, a purpose-built scheduling workspace for the placement work no CRM provides, and a small integration service that moves information between them and the school's existing tools. A CRM (customer relationship management system) already provides families, students, teachers, custom fields, tasks, per-user access and export, and building those again would be pure cost.

This is a container diagram in the C4 style: containers are the parts that would be built or configured for the school, and external systems, drawn dashed, are the tools the school already uses. The dashed line to the lesson platform is the one connection left to the final phase.

The main design decisions and their reasons:

• Twenty as the record; integrate rather than patch. Twenty is an open-source CRM the school would host itself. Its licence is mostly the AGPLv3, with an added permission: an application that talks to Twenty only through its published APIs, webhooks and SDKs may be licensed on any terms. Editing Twenty's own source would bring source-sharing obligations and break the upgrade path, so every missing capability is added as configuration, a custom object, or code in our own layer.
• The workspace as a separate web application. Twenty can render custom components inside its own interface, but that route was unproven for a dense scheduling grid and exposed to frequent upstream changes. The design names the finding that would reverse this: if the owner will not switch between two applications mid-session, the workspace moves inside the CRM. The scheduling workspace design page covers the interface itself.
• A reconciling poll behind every webhook. Twenty's documentation logs a failed webhook delivery but describes no retry, so the design assumes a missed event is lost. Every part of the system that reacts to a record change also polls and reconciles, and the webhook only reduces delay.
• The record survives a platform change. Placement cases, reasons, open work and history live in the CRM, not the lesson platform, so they stay put if the school changes lesson platforms.
• Validate before commit. The published API reference for the candidate replacement platform lists a route to create a lesson but none to modify or delete one. A lesson the system writes could not be undone through the API, so every write path is checked before it commits.
• Gmail authorisation inside the school's own workspace. Creating the Google Cloud project inside the school's own Google Workspace, with an internal consent screen, avoids the restricted-scope verification that would otherwise apply. The design flags this as the largest avoidable risk in the email work, settled by one check with whoever administers the school's Google Workspace.

The phased delivery plan

The plan has three cumulative phases, each designed to leave the school with a working system it could run without us.

Phase	What it adds	How it starts
1. Data alignment and scheduling workspace	Families, students and teachers linked in one record; availability as usable facts; a workspace where staff start from a teacher or a student, see suitable matches, save a draft placement, resume it and hand it on for booking; logins, change history, backups and a manual fallback	A short prototype on one real teacher's week, ending in a written go or no-go recommendation
2. Automation before migration	Forms and email matched to the right case; follow-ups for availability and paused families that stop when someone replies; tracking of each party's agreement to a proposed time; staff control of the automation	Builds on Phase 1's record, which tells the automation who a reply belongs to and what is still missing
3. Migration and integration	A rehearsed migration that reconciles every record; then bookings, trials, cancellations, attendance and payroll preparation connected	A check of the candidate platform, after Phase 1 is in daily use, because the school must be able to operate the record before the platform underneath it changes

The plan is phased for three reasons. The current lesson platform has no public API, so everything that depends on writing bookings has to wait for a platform that does; the first two phases deliver value without it. Each phase raises operational exposure only as trust is earned, moving from copies of data with no live actions, to live staff data with drafts only, to a controlled pilot on real work. And the school can stop after any phase and keep what works, which answers the owner's questions about control, lock-in and whether the system works.

The design includes its own test: re-record a placement session with the workspace and count surface switches against the narrated session's baseline. If the count does not fall, the system has added work.

What we learned

• Ask for narration. Silent recordings hide the most important failure class, state held only in someone's memory. One narrated session was the strongest evidence in the engagement.
• Design around the judgement. In an owner-run service business the owner's judgement is often the product. The most useful automation gathers information for that decision and handles the follow-through after it.
• Build on the owner's own workarounds. His location tags and self-built form showed what he needed and are natural integration points, so the design keeps them.
• Retire a tool for every tool added. The workspace absorbs the two scheduling documents; a system beside them would add a tool and make the work worse.
• Trust before return on investment. The owner's questions were about control, proof and getting out, not hours saved. Approval in the inbox he already uses, a manual fallback and the right to stop after any phase answer them.
• Test the model with the owner early. Evidence analysis can run ahead of conversation. We now close evidence gathering at a stated point and ask the owner to correct the current-state model, recording the correction in his own words.

The music school scheduling guide turns this design into steps any school owner can follow. The guide to enquiry form fields for lesson matching covers what to ask families, and the guide to tutor matching and trial booking adapts the same approach for tutoring companies.