Calling 3,000 London Restaurants
with AI
Michelin sends inspectors. Harden's surveys diners. We send a phone call.
First Order asks for the must-order dish. Queue Index asks about walk-in queues. Buggy Smart checks buggy access. Each one calls real London restaurants by phone.
Restaurants answer the phone way more than you'd expect
48% answer rate on a Saturday lunchtime. Independent restaurants pick up. Chain restaurants with IVR systems don't. The places you actually want to hear from are the ones that answer.
The interesting data is the reaction, not the answer
The personality of the response is the product. These aren't data points. They're character sketches that tell you more about a restaurant than any review.
"If you come, we can see if there's space. But if there isn't space, then there is no space."
Jolene, Stoke Newington
3pm is the magic hour
Lunch rush done. Kitchen cleaning up. Someone standing near the phone with nothing urgent to do. Timing the calls matters more than the script.
One question is the whole product
Every time I added a second question, responses got worse. People give their best take when you only ask for one thing. The constraint isn't a limitation. It's the design decision.
The AI detection moment is content
When a restaurant clocks the AI, that's the most shareable moment. Don't hide it. Feature it. The detection is more entertaining than the dish recommendation.
"Sam, this feels like I'm speaking to an automated service. Is that correct?"
Brawn, Columbia Road
Volume beats precision
15% success rate sounds terrible until you have 4,060 venues. That's 600 successful conversations. One OpenStreetMap query returned 2,993 restaurants with phone numbers in 30 seconds.
The server should do one thing
Every project started as a monolith: calls, transcripts, classification, deployment. Four failure modes in one process. Now the server just makes calls. Everything else happens elsewhere.
Each piece can fail independently and get fixed without touching the others. No database. No filesystem. No monolith.
Your API provider is your database
ElevenLabs stores every conversation permanently. Once I stopped trying to save transcripts on my own servers, the whole architecture simplified. The data already lives somewhere permanent.
Shared resources break in ways you can't see
Two projects sharing one Twilio number seemed efficient. Then the calls overlapped silently. No errors. No alerts. Just bad data in both projects. Separating them cost an extra five quid a month.
Ship the pipeline, not the product
The calling works. The responses are interesting. What broke was everything in between. Filesystem wipes, silent API failures, missing notifications. The plumbing is the product.
Every guide sends a critic. We called the chef.
