Software Can't Apologise at 9:40 on a Saturday

integration limits, delivery failure handling, direct ordering support, restaurant account management

Watch any restaurant technology demo and count the failures.

There are none. Order arrives. Rider is assigned. Food is delivered. Status updates fire. Everybody nods.

Nobody demos 9:40 on a Saturday, when no rider has been allocated, four tickets are sitting under the pass, and a customer is thirty five minutes into a thirty minute promise.

That is the moment the relationship with that customer is actually decided. It is also the exact moment software is worst at its job.

Automation is strongest where it matters least

This is not an argument against automation, which would be silly. It is an argument about where the value sits.

The 2026 picture on AI in customer service is reasonably clear. <cite index="15-1">It works well for tier one FAQ deflection, resolving 55 to 70 percent of volume without humans, for ticket routing, and for conversation summarisation. It remains overpromised for full human replacement, complex complaint resolution, and genuine empathy, because resolution requires emotional intelligence, service recovery judgement, and decisions about policy exceptions that current models get technically correct but tonally wrong</cite>.

Read that last part again. Technically correct and tonally wrong.

Which produces an uncomfortable shape. The more routine a task, the better software handles it. The more emotionally loaded, the worse. And failures are the most emotionally loaded moments in the entire business.

So the tool is at its strongest on the interactions nobody remembers, and at its weakest on the ones that decide whether somebody orders from you again.

The trap: making the bot better makes it worse

Here is the finding that should stop anyone planning to automate their way out of this.

Research on AI mediated service recovery describes a genuine paradox. <cite index="11-1">As generative AI becomes more adept at mimicking human conversational norms, customers shift their evaluative lens from procedural sufficiency to relational authenticity. What begins as an efficient exchange is reinterpreted, especially under high emotion conditions, as a moral interaction. The more the AI sounds human, the more it is held to human relational standards</cite>.

That is not a bug you can patch. It is a moving target that moves in the wrong direction.

A crude autoresponder gets judged as a form. A convincing one gets judged as a person, and then fails as a person, which is worse. Every improvement in fluency raises the standard it will be measured against.

Work published in the Journal of Consumer Behaviour reaches the same place from a different angle: <cite index="12-1">AI chatbots offer scalability, speed and unlimited availability, but are perceived as impersonal, particularly in service recovery situations that require empathy</cite>.

And research in the Journal of Business Research found that <cite index="13-1">the relative effectiveness of AI versus human agents depends on the response strategy adopted, such as apology versus denial, which highlights that who responds can matter when recovery involves social and emotional interpretation</cite>.

Who responds matters. Specifically for apologies.

An apology needs authority behind it

There is a reason for that, and it is not sentimentality.

An apology is only worth something if the party giving it could have done otherwise and can make it right. That is what makes it an apology rather than a notification.

A system message saying your order is delayed carries no authority. Everyone reading it knows the sender cannot decide anything, cannot compensate anyone, cannot escalate to a person who can, and does not care. It is weather. You do not accept an apology from weather.

This matters commercially because service recovery is not soft. Done properly it produces more loyalty than a clean experience would have. But the conditions are strict: <cite index="10-1">post failure loyalty depends on customer attribution, sincere recovery effort, company responsibility, and resolution exceeding revised expectations</cite>. And in this sector specifically, <cite index="11-1">the recovery paradox is contentious in online food delivery, where instant gratification, tight delivery windows and multi party accountability complicate both recovery and consumer perception</cite>.

Sincere effort. Responsibility. Multi party accountability. Not one of those is a data pipeline problem.

The judgement software cannot make

Take the actual decision at 9:40 on a Saturday.

No rider allocated. The food is ready. What happens next?

Do you reassign to another partner and accept the food will be twenty minutes late? Do you refund immediately and protect the review? Does it matter that this customer has ordered eleven times before? Does it matter that it is a Rs 400 order rather than a Rs 3,000 one? Does it matter that the restaurant is in the middle of its heaviest hour and cannot remake anything?

Software resolves this by applying a policy. A policy is an average, and averages are exactly wrong for the specific customer in front of you, which is the only customer that exists at 9:40.

And there is a further question most vendors never even raise. Whose decision is it?

A system defaults. It refunds automatically, or it does not, according to a rule somebody set once. A service can defer to the person whose name is on the bag.

Why almost nobody does this

Now the honest part, because there is a reason the industry sells integrations instead.

Staffing does not scale the way software does. An integration is written once and serves ten thousand restaurants at almost no marginal cost. A named person watching allocation for a specific restaurant costs money every month, forever, and the cost grows in a straight line with the customer base.

That is the opposite of how software businesses are supposed to work, and it is why the standard answer to operational risk is a dashboard. Dashboards have wonderful margins.

We have taken the other side of that trade at Menuthere, and I would rather say plainly what it costs than pretend it is free. It means we grow more deliberately than a pure self serve product would. It means onboarding takes a week rather than an afternoon.

What it buys is the only thing that actually matters at 9:40, which is somebody whose job it is.

How it works in practice

Every restaurant on Menuthere gets a named account manager who oversees delivery allocation on your orders, from the moment a Porter booking is raised until the food is handed over.

If no rider is allocated, we arrange an alternate delivery partner without waiting for you to notice. If the delivery genuinely cannot be completed, we refund the customer so the experience closes cleanly and your name is protected.

And no refund is ever processed without your permission. We recommend, you decide.

That last line is not a support policy. It is a position on who owns the customer relationship, and the answer is not us.

The question to ask any vendor

If you take one thing from this, take the test.

Ask whoever is selling you restaurant software: what happens at 9:40 on a Saturday when the rider does not show?

If the answer is a dashboard, a status page, an alert, a webhook or a ticket queue, that is not an answer. Those things tell you something broke. Not one of them fixes it, and none of them will speak to your customer.

Then ask the follow up, which is the one that separates vendors properly. Who decides whether to refund? If the system decides, you have outsourced a judgement about your own customer to a rule written by somebody who has never met them.

The bottom line

The restaurant industry named itself after the thing software cannot do. Hospitality is the reception of a guest, the accommodation of the specific person in front of you, the judgement call made warmly and fast.

Then it spent a decade buying tools whose core competence is treating everybody identically.

Most of that was correct. Billing, ordering, inventory, menus, payments and reporting should all be automated, and they are better for it.

But the exception path is not the routine path, and the exception path is where restaurants are actually judged. Every kitchen can serve a table when everything goes right. The craft has always been in what happens when it does not.

An integration is a promise that nothing will go wrong.

A service is a promise about what happens when it does.

Ask us what happens at 9:40 on a Saturday. Menuthere gives you WhatsApp ordering, Porter delivery from the same screen, and a named account manager watching allocation on every order.

Sources: Journal of Marketing Communications 2025 (AI mediated service recovery, relational authenticity, food delivery accountability), Journal of Consumer Behaviour 2026 (chatbot complaint handling and empathy), Journal of Business Research 2026, Zhao et al. (agent type and response strategy in recovery), AmplifAI 2026 (service recovery paradox conditions), Builts 2026 (AI customer service capability boundaries).