What guests see when booking

At the top of the page your cover image runs the full width of the screen, with your logo, your restaurant's name and your address beneath it. Set all of these under Branding.

Underneath that, guests see your opening hours, phone number, address and a View menu link, if you have one, laid out as a row of facts.

Further down the page there's a short About describing the place (with a "Read more" link when it's long), and a map showing where you are with an "Open in Maps" link. The map appears only when you've saved an address.

Your booking page uses one clean, consistent layout, and your main brand colour is applied to the parts guests tap — the time buttons, the confirm button, and whatever they've currently selected. Everything else stays on a neutral background so the page reads clearly on a phone.

If your main colour is very light, we'll use a slightly darker shade of it for buttons and links so guests can actually read them. The Branding page tells you when that's happening and shows you exactly how your booking page will look.

The page adapts to the screen it's on. On a phone it's a single column; on a computer it's one wide, centred column with the sections separated by thin dividing lines rather than sitting in boxes. The last page splits into two — the guest's details on the left, and a reminder of the booking on the right.

Guests pick their table from a single bar with three parts — Guests, Date and Time. Tapping one opens it: a list of party sizes, a two-month calendar, or a list of service times to narrow the results. The party sizes run up to the Largest party set on the booking setup — 20 by default, and anywhere from 8 to 20 if you change it. A Bookings Pro flow with its own Party size step uses that step's numbers instead. The calendar only lets guests pick dates you actually take bookings for, which comes from the notice period and how far ahead you accept bookings on your booking setup. Available times appear underneath as buttons; times that are gone aren't shown greyed out, they're simply not there.

When a day has no times, guests are told why

If a guest picks a day with nothing on it, the page says which of these it is. It doesn't guess, and it doesn't give the same answer to all of them:

• You closed the day. Guests read your own words, exactly as you typed them in What guests see on the Closed days tab. If you left that box empty they read "We're closed on this date — pick another." Your phone number is added underneath when you've set one.
• The day is full at that party size. Guests read "Nothing left at this party size. Try another date", and your phone number if you have one.
• The date is too far ahead, or already gone, or no table you have is big enough for that party. Each gets its own line, because "try another date" is no help when every other date says the same thing.

On your public booking page the customer then works through a short journey, one page at a time — they see a single card and move forward with the button on it (or by picking a time), with a Back link. Guests are not shown a step counter: the number of pages depends on how you've set your flow up, and telling someone they're on "step 2 of 5" reads as how much admin is left rather than where they are. The exact pages depend on what you've set up, but the core flow is:

1. Choose a location, if you have more than one site.

2. The booking bar — pick a date, a party size, and a time, all on the first page. If you run more than one booking setup (say a Lunch and a Dinner service, each with its own hours and tables), guests pick that here too, under Booking type. Picking a time takes them to the next page.

3. Where to sit — only if you've asked for it. By default guests are not asked which part of the restaurant they want. They book, and you give them a table anywhere in that setup. If you want the question, turn on Ask guests where to sit on the setup's Sections card (Bookings → Setups → your setup).

   With it on — and with the setup's tables spread across more than one floor plan — guests pick a floor plan on its own page: "Ground floor", "Garden", with Any area first and how many times each still has beside it ("Ground floor · 4 times available"). Only what can still seat them at the time they picked is offered, so they can't choose something that turns out to be full.

   Guests never see your room names. The rooms on one floor plan are a single choice between them, and we put the booking in whichever of them has the most free tables at that time. A room whose tables aren't on a floor plan keeps a row of its own, so nothing bookable disappears.

   If everything bookable sits on one floor plan, guests aren't asked at all even with the setting on. They read "We'll seat you in the best available area" and move on — one plan is not a choice, however many rooms are on it.

4. Enter their details and confirm — name and email are required; phone and a notes box appear if you've asked for them.

   The page comes in two halves, and only one is on screen at a time. While a guest is filling in who they are, your terms — and the card box, if you take one — are not on the page yet; a greyed strip says what is coming. Once the details are complete and the guest taps or tabs away from the fields, that half folds down to a single line ("Giulia Ferrari · giulia@…") and the rest opens underneath. A Change link beside it puts the fields back, with the cursor in the first one, and nothing else on the page disappears when they use it.

   Two things it deliberately will not do. It never folds while a guest is still typing — it waits for them to leave the fields, because an email address is valid a few characters before anyone has finished typing one, and your phone box is often optional and still empty at that moment. And it never folds a field the guest still has to fix: if something is wrong, that half stays open with the message beside the box it belongs to.

   On a booking that owes a deposit, the button says Continue to payment from the start. Party size is what decides whether a deposit is owed, so the page knows as soon as the guest picks their number — it does not wait to find out. From the moment they land on the details page the button under the fields reads Continue to payment, greyed until their details are complete, with a line above it saying what is still needed. There is never a Confirm booking button on that page for these guests, so nothing changes under them as they type.

   What changes when their details are complete is that we hold the table, their details freeze — the booking has been made against them, so the form says so rather than going on accepting edits — and the button becomes pressable. The line above it changes to say the table is being held. Pressing it opens the Deposit panel; paying there is what unlocks Confirm booking underneath.

   The note over the frozen details names what is actually happening — "while we take your deposit" on a venue that takes one, "while we save your card" only where a card is genuinely being stored. Either way the way out is the same: cancel from the confirmation email and rebook.

   Changed 16 September 2026: the button used to read Confirm booking for the whole of the details page and only switch to Continue to payment on the guest's very last answer — the page was waiting to be told the deposit amount before it would admit a deposit was coming, when the party size had already settled it. A guest filling in a nine-cover booking watched the page change under them at the last keystroke. It now reads the party size, like the rest of the deposit rule does.

   The phone field is two controls: a country picker and the number itself. It opens on your venue's own country, so a local guest just types their number as they normally would, and a visitor from abroad picks their country from the list (every country is there, and you can search it). Letters can't be typed into the number box at all, and if the number or the email address isn't usable the guest is told which one and the Confirm button stays off until it's fixed. What you see on the booking is the tidied international version, so a number is always dialable from anywhere.

   On this final page the guest also sees anything else you ask them — your custom questions (allergies, an occasion, a high chair) and a marketing opt-in, if you've added those steps — grouped onto the same card, so the last thing before booking reads as one short review rather than several pages of small print.

   On a computer that page splits into two columns: their contact details and the Confirm button on the left, and what you're asking them on the right. That right-hand column now stays put as the guest scrolls, so the date, time and party size they picked — and your terms — are still in front of them while they fill the form. On a phone the right-hand column sits underneath instead, and does not pin: there is no "beside" on a phone, and a card floating over the fields would be in the way.

   Your terms are not in that card. They sit in a panel at the top right of the page, beside your About section, where a guest can read them while filling the form. The tick box stays in the form itself, just above Confirm — it's the last thing a guest agrees to before booking.

   The notes box renames itself. Normally it's labelled Allergies or requests, because for most venues it's the only place a guest can tell you about an allergy. But if you've added a custom question marked as a safety alert — an allergen question, typically — the box changes to Special requests, and its hint suggests things like a birthday, a high chair or step-free access instead. Nothing is lost either way; it's about which box a guest types an allergy into. Two boxes sitting side by side, both mentioning allergies, means guests answer the free-text one and skip the structured question — and only the structured answer reaches your kitchen ticket and the allergen warning on the booking.

Also changed 15 September 2026: the page (when you ask for it) used to list one row per room. A venue with nine rooms gave guests nine things to read, most of them named for staff. Guests now choose the floor plan, and your room names stay internal.

On Bookings Pro you can add extra steps such as a custom question, a marketing opt-in, or an experience to choose from — see Booking flows.

How the allergens question looks

Your questions sit inside the guest's details card, between their contact details and the "Anything else we should know?" box — so a diner answers them in the same breath as giving you their name, rather than in a separate panel above.

A question with a long list of options — allergens being the one that matters — shows two choices rather than the whole list. Most diners tap No allergies and are done. I have allergies or dietary needs opens the list, and shows a count once something is picked.

Questions you mark as required

If you mark a Pro question as required, the guest can't move past the page it sits on, and can't confirm the booking, until they answer it. The button stays greyed out. This is the setting to use for anything you genuinely need before service.

The allergy question already arrives required, however it got onto your flow — you don't have to set it. Guests answer it with one tap, because No allergies is a choice they make rather than a box they leave alone.

A tick-box question counts as answered whether the guest ticks it or leaves it unticked: "no" is a real answer. If you need an active yes, ask it as a choice with two options rather than a single tick box.

Asking guests to agree to your terms

If your flow has a terms step with wording in it, guests see a tick box reading "I agree to the booking terms and cancellation policy", and can't book until they tick it. It sits at the bottom of their details card, directly above Confirm — agree, then confirm, in that order, immediately before the only step a guest cannot undo.

On a venue that takes card details, that tick is also what opens the card fields, which sit just above it. So the order a guest works down the page is: their details, then the card box (locked, saying to agree to the terms below), then the tick, and the card fields open. Both appear together once the details half has folded, so a guest is never hunting up the page for something.

Your cancellation policy is also printed in full on that page, in the right-hand column directly under the booking summary, where a guest sees it while they are deciding rather than after they have scrolled past everything. There's no switch to make that optional — a cancellation policy guests could skip wouldn't be a policy. The box starts unticked, always: an agreement a guest didn't actively give isn't an agreement.

We record the exact wording you had on the page at the moment they ticked, against that booking. So if you later change your cancellation policy, an older booking still shows the terms that guest actually agreed to. That's the record you'd want if a no-show fee were ever questioned.

The wording is taken from your saved booking flow, not from the guest's browser — so nothing a guest (or anything pretending to be one) sends can change what gets filed against their booking.

If you edit your policy text while someone is midway through booking, their record shows the wording saved at the moment they confirmed. We never block a booking over it — a guest part-way through always gets to finish.

This is separate from the marketing opt-in — two different things to agree to, two separate tick boxes, recorded separately. Never one tick covering both.

Paying for a set menu

For most bookings there is no payment step. The guest enters their details and goes straight to confirmation without paying anything, and the Pro experience/package step is selection only — it can show a price so the guest can choose, but no charge is taken.

If we've switched set-menu payments on for you, and the guest picks a set menu that has a price, they pay for it as part of booking. The Deposit panel sits on the details page itself — under the card box if you have one, above the box where they agree to your terms, and well above the Confirm button. It shows the amount. The price is the one on your set menu, worked out per cover: four guests on a £34.99 set menu pay £139.96, not £34.99. The guest can't change it, and neither can their browser.

Paying and confirming are two separate actions. The guest pays on the Deposit panel, then presses Confirm booking, which finishes the booking off. Pressing Confirm does not take the money and never shows a payment screen.

Changed 5 August 2026: the payment screen used to appear only AFTER the guest pressed Confirm, taking over the whole page. That put the payment behind the button that was supposed to complete the booking, so a guest who pressed Confirm got a payment demand instead of a confirmation. It was switched off that day.

Changed 15 September 2026: paying came back, in the page rather than over it. Between those two dates there was no online set-menu payment step at all — if you were told a guest would be asked to pay during that period, they weren't.

Three things worth knowing about how it behaves:

• A declined card ends that booking attempt. The guest is told their bank didn't approve it and asked to start a new booking to try another card. We can't reopen the payment on the booking they were part-way through, so if a guest rings you after a decline, take the booking yourself and record the deposit by hand.
• Paying is what completes the booking, not pressing Confirm. If they pay and then close the page before pressing Confirm, the booking still stands and their confirmation email still goes out — the button only takes them to the confirmation screen. Nothing is stranded.
• If they walk away without paying, the table doesn't stay held. A booking where the guest never got as far as entering a card is cancelled automatically after 30 minutes and the table goes back on sale. The guest is not emailed about it, so someone who tells you they "started booking and something went wrong" may have no booking at all.
• But a payment that was started and didn't finish is kept, not cancelled. If the guest got as far as their bank, the booking is held for us to look at rather than cancelled underneath them — because at that point we can't be sure they weren't charged. If a guest says they paid and you can't see their booking, that's the case to send to us rather than rebook over.

Deposits taken by hand — over the phone or in person — work exactly as before. See Deposits and prepayments for the full picture.

Card details at booking

If your venue stores a card as a condition of booking, guests see a Card details box on the final page, just above your terms tick — it appears once they have finished entering their details. It stays locked until they agree to your cancellation terms in the tick below it, and their booking is held while they enter the card. No payment is taken — the card is stored securely, and it's only ever charged under the terms they agreed to (your no-show fee).

When the guest's bank asks them to approve the card

Card rules mean the guest's bank checks who they are before a card can be stored. That check runs on every card taken at booking. Almost always the guest sees nothing: it happens in the background in a second or two.

Sometimes the bank wants more. Usually it asks right there on the page — a small panel appears, the guest approves in their banking app, and the booking carries on as normal.

Occasionally the bank takes the guest away to its own page instead. When it sends them back, they land on a short message that says their bank has sent them back, we're waiting for the card to be confirmed, and we'll email them either way. That message is deliberately careful: at that moment the confirmation from our payment provider has not arrived yet, so it doesn't promise the card worked.

The same care applies on the ordinary path. Once a guest has entered their card the box says the details have been received and are being confirmed with our payment provider, and they carry on and press Confirm as normal. It does not say the card is saved, because at that moment nobody has told us it is — that answer comes from our payment provider a few minutes later, and it is what turns the booking into Card on file in your diary. (Corrected 1 September 2026 — the box used to say "Card saved. Your booking is secured." as soon as the guest pressed the button, which was sometimes untrue.)

Added 25 August 2026: guests used to land back on an empty booking page after their bank sent them back, with no sign of what had happened, and often booked again or gave up.

If the card box can't load

Very occasionally the card box fails to appear at all. The guest sees a red panel saying we can't take card details right now and that it isn't anything they have done, followed by your venue's phone number and a line telling them to ring you and book that way.

They cannot finish the booking themselves when this happens. Your venue takes a card as a condition of booking, so the Confirm button stays switched off until a card is stored, and nothing on the page gets them past it. Anything provisionally set aside for them is released automatically within about 40 minutes, so the guest genuinely does need to ring.

If a guest rings about this, take the booking by hand in the diary. We're alerted automatically when it happens, so you don't need to report it, but tell us if you see it more than once.

Two things worth knowing:

• A guest who gets this far and abandons the card step holds their table briefly — the system releases it automatically within about 40 minutes, and the booking shows as Card pending in your diary until then.
• Make sure your terms wording says the card is stored at booking and what a no-show costs, with the amount — that wording is your evidence if a charge is ever disputed. Set it under Bookings → Flows → your flow → Terms.

Confirmation

When the guest confirms, they see a "You're booked" screen with the date, time, party size, the table they've been given and a cancellation code.

Underneath that, the screen tells them what is happening with their confirmation message — and which sentence they get depends on your venue:

• Most venues — "Your confirmation is on its way to sam@yetipay.me."

• Venues that take a card at booking — "We'll send your confirmation to sam@yetipay.me as soon as your card is confirmed." Your guest's card is confirmed by our payment provider a few minutes after they enter it, and the confirmation goes out then. Nothing is sent before that, deliberately: a booking whose card never arrives is released, and we would rather not have told the guest they were coming.

  This sentence follows the card step itself, not the setting. If your flow has no cancellation policy written into its Terms step, no card is asked for (see Booking flows) — so your guests get the ordinary "on its way" sentence instead, and their confirmation is sent straight away.

• Venues taking a deposit — the same sentence, waiting on the deposit.

Either way the screen ends by telling the guest to keep the cancellation code. That is not decoration: it is the guest's own record of the booking and the only thing they need if a message is slow or goes to spam.

"Pre-order your food" on the confirmation

If you've turned pre-orders on for that booking setup, and the party is big enough to meet the minimum you've set, a Pre-order your food button appears on the confirmation screen. It takes the guest to a menu where they can choose dishes for their table ahead of the visit.

The button only shows when both are true — pre-orders on for that setup, and the party size at or above your minimum. A smaller party, or a setup with pre-orders off, sees exactly the confirmation screen described above, with nothing extra.

The button is currently the only way in — the confirmation email doesn't carry a pre-order link yet, so a guest who closes that screen can't get back to it. Worth knowing before you rely on guests ordering later rather than there and then.

If you use product availability counts ("10 left" on a dish), a dish that has sold out shows greyed out as Sold out on the pre-order menu and can't be added, and a guest can't save more of a dish than you have left. Nothing is set aside for them by pre-ordering — the count only goes down when the order reaches a bill on the day.

There's no separate password or login: the page opens from the same private link the booking already uses. Guests can change their order until your cut-off passes — you set that as a number of hours before the booking. After the cut-off, or once your team has locked the order in, the page explains the deadline has passed and asks them to call you rather than letting them make a change you might not see in time.

No money changes hands here. Pre-ordering is choosing dishes, not paying for them. That's separate from a set menu bought at booking time — see Paying for a set menu above.

Holding the table during checkout

Once a guest picks a time, their chosen table is held for five minutes while they finish the booking. From the second page onward the top of the page becomes a single line — your name, the date, the time and the party size — with the countdown on the right of it. This stops two guests grabbing the same slot at once. If the five minutes run out before they confirm, the countdown turns into "this table may no longer be available — please pick another time" and they're sent back to choose a fresh slot. The hold is automatic — there's nothing for you to set up, and the hold itself never takes a payment.

If the time fills up while the guest is typing — the last table went, or a pacing or arrivals limit you set was reached — pressing Confirm tells them "That slot just went. Please pick another time." and takes them back to the times, which are reloaded. Nothing is booked and nothing is charged.

If your page is switched off

A guest opening your /book link while Accepting online bookings is off is told the venue isn't taking online bookings right now, and asked to call instead. They are not offered a Try again button, because nothing is failing — the page is simply not on yet.

This used to read "We couldn't load this venue's times," which made a switched-off page look broken and sent merchants hunting through their opening hours for a fault that was never there.

What's next

• Your booking page — set the address the customer books at.
• Booking flows — customise the journey (Bookings Pro).
• Deposits and prepayments — why the guest doesn't pay to book.