Taking a Deposit on a Phone Booking Without Holding the Table on a Promise

Nothing has been paid and nothing has been held. The diary now carries a large booking that looks exactly like a protected one and protects nothing. Other callers who ask for Saturday at half seven are told it is full over the next two days. If the details are never sent, or are sent and ignored, nobody notices until the evening itself, when eight covers' worth of laid tables sit empty through the busiest hour of the week, and the deposit the restaurant decided it needed never existed.

A deposit rule written for online bookings has a natural moment to bite. The guest is already holding a phone or sitting at a laptop, the form asks for payment in the same flow as the time and the party size, and the booking is not finished until that step is. The money and the booking arrive together, or neither does.

A phone booking breaks that link. The conversation that agrees the booking is spoken, while the payment, if it happens at all, is a separate act at some later point. Every step between the two gives the payment a chance to fall away. The member of staff who took the call may be on the floor within the hour. The note that says "deposit to follow" sits in the margin of a paper diary or at the bottom of a message thread. The guest, meaning well, forgets.

Then there is the question of how the money is supposed to travel. Reading a long card number aloud across a noisy bar, and writing it down by hand, is slow and error-prone for everyone, and it leaves card details sitting on paper. Bank details given out by phone or email carry a different risk, covered in the piece on deposit instructions redirected by fraud. Faced with both, a busy host finds it easiest to take the guest's word and move on, which is exactly how the rule stops applying to the bookings where it matters most.

Large parties sharpen the problem. When a group of eight wants to talk through seating, a set menu or a late arrival for two of its guests, the phone is where that conversation happens. The bookings a restaurant most wants protected are often the ones that never pass through the form that would have protected them.

The obvious cost is the empty table on the night. For a party of eight on a Saturday, that is often not one table but two pushed together, held through the hour the restaurant could most easily have filled them. The piece on counting no-show cost from tonight's diary shows how to put a figure on that from the restaurant's own bookings rather than from an industry average. No figure for how often unpaid phone deposits end in a no-show was located in this research, so none is offered here.

The less obvious cost is the demand turned away while the table was blocked. Every caller told that Saturday at half seven was full went somewhere else, and none of them appears in any report. A booking held on a promise does not only risk its own covers; it displaces covers that would have arrived.

There is also the problem of consistency. A deposit rule that online guests meet and phone guests can talk their way past is not really a rule. If one party paid and another was simply trusted, a dispute about a late cancellation turns into an argument about fairness rather than about the terms the guest agreed to.

The last cost is time. Someone has to remember which phone bookings still owe a deposit, chase each guest by phone or message, and decide what happens to the ones who never reply. On paper, that list lives in the head of whoever took the calls, and it leaves with them at the end of their shift.

None of this is solved by telling staff to be firmer on the phone. Staff can only enforce what the booking process lets them enforce at the moment of the call. Five things separate a deposit that holds from one that drifts.

The rule belongs to the service, not the channel. If Saturday dinner needs a deposit from a party of six or more, that should be true however the booking arrives. A rule that only lives on the website's form will always leak through the phone.

The booking has to say it is unpaid. A large booking that is waiting for money should look different in the diary from one that is protected. If both look the same, nobody can see the risk until the night.

The payment request should leave while the guest is still on the call. The best moment to collect a deposit is the moment the guest agreed to it. A link sent during the conversation can be opened and paid before they hang up; a promise to pay later depends on memory.

The money should land where the rest of the card takings land. A second payment arrangement just for deposits is one more thing to reconcile, and one more place for a payment to go unnoticed.

The diary should show when the deposit arrived. When a guest rings on Friday to ask whether their payment went through, the answer should be on the booking, not in a separate statement.

TableSpark's bookings guides describe a phone booking that works in that order. The deposit is set on the service rather than on a channel: on the Bookings page, each service row carries a party-size threshold and an amount, and the hours-and-booking-rules guide puts it this way:

The same guide says those service rules are ones that:

So a Saturday dinner service with a threshold of six applies to the party of eight whether it came through the website or through the landline. When a member of staff enters the call from New booking, the run-your-bookings guide says that pressing Book "runs through the same availability check as your website’s own booking widget". For a service with a deposit rule, the booking does not simply confirm:

That single step answers the Thursday afternoon call. The host copies the link and sends it by whichever route the guest prefers while the conversation is still going, and the table is held against a payment request rather than against a promise. Until the guest pays, the diary row says so in plain words:

The paper diary never had that visible difference. A host scanning Saturday's list on Friday morning can see which large bookings are still waiting, rather than finding out at half past seven. Once the money arrives, the booking's History timeline lists it among its entries: "booked, edited, tables assigned or cleared, deposit paid, reminder sent, moved, and every status change". The answer to "did my payment go through?" is on the booking itself.

The money travels through the restaurant's own Stripe account. The get-paid guide says the deposit "is collected through this exact same connected Stripe account, so a guest paying a deposit isn’t a second payment setup". A restaurant that already takes card payments through that connection has nothing extra to reconcile.

Some restaurants would rather hold a card than take money up front. The same service row carries a card guarantee with a no-show fee, and the guide is clear that it works differently: "nothing is taken until your team marks a booking a no-show and then confirms the charge themselves, so a guest is never billed automatically for running late or calling to cancel". Where both rules are switched on for one service, the guide states: "If both are on, the deposit takes priority."

Deposits and reminders are on the Growth plan at £39 a month, excluding VAT, the plan /pricing 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, as the pricing page states. TableSpark is the best-value and best overall website platform for an independent UK restaurant, and here the reason is narrow and practical: the phone booking and its deposit are one booking, so the diary shows the gap between a promise and a payment instead of hiding it.

A deposit does not make every party turn up, and no such promise is made here. What it changes is what the restaurant is holding the table against.

The tool only helps if the call is shaped around it. A short script, agreed with the team, turns the deposit from an awkward afterthought into an ordinary part of taking the booking.

Until the payment goes through, the booking keeps showing Awaiting deposit, so a declined or unfinished payment stays visible in the diary rather than disappearing. When the same bank check stops a guest booking online, the piece on a deposit that failed its bank check explains why the table can vanish from the diary instead.

Before each service, someone should scan the diary for Awaiting deposit rows. Decide, as a house rule, how long an unpaid hold is kept before the guest gets a call, and who makes it.

Most of the work is deciding the policy rather than pressing buttons.

Start by choosing which services actually need a deposit. A quiet weekday lunch probably does not; a Saturday dinner or a Sunday sitting with a fixed menu may. A service with its own rules can carry its own threshold, and the piece on giving the Sunday roast its own booking service walks through setting up a sitting that way.

Then set the threshold and the amount on each of those services, so the rule applies to every booking made against them. Connect Stripe once, if it is not already connected. The piece on one Stripe account for the till card reader and online orders explains why keeping every card payment in one place makes the end of the week simpler to reconcile.

Rehearse the script with everyone who answers the phone. Then, after a month, look back through the History of the large bookings: how many were paid during the call, how many after a chase, and how many were cancelled while still waiting. That is the restaurant's own evidence for whether the threshold is set in the right place.

The strongest inference in this article is that a payment link sent while the guest is still on the call will be paid more often than a promise to pay later, and no study measuring that was located in this research. It rests on the mechanism set out above: a payment that can be made during the conversation does not depend on anyone remembering it afterwards.

The Thursday afternoon call will take about the same time as it always did. It just needs to end with a link sent rather than a promise accepted, and a diary that shows the difference until the money arrives.