An order gets built, read back, and sent on, or a question gets answered from what the restaurant has published, and most calls end there. This page is about the calls where a person has to actually get involved — a transfer that stalls, a callback that sits without a clear next step, or a call that needs to end for reasons that have nothing to do with the order at all.
01What actually sends a call to a person
Exactly two things put a call on this path, and neither is a mood Dohos reads into how urgent or upset a caller sounds. The first is direct: a caller simply asks for a person, at any point in the call, and doesn't have to wait for a script to finish or an order to be underway first. The second is structural — the call, or the order underneath it, crosses a boundary the restaurant set up in advance, checked the same way on every call rather than judged fresh each time. The full mechanism behind both, including exactly what happens when nobody's actually available to take a live handoff, belongs to Escalation — this page assumes that part is already understood and picks up specifically where a handoff itself runs into trouble.
Worth being clear about what doesn't belong here, too. A quiet, ordinary transfer that connects cleanly on the first attempt isn't a troubleshooting situation — it's the system working exactly as intended, and there's nothing on this page to check for it. What follows is specifically for the handoffs that hit a snag somewhere in the process.
02Reading the callback state on a console
Once a call or an order actually needs a person, that need shows up as one of four states on the order it's attached to, visible on the orders screen. These four are what's actually on screen today — not a longer list of finer-grained stages, just these four, and each calls for a different response.
| What's shown | What it means | What to do |
|---|---|---|
| No callback | Nothing is waiting on a person right now. | Nothing — the default, ordinary state for almost every order. |
| Callback pending | A caller asked for a callback, or a request is waiting on a response, and it hasn't been picked up yet. | Look at it. It stays open until someone actually resolves it — nothing closes it automatically on a timer. |
| Callback resolved | Someone already followed up and marked it done. | Nothing further, unless the caller says otherwise — if they do, that's worth a fresh look, not an assumption the earlier resolution still holds. |
| Needs manager | An order crossed one of the restaurant's own configured thresholds, or a call was escalated, and it's waiting on a decision. | Open it, read the specific reason it's flagged, and decide — approve, decline, or follow up with the caller directly. |
That last state carries the most weight, because it's genuinely a decision waiting on a person, not a notification that can be dismissed. Escalation covers the full manager, then owner chain that gets a “needs manager” state actually looked at. What matters here is narrower: once it's flagged this way, it stays flagged until a real person acts on it, and the caller was told one of three honest outcomes once that happens — approved, denied, or a callback that's still being tracked, never left to just quietly disappear.
A concrete case makes this easier to act on than the table alone. An order comes in large enough to cross the restaurant's own configured size threshold, and it lands on the orders screen showing “Needs manager” rather than moving straight to the kitchen. Opening it shows the actual reason it stopped there — the threshold it crossed, not a vague flag — along with the full order underneath it, exactly as the caller confirmed it. From there the choice is a real one: approve it and it proceeds as ordered, decline it and the caller is told along with whatever alternative the restaurant allows, or reach out directly if something about it genuinely needs a conversation first. Whichever happens, the state only changes once a person actually makes that call — it never resolves itself by sitting long enough.
03When a handoff doesn't go the way it's supposed to
A transfer is a live, real-time thing, and live, real-time things don't always go cleanly. Three moments are worth understanding in detail, because each has Dohos saying something specific and deliberate rather than just letting the caller assume the best.
Before the handoff actually happens
The moment right before a transfer begins is worth pausing on, because what gets carried over to the person taking the call is exactly as important as the transfer itself:
I'm transferring [minimum necessary verified context] to [identified recipient role] for [purpose]. [State whether the recipient will receive call content, order details, or no stored transcript.] Would you like me to proceed?
Two things are happening in that one line. The caller is told who's actually receiving the handoff and why, rather than being moved without explanation, and they're told plainly what the receiving person will and won't have. A caller says yes to a specific, named handoff, not a vague “let me get someone.”
Confirming a person has actually joined
A hold tone, a ring, or an attempt that's merely been made is never treated as proof that someone has actually picked up. Dohos only states that a person is there once that's genuinely confirmed:
[Verified name or role] has joined. I'm the AI assistant and will [leave/remain only if truthful]. [State current recording/transcript status based on verified runtime.]
Worth understanding from an operator's side specifically because it explains why a caller sometimes reports waiting through what sounds like a connected call before anyone actually speaks to them — Dohos is holding off on saying “you're through” until it can say so honestly, rather than letting a ring tone stand in for an actual person answering.
When a call has to end for safety, not for the order
Occasionally a call stops being about the order at all. Harassment, threats, or content that's simply unsafe to continue engaging with gets a direct, bounded response rather than an attempt to redirect the conversation back to a menu:
I can help with a restaurant order, but I can't continue with threats, harassment, or unsafe content. I will pause or end the interaction and preserve only the information required for safety and review.
That's a real boundary, not a warning that gets repeated indefinitely — the call is paused or ended, and only what's actually needed for a safety review is kept from it, not the whole conversation by default. Acceptable use is the fuller policy this moment is the practical, on-call version of — worth reading if this comes up more than once with the same caller.
04When the call itself is the problem
A slightly different situation from all three above: sometimes nothing has gone wrong with the handoff mechanism at all, and the actual difficulty is that the conversation has stopped working — Dohos and the caller aren't understanding each other well enough to keep going as-is. That gets its own honest acknowledgment before it escalates any further:
I may not be understanding you accurately. I can slow down, repeat, review one choice at a time, use an available text/keypad option, or provide the verified human/Restaurant alternative.
That's offered before Dohos gives up on the call entirely, not after — a caller gets a real set of alternatives rather than being routed to a person purely because the system hit a wall. Worth recognizing this pattern from the caller's side, too, because it can sound frustrating in the moment even though it's the system being careful: a caller repeating themselves, or being asked to choose one thing at a time instead of describing a whole order at once, isn't stuck in a loop by accident. It's working through the same list of alternatives, in order, until one actually gets the order built correctly, or until it's genuinely time to hand off to a person instead.
If the same caller later asks whether an action from earlier in a difficult call actually went through — a change, a cancellation, anything that isn't obviously still sitting there to check — that's a distinct, separate question with its own honest answer, covered on Duplicate orders and charges. The two situations look similar from the outside, since both involve a caller who isn't sure something worked, but a communication breakdown and an unverified action are different problems with different fixes.
If this page didn't cover what's actually happening, or its fix didn't hold, write to support — a real person reads it. Name the location, what you were doing, and any order or call reference you have.