Ask small parties only for a reply to a confirmation text, hold a card for mid-sized groups and take a deposit from the biggest, with the cut-offs set from your own no-show log. Send one confirmation request about two days ahead and a short reminder on the day. Use AI to write the messages and sort the replies.
AI does not send the texts or take the money; your booking system does. What AI does well is the repetitive work around the rule: reading your log, drafting the policy wording, writing and testing the reminder texts, sorting replies into confirmed, changed and silent, and drafting the message that offers a freed table to the waitlist. Before you switch on card holds or fees, check the rules on cancellation charges and text-message consent that apply where you trade.
Count your no-shows by party size before choosing a rule
A deposit rule copied from another restaurant is a guess. Your own log says where the empty seats come from, and it usually points at a narrower group than you expect. Export eight weekends of dinner bookings (Friday and Saturday are where the cost sits) with five fields: date, party size, how the booking was made, how many days ahead it was made, and the outcome (arrived, no-show, late cancellation, cancelled in time). You do not need names or phone numbers for this analysis, so delete those columns before the file goes anywhere near an AI tool.
Here are eight weekends of dinner bookings (date, party size, booking source, days ahead, outcome).
1. Group party size into bands: 1-2, 3-4, 5-6, 7-9, 10 or more.
2. For each band show bookings, no-shows, no-show rate, and covers lost (no-shows x average party size in the band).
3. Show what share of all bookings and of all lost covers each band accounts for.
4. Repeat by booking source and by days ahead (0-2, 3-7, 8 or more).
Show your working. Do not recommend rules yet.If you want the general method for pointing a chat assistant at attendance data, the clinic no-show analysis walks through the same idea for appointments. Here is what the bands look like for a 70-seat restaurant (illustrative).
| Party size | Bookings | No-shows | No-show rate | Covers lost | Share of lost covers |
|---|---|---|---|---|---|
| 1 to 2 | 340 | 14 | 4.1% | 28 | 15.7% |
| 3 to 4 | 210 | 15 | 7.1% | 54 | 30.3% |
| 5 to 6 | 70 | 8 | 11.4% | 43 | 24.2% |
| 7 to 9 | 28 | 4 | 14.3% | 31 | 17.4% |
| 10 or more | 8 | 2 | 25.0% | 22 | 12.4% |
| All | 656 | 43 | 6.6% | 178 | 100.0% |
Parties of five or more are 16% of the bookings but 54% of the lost covers (96 of 178). That one fact decides where the friction of a deposit is worth paying. Putting a payment step on 340 bookings from twos to catch 14 no-shows is a poor trade; putting one on 106 larger bookings to catch 14 no-shows that cost 96 covers is a much better one.
Put a value on the loss so you can judge any rule against it. Say the average spend is $48 a cover and 70% of that is gross profit after food and drink costs, so each cover earns about $33.60. Assume 40% of no-show seats get refilled by walk-ins or the waitlist. A lost cover is then worth roughly $20, and 22 lost covers per weekend (178 over eight) is about $450 a weekend. Replace each of those three assumptions with your own. Eight weekends is a small sample, so treat a band with a handful of bookings, like the groups of ten or more here, as a pointer rather than a fact.
Lead time and booking channel: two more cuts of the same log
Your prompt also asked for no-shows by how far ahead the booking was made and by channel. Both cuts often reveal a cheaper lever than a deposit. In the same eight weekends (illustrative):
| Booked how far ahead | Bookings | No-shows | No-show rate |
|---|---|---|---|
| 0 to 2 days | 300 | 9 | 3.0% |
| 3 to 7 days | 250 | 17 | 6.8% |
| 8 days or more | 106 | 17 | 16.0% |
| Booking channel | Bookings | No-shows | No-show rate |
|---|---|---|---|
| Phone | 240 | 8 | 3.3% |
| Own website | 260 | 16 | 6.2% |
| Third-party booking platform | 156 | 19 | 12.2% |
Bookings made eight or more days ahead are 16% of the total but 40% of the no-shows (17 of 43). A table booked more than a week ago is easy to forget, and plans change in between. The cheap fix is a third message a week out that asks for a YES, in addition to the two-day text:
Hi [first name], [restaurant] here. Your [Sat] table for [4] is a week away. Reply YES to keep it or NO to release it. Free changes until [Thu 6pm]. (148 characters)Platform bookings are the other hotspot at 12.2%. A log cannot tell you why, so don't guess; just make sure those guests also receive your own confirmation text rather than relying on an email the platform sends. If a platform restricts what you can charge, read its terms before you add a payment rule to that channel. Cross-tabulating the cuts (party size by lead time, say) is tempting, but with 656 bookings any cell under about 20 bookings is a pointer, not a finding. Ask the AI to flag those cells instead of drawing conclusions from them.
Card hold, deposit or prepaid ticket: matching each to a party size
OpenTable's own guidance names three payment tools, and the distinctions are useful whichever booking system you use. A card hold takes the card at booking without charging it, and you charge a fee only if the guest does not show or cancels late. A deposit takes money at booking, which you normally credit against the bill. A prepaid ticket (OpenTable calls these prepaid Experiences) takes the full price in advance, which suits set menus and events. The same page suggests requiring deposits by party size, by specific dates or for high-demand time slots, and testing on particular dates or party sizes before rolling out widely. Its figures on how much each tool reduces no-shows come from the vendor, so I leave them out. The OpenTable guide is worth a read for the vocabulary.
The trade-off is friction against certainty. A hold asks little of the guest, but a fee you try to charge afterwards can bounce or be disputed. OpenTable's page itself says holds can lead to complaints, chargebacks and failed transactions, while a deposit is already in your account. Here is the rule I would draft for the restaurant above, built from the table.
| Party size | What you ask for | Why |
|---|---|---|
| 1 to 2 | Nothing up front. Confirmation text two days ahead, same-day reminder | Lowest rate, and the most bookings to put off with a payment step |
| 3 to 4 | Nothing up front. Both texts; unconfirmed tables get a chaser text at 3 pm | Costs the most lost covers in total, but a payment step would hit 210 bookings |
| 5 to 6 | Card hold, $15 a head, fee only after the 15-minute grace period or a cancellation inside 24 hours | Rate is above ten percent; the hold is a light ask |
| 7 to 9 | Deposit of $20 a head, credited to the bill, kept if cancelled inside 48 hours | Rate above 14% and each no-show empties a large table |
| 10 or more | Deposit of half a set menu, plus a phone call five days out to confirm numbers and allergies | Rare, expensive and worth a conversation |
The amounts are placeholders. I would set the per-head figure below the roughly $34 of gross profit an empty seat costs you here, because a fee guests accept is worth more than a full one they argue about. Treat the busiest nights as their own band: if festive weeks or a holiday brunch fill instantly, ask for deposits from parties of four or more on those dates only. And start where the pain is greatest. Switch on the 7-plus rule first, since it affects only 36 of 656 bookings, and extend to the 5 to 6 band after four weekends if the numbers hold.
Writing the policy so guests see it before they pay
A policy only works if the guest sees it at the moment they hand over a card, and again in the confirmation message. It needs five facts, and every one of them should be a number or a time, not an adjective:
- How much is held or charged, and per what (per guest, per table).
- When it is charged: no-show after how many minutes, cancellation inside how many hours.
- How to cancel or change, with the phone number or link that works at 11 pm as well as 11 am.
- What happens to a deposit: credited to the bill, refunded, or kept.
- Who can waive it: a named role, for illness and genuine emergencies.
Write the cancellation policy shown when a guest books a table for 7 or more, in plain English, under 90 words.
Facts: $20 a head deposit, credited to the bill. Free cancellation until 48 hours before the booking time.
Inside 48 hours, or if no one arrives within 15 minutes of the booking time, the deposit is kept.
Changes by phone [number] or the link in the confirmation text. The manager may waive in an emergency.
Tone: polite, direct. No legal threats, no capital letters, no exclamation marks.A typical draft comes back with phrases like "non-refundable under all circumstances", "we reserve the right to take further action" and "no exceptions". Strike all three. The first contradicts the manager's waiver, the second is an empty threat that sounds hostile, and the third removes the discretion that lets you be kind in a real emergency. A draft may also say "if you are late" without a number; keep your 15 minutes. What you want is a version a guest would read in ten seconds: "A deposit of $20 per person secures your table and comes off your bill. You can cancel free until 48 hours before. After that, or if no one has arrived 15 minutes after your booking time, we keep the deposit. Need to change something? Call [number]."
Log every waiver with the date and the reason. If the policy touches consumer rules on fees or terms, have a qualified adviser read the final wording; an AI draft is not legal advice. For the awkward replies that follow a charge, answering restaurant complaints with AI has wording that stays calm.
Exceptions: illness, regulars and the guest stuck in traffic
The rule will be tested in the first fortnight, usually by someone you like. Decide the answers now, in writing, and put them in the same sheet as the log so the next manager does the same thing.
| Situation | Suggested response | Who decides |
|---|---|---|
| Guest rings with a genuine emergency or illness | Waive the fee, or move the deposit to a new date within a set window | Duty manager, logged |
| A regular forgets and apologises | Waive once with a note; apply the policy the second time | Duty manager |
| Running late but on the way | Hold the table through the grace period, then ring the guest before releasing | Host |
| A group shrinks inside the cancellation window | The deposit for guests who no longer come is kept; the policy wording should say so | Written policy |
| A card-hold charge fails | Try once more the next day, then stop; chasing a small fee is rarely worth a bad review | Manager |
One safety rule sits above all of these: never write card numbers into a sheet, a text or an AI chat. If you take bookings by phone, send the guest a payment link from your booking system or payment provider, so card details go straight to the processor and never through your notes.
Two reminder texts, each asking for something different
The first message asks a question and the second does not. If both ask for a reply, guests ignore both. Here are mine for an ordinary booking; the character counts are with the placeholders in, so recheck once they are filled.
Text 1, about 48 hours before (146 characters):
Hi [first name], it's [restaurant]. Table for [4] on [Friday] at [7:30pm]. Reply YES to confirm or NO to release it. Free changes until [Thu 6pm].
Text 2, the day of, about 3 hours before (139 characters):
See you tonight at [7:30], [first name]! We hold tables 15 min. Running late? Call [number]. Can't make it? Reply NO so we can offer it on.Keep each text near 160 characters or fewer. Twilio's documentation, for one, explains that longer messages are split into segments and billed per segment, that a single emoji switches the message to an encoding with a limit of 70 characters, and that curly quotation marks sit outside the standard SMS character set (its optional Smart Encoding swaps them for straight ones; other senders may not). AI tools often produce curly quotes and apostrophes, so ask for straight ones. For groups of seven or more, the first text becomes a phone call, and the second asks for final numbers and allergies. Then decide who reads the replies before the first message goes out. A common failure is a reminder sent from a number nobody monitors: guests answer "sorry, can't come", nobody sees it, the table sits held, and the no-show happens anyway. Name one person or one shared inbox for replies on service days. If your booking system sends its own reminders, improve its templates with the same wording; if it cannot, an SMS tool or the booking platform's messaging does the sending.
Ask an AI for variants when you want to test wording against your confirmation rate:
Write five versions of this confirmation text, each under 150 characters. Keep [first name], [restaurant], [party], [day] and [time] as
placeholders. The guest must reply YES or NO (no other words). Friendly, straight apostrophes, no emojis, no threats, at most one exclamation mark.
Original: Hi [first name], it's [restaurant]. Table for [party] on [day] at [time]. Reply YES to confirm or NO to release it.Expect one version that says "confirm or lose your table", which is a threat in a nice font, and one that asks guests to "reply C to cancel" when your system only reads YES and NO. Discard both. Pick two of the remaining three, send one to half the bookings and one to the other half over two weekends, and compare reply rates. With a few hundred bookings the difference will be rough, so choose on clarity unless a version clearly wins.
The 2:30 sweep: paste the replies, get five lists
Most no-show prevention is a timing problem, so structure it as a clock:
- Two days before: text 1 goes out (large groups get a call).
- Morning of service: check the reply inbox and update the booking sheet.
- 2:30 pm: the sweep. Paste today's bookings with their replies into an AI, and get the lists below. Five minutes.
- 3:00 pm: a chaser text to silent small parties; phone calls for silent groups of five or more.
- Three hours before: text 2 goes out.
- 5:30 pm: offer freed tables to the waitlist (next section).
The sweep needs no names. Use booking IDs, party sizes, times and what came back.
Today's bookings with replies. Rule: parties of 1-4 must reply YES by 3pm; 5-6 hold a card; 7 or more paid a deposit.
Sort into: CONFIRMED, CHANGE REQUESTED, CANCELLED, SILENT (1-4), SILENT (5 or more), NEEDS A HUMAN.
Count only a clear yes as confirmed. Never offer a new time or release a table yourself. Anything unclear goes to NEEDS A HUMAN.
B101 | 2 | 6:00 | YES
B102 | 4 | 6:30 | (no reply)
B103 | 6 | 6:30 | card held | YES
B104 | 2 | 7:00 | can we do 7:30?
B105 | 8 | 7:00 | deposit paid | (no reply)
B106 | 3 | 7:30 | yes x
B107 | 5 | 7:30 | card held | we may be 6, will confirm
B108 | 2 | 8:00 | NO sorry
B109 | 4 | 8:00 | (no reply)
B110 | 2 | 8:30 | (thumbs-up emoji)A good answer (illustrative) puts B101, B103 and B106 under confirmed. B104 goes to change requested, B107 to needs a human, because the party might grow to six and nobody has confirmed a number. B108 is cancelled and the 2-top at 8:00 is available for the waitlist. B102 and B109 are silent small parties for the 3 pm chaser, B105 is a silent group of eight who must get a phone call even though a deposit is paid, and B110 is a human call: a thumbs-up is probably a yes, but it is not what your rule asks for.
Where a sweep goes wrong: a model can count the emoji as confirmed, promise B104 the 7:30 slot because the sheet looks open, or invent a reply that was never there. That is why the prompt says never to offer a time. The AI cannot see your floor plan or who is booked on table 12. It sorts; a person decides. Only the booking system should release a table.
Backfilling from the waitlist without false urgency
A refilled four-top at $33.60 gross profit a cover is worth about $134, so a few minutes spent on the waitlist are well spent. The mechanics matter more than the wording. Decide how many tables you are offering, message that many guests in order, let the first YES win, and send a short "sorry, it's gone" to the rest. Give each guest a clear window.
A table for [2] at [8:00pm] tonight has opened up at [restaurant]. Reply YES within 15 minutes and it's yours; after that it goes to the next guest. (148 characters)An AI draft may add "Hurry! Only one table left!". The scarcity is false, and the guest who arrives to a half-empty dining room will feel it. Ask for a version with no pressure words and keep the 15 minutes. The waitlist tutorial covers the tools that automate this, and your pre-shift briefing is the place to tell staff which tables are still unconfirmed at 5 pm, so the floor is not surprised by a gap at 7:30.
Judge the rule after four weekends, not four nights
Run the new rules for four weekends, then give the AI the same log structure and ask it to compare the two periods. Four weekends is still a small sample; look for direction. Here is what a sensible review table looks like for the bands that got a rule (illustrative).
| Measure, parties of 5 or more | Before (8 weekends) | After (4 weekends) |
|---|---|---|
| Bookings per weekend | 13.3 | 13.5 |
| No-shows | 14 of 106 (13.2%) | 4 of 54 (7.4%) |
| Card-hold fees attempted, and failed | none | 3 attempted, 1 declined |
| Complaints about the policy | none | 1 |
The first row is the one owners forget. If bookings per weekend fall as soon as you add a payment step, the rule is turning guests away and the lower no-show rate is the wrong yardstick. Here bookings held steady, so the friction was acceptable. The failed charge is the realistic wrinkle: with a card hold, you only find out the card does not work when you try to use it. If that happens more than occasionally in the 5 to 6 band, move that band to a deposit, since a deposit is collected when the booking is made.
A rough check of what is at stake: if the new rule halves no-shows in the 5-plus bands, you regain about six covers a weekend (48 over eight weekends). At $20 a cover that is roughly $120 a weekend, or about $970 over the same eight weekends. That is an assumption to test, not a promise, but it tells you the setup effort has a ceiling and a payback. Cover forecasts also firm up once no-shows fall; forecasting covers becomes more reliable when fewer bookings evaporate. For the general version of reminders and rebooking beyond restaurants, see reducing no-shows with AI reminders.
No-show questions restaurant owners ask
Should a restaurant charge a deposit for a table of two?
Usually not. Small parties are the bookings you least want to put off, and in the example log their no-show rate is the lowest. Ask for a reply to a confirmation text instead. Only add a payment step for twos on specific nights if your own log shows a high rate there, and test it on that night first.
How far ahead should the first confirmation text go?
About two days ahead for ordinary bookings, which leaves time to refill a released table, and earlier for large groups, where a phone call five days out is reasonable. The first message should ask for an answer. The second, on the day, should simply reassure and give a number to ring.
What if a guest disputes a no-show charge?
Reply politely, point to the policy they saw at booking, and keep your records: the policy text, the time they agreed, and the confirmation messages. Waive the charge for a genuine emergency and note it. If the dispute goes through their card provider, follow your payment provider's process, and ask an adviser if terms are in question.
Can AI send the reminder texts by itself?
Not on its own. Your booking system or an SMS tool sends the messages and takes the payments. AI drafts and tests the wording, reads the replies you paste in, and sorts them for a person to act on. If your booking system sends automatic reminders, use AI to improve those templates.
Further reads
- Can AI Answer the Phone and Take Restaurant Reservations? — What AI can and cannot do when guests ring to book.
- AI Chatbot for Restaurants: Hours, Bookings and Hand-Offs to Staff — Put the deposit policy in a website chatbot's answers.
- How to Build a Restaurant Staff Rota With AI Demand Forecasts — Use the covers forecast to staff for the evening you expect.
- SevenRooms Voice AI: What It Does and Who It Suits — A booking platform's voice AI, and who it suits.
- Restaurant AI Voice Agent: 12 Test Calls to Run Before Go-Live — Test calls to run before an AI voice agent takes bookings.
- How to Use ChatGPT Scheduled Tasks for Business Reminders — Nudge yourself to run the daily reply sweep on time.
- Owner.com Pricing for Restaurants: Flat Rate or Per-Order Fee? — Owner.com's $249 plan with a 5% order fee against the $499 flat plan: the break-even in sales and orders, with worked monthly numbers.
- Pickleball Court Booking Software: Rules, Reminders and No-Show Fixes — How a small pickleball venue sets booking rules, takes payment up front and sends reminders that cut no-shows, with AI drafting the wording.
- Bakery Pre-Order Form for Christmas and Easter With AI — Form fields, slot caps, deposit wording and a reminder schedule, followed through a sample 120-order Christmas season with AI drafting the words.
- Board Game Café Business Plan: Table Pricing, Menu and Bookings With AI — How a board game café can price table time, cost a game-friendly menu, design booking slots and plan year one, with AI drafting and a spreadsheet checking.
- Bowling Alley Marketing: Eight League and Party Offers Written With AI — Eight league, party, school and quiet-hour offers for a bowling alley, each with an AI prompt, a sample draft and the prices only you should set.
- Dog Boarding Cancellation Policy: Peak-Season Wording With AI — Peak-season wording for a dog boarding cancellation policy: deposit tiers, holiday blackout dates, an AI prompt and reply scripts you can adapt.
- Event Venue Contract: Deposit, Cancellation and Damage Terms With AI — A clause-by-clause guide to deposit, cancellation and damage terms for venue hire, with an AI drafting prompt and five checks before a solicitor sees it.
- Restaurant Influencer Marketing: Shortlist and Brief Creators With AI — Shortlist local creators in a sheet, send a one-page brief with ad disclosure, and compare each comped meal's cost with tracked bookings.
- Taxi Business Automation: AI Booking Confirmations and Receipts — Send taxi booking confirmations, driver job cards and receipts automatically, with AI reading messy requests and your records doing the sums.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: OpenTable's published guidance on credit card holds, deposits and prepaid experiences; Twilio's documentation on SMS length and segments. The no-show log, costs and message examples in the worked example are illustrative.