One call. One opening. Every way it can actually go.
Every call into a restaurant’s line runs through the same beginning before it goes anywhere — routed on what the caller actually says, resolved into one of four honest endings, and kept the same way afterward no matter which of the four it was. This page is that sequence, start to finish — not a restatement of any one piece of it.
Before anything forks, the same opening plays in full.
What that line actually says belongs to calls; on this page, it’s the one fixed beginning every call runs through, in full, regardless of what it turns into next.
That single beginning is also why the forks below never have to repeat themselves. Whether the next thing out of a caller’s mouth is a question about a delivery fee or a request for the manager, the identity, the restaurant, and the way out already played, in the same order, before either was routed anywhere. The fork is a difference in what happens next — never in what happens first.
Four places a call can end up. None of them a consolation prize.
From that single beginning, a call forks into exactly four places it can end up: an order, a question answered, a transfer, or a callback. None is drawn bigger than another, and none is a fallback for the rest — a question answered is a complete result on its own, not a consolation prize for a call that didn’t become an order. Orders and questions cover what happens once a call heads down the first two paths; a transfer and a callback both run through the same mechanics, covered in full on escalation. This page shows where each one splits off — not how it works once it has.
The two callouts on the drawing sit on the same timeline. The opening plays in whichever voice the restaurant chose for its line — an identity someone picked, not a default nobody decided on; voice covers how that choice works. And if there’s real uncertainty about which language a caller wants, it gets sorted before routing goes any further — asked directly, at the earliest point it can matter, never assumed from a guess. Languages covers that mechanism, including the rare call where asking still doesn’t resolve it.
If the line drops, the call doesn’t start over by default.
A dropped connection partway through a call doesn’t automatically mean starting from nothing. If what was already said is still reliably intact, the call picks back up close to where it left off, rather than making a caller repeat themselves. If that can’t be confirmed cleanly, the safer, more honest move is to review everything again from the start rather than assume the gap left nothing changed.
Calls is where the actual reconnect line lives; here, it’s a real gap on the same timeline every other call runs — not a separate failure mode off to the side.
Two calls that never reach this timeline at all
Neither of these is a completed call that went badly. Both sit outside the fork entirely, for the same honest reason: the fork only describes what happens once a call is actually underway — and these two never get that far.
A number that can't be verified
A call arrives on a number the restaurant-matching step genuinely can’t resolve to a single confident answer. It still gets answered, and the caller still hears from Dohos — just not an attempt to guess which restaurant it might be. It says plainly that the match can’t be confirmed, and stops there, before any fork is even reachable.
A caller this restaurant has blocked
A caller the restaurant has already blocked is declined before the call is ever answered at all — no opening, no disclosure, nothing spoken, because nothing here picks up in the first place. Not a version of a call that went wrong; a call that never begins.
NEITHER ONE REACHES THE FORK ABOVE.
Four different endings. The same place afterward.
An order, a question answered, a transfer, a callback — four genuinely different endings, and none of them disappears into a different kind of record depending on which one it was. Whichever fork a call took, it shows up afterward on the same screen, tracked the same way, sitting alongside every other call the restaurant had that day. Console is where that record actually lives.
That’s not a small detail. A question-answered call isn’t harder to find later just because it never produced anything resembling a ticket, and a callback still waiting on a manager isn’t sitting somewhere separate from the orders around it. None of the four forks is a dead end to look back on — a transfer that connected, a callback still open, a question that got a straight answer: each is exactly as visible afterward as an order that became a ticket, at the same level of detail. Which fork a call took never decides how seriously it’s kept.
One call, two different needs
A PLAIN QUESTION, ANSWERED
A caller opens by asking whether a weekday special is still being served this afternoon — a plain question, nothing about an order yet. Dohos answers it from what the restaurant has actually published, the way any menu question gets handled. On its own, that would already be a complete, finished call — plenty are.
THE SAME CALL KEEPS GOING
This one continues. The same caller follows the answer with something else: a catering order large enough that they’d rather describe it to a person than build it item by item over the phone. The call doesn’t reset. It continues from wherever the conversation already is, moving from the question branch toward asking for a person — a real attempt, described honestly, never promised as a guaranteed connection before it’s confirmed.
BOTH KEPT THE SAME WAY
Two different needs, inside one continuous call, and neither treated as more real than the other. The question got a sourced answer on its own terms; the request for a person got its own honest attempt, covered in full on escalation flow. Both are logged the same way once the call is over — not one properly and one as an afterthought.
The questions people actually ask.
Does every call end in a ticket?
No — see the fork above. Getting a straight answer, reaching a person, or landing a callback closes a call out just as fully as an order does. Only one of the four branches produces anything resembling a ticket.
What if a caller changes what they want partway through?
The call doesn’t restart. It continues into whichever of the four branches the conversation now belongs to — answering a question doesn’t rule out ordering a minute later, and neither rules out asking for a person after that.
Is the opening ever skipped, to save time?
No. Every call plays the same identification and the same way-out in full before anything else happens, regardless of which of the four the caller ends up needing.
What happens to a call that never resolves cleanly?
It’s tracked honestly as exactly that, rather than folded into one of the four as though it had gone somewhere. A call that fails outright, or one a caller abandons mid-conversation, is its own kind of record — distinct from a finished order, question, transfer, or callback, and never disguised as one. Calls covers the complete picture of how a call is tracked from the moment it starts.
Heading toward the transfer branch isn’t itself a guarantee a live person picks up. That offer goes out when someone’s genuinely free to take it; when nobody is, the caller gets a real, working way to reach the restaurant directly — never a transfer attempt left to ring out and fail.
A language is only used on a call once every part of that call has actually been tested in it, for that specific restaurant — never assumed available just because Dohos generally supports it somewhere else.
A restaurant that has turned audio recording on for a specific location says so at the start of the call, every time it applies. A restaurant that hasn’t simply doesn’t have it running in the background — regardless of anything else happening on that call.
Nothing about how quickly a caller talks, or how many things they ask for in one call, changes which branch applies. The fork is about what a call was for — not how long it took to get there.
Hear the same opening on your own number.
Request access and hear it for yourself — before any of the four branches even come up.