How to automate music school scheduling from enquiry to booked lesson

This guide from AR Labs shows the owner of a music school how to automate the path from a family's first enquiry to a booked weekly lesson: capturing the details a teacher match needs, shortlisting teachers, booking the trial lesson and moving the student into the schedule. It is written for schools with several teachers, especially those whose teachers travel to students' homes, and it assumes no technical background. It comes from detailed discovery and design work we carried out for a regional in-home music school, checked against public material from music and tutoring operators in the UK, the United States and Australia. That work is a design; the case study describes it.

The method keeps the owner's judgement and removes the carrying, chasing and re-typing around it. At every step, try the simplest fix first: a written rule, then a setting in the software you already pay for, and only then something new. It applies our general method for mapping a business process before automating it to music schools.

The path this guide works towards fits in one picture: eight stops from enquiry to booked lesson, with forms and records carrying the details and four decisions, marked with flags, left to a person. Step 1 starts from the opposite end, with the path as it runs today.

Step 1: Map the path from enquiry to first lesson as it runs today

What to do. Take three recent students: one new enquiry, one existing student who changed teacher, and one student who left after a trial. For each, write down every step from first contact to first regular lesson, which tool or person held the information at that step, and where it was typed in again. Better still, record your screen while you do a normal stretch of placement work, and say aloud what you are thinking and why. Your computer can already do this: on a Mac, press Shift, Command and 5 together; on Windows, the Snipping Tool has a record option. Send long recordings as files rather than through a messaging app, which shrinks video until on-screen text is unreadable.

Why. Owners describe their process as they think it runs. A recording shows how it does run, and talking aloud captures the reasons that silent footage misses: the facts you hold only in your head.

Example. When we designed this for a regional in-home music school, the owner's email inbox turned out to be the real system: labels marked each family's stage, snoozed threads acted as follow-up timers, and the lesson platform was updated afterwards. A typical flow at schools like this looks like the diagram below. Every step is done by a person, and the same details are typed again at four of them.

flowchart TD
  E["Enquiry arrives: email, text, phone or web form"] --> R["Owner replies by hand, asking for availability"]
  R --> C["Phone call: age, level, goals, personality"]
  C --> N["Notes typed into a spreadsheet, the inbox, or kept in memory"]
  N --> J["Owner compares availability, teachers' weeks, a map and the notes, by eye"]
  J --> T["Owner emails a teacher about a trial, retyping the student's details"]
  T --> B["Trial typed into the lesson platform"]
  B --> F["Teacher reports back; owner writes the family a summary"]
  F --> S["Weekly lesson typed into the platform again"]

• Three real cases written out, step by step
• Every tool and person that holds information is listed
• At least one narrated recording of real placement work

Step 2: Find where time and enquiries are lost

What to do. Go through your map with a highlighter and mark six kinds of loss:

1. Information typed twice, such as a phone number copied from an email into a spreadsheet.
2. Facts that exist only in someone's memory, such as which day a teacher will not work.
3. Waits where nobody records who owes a reply.
4. Calculations, such as drive times, that are worked out and then thrown away.
5. Reminders that say when to act but not why, such as a snoozed email you have to reread to remember its purpose.
6. Checks nobody makes, such as whether a student's area matches the teacher's.

Then count how many students are currently waiting on something, and on what.

Why. The losses tell you what to fix first, and they are often not where you expect.

Example. In the school we designed for, the most work during the back-to-school period went into re-placing existing students, not new enquiries. Teachers lost days and families changed schedules, and each change set off the same placement work as a new family. The owner had also built his own availability form, which collected clean, structured answers. Those answers then arrived in a spreadsheet as one block of text, were read by eye and re-typed into a scheduling document. The structure existed for one step and was then destroyed.

• Re-typing points marked on the map
• Memory-only facts listed (teacher preferences, family situations, pending decisions)
• Reminders without a reason, and checks nobody makes, marked
• A count of students waiting, grouped by what they are waiting for
• New enquiries and re-placements counted separately

Step 3: Decide what must stay a human decision

What to do. Write two lists. The first holds the judgements that make your school what it is: which teacher suits which child, when to bend a family's preference, how to handle an unusual case. The second holds the clerical work around those judgements: logging the enquiry, chasing a missing form, looking up a drive time, drafting the confirmation, entering the booking.

Why. Many schools sell personal matching. Families choose them because someone learns about the student before choosing a teacher, and matching on availability alone would remove the thing they pay for. Automate the second list and protect the first.

Example. The school's owner kept the first phone call with every family, because that is where he learns about the child. The design ranked candidate teachers but never chose one, prepared every message as a draft for his approval, and sent nothing to families automatically, in line with the school's policy of sending no lesson reminders.

• A written list of decisions that stay with a person
• A written list of clerical tasks around them
• A rule for which messages may go out without approval (possibly none)
• Your school's existing policies (reminders, cancellations) checked against both lists

Step 4: Capture complete enquiry information once

What to do. Replace "tell us about your needs" with a form that asks for what a match needs: instrument, the student's age and level, goals and musical style, the area or postcode, several weekly availability windows, a preferred start date, and any constraints. Make every answer land in its own field in one record per family and student, not as a paragraph in a spreadsheet cell or an email. Add the notes from your first phone call to the same record. The enquiry form fields reference lists each field and why it matters.

Why. Every missing field becomes a follow-up message, and every free-text answer becomes something a person has to read and re-type.

Example. Most music school software can do part of this already, so start there. My Music Staff's sign-up form accepts custom fields, and the vendor's announcement says the answers are saved to the Notes section of the student's profile (vendor post); check whether you can sort or filter on them. Teachworks offers a website inquiry form that delivers enquiries into Teachworks and by email, and custom enrolment forms that create new profiles (add-ons). TutorCruncher's website enquiry form creates a client profile and can include your own custom fields (help article). Submit a test enquiry to your own form and look at where each answer ends up before you build anything.

• A test enquiry submitted, and where each answer landed written down
• Form asks for every field a match needs
• Availability collected as several weekly windows, not one preferred time
• Each answer lands in its own field, in one record per family and student
• An enquiry from the same family by email and by text ends up in one record
• Phone-call notes stored on the same record

Step 5: Hold teacher availability and travel zones as data

What to do. Collect teacher availability with the same kind of form you send families, and keep it as weekly windows. Record for each teacher the instruments, styles and levels they teach, the areas they cover, day constraints and how many more students they can take. Give every student an area tag. For in-home lessons, store the drive time between homes once you have looked it up, and write down your rule for gaps between lessons.

Why. A match compares two sides. If only the family's side is recorded, the teacher's side stays in the owner's head, and the owner cannot hand the work to anyone else.

Example. The owner had already tagged every student with a zone in his lesson platform, and those tags were the most useful structure in his whole system: he filtered by area constantly. His spacing rule was drive time plus a five-minute buffer, rounded up to an even minute. If a lesson ends at 4:30 and the next home is 13 minutes away, the next lesson starts at 4:50. A rule written down like that can be applied by software; a rule held in someone's head cannot.

• Teacher availability collected by form and stored as windows
• Instruments, styles, levels, areas and capacity recorded per teacher
• Every student has an area tag
• Drive times kept after the first lookup
• The gap rule between home lessons written down

Step 6: Produce a shortlist of matches for a person to confirm

What to do. Turn the question you answer by hand into a filter. Typically it is: which unplaced students are in this teacher's area, want an instrument and style this teacher teaches, and have availability that overlaps this teacher's open days, in order of distance from the teacher's other students, and which of them still owe us a form or a reply. Show the result as a list beside the teacher's week, with a reason against each candidate. A person picks.

You can try this on Monday with a spreadsheet. Put one row per waiting student, with columns for area, instrument, style, the days they can do and whether their form is in. Turn on the spreadsheet's filter buttons, then for one teacher filter to their areas, instruments and open days. The rows left are your shortlist. If that already saves time, you have proved the idea before paying for anything.

Why. Without a shortlist, the owner switches between the spreadsheet, the schedule, the lesson platform, a map and the inbox for every decision. With one, the decision stays and the gathering disappears.

Example. The design for the school put a teacher's repeating week beside the ranked candidates, with drafts drawn differently from booked lessons; the scheduling workspace design describes it. Off-the-shelf tools go part of the way: TutorCruncher compares the skills a job needs with each tutor's skills, lets staff narrow which tutors are told about the job by a radius around the job's location and by labels, and tutors then apply (help article). The matching decides who hears about the job, not who gets it.

• Your matching question written as a filter
• The filter tried once, by hand or in a spreadsheet, for one real teacher
• Candidates shown with the reason each one fits or needs checking
• Missing forms and replies flagged in the list
• Draft placements visibly different from booked lessons
• A person confirms every match

Step 7: Book the trial and move the confirmed lesson into the schedule

What to do. Turn the trial into a checklist that runs from the record: brief the teacher with the student's details and lesson instructions, get the teacher's confirmation, book the trial, collect the teacher's trial report, and send the family a summary and next step. After the family says yes, enter the weekly lesson in your lesson platform and mark the case as booked.

Why. Each hand-off in a trial is a point where a family can be forgotten, and each message re-types the same student details.

Example. The school already had a good trial sequence: a teacher briefing with a report template, the teacher's confirmation, and a next-day report that became the family's summary. The design kept it, drafted each message from the record, and left the booking as a human step until the platform could accept a checked automatic write. Before automating bookings, check what your platform's API (its connection for other software) can do: some can create a lesson but cannot change or cancel one, so a software mistake has to be fixed by hand.

• Trial steps written as a checklist attached to each student
• Teacher briefing and family summary drafted from the record
• Teacher confirmation recorded, not just received
• Booking entered in the lesson platform and marked on the record
• Your platform's ability to create, change and cancel lessons checked

Step 8: Handle changes, rematches and the seasonal surge

What to do. Treat every change as a new placement case with a reason: a teacher losing a day, a family asking for a different teacher, a student returning after a pause. For the start of the school year, send availability forms to every family and teacher at once, track who has replied, and have reminders drafted for the rest, each carrying its reason and what to say, for a person to approve. Draft the new timetable as alternatives before committing any of it.

Why. During the seasonal surge, a schedule often cannot be finished piece by piece. Booking one student into a slot can block a slot someone else needed, so the owner waits until nearly everyone has replied. Anything that gets the replies in sooner moves the whole season.

Example. At the school, the list of teachers who had not returned their availability was kept in memory and passed on aloud, and follow-ups were snoozed emails that recorded when to act but not why. The design added one queue of outstanding forms for families and teachers, with reminders drafted for approval that stop once someone replies.

• Changes and transfers logged as cases with reasons
• One list of who still owes a form, families and teachers together
• Reminders stop automatically on reply
• Alternative timetables compared before anything is booked

Step 9: Measure enquiry-to-trial and trial-to-enrolment

What to do. From the record, report the time from enquiry to first reply, from enquiry to trial and from trial to enrolment; the share of enquiries that arrive with every matching field complete; the number of follow-ups per placement; stalled cases; and rematches. Take a baseline before you change anything.

Why. Without a baseline, nobody can tell whether a change helped, or whether the problem is response speed, missing information or teacher supply.

Example. The design for the school included its own test: record another placement session with the new system and count how often the owner has to switch between tools, against the count from the original narrated session. If the number does not fall, the system has added work.

• Baseline taken before any change
• Enquiry-to-trial and trial-to-enrolment reported from the record
• Completeness of enquiries tracked
• One tool-switching count before and after

Step 10: Roll out in phases, starting with the smallest step that removes real work

What to do. Start where structure is lost: get enquiry and availability answers into one record and retire the spreadsheet they used to land in. Add the shortlist next, then reminders and drafted messages, and connect bookings to the lesson platform last. Retire one old tool for every new one, and keep a manual fallback so the school runs if the system is switched off.

Why. Each phase should leave something that works on its own, so you can stop after any phase. A new system beside the old spreadsheet is one more place to update, which is why each new tool retires an old one. Bookings come last because families are billed from them.

The diagram shows the finished flow. Rectangles are work the system does; diamonds are decisions a person makes.

flowchart TD
  E["Family fills in the enquiry form: one record per family"] --> Q["System drafts a reminder if details are missing"]
  Q --> L["System lists suitable teachers, with a reason for each"]
  L --> H1{"Owner picks the teacher"}
  H1 --> D["System drafts the messages to family and teacher"]
  D --> H2{"Owner reads, edits and sends each message"}
  H2 --> T["System tracks the trial and both parties' agreement"]
  T --> H3{"Staff enter the booking in the lesson platform"}
  H3 --> P["Weekly lesson booked; the record shows it"]

In the design for the school, the first two decisions stay with a person in every phase. The booking stays a human step until the final phase, when checked automatic bookings were planned.

• First phase removes a real re-typing step
• One old tool retired for each new one
• A manual fallback exists for every automated step
• Booking automation planned last

Choosing how far to go at each stage

Off-the-shelf software already covers much of this, and for many schools configuring it is the whole answer. Teachworks has a lesson requests add-on in which families with an account can see the availability of their teachers and request a lesson, which staff accept or decline (lesson requests), and a website booking plugin that books against the availability set on each teacher's profile (booking plugin). My Music Staff lets new students book directly from teacher availability on your website, with a custom price for the first lesson so you can offer a free or discounted trial (vendor post). TutorCruncher has a client pipeline with stages you can rename, ending with each client marked won or lost (help article). If one of these covers your path from enquiry to booking, set it up, run a full season on it, and only then decide whether anything else is needed.

The work these products leave to people is mostly the judgement around fit, travel between consecutive home lessons, chasing missing availability, and comparing alternative timetables in the seasonal rebuild. We did not find features for drive time between consecutive home lessons or for comparing draft timetables in the public documentation of the products above, though that may change, so ask your vendor.

Read the table from left to right: each column costs more than the one before, so move right only when the column to its left has stopped being enough. AI belongs late on this ladder: an assistant that cannot see your records writes drafts that need correcting, so give it the record first, or use a template.

Stage	Do it by hand	Configure an existing tool	Connect tools together	Build custom
Enquiry capture	Phone call and notes	Your platform's sign-up or enquiry form, with custom fields	A form tool sends each answer into your records through a linking service such as Zapier	Only if you need branching questions your tools cannot ask
Teacher availability	Ask each teacher	Availability set on teacher profiles	Teacher form writes windows into the record	Rarely needed
Shortlist	Owner's memory and a map	Filters by instrument, area and status	A spreadsheet filter across data exported from your platform	A screen showing the teacher's week beside ranked candidates
Follow-ups	Snoozed emails	Tasks and pipeline stages	Reminders triggered when a form is missing	Reminders that carry their reason and stop on reply
Trial and booking	Staff enter it	Booking forms and trial pricing	Trial completion triggers the family summary draft	Checked write into the platform, last

About this guide

AR Labs offers this kind of discovery and design work to small service businesses, starting from recordings of real work and keeping the owner's decisions with the owner. The method follows the discovery stage of our client delivery framework. More about us is on the about page.