The page is loading. No inquiry, booking, or provider action is happening in the background.
A booking and studio-system demonstration for experience-led businesses, covering appointment capture and follow-up ownership with no implied booking-provider connection.
Capability proof, not a client engagement. No measured business outcome is claimed anywhere on this page.
An experience-led venue runs a tasting room and a private studio on the same site, with bookings that look identical in a shared inbox but mean very different things to two different hosts. The demonstration models one venue\u2019s path from a generic enquiry inbox to a per-host intake that distinguishes tasting and studio requests before either host is paged.
In the modelled venue, a studio booking for a private dinner lands in the same inbox as a casual tasting inquiry. The tasting host replies first — they happened to be at the keyboard. The studio guest waits until the studio host has logged on, and has already taken the calmer venue’s confirmation.
Every appointment request is captured with booking type, date, and party size. The intake names the host who owns that type and that night and starts a confirmation clock. Stale requests surface before the guest has found a calmer venue, so the team sees drift before the booking has been lost.
A visitor submits a tasting or studio appointment request, capturing their preferred date, party size, and the contact detail a host needs to confirm.
The submission is written to a durable record with consent and source. A follow-up is assigned to the named host who owns that night’s seating.
The assigned host receives the request with date, party size, and any stated occasion. They reply as the person who will seat the booking, not as "the studio".
A host dashboard shows every request by status. Anything past its confirmation window surfaces before the guest has booked elsewhere.
A focused form captures preferred date, party size, and any occasion detail. Anything else is opt-in, recorded with consent.
Every request is assigned to the host who owns that night’s seating. The dashboard shows who is responsible and when a confirmation is due.
Requests without a confirmation inside the target window are surfaced automatically. No booking opportunity is left waiting on an unowned inbox.
Submissions land in a structured record with date, party size, and occasion. The host replies with full context rather than half of a forwarded email.
A demonstration that pretends to be more than it is misleads the buyer. These limits are designed in, not missing features.
Until a real reservation system is connected, this is a request-only flow. No appointment is ever confirmed automatically — the host confirms it on a call.
The system never invents "there is another party of four looking at this slot" to push a confirmation. Hosts earn the next booking by replying properly to the one in front of them.
The intake does not subscribe the guest to anything they did not ask for. The host’s first reply is the first — and only — mandatory touch until the guest asks otherwise.
The intake pipeline is a designed demonstration; the booking platform, payment, and seating-plan integrations are not connected. There is no measurement of conversion lift, response-time improvement, or deposits recovered \u2014 only that the booking routing structure is sound.
No testimonial, metric, benchmark, or provider callback is attached to this work.