When something Dohos depends on fails mid-call, it says so — and tries for a person.
A call already underway can run into a real problem: something the system depends on has trouble right in the middle of things. What happens next is specific and tested. Whether a call reaches Dohos at all in the first place is a different question, and this page is careful not to blur the two.
One specific situation,
named before anything is claimed about it.
“Reliability” here means one thing: a call that has already been answered running into a failure partway through — the model, a speech service, or a database write having trouble mid-conversation. That is a real, well-evidenced situation, and the rest of this page walks through exactly what happens when it occurs.
Whether a call reaches Dohos at all is a different question with a much thinner honest answer. It is covered plainly further down rather than skipped. Keeping the two apart matters, because the tested behavior described next only ever applies once a call is already underway. It says nothing about what happens before that point.
Escalation describes a manager-then-owner sequence too, for a business reason — a caller asking for a person, or an order that needs a manager’s judgment. That one is a signal asking somebody to review something; nobody’s phone rings. This one is a live attempt to reach an actual number, and it only starts because something technical broke mid-call — never because of anything a caller asked for.
Four things happen in order.
Every one of them is real and tested.
NO STEP IMPLIES HOW LONG IT TAKES · THIS RUNS ONLY ONCE A CALL IS ALREADY ANSWERED AND UNDERWAY
Here is what a caller actually hears once the failure is confirmed, before any transfer is attempted:
I’m sorry, the automated ordering system is having trouble. I’ll try to connect you with the restaurant.
That is the exact apology, not a paraphrase of it. This is a real improvement over dead air — the behavior it replaced gave a caller nothing at all before its own transfer-or-hangup attempt.
A second line, doing four separate jobs.
Where the underlying problem is one Dohos can name, and something is already settled about the caller’s order worth stating plainly, a more detailed line follows the apology.
Whichever line plays, what follows is the same sequence above: the manager-number attempt, then the owner-number attempt if the first did not connect and that fallback is turned on for the location, then a hangup only if neither is configured or both attempts failed.
The line a caller hears describes a decision already made somewhere else in the system — it is not the thing making that decision. What is available on a given call is enforced by the restaurant’s own configuration and by Dohos’s backend, not by which words happen to get spoken out loud. A caller cannot talk their way past a limit that is not there to cross, and where something cannot be verified, the system stops and says so rather than continuing on the assumption that it is probably fine.
A dropped connection can slow a call down. It cannot double an order.
A submission, a tool call, or a transfer attempt sent twice because a connection dropped is treated as the same request, not a fresh one — so a failure and a retry together cannot produce a duplicate order or a duplicate charge. A repeated attempt is checked against what was already tried, at more than one layer, before anything new is created.
Where the system genuinely cannot tell whether something already went through, it says that plainly instead of guessing either way. The fuller detail behind that guarantee is on security practices.
I can’t verify whether that action completed. Do not repeat it yet. I’ll use the same reference to check or route it for human review.
Two columns, both filled in.
Not a vague gesture at “some things aren’t handled.”
The number a reader expects here
There isn’t one. This page describes behavior, not a measured figure, and where a figure does not exist to publish it is not borrowed from anywhere else to fill the gap.
THE CONTRACTUAL SIDE OF THIS — A TARGET PERCENTAGE, A RESPONSE TIME, A CREDIT FORMULA — LIVES AT THE SLA, WHERE THE METHOD IS DEFINED AND THE NUMBERS ARE NOT YET APPROVED. NOTHING ON THIS PAGE ANTICIPATES WHAT THEY WILL SAY.
What gets recorded
A mid-call failure is not invisible to a restaurant just because the caller experienced it as a clean handoff. It becomes part of that order’s or call’s own event history — the same append-only record every other change and exception is preserved in — and shows up on console, the same place every other event lands. Not a separate system a restaurant has to know to check.
Nothing lost.
Nothing silently resubmitted.
A caller is partway through confirming a delivery order — items picked, address given, payment still to come — when a service the call depends on stops responding. The apology plays first, plain and immediate, followed by the honest current-state line: the items already confirmed stay confirmed, stated back plainly rather than left in doubt.
Dohos attempts the location’s manager number. If that number is not configured, or nobody picks up, and owner fallback is turned on for that location, it tries the owner’s number next. If that connects, a real person is on the line with the caller’s order exactly as it stood the moment things went wrong. If neither number is configured, or both attempts fail, the call ends there — honestly, rather than looping the caller through a repeated apology or claiming a transfer happened that did not.
What people ask when something breaks
What happens if Dohos itself is down?
Nothing on this page runs in that case — no application code executes at all. This page does not claim a fallback happens, and it does not claim one doesn’t. Whether something exists at the carrier level is genuinely not something this page has an answer for, and guessing in either direction would be worse than saying so.
What if the manager doesn't pick up?
The owner-fallback attempt runs next, if it is turned on for that location, then a hangup only if that also fails or is not configured. No duration is stated anywhere in this.
Can a dropped call double-charge someone?
No. A retried request is checked against what was already attempted before anything new happens — see the guarantee above.
Is there an uptime number?
No. This page describes behavior, not a measured figure, and the contractual framing lives at the SLA rather than here.
Does the transfer definitely reach the right person?
That depends on a number the restaurant configures for that location. This page does not assume it is set, and does not describe the destination as generically “the restaurant’s line” — it is a number somebody chose, and it is only as right as that choice.
No uptime or recovery-time figure — how a failure is handled is not the same as how often one happens or how fast it resolves. No assumption that a transfer number is set, or proven to reach the right person for every restaurant. No figure for how quickly a fallback call gets answered on somebody’s own line. And an unrecognized or blocked call is declined rather than handled by this mechanism at all — a design boundary, not a quiet version of the failure described above.
RELATED READING
Escalation
The moment a boundary is crossed, a person is in it — manager on duty, then owner fallback.
OPEN →PLATE Nº 012Owner console
The dashboard: tonight at a glance, analytics, menu, team, closeout.
OPEN →PLATE Nº 070Availability
Continuity posture, and what happens when things fail.
OPEN →Set the numbers this page describes.
Request access and decide, for your own location, which manager number gets tried first and whether an owner fallback stands behind it.