A bot booked your best table
A diner's AI assistant hammered a restaurant's booking system around 200 times an hour until it got a table — and got its owner banned. For any small business with limited slots, the question is no longer whether bots book, but whether a person is behind each booking.
Last month a man in New York wanted a table at one of the city’s hardest-to-book restaurants. So he asked his AI assistant to get him one.
It did not give up. By his own account it sent roughly 200 requests an hour, around the clock, with a burst of up to 375 each morning at nine, the moment the restaurant opened its bookings for the day.
It got him the table. Then the booking platform deactivated his account. Its explanation was plain: it does not permit unapproved bots or agents to use the system on their own, because they introduce risk and give some diners an unfair advantage. He was later reinstated, and said he had learned his lesson.
Why this matters to a restaurant with twelve tables
A famous New York dining room can survive a few bot-booked tables. A small independent place, a two-chair barber, a physio with eight appointments a day, a pottery class with six wheels — they can’t.
Anything with a fixed number of slots has the same weakness. If one person’s software can check your availability two hundred times an hour, while everyone else checks once when they remember to, the software wins every time. The regular who has come in for years loses to someone who has never heard of you.
And it does not stop at one person getting an unfair go. The same behaviour, pointed at resale, turns your best slots into something to be grabbed and sold on. Paid reservation clubs and grey-market resellers already do a version of this for the busiest restaurants; tireless software makes it cheaper to do to everyone else.
We have to square this with something we said
Earlier this month this blog argued the opposite-sounding thing: that people are sending AI assistants to book things for them, that most small business websites make that impossible, and that you should stop putting needless barriers in the way.
Both are true, and the difference is the useful part.
An assistant booking one table for one real person is just a new way of picking up the phone. That is a customer. You want them.
Software checking your availability hundreds of times an hour, to grab whatever appears — whether for its owner or for resale — is something else. It is not a customer being helped. It is a queue being jumped.
The goal was never to block automation, or to wave it all through. It was to make sure there is a real person at the end of every booking, and that scarce slots go to people rather than to whoever runs the fastest software.
How to tell the difference without a fraud team
You do not need detection software. You need booking rules that are fair, cheap, and unattractive to anyone who isn’t actually coming.
- A name and a phone number on every booking, and a confirmation the person has to answer. A human answers a text. A reseller’s software has nobody to reply.
- A small deposit or card hold for your busiest slots. It is the oldest no-show fix in hospitality, and it is also the one thing that makes hoarding expensive.
- One booking per person per evening or day. Simple, fair, and it stops one account grabbing several slots “just in case”.
- The name on the booking turns up. Say plainly that bookings are not transferable. Resale stops being worth the effort when the table cannot be sold.
- Keep something back. A couple of tables for walk-ins, or a phone line for regulars. A slot that is never released online cannot be grabbed online.
None of that stops a customer’s assistant booking a table for them. It just means the assistant has to book like a guest — one table, a real name, a reply to a text.
The fair question
devkoi doesn’t run booking systems, take deposits or decide who gets a table. If your bookings go through an outside tool, the settings above live there.
What devkoi does build is the page where your rules are written down. That matters more than it sounds: a deposit or a “one booking per person” rule feels fair when customers can read it in advance, and petty when they discover it at the door.
What to do this week
1. Write your booking rules on your website. Deposits, cancellations, one booking per person, no transfers. Plainly, in advance, so nobody feels ambushed.
“Add a booking policy section: £10 deposit for Friday and Saturday evenings, refunded if you cancel 24 hours ahead, one booking per person, and the name on the booking must be in the party.”
2. Require a name and phone number, and ask for a reply. Check whether your booking tool can send a confirmation that needs answering. A reply from a person is the cheapest proof there is.
3. Put a deposit on the slots people fight over. Not every slot — just the scarce ones. It protects you from no-shows whoever made the booking.
4. Keep a human route in. A phone number for bookings, or tables held back for walk-ins, written on the site.
“Add: we keep two tables for walk-ins every evening, and regulars can always ring us on 0123 456 7890.”
5. Don’t block assistants outright. A customer whose assistant books one table under their own name is a customer. Make the rules about people and fairness, not about software.
6. Watch for the pattern. A slot that is always gone the moment it is released, bookings in names nobody recognises, a cluster of no-shows on your best nights. That is the shape of this problem, and it is worth a word with whoever runs your booking system.
For most of its history, a reservation was a small promise between two people: I’ll hold this table, you’ll come and sit at it.
Software can keep the first half of that promise faster than any human ever could. It still can’t keep the second. The fix is to make every booking ask for the part only a person can do — turn up.