The phone was the busiest part of the restaurant, and no one was looking at it.
An account of what I watched happen behind a counter during a dinner rush, the fixes I looked at and rejected, and what I built instead — written in the first person because it is one person’s reason, not a company position.
I spent time behind the counter of a busy independent restaurant during its dinner rush, and the thing that stuck with me wasn’t the line out the door or the ticket rail filling up. It was the phone.
It rang constantly, and it rang at the exact moments the staff had the least capacity to answer it. Someone would wipe their hands, jog to the counter, and spend two minutes on a call that could have gone to voicemail, while three tables waited to be greeted. If nobody could get to it in time, the caller didn’t leave a message. They called the next place.
What was being asked, most of the time, wasn’t complicated. Whether a specific size was still available. Whether delivery reached a specific block. Whether an order from twenty minutes ago was actually on its way. None of it needed a manager’s judgment. All of it needed a phone line somebody could get to, which is precisely the one thing a real rush doesn’t provide. I watched two calls come in back to back while a printer was already three tickets behind, and neither one was unreasonable to ask. The restaurant just didn’t have a free hand at that exact minute.
I thought about it from the caller’s side too, not just the counter’s. Nobody dialing a restaurant at seven on a Friday thinks of themselves as an inconvenience. They’re hungry, or they’re feeding a family, or they’ve already decided where dinner is coming from tonight, and a phone that just rings past them doesn’t feel like a busy restaurant doing its best. It feels like being ignored. Neither side of that call is doing anything wrong — the staff can’t be in two places, and the caller has no way to know that. The gap between them is the actual problem, not either person in it.
Missed calls during peak hours are a meaningful share of a restaurant’s lost phone orders. The exact figure depends on the restaurant, and I’m not going to publish an invented one here:
What I did see, consistently, was a phone that a fully staffed kitchen still couldn’t keep up with, because answering it was never really anyone’s job. It was everyone’s interruption. The industry-wide picture, from people who actually measured it, is the one part of this I can put real numbers against:
THOSE THREE DESCRIBE THE INDUSTRY, NOT THIS ACCOUNT AND NOT DOHOS. THEY ARE NOT A MEASUREMENT OF ANY RESTAURANT’S OWN LINE, INCLUDING THE ONE I STOOD BEHIND.
Three obvious answers.
I watched two of them fail on paper and one in a rush.
The obvious fix — hire someone whose only job is the phone — doesn’t survive contact with a restaurant’s actual economics. A phone-only hire is idle most of the day and still overwhelmed for two hours a night, and a restaurant running close to the margin it actually runs on can’t carry a role shaped like that. The other obvious fix, an answering service, solves the ringing but not the order — someone still has to write it down, still has to key it in, still has to get the modifiers right from a message left in a hurry.
There was a third option I looked at closely, and it’s the one that changed what I decided to build. A system that could take the call, sound natural doing it, and then hand a manager a screen full of orders to look over before any of them moved. On paper that solves the phone. In an actual rush it doesn’t solve anything — it takes the exact interruption that was happening at the counter and moves it to a screen, still during the same rush, still needing the same person’s attention at the same busy moment. Nothing about the restaurant’s actual problem got smaller. It just changed shape.
That was the moment the real question came into focus, and it wasn’t “can a system hold a convincing conversation.” Plenty can. It was: once the call ends, is there less work sitting on the restaurant, or the same work wearing a different interruption. A voice that sounds impressive on a demo and still needs a person to review everything afterward hasn’t done anything for the person running the floor. It has just moved where they have to look.
The phone-only hire that scales down to nothing between calls.
Something that answers immediately, knows what is actually available right now — not a printed menu from three weeks ago, whatever the kitchen actually has today — takes the order correctly, and hands the kitchen a ticket instead of handing a staff member an interruption. An ordinary order, inside whatever limits a restaurant sets for itself, goes straight through. Nobody stands between it and the kitchen just to confirm what was never in question.
The moments it shouldn’t handle alone — an allergy question, an order past the usual size, a caller who just wants a person — it hands to one, immediately, rather than guessing. That line matters more to me than almost anything else about this, because I watched what the alternative costs. A wrong guess doesn’t feel like a mistake in the moment. It sounds confident right up until someone finds out it was wrong, and by then it is already on a ticket or already promised to a caller who believed it. A person interrupted for something real is a fair cost. A kitchen quietly working from a wrong answer is not, and I built around the difference between those two rather than trying to make the second one happen less often.
I also insisted on reading the whole order back before anything moves anywhere — not a quick “got it,” the actual total, out loud, agreed to before it is sent. I had watched a phone order get keyed in slightly wrong more than once: a size misheard, a modifier dropped in the noise of a kitchen behind somebody taking the call, and the caller never finding out until the bag was already in their hands. Nobody was careless. It is just what happens when a person is doing three things at once and a phone order is only one of them. A system doesn’t have that excuse, so it doesn’t get the shortcut either. If it heard something wrong, the readback is where that gets caught, before it costs anyone anything.
And a call doesn’t have to become an order to count as something real. Someone calling to ask if the kitchen is still open, or whether a coupon is still good, or where their order actually is — that is a complete, ordinary reason to pick up a restaurant’s phone, and it deserves an honest answer, not a lesser version of one because it didn’t end in a sale. I spent enough shifts fielding exactly those calls to know they are not the residue left over after the real calls. They are most of what the phone is actually for.
The refusals list mattered more than the feature list.
I was at least as interested in what this should refuse to do as in what it should do, and that turned out to be the part worth writing down.
None of that is a limitation I’m apologizing for. It is the actual design. A system that always sounds certain isn’t more capable than one that asks when it should — it is just worse at telling you when to trust it. I would rather build something that says “I don’t know, let me get someone who does” at the right moment than something that never says it at all. What that refusal actually looks like on a live call is written out in full on escalation and reliability, not summarized here.
Some of this thinking comes from time spent inside a family restaurant, not just from watching one from outside. I’m not going to turn that into a dollar figure or a savings claim — one kitchen’s numbers aren’t anyone else’s, and I don’t think a founder’s own story is good evidence for what a stranger’s restaurant would actually save. What it did give me is a working respect for how much restaurant owners and staff already understand about labor, margin, and their own customers — more than I did walking in, and more than most software built for them seems to assume. I wasn’t trying to build something that explains a restaurant’s own business back to it. I was trying to build something that stays out of the way of people who already know what they are doing, and shows up only where a real decision is actually needed.
Right now, this is running as a real pilot, on one restaurant’s actual phone line, not a simulation built to look convincing in a demo. I would rather tell you that plainly than dress it up as something bigger than it currently is. There is no roster to point to, no funding number to cite, no wall of logos — just this account of why it exists, signed by the person who built it, and a product you can verify claim by claim rather than take on faith because a page like this one asked you to.
If your own restaurant’s phone sounds like the one I described at the top of this page, I’d like to hear about it — or just see it running. Sign up and put it on your own line yourself, or request access and an actual person will follow up — not a script, not an automated sequence, someone who will ask about your menu and your hours and work through it with you directly.
Tell me what your phone sounds like.
Sign up and see it running on your own line, or request access and an actual person follows up — about your menu, your hours, and the calls your line is already getting.