What your guests see

The booking widget: request, confirm, remind

A guest reaches your booking widget from a button on your site — usually labelled Reserve a table, sitting on your home page and on a dedicated reservations page (on many TableSpark sites that address is /p/reservations, though yours may differ depending on how you named the page). The form itself asks for what any restaurant needs to hold a table: date, service, seating preference, party size, name, phone, email, allergies, occasion and any notes for the kitchen.

Booking is a signed-in action, and that is a feature working in the guest’s favour, not a hurdle in front of them. If someone tries to book while signed out, TableSpark sends them to your site’s /account page first, then brings them straight back to finish the request the moment they have signed in — the same page covered in the next step. The payoff is immediate: the booking lands inside their own account automatically, with nothing for them to re-enter next time.

Once you confirm the booking, TableSpark emails the guest automatically — no separate step for you to trigger. The confirmation restates the restaurant, date, time and party size, and its button reads View or change booking, opening straight into their account rather than a dead-end confirmation page. The day before the booking, a second email goes out on its own: a plain, friendly reminder with the same details. Neither email is something you write from scratch — see Guest emails for how the wording and sender identity are set.

Signing in: the guest’s own account

Every published TableSpark site carries a page at /account — the guest’s own sign-in and self-service space. It is not a generic TableSpark screen: it wears your restaurant’s own accent colour, your logo, and a hero photograph pulled straight from your own home page, so a guest never feels like they have left your site. The page is deliberately kept out of search results — it is the guest’s own space, not a listing.

A signed-out guest sees two tabs, Sign in and Create account, an email and password field, and a Forgot password? Email me a reset link option underneath. Creating an account asks for a name, an optional phone number, an email, a password, and a required tick against your Terms and Privacy Policy before it will submit anything. Google sign-in is available too, right on your TableSpark subdomain — guests on a custom domain can use Google from that same subdomain link, or simply sign in by email, which works everywhere.

Behind the scenes, this page is guarded the way a sign-in page should be: a human-verification check sits in front of every signup and password-reset request, alongside limits on how many of those emails can go out in an hour, so the shared sending budget a guest's confirmation and reminder emails also rely on can never be drained by a bot. And every account-creation or reset email that goes out is sent by TableSpark in your restaurant’s own name, not as a generic Supabase notice — it reads like it came from you, because in every way that matters, it did.

One page for bookings, orders and gift cards

Once a guest signs in, the same page becomes their personal dashboard. The hero turns into a greeting — “Good afternoon, <first name>” — next to a stat panel showing their gift-card balance, and how many upcoming bookings, orders and past visits sit on their account, plus a “next visit” card so the one thing they are most likely to want — when am I next in? — is answered before they scroll.

Below that sit five modules, in this order: Upcoming bookings, Past visits, Orders — each one opening a detail sheet with a live status timeline, an itemised receipt and a pay-now button for anything still owed online — Gift cards, shown as real card faces with a masked number and balance, and Your details, where a guest can update their name, phone, delivery address and a news-and-offers subscription. If your site has ordering switched on for collection or delivery, quick-order buttons sit right in the hero too, but only for the channels you actually offer.

Every field on this page is the guest’s own record, not a copy that lives somewhere else. It is exactly what you already see in your own Inbox and guest list — nothing here sits outside TableSpark. A guest can ask you at any time to export or delete their details, and the account page says so plainly, right under the details form.

Changing or cancelling a booking

A guest can act on their own upcoming booking without picking up the phone, for the routine cases. From the Upcoming module, a Change button opens a sheet where they pick a new date, party size and time against your real, live availability — the same availability check your own booking widget uses — and confirms the move. A Cancel button sits beside it, and it needs a genuine second tap: the first click turns it into “Really cancel?” for a few seconds before the second click commits anything, so a guest can never cancel by accident.

Both buttons only appear on a booking your own record marks as changeable in the first place. A booking under deposit, a card guarantee, or one starting too soon simply tells the guest to call the restaurant instead of offering the self-service buttons — the two paths never contradict each other. If a guest picks a time that just filled up, the sheet offers the nearest free alternatives rather than a flat “try again.” Every change or cancellation a guest makes here shows up on your side exactly the way a phone-in change would, through Run your bookings.

The emails that go out along the way

This guide has already mentioned two of them — the booking confirmation and the day-before reminder — but a guest's full inbox with you can carry several more: a deposit receipt, a cancellation notice, a rescheduled-booking notice, a waitlist update, and the gift-card emails covered in step seven. Every one of them sends in your restaurant’s own name, with your reply-to address, and every one of them can be reworded to match how you actually talk to guests.

That wording, sender identity and branding is a full guide of its own, not something to duplicate here — see Send emails, campaigns and journeys → Guest emails for the complete list and how to edit each one.

After the visit: review invitations

A TableSpark review is never a cold request — it is always tied to a real, completed visit on your books, and you are the one who sends it, from that guest’s own profile with an Ask for review button. What the guest sees is a plain link inviting them to rate and write up their meal. Once they submit a rating and a few lines of text, both are fixed for good on your side — from there, moderating and replying is entirely yours to do.

The full moderation workflow — the Pending, Approved, Hidden and Rejected tabs, and posting a public reply as the restaurant — belongs to a guide of its own: see Know your guests → Collect reviews, and reply as the restaurant.

Redeeming a gift card as a guest

Two real, live paths, and a guest can use either one. At checkout, a signed-in guest with a balance sees “Use my gift card — £X available”, and the value applies itself — nothing to type. From the account page covered in step three, a guest can also key in a gift card’s 16-character code and 6-digit PIN from an email, under Add a gift card. That tops up their own account balance rather than a single order, and the balance then spends itself automatically the next time they check out — a code is never applied to one order directly from that box.

• At checkout — the balance applies itself the moment a signed-in guest with funds reaches payment; no code needed.
• Add a gift card — a guest types the code and PIN from an email once, and the value joins their account for good.
• The card face itself — shown on the account page with a masked number and current balance, exactly like a physical card in a wallet.

Every gift card a guest redeems, every booking they change, every order they check on — it all runs through the one account they signed into once. The full selling, balance and refund workflow on your side of that same card lives in Sell gift cards → Redeem a balance.