Guest Booking Journey
For managers verifying the restaurant's published guest links. Check the
intended business/location and use an agreed safe test process. Displayed
choices depend on saved configuration and live availability; a preview or slot
selection is not a completed reservation.
Choose the right journey
The venue website separates two guest intents:
/book is for ordinary table reservations, including food, drinks, paid
experiences, seating preferences, and non-exclusive named spaces./private-hire is for exclusive rooms, areas, and whole-venue hire.
Private hire does not appear as a second reservation type inside regular table
booking. This keeps the common journey short while giving event organisers the
space details and request status they need. Both journeys still use the same
allocation and capacity engine, so one cannot promise inventory already held by
the other.
Search and selection
A regular booking begins with date, time, and party size. Depending on your
setup, the guest may also choose:
- an offering such as Food & drinks or Drinks only;
- a non-exclusive named space;
- a seating area preference; and
- an alternative eligible time.
Private hire begins with the event rather than a room list. The guest chooses an
occasion, Seated meal or Standing reception, and an expected party size.
TablePort then recommends only exclusive spaces whose configured layout range
fits those needs and explains why each is suitable. After choosing a space, the
guest selects a date and preferred time; TablePort searches its full service day
for valid event windows. If no configured space supports the event, the journey
offers the venue's enquiry route where enabled instead of promising unsuitable
inventory.
TablePort checks the booking window, shifts, durations, tables, combinations,
spaces, overlapping covers, and pacing. Invalid offering configuration fails
closed: the system does not guess and expose uncertain availability.
The three booking outcomes
| Configured flow | What the guest sees | What staff see |
|---|
| Direct reservation | Immediate confirmation after required details/payment | Confirmed booking |
| Booking request | Acknowledgement that the request is pending and not yet confirmed | Pending booking to review |
| Enquiry only | Enquiry form for follow-up; no table is promised | Enquiry sent to the configured inbox |
Large groups are routed to an eligible direct or request space before an enquiry
option is used. An enquiry never holds inventory.
Guest details and payment
The guest provides contact and visit details required by the booking form. If a
deposit applies to a direct reservation, it is charged securely. For a booking
request, the card is saved but the deposit is charged only if the venue accepts.
If a cancellation fee applies, the guest verifies a card for possible later use.
The page states the amount, timing, refund window, maximum liability, and
whether a retained deposit offsets a later fee. Do not ask guests to put card
details in notes.
When the selected offering is a paid experience, the guest sees its description,
calculated price, included items, refund terms, and final-bill treatment before
confirming. The same promise appears on confirmation and is saved with the
booking even if settings later change.
The final page reflects the real state—confirmed, pending request, or waitlist—
and shows relevant policy information. Confirmation messages use email where
available, with text-message fallback where supported.
After booking
When enabled and before the configured cutoff, the guest can use secure links to
cancel or request a valid change. A change still needs available inventory and
must pass all capacity and policy checks.
For a pending request, staff approval changes the booking to Confirmed and sends
the confirmation. Restoring a cancelled or no-show booking is a staff correction
and does not send a new guest confirmation automatically.
When no time is available
If Notify me when full is enabled, the guest can create an availability
alert for that search. This does not join the walk-in queue or reserve a future
table. See Waitlist & Availability Alerts.
Verify the actual outcome
Inspect the final message and the matching Console/App record. A pending request
is not confirmed, and an enquiry is not reserved inventory. A payment method
saved for later collection differs from a captured deposit or settled experience
fee. Confirm amount, date/time, status, and notification outcome separately
rather than assuming every completed screen means the same thing.
After a failed or uncertain submission, check existing bookings and payments
before sending another request. Use the supported error/retry flow and preserve
the reference. Never ask a guest to paste card details into notes or ordinary
messages. Escalate with the intended journey, location, selected service/space,
record reference, observed status, and exact error through an authorised
channel.