Calls
Everything here is about the call itself — the live conversation between a caller and Dohos, and the narrow window right around it — never about what the call produced. An order can be examined at leisure once it exists; a call is happening in real time, and the three situations below are the three distinct ways that real-time conversation can go somewhere it wasn't supposed to.
A useful way to hold all three at once: picture a call as a straight line from the first ring to the last word spoken. Somewhere on that line, a connection can fail outright. Somewhere on that line, a caller or a rule can decide the automated part of the conversation should end early. And the whole way along that line, the conversation itself can simply be harder than usual to carry on. Three different points of failure on the same timeline, not three names for one thing — which is exactly why fixing one doesn't tell you anything useful about either of the other two.
One thread runs underneath all three anyway, worth knowing before opening any single article rather than discovering it three separate times: none of the three situations here ever treats a half-finished order as settled just because something about the call went sideways. A call that drops mid-sentence doesn't quietly assume the last thing the caller said was agreed to. A call handed off to a person doesn't quietly assume the handoff succeeded. A caller who was hard to follow doesn't quietly get an order guessed on their behalf. Every article below is a variation on the same underlying discipline — confirm before assuming — applied to a different kind of interruption.
Worth knowing what doesn't belong here, too. A caller asking a question that has nothing to do with placing an order — hours, a menu detail, whether the restaurant delivers to a certain address — isn't one of the three situations below, because nothing about that kind of call has gone wrong; it's simply a different, ordinary kind of call. This topic is for the moment something about the call needs a closer look, not for every kind of call a caller might place.
It's worth noticing what these three don't have in common, too. A dropped call is a fact about the phone line — nobody's speech was ever hard to parse, the line itself simply cut out. A caller needing a person can happen on a perfectly clear line, with a caller who's easy to understand, simply asking for something automated handling isn't meant to do alone. And a caller who's hard to understand might never need a person at all. Treating any two of the three as interchangeable, or assuming one implies another, is the single easiest way to reach for the wrong article first.
Timing changes which article is actually useful in the moment, too. A dropped call usually needs its article read while the reconnected call — or the callback — is still live, since the steps are about what to do right then; a transfer that didn't connect is the same way. None of the three is written to be read calmly after the fact the way an article about reading an order's status might be — they're built to be opened with a call still in progress, skimmed for the relevant piece, and acted on immediately.
None of the three articles above says anything about whether the order that came out of a call is actually correct — a genuinely separate question, answered under Orders & menu instead. A call that went perfectly can still produce an order with a problem, just as a call that had real trouble can still end in a clean, accurate order. Money moves the same way: a payment link that won't load, or a charge a customer disputes weeks later, belongs under Payments, not here, even when the underlying call itself was difficult. And what actually gets kept from a call afterward — a transcript, or a recording somewhere a restaurant has separately turned that on — is a different topic again, covered under Privacy & accessibility rather than repeated in any article here.
There's a second, smaller boundary worth naming too. Setting up a phone number to reach Dohos in the first place, or diagnosing why calls have stopped arriving at all, aren't questions about a call that's already happening — they're setup and diagnostic questions that live under getting started and under operations instead. This topic assumes the call has already connected and something about the conversation itself, not the phone line carrying it, is what needs attention. The full mechanism behind an ordinary call — the opening, the routing, the four ways it can honestly end — is the province of the product page for calls, worth reading before any of these three situations comes up rather than only after.
None of the three above is optional reading only when something's already gone wrong — but if a call is live right now and none of the three quite matches it, write to support — a real person reads it. Name the location, what you were doing, and any order or call reference you have.