When a restaurant turns on an AI phone agent, sometimes things go wrong. Most of what goes wrong has nothing to do with the AI.
I assumed the hard problems would be in the model, whether it be accents, interruptions, or making up menu items. Though those are real problems, but they’re not the hardest ones to solve, because everyone is already working on them.
When we went live at one of our largest clients, I sat staring at my screen, waiting for the first call to come through. It turned out to be a big, complicated order, and I watched with sheer relief as the agent got every last item and every modifier correct.
Then, the caller went to pay, and the bank blocked the charge.
The caller cursed out the agent (quite colorfully). From their vantage point, our agent had failed. From our vantage point, we knew the bank had failed. That didn’t matter.
This is one of the biggest lessons I’ve learned since we’ve started working with our clients. When you deploy into a real business, you’re plugging into a nuanced, delicate web of systems, and you become responsible for all of it.
Guests don’t know or care to know which systems broke in any given interaction. They called the restaurant, and the restaurant didn’t work. And with AI under intense scrutiny, the agent takes the blame for every failure, wherever it actually came from.
Another time, I got called while paddleboarding on PTO. Transfers to staff stopped working because the restaurant’s phone provider was down and blocking them. Nothing in our system had changed. However, to the person who asked for a manager and didn’t get one, it was because the agent wasn’t willing or able to transfer them.
Then there was the regular who called in their usual and was told it didn't exist. It didn't exist on the menu we'd been given. It existed in the heads of the staff who'd been making it for them for years. Every restaurant has an unofficial menu like this, and you won't find it in the POS.
This is why the standard way of onboarding an AI agent doesn't work. The standard way is a form: upload your menu, list your hours, send us your FAQs. It seems reasonable. But it asks the operator to know what an AI needs to know, and they don't. Why would they? They've never had to think about it - these little nuggets of knowledge formed out of months or years of lived human experience and habit. The important stuff that gives a restaurant its identity lives in staff's heads and in POS settings someone configured years ago, and a lot of it nobody thinks of until it comes up on a live call with an angry guest.
So the onus has to be on the provider. If you're putting AI into someone's business, it's your job to find out how that business actually works.
The other thing the form gets wrong is treating go-live as a day. It's a period. The first weeks are when you learn what you missed. You watch calls. You flag the questions the agent couldn't answer and add what it needed to know. You work with the operator on upselling and keep tuning it. This is closer to consulting than to software setup, and that’s how I’ve learned to see it, and how I’ve explained it to my team and clients alike.
That's why we deploy with forward deployed engineers instead of handing over a dashboard. An FDE finds the off-menu usual and the stale throttle time. More importantly, they bring what they find back to the product.
Each deployment makes the next one easier. After enough of them, the things that used to break just don't.
That compounding is our real advantage. We know how a real restaurant differs from a demo because we’re in a lot of them, hearing from operators and their guests every single day.
So if you're an operator looking at AI, don't just ask how good the agent is. Ask who's going to find out what it needs to know.
That's what we do at Palona. If you want to see what a deployment would look like for your restaurant, and meet the team that would run it, book a time here: palona.ai/contact.