Scheduling workspace design for teacher matching

The scheduling workspace is the screen AR Labs designed for the first phase of the music school automation case study. It is a teacher-matching and scheduling interface for a music school owner: it gives a school owner one place to place a student with a travelling teacher, holding the information he previously joined from five tools and his own memory. This page covers what the screen shows, how a placement case moves through it, and the rule that decides how much of the school's data it holds. It is a design; it has not been built. The enquiry form fields guide covers the information the workspace's list depends on.

The design question

The question was how to give the owner one consistent view of scheduling without becoming one more tool on top of the many he already runs. The answer the design settled on: deep enough to retire his two scheduling documents, and not one field deeper.

Those two documents, a spreadsheet of pasted availability answers and a text document of each teacher's typed-out day, were not tools he chose. They exist because nothing in his platforms could hold the work that happens before a lesson is booked. A system that replaces them lowers his tool count. A system that sits beside them raises it.

Two options, one recommendation

Two shapes were considered.

• A read-only shortlist beside the existing documents. It answers "who could go with this teacher?", but the owner still copies each decision into his scheduling document by hand. The list and the document would drift apart the same way the spreadsheet and document drift today. It is the smallest build and it fails the design question.
• A workspace that absorbs the documents. On one screen, the owner picks a teacher, sees the students who could go with them, and places a student by putting them on that teacher's week. The draft lives in the system, and a what-if comparison is a real alternative rather than a copied block of text.

The design recommends the second. The placement decision stays the owner's; only the place where the draft is written changes.

What the screen shows

The screen has two halves that share one selection.

The list. Pick a teacher, and the workspace shows every unplaced or re-placeable student who could go with them: the right area, the right instrument and style, availability that overlaps the teacher's open days, and the drive time from the lesson before. Each row says why it fits or what needs checking. A student whose family has not returned an availability form is flagged, with the chase action beside it. The owner can also start from a student and see plausible teachers.

The week. The selected teacher's template week shows placed students, open slots and drafts, with drafts drawn differently from committed lessons. It is a repeating weekly pattern, not a calendar: no dates and no navigation, because the back-to-school round builds the pattern that runs all year.

How a placement case moves

stateDiagram-v2
  [*] --> Open
  Open --> WaitingOnForm: availability missing
  WaitingOnForm --> Open: form returned
  Open --> Draft: owner places on a teacher's week
  Draft --> Open: owner withdraws the draft
  Draft --> Proposed: messages approved and sent
  Proposed --> Draft: a party declines
  Proposed --> HandedOff: both parties agree
  HandedOff --> Booked: staff enter the booking and record it
  Booked --> [*]

Every case has an owner, a position and a reason it is waiting. A draft is never a booking. Until a person enters the booking in the lesson platform and records the evidence against the case, the case cannot be read as booked.

How far into the data

One rule decides what the workspace represents: an attribute is held only if the placement query filters on it or displays it. That sorts the school's data into three classes.

Class	What	Why
Owned outright	Student and teacher availability windows; drive times, kept after the first lookup; teacher constraints, style fit, family preferences and pending decisions; who owes a form; pipeline status in the school's own vocabulary; draft placements and alternatives	None of this has a home today, or it is lost one step after capture, so owning it duplicates nothing
Mirrored, read-only	Identity for every student: name, family, instrument, area, current teacher and slot, refreshed from the lesson platform's export	The join key. The lesson platform stays authoritative, and if the two disagree, the platform wins
Never held	Bookings, correspondence, billing, attendance, payroll	They have working homes. Reaching into them is what turns a workspace into another tool to reconcile

What retires and what stays

The availability spreadsheet retires, because its contents become structured fields. The scheduling document retires and becomes the template week. Map lookups at placement time leave the loop, because drive times are computed once and kept. The facts held only in memory get written down.

The lesson platform stays as the record of booked lessons, and committing a booking stays a human step. Gmail stays as the place where messages are written, approved and sent. The owner's own capture forms stay too; they are the integration point, not something to rebuild.

What would disprove it

The design names the evidence that would weaken it. It should be revised if the workspace becomes another place to reconcile instead of the place where work is resumed, if keeping it current costs staff more effort than it removes, if important actions cannot be performed or reflected there, or if the owner and administrator do not use it for the real cases chosen to test it.

The measure is direct. A narrated scheduling session recorded during discovery showed the owner switching between five surfaces roughly twice a minute. With the workspace, a placement should need two surfaces: the workspace, and the lesson platform at the moment of booking. Re-recording a session and counting switches tests the claim.