Escalation
Knowing what not to decide is the whole job here. Most of a call, Dohos handles on its own, because the answer is a fact the restaurant already published or a request its own rules already cover. The moment that stops being true, Dohos stops pretending otherwise — a person gets it, honestly, with the caller told exactly what’s happening and what isn’t.
A rule the restaurant set, or something
a caller asked for outright.
Two different things send a call toward a person, and neither one is a mood Dohos infers from how urgent a caller sounds. The first is direct: someone simply asks. The second is structural — the call, or the order underneath it, crosses a boundary the restaurant set up in advance, checked the same way every time rather than judged fresh on each call.
The four order-side triggers are defined in full on orders; here, they’re one branch among several that end up in the same place. Every one of these is a rule the restaurant set in advance, or something a caller asked for outright — never a mood Dohos reads into a voice.
The real answer,
instead of a reassuring one.
What happens when a caller asks for one depends entirely on what’s actually available right now. When a live handoff is available, Dohos says so and sets expectations before it even tries:
I’m the AI assistant. I’ll try to connect you with [verified restaurant or Dohos support role]. The transfer may not succeed. I’ll tell you when an authorized person has actually joined.
When nobody is reachable live, but a request can still be logged for someone to see:
A live person is not available through this call. I can create a support request through [verified channel] or give you the restaurant’s verified contact option. I can’t promise when someone will respond.
And when there’s no verified way to reach a person at all right now, Dohos doesn’t fake it:
I can’t verify a human-help connection right now. I won’t pretend to transfer you. Please use [verified public restaurant / emergency / support alternative if available] or try again later.
A hold tone, a ring, or an attempt that’s merely been made is never treated as proof someone has actually joined the call. Dohos says a person is there only once that’s actually confirmed.
The wait is a setting the restaurant chose.
Not a number Dohos is promising.
Once a call or an order actually crosses one of the lines above, it goes first to whoever the restaurant has named manager on duty for that shift — its own schedule, or a manual override, decides who that is, never Dohos. If the manager doesn’t respond inside the window the restaurant itself configured, the same request escalates once to the owner, rather than sitting there unanswered.
The person the restaurant’s own schedule, or a manual override, names as responsible for exceptions during the current shift.
Where an unanswered exception goes next, on a timer the restaurant configured — never a number Dohos sets or publishes.
What “notified” actually means, today
“Notified” is worth being exact about, because it’s easy to hear it as a phone ringing somewhere. That isn’t what happens today. When an exception reaches a manager, what actually happens is a signal appearing on a screen the restaurant already has open during a shift — the operator console, or the tablet on the pass. Dohos doesn’t place a call to a manager’s personal phone to trigger this, doesn’t send a text message, and doesn’t send an email. The record behind a notification has room for all three of those channels — the underlying design allows for them — but nothing currently uses that room.
An exception waits out the owner-fallback window the same way it would if the manager had simply not answered. There’s no separate channel standing by to reach a phone that isn’t already showing Dohos.
The caller is never left assuming
a handoff happened when it didn’t.
The transfer did not connect. No person received the handoff through that attempt. Your order remains [verified state]. I can [retry once / create support request / provide verified contact / stop safely].
Attempts fail sometimes, for ordinary reasons — a line is busy, nobody picks up, the call drops before it completes. The point is that whatever the order or request already was stays exactly that: stated plainly, not left to guesswork.
What happens to the order while this is sorted
An order waiting on a manager isn’t lost, and it isn’t quietly dropped while everyone assumes someone else has it. It holds in review until a person with real authority actually decides, and the caller is told which of three things happened — never left to assume the best.
| OUTCOME | WHAT THE CALLER IS TOLD |
|---|---|
| APPROVED | The order proceeds, and the caller is told so. |
| DENIED | The caller is told, and offered whatever alternative the restaurant allows. |
| CALLBACK REQUESTED | Tracked and kept open — not a vague promise that someone will call. |
None of the three is silence. A callback specifically has no clock that quietly runs out on its own — it stays open until the restaurant marks it resolved, not until some interval passes unnoticed.
Getting it wrong costs more
than getting it slow.
A question about an allergy or cross-contact gets treated differently from an ordinary menu question. Dohos doesn’t guess, and it doesn’t promise something nobody has actually confirmed:
I can’t determine whether food is safe for an allergy or prevent cross-contact. Please confirm directly with the restaurant. If someone may be having a medical emergency, contact local emergency services now.
Where a live handoff exists for exactly this reason, Dohos offers it — as a try, not a guarantee:
I’ll try to connect you with the restaurant so they can address ingredients or preparation directly. I can’t guarantee their answer or food safety.
Dohos still passes along whatever the restaurant’s own menu actually says, attributed as the restaurant’s own statement, not Dohos’s. What never happens is a menu label turning into a promise, or an attempted transfer being described as one that succeeded before it has.
A cross-contact question, start to finish
A caller is midway through ordering two sandwiches when they ask whether the kitchen can keep one of them away from tree nuts. Dohos doesn’t answer that on its own — it opens with the disclaimer, then offers what it actually has, framed honestly as a try. The attempt goes out. This time it doesn’t connect — nobody picks up on that line in the moment. Dohos tells the caller exactly that: the transfer didn’t connect, no one received the handoff, and the sandwich order they’d already been building stays exactly where it was — not lost, not silently cancelled.
From there, Dohos offers what’s actually available next: try the transfer once more, log a request the restaurant will see, or hand over the restaurant’s own verified contact. Whichever the caller picks, the order itself hasn’t gone anywhere — waiting on one open item, not restarted, and not silently submitted around it.
No fourth branch
where Dohos pretends.
So does anyone actually see this fast?
No number is published for that, and there isn’t a hidden one. What actually happens is the signal above — an alert on a screen the restaurant already has open — with no timing commitment attached to when someone looks at it.
What if the manager's asleep, or just doesn't check?
The owner-fallback window exists for exactly that. If neither one responds inside the windows the restaurant configured, the request doesn’t vanish from view — it’s marked plainly as unanswered, with nothing about it ever described as complete.
Can a caller just insist and get a human?
Insisting doesn’t create a person who isn’t there. What a caller actually gets is one of the three honest branches above — a live attempt, a logged request, or a verified alternative — depending on what’s real right now.
What happens to my order while all this is sorted?
It holds in review — not lost, not silently accepted, not silently dropped — and the caller is told which of the three real outcomes applies once it’s actually known.
No response-time figure — how quickly a manager or owner actually responds depends entirely on the restaurant’s own staffing and the window it configured, and nothing here should be read as one. A transfer attempt can fail, and when it does, Dohos says so plainly. Dohos is not an emergency service and can’t dispatch help — a caller facing what might be a medical emergency is told directly to contact local emergency services. An allergy answer is never a safety guarantee. And none of the thresholds, schedules, or fallback destinations above are Dohos defaults dressed up as settings — a restaurant that hasn’t configured a step yet simply doesn’t have that step available.
RELATED
Escalation flow
What reaches a human, when, and with how much context.
OPEN →PLATE Nº 015Reliability
It fails open: when something breaks, callers hear the truth and reach a person — never dead air.
OPEN →PLATE Nº 006Orders
Sizes, halves, swaps, allergies — the whole order, read back in full for a yes.
OPEN →RELIABILITY COVERS A DIFFERENT MANAGER-THEN-OWNER MOMENT — A TECHNICAL FAILURE INTERRUPTING A CALL ALREADY UNDERWAY, NOT A CALL THAT NEEDS A PERSON’S DECISION. A SEPARATE MECHANISM, COVERED ON ITS OWN TERMS.
See your own chain.
Tell us how your restaurant already handles a call that needs a person, and Dohos sets up the same chain for you — manager, then owner, on your own schedule.