Bookings, resources and private events

Bookings owns availability, customer reservations and operational visits. Site and Space identity belongs to shared Places; Bookings supplies the inventory and commercial policy used to reserve them.

Operational screens and service workflow#

The workspace at /app/[orgSlug]/bookings opens on the current trading date. Running order, Timeline and Table plan are three views of the same Bookings and allocations. Filter by venue, area, status, guest, resource or note. All venues remains a complete projection; it does not require choosing one venue.

1. Select the service date and venue/area filter, then inspect booking, cover and held counts and the expandable Service brief.
2. Use Add booking to choose date/time, party size, available resources or a staged journey, then enter guest details and notes.
3. Open a booking to review its whole itinerary, resource allocations, service state, payments, pre-order, communications and audit evidence.
4. During service, progress the explicit states: arrived, seated, in service and departed. No-show remains a separate service choice.
5. For a move, preview the new resource/time in the timeline or table plan and confirm the named old and new allocation. A drag preview does not save itself.

Closed hours, closeouts and overlaps block invalid moves. The final server check also protects against availability changing while a form is open. Journey replanning searches whole replacements, preserves the supported commercial constraints and replaces allocations atomically. Cancellation and paid refund remain distinct actions with separate permissions.

The service brief separates current booking states and manager checks from a saved arrival forecast. The business's trading-day boundary determines the operating day; actual calendar dates and local times remain visible for overnight bookings and arrival estimates.

Configure Spaces, Resources, joins and Booking options#

The Space's Resources editor is the main inventory surface, also reachable through Bookings Settings → venue setup. Nested Areas organise resources and provide inherited defaults. A Resource is the thing occupied; a Booking option is the published experience or activity a customer chooses.

Parent defaults affect linked resources; Override creates a local setting and Use inherited restores the parent link. Applying defaults to existing resources is explicit. Changing a price does not rewrite a held or confirmed Order. Adding a duration-specific price does not make that duration bookable. Setup/cleanup time blocks availability but is not silently charged as occupancy. Creating resources does not publish a Booking option.

Publish a customer booking widget#

1. Open Widgets, choose a Site, name the widget and select the starting Spaces and published Booking options.
2. If customers may add activities, set the separate follow-on allowlist. Configure eligible extras/shared add-ons, payment collection and customer copy.
3. Save and review the published preview, then publish the widget version.
4. Copy the install snippet or direct link. Replacing the existing venue booking link is a separate explicit action.
5. Test the intended public journey using the appropriate mode and seller setup.

The guided customer journey is: choose party/date and activity, review available options, build any permitted follow-on parts, select optional add-ons, verify email, review the quote and then reserve/pay. The current public composition supports one venue, lead customer, seller/currency context and up to six sequential parts; cross-seller add-ons use their separate card coordinator. Joins or eligible multi-resource activities reserve their actual members together. One unavailable part prevents the whole visit from reserving.

Quotes freeze the relevant configuration and amount; final holds recheck it. Changed availability or pricing asks the customer to review again. A lost payment response/reload recovers the existing checkout rather than creating another booking. Pending or uncertain payment warns against a second purchase.

An optional public Assistant can propose an editable widget-scoped draft. It cannot reserve, pay, refund, read private workspace records or message staff. Its current session, widget publication and source access are checked again after prompt preparation, immediately before sending data to the model. The form remains usable if assistance fails. Generic widget deposits, parallel subgroup editing and customer amendments to confirmed paid visits remain outside this public composer; private-event deposits and supported payment-link instalments have their own workflows. Widget disablement closes new reservations while preserving a valid held checkout's recovery path.

Payments, guest self-service and communication#

Online collection is the safe default. A permitted pay-on-arrival booking can confirm inventory with an Order in payment_due; it is not paid revenue. Mandatory online collection, previously collected amounts and the venue balance remain separate. Record venue payment records money already collected as card at venue, cash or bank transfer, with its receipt/transfer reference. Payment history retains online payments, venue payments, corrections and venue refunds. Recording a payment is not initiating a card charge or bank transfer. Staff cannot silently bypass a required online obligation.

The secure manage-booking page at /org/[orgSlug]/booking/manage shows the whole visit, payment state, eligible changes/cancellation, pre-order and communication history. The frozen policy determines which actions are available. Waitlist offers have a separate scoped portal at /org/[orgSlug]/booking/waitlist.

For an eligible confirmed unpaid on-arrival Booking, authorised staff can create an expiring link requesting an instalment from the original seller. Creating the link neither charges the guest nor sends a message. The guest opens /booking/pay/[paymentRequestId], reviews and confirms payment; the receipt retains the full Booking total and remaining venue balance. An already provider-bound or mandatory-online Order must use its existing collection flow.

Guest cancellation can request the governed refund within the frozen deadline. Money collected at the venue requires staff evidence of its actual return; a guest cannot create cash-return evidence. Inventory remains protected until the required refund/cancellation operation completes.

Communications exposes editable email/SMS defaults for confirmation, modification, cancellation, pre-order, standby, waitlist, reminder, post-visit, payment request and marketing preferences. Template editing is not sending. SMS provider readiness is shown separately. A Bookings detail can mount an Inbox-owned conversation/composer when the operator also has Inbox access; mailbox selection, send authority and message history remain Inbox-owned.

Booking invoices#

A Booking's Invoices & payments rail also contains a separate invoice builder. With the current direct-seller payments.manage authority, choose New invoice, enter billing name/email/address and payment terms, then add saved catalogue products or new quantity/price lines. Select inclusive or exclusive price basis and an explicit VAT rate; optionally save a new item to the catalogue. Review the line and invoice totals before issue.

The Issue & send through Stripe action requires the configured live default Stripe connection and issues the invoice and emails it through Stripe. Review billing details and recipients before invoking that action. The invoice records draft, issuing, awaiting payment, paid, void, uncollectible or needs attention states. Once available, Open in Stripe opens the hosted invoice; Send / download offers Send to accounts, Send to me and Download. Clearing an unsent draft is a separate confirmed action. Provider-confirmed payment and delivery evidence remain distinct from issuing/downloading a file. Do not treat this invoice builder as permission to replace the Booking Order's existing collection or refund lifecycle.

Private-event enquiries and function sheets#

Private events handles multi-stage venue sales. Create an enquiry with contact snapshot, event type, guest estimate and initial date/space. Review availability and construct a capacity plan containing the actual occurrences.

The detail screen exposes valid next steps: qualify, hold a time-limited option, issue a priced proposal, accept it, issue a contract, record the signature and required deposit evidence, confirm, set guaranteed counts, publish a function sheet/BEO, complete or cancel. It keeps capacity plan, commercial evidence, operational milestones and audit trail together.

Private-event access covers the current plan and its earlier Sites and Spaces. Older records and resource allocations whose original scope cannot be verified remain stored but unavailable. Replacing the plan does not restore access to that history; missing evidence requires separate review.

Setup, AV, furniture, staffing and communication milestones can contribute to operational demand. Each published function sheet is an immutable snapshot with its predecessor; later edits produce another version. A proposal, signature or payment record alone does not bypass the required lifecycle state. Cancellation records the reason and governs the associated inventory/money consequences. CRM Sales can project this pipeline without becoming a second booking database.

Settings, providers and migration#

Bookings Settings groups organisation defaults, weekly service hours, venue inventory, widgets/customer journey, communications, menus, payment connections, provider distribution and migration. Providers & distribution can register webhook, poll or import connections with freshness targets, map external identity and status to Soupy, set the exact resource's authority owner with a reason, and create distribution channels. Channel policy includes owned/embed/QR/approved partner kind, party/advance limits and attribution. It shows received/reconciled timestamps and health separately from configured state. Every channel still uses the canonical quote/hold checks. Provider setup and cutover do not follow from merely importing records.

The ResDiary migration studio stages an account import, reviews bookings and customers, maps historical inventory, rehearses the apply result and then applies the reviewed scope. Exact normalised email may identify an existing customer; shared-address/name conflicts require explicit decisions. Imported contacts remain unverified and gain neither consent nor purchase totals. Imported confirmed visits remain labelled separately from verified attendance.