The Phone Booking With No Email Never Gets a Reminder

That missing address is where the trouble begins, and it stays hidden until the weekend. The guest said "Saturday", but the staff member heard "Friday", or wrote seven instead of eight, and nothing arrives in the guest's inbox to show either of them the mistake. Nothing arrives the day before, either, so if Saturday fills up with other plans, the booking slips out of the guest's mind. At eight o'clock a table for four sits laid and empty on the busiest night of the week, while the host turns away a walk-in party of four because the diary says the table is taken. The restaurant has lost the covers, and in all likelihood the guest has no idea that anything went wrong.

A booking confirmation and a reminder can look like plain courtesy, the kind of thing a restaurant sends because it seems polite to do so. Each one, in practice, works as a check on what was written down.

The confirmation is the first moment the booking exists in writing on the guest's side. It puts the date, the time and the party size in front of the person who asked for them, while the call is still fresh in their mind. A guest who reads "Friday" when they meant Saturday can reply or call back that afternoon, turning the error into a thirty-second fix instead of an empty table. The piece on testing a booking confirmation field by field walks through what that message needs to get right to do the job.

The reminder is the second check, and it works on memory rather than accuracy. Landing close enough to the visit, it prompts a guest who has double-booked themselves, or simply forgotten, to either turn up or cancel. A cancellation the day before frees a table the restaurant can give to someone else. Silence on the night leaves a table it cannot.

Both messages depend on one thing: an email address. Without it, there's no confirmation to catch the misheard day and no reminder to jog the forgetful guest. Of all the fields on the booking, the address is the one that decides whether the guest ever hears from the restaurant between the phone call and the night itself.

A guest booking through a restaurant's own website types in their own email address, because an online booking form needs somewhere to send the result. A booking taken by a person on the phone has no such built-in step. The staff member decides what to ask for, and under pressure, asks for as little as possible.

The reasons all make sense. A phone number feels like contact enough: if something goes wrong, the restaurant can ring. Spelling an email address out over a bad line, with a kitchen printer chattering in the background, is slow and awkward, and invites mistakes of its own. Guests sometimes hesitate to hand over an address, expecting marketing to follow. And whoever picks up may be covering the phone for five minutes, with no script.

The result is a diary with two tiers of booking sitting side by side. Bookings made online carry an address and get both checks. Bookings made by phone often carry only a number and get neither. The awkward part is that the phone tier has more room for error to begin with. A booking typed by the guest is at least in the guest's own words. A booking spoken aloud, heard over noise and written down by someone else, is exactly the kind that benefits most from being read back in writing, and it is the kind least likely to be.

No figure for how many UK restaurant bookings are taken by phone, or how many of those carry no email address, was located in this research. What's described here is the mechanism, not a measured rate, and the size of it will vary from one restaurant to the next. Any owner can measure their own by opening last month's diary and counting.

Losses from an unconfirmed phone booking rarely look like a system problem, so they get chalked up to bad luck.

First is the wrong date or time nobody catches. A table sits held for a night the guest never meant to book, and the guest may show up on a different night expecting a table that isn't there for them. One of those is an empty table; the other is an awkward conversation at the door on a night that might already be full.

Second is the forgotten booking. Without a reminder, a guest who booked ten days ahead has only their own memory to go on. When they forget, the restaurant finds out at the moment the table should be filling, far too late to offer it to anyone else.

Third is the cancellation that never happens. A guest who changes plans and has a message sitting in their inbox has an easy way back to the restaurant. A guest with nothing but a vague memory of a phone call has to track down the number, call during opening hours and hope someone picks up. Many will not bother. The piece on guests who cancel without phoning sets out why that friction matters and where cancellations get lost.

Fourth is quieter, and arrives later. A diary that counts no-shows will count these too, and the guest's history will carry a no-show against their name for a booking they may never have realised they'd made.

None of this looks like an obvious failure on any single night, so the pattern goes unnoticed and stays that way. It shows up instead as a steady run of empty tables the diary said were booked, spread thinly enough across a season that the phone call where it started is never the thing anyone blames.

The fix is less a new policy than a single question asked at the right moment. If the confirmation and reminder travel to an email address, then that address belongs on every booking a staff member enters, and the screen used to enter a phone booking should make the field hard to miss and clear about why it matters.

TableSpark's guide to running bookings describes its New booking form in exactly those terms. Staff open it from the Bookings page, set the date, the party size and the time, then record where the booking came from:

That sentence answers the question an owner is really asking. The phone number is the optional field. The email is the one that gets the guest's messages sent, and the form marks the booking's source as Phone, so a phone booking is recorded as what it is rather than disguised as something the guest did online. The guide adds that pressing Book runs the booking "through the same availability check as your website’s own booking widget", so a slot that's genuinely full offers the nearest open times rather than a double booking, and the phone booking travels the same route to the diary as one the guest makes themselves.

What the guest receives is spelled out in the guide to what guests see. The confirmation "restates the restaurant, date, time and party size", with a button reading View or change booking that opens the guest's own account. Then: "The day before the booking, a second email goes out on its own: a plain, friendly reminder with the same details." That's the pair of checks this article opened with, attached to a confirmed phone booking by one field.

The diary shows which bookings have had that second check. Each row carries a source chip, so phone bookings stand out at a glance, and, where it applies, "a reminder-sent badge". A row's History timeline lists "reminder sent" among the events it logs. On the day, a manager scanning the diary can see which phone bookings show that badge and which don't, then ring the ones without it while there's still time to fill the table. A badge means the reminder went out, not that it arrived; an address misheard on the call still shows one. For the related problem of finding a caller's booking while they're still on the line, see the guest on the phone whose booking nobody can find.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and here the reason is specific: the booking a member of staff types in from a phone call and the booking a guest makes online produce the same confirmation and, once the booking is confirmed, the same day-before reminder, as long as the address is on it. The Bookings diary, with reminders and deposits, starts on the Growth plan at £39 a month, excluding VAT, the tier the /pricing page describes as for restaurants running bookings, tables and guest marketing from their own site. Direct reservations carry 0% TableSpark commission, and Stripe's standard card-processing fees apply to online payments. Growth also covers guest email from the restaurant's own domain, so the confirmation a phone guest receives comes from the restaurant's own address as well as in its name.

A field on a form only works if the person on the phone fills it in during the call, before the receiver goes back down. The habit matters as much as the screen it lives on.

The simplest change gives the ask a reason the guest cares about. "What email shall I send your confirmation to?" lands better than "Can I take an email?", because it tells the guest what they get back: the booking in writing, and a reminder the day before. It also answers the unspoken worry about marketing. An address given so a confirmation can be sent isn't the same as permission to send offers, and the piece on separating booking messages from marketing consent covers where that line sits.

Read the address back, letter by letter where it's unusual. A mistyped address fails quietly, which is worse than no address at all, because staff believe the guest has been confirmed when nothing has arrived. The piece on testing booking reminder delivery covers how to check that messages are actually reaching guests.

When a guest won't give an address, note that and treat the booking as unconfirmed. On a busy night, those are the tables worth a courtesy call on the day. The run-bookings guide applies the same fallback on the waitlist, where its Notify button emails a waiting party that their table is ready, with the instruction to "call instead if there’s no email on the entry". The principle carries over: where there's no address, a person has to make the call.

If an address is missed and the guest calls back later, the guide's Edit control on the booking row lets staff change "the guest’s name, phone, email, party size or notes inline". The guide pairs the address with the booking at the moment it's made, which is why the ask belongs on the first call; no such promise is made here about what is sent for an address added afterwards.

The same thinking applies well beyond bookings. Every detail that lives in a staff member's head, rather than in the system, eventually turns into a phone call. The piece on setting up sizes and paid extras on a dish applies it to the menu, so guests choose the right option and price without ringing the kitchen to ask.

An owner doesn't need a study to find out whether this is costing them tables. The diary already holds the answer.

Pull up last month's bookings and filter or scan for the ones taken by phone. Count how many carry an email address and how many don't. Then look at the no-shows and late cancellations from the same period and see which tier they came from. If phone bookings without an address are over-represented among the empty tables, the problem sits in one field on one form, and the next shift can fix it.

Then ask the team how they take a phone booking. If the answer doesn't include an email address, add it to the script, give the reason, and make it the question every staff member asks before they hang up.

The strongest inference in this article is that asking for an email address on every phone booking will cut wrong-date errors and no-shows, and no study measuring that effect for restaurant phone bookings was located in this research. It rests on the mechanism set out above: the confirmation and the reminder can only do their job for bookings that carry an address, and a phone booking without one gets neither.

The Tuesday afternoon call will still take under a minute. It just needs one more question before the line goes quiet.