Hospitality Multi-Tenant SaaS

The staff member is the synchronisation layer

Restaurant bookings look like a simple scheduling problem and are not, because the resource being booked is physical and finite. A table exists once. Requests for it arrive by phone, through the website, and from people standing at the door, and those channels have no knowledge of each other.

In most restaurants the thing reconciling them is a person. Someone holds the book, remembers that a table was promised on a call ten minutes ago, and mentally reserves it while taking the next enquiry. That is the manual workload — not the act of writing a booking down, but continuously being the synchronisation mechanism between channels that cannot see one another.

It is also work that fails in a particularly unforgiving way. A double-booked table is not a conflict a system can retry its way out of; it is two parties arriving at the door expecting the same seat, resolved in person, at the worst possible moment. Restaurants live and die on bookings, and that phrase is not a figure of speech about revenue — it is about the fact that a booking mistake is experienced by a customer directly, in public.

What "dependable in real time" actually demands

Real-time updates here are not a matter of polish. Several staff on several devices are looking at the same floor at the same time, and the moment one view is stale, someone seats or promises a table that is no longer free. A page-refresh model is a synchronisation strategy that works precisely when nothing is happening and fails during service, which is the only period that matters.

Isolation is the second hard requirement, and hospitality sharpens it. The tenants sharing this deployment are restaurants — often competitors in the same market — and the data involved is covers, customers, and takings. One tenant seeing another's bookings is not a privacy inconvenience, it is commercially disqualifying, so isolation has to be structural rather than a filter someone remembers to apply.

The third constraint is who operates it. This front end is used by restaurant staff during service, on a busy floor, under time pressure, by people whose job is hospitality rather than software. That rules out interfaces that assume a calm user with time to read, and it means the automation has to be trustworthy enough that nobody feels the need to keep a paper copy alongside it — because the moment a parallel paper book appears, the synchronisation problem is back and now there are two sources of truth.

How it is put together

WebSocket-driven updates are the answer to the stale-view problem, and the reason is directional. Polling means every client repeatedly asks whether anything changed, which is both wasteful and always slightly late. A push model means the source of truth announces the change and every connected device reflects it — so the floor plan one staff member is looking at is the same floor plan everyone else is looking at, without anyone refreshing anything.

Multi-tenancy for five restaurants on a single deployment is what makes the economics work for businesses of this size, and it puts the isolation burden on the architecture. The detail worth naming is that a real-time layer is a second place isolation must be enforced, and it is the one that gets forgotten: database-level scoping does not reach a WebSocket channel. A subscription has to be scoped to its tenant explicitly, or a correctly isolated database is undone by a broadcast that reaches the wrong client.

The AI-assisted booking automation is deliberately described as assisted. The useful design here is not a system that decides everything, but one that handles the routine majority and hands the rest to a person — the unusual request, the large party, the case where judgment is genuinely required. Automation that cannot escalate becomes something staff work around, which returns the workload it was meant to remove.

Stripe handles payments in the same place the booking lives, which matters because a booking and its payment describing different states is the kind of discrepancy that surfaces at the table, in front of the guest. Keeping both on the platform means the record of what was reserved and what was paid cannot drift apart.

What the numbers mean

An 80% reduction in manual workload is the figure that describes the product working, and its value depends entirely on where that time was being spent. This was not back-office administration — it was front-of-house attention during service, taken by phone calls and by holding the booking state in someone's head. Time returned there does not become spare capacity; it becomes attention available for the guests who are actually in the room.

400 bookings automated per month is the volume that reduction is measured against, and it is also the trust threshold. A staff member abandons a parallel paper book only once the system has handled enough real bookings correctly to have earned it, and that number represents the automation being relied upon rather than merely available.

Five restaurants from a single deployment is the tenancy working as intended — one codebase, five isolated operations, and no tenant with any reason to think about the others. The measure of success for that part of the architecture is that it never becomes visible to anyone using it.