Booking a 780-seat theatre without the email thread
The problem
Booking the school theatre used to be an email thread. Someone asked whether a date was free, the theatre manager checked a calendar that did not show load-in and load-out time, and an answer came back when it came back.
Nothing lived in one place. Double bookings happened. What had actually been agreed, and what equipment had been promised, survived only in whichever inbox still had the thread. When the manager was away, the school had no way to see the state of its own largest room.
The theatre seats 780 and nearly every division uses it: concerts, assemblies, drama, admissions events, commencement rehearsals. A space that contested needs a system rather than a habit.
Four decisions that shaped it
The interesting part of this build was not the code. It was deciding who should be able to see what, who should do which work, and what the system should refuse to do.
This looks like a limitation and it is deliberate. A raw calendar hides the load-in and load-out either side of an event, so a slot that shows as free often is not. Exposing it would have made the flow feel faster while producing worse bookings. Availability decisions stay with the person who knows what a two-hour concert actually costs in stage time.
Minimum lead time, venue capacity, the weekly digest schedule, the audience-facing row labels, and whether seat one sits on the audience's left or the performer's left. All of it is editable by the theatre manager, takes effect immediately, and needs no developer. A system the operator cannot tune is a system they depend on someone else for.
The person running the event knows which group sits where. Routing that through the manager would have created a bottleneck and lost information on the way. So the requester paints their groups onto a faithful grid of the house, and the printed row-end signs generate themselves and arrive by email. The work moved to the person with the knowledge, and it cost them less than the email thread did.
Approvals, rejections, cancellations, ad-hoc bookings, settings changes, seating finalised. Each one attributed and timestamped. Not because anyone expected disputes, but because a shared resource with no record is where disputes come from.
The hard part of an operations tool is not building it. It is deciding what it should refuse to do.
See it from both sides
The same system, seen by a teacher requesting the space and by the manager running it. Switch roles and move between screens.
The same system seen from both sides. A teacher requests the space and manages their own seating; the theatre manager approves, oversees the calendar, and tunes the rules without touching code. Switch roles to compare.
A working rebuild of the live interface. Every booking shown here is invented: the deployed system carries real staff requests and event details, so none of its data appears on this page.
Request the FAC Theatre
signed in as a staff memberBookings inside 14 days' notice are arranged directly with the theatre manager. Everything else comes through here.
The requester supplies event time only. Load-in and load-out buffers are added by the manager, so the calendar stays truthful.
My requests
A teacher sees only their own bookings. No calendar browsing, because a raw calendar hides load-in time and reads as available when it is not.
Seating: Spring Concert
Placed 32 more seats for Elementary. 96 of 252 done, 156 still to place. Click another seat to continue.
Remaining 156
Click a seat and it fills contiguously up to the group size, stopping at aisles and row ends. Printed signs generate one per block.
Theatre dashboard
2 need attention
1 pending approval
1 unfinalised seating
Every state change is written to an audit log. The weekly digest goes out Monday at 08:00.
Review booking request
manager onlyOpened from the notification email. The role is checked twice, once on load and again on submit, so a forwarded link cannot approve anything.
All bookings
Everything on the calendar from 90 days back to a year ahead, cancellations included, because the record of what was cancelled matters too.
Settings
changes apply immediatelyThe rules of the system live here, not in the code. Nothing on this page needs a developer.
- Space and capacity
- FAC Theatre · 780 seats
- Minimum lead time
- 14 daysHow far ahead a teacher must book before the request needs a conversation instead.
- Weekly digest
- Mondays, 08:00Summary of the week ahead and anything still needing a decision.
- Allowed domain
- School Workspace domain only
- Row labels
- Front 1 to 6 · Main 7 to 22Audience-facing labels printed onto the seating signs.
- Seat numbering
- House leftSeat 1 on the audience's left, or switch to the performer's left.
Handing the settings to the person who runs the space is the difference between a tool they own and a tool they depend on someone else for.
What is not built yet
Amendments and cancellations still go through the manager by email. A requester who needs to move a date replies to the approval email and the manager updates it on her side.
That is a phase boundary rather than an oversight. Approving requests and laying out seating were the two things that actually hurt, so they shipped first and the rest waited. In-app amendments are the next phase. I would rather ship the painful half and say so than hold everything back for a complete version nobody is using yet.
Where else this fits
None of this is really about theatres. Every school has a small number of contested shared resources, and most of them are run on memory, goodwill, and a thread. A gym, a maker space, a bus, a set of iPad carts, a room with the good projector in it.
The pattern transfers unchanged: one source of truth, a named person who can approve, the operating rules owned by the operator rather than buried in code, the work pushed to whoever holds the knowledge, and a record of who decided what. The theatre was simply the version of the problem that was costing the most.