When a call drops and picks back up

A line dropping mid-call isn't rare, and it isn't really preventable from Dohos's side. What actually matters is narrower and more useful than preventing it: what happens the moment a caller reconnects, why Dohos handles it the way it does, and what's actually worth checking afterward rather than assuming everything picked up exactly where it left off.

A short, ordinary reconnect — the kind where the connection itself survives and the caller is back within moments — already has its own clean handling, covered in full on Calls: the assistant reintroduces itself briefly, states what it still has from before the interruption, and asks the caller to confirm before continuing. This page is about the three situations that fall outside that clean case: when what happened before the drop genuinely can't be trusted, when the caller comes back by way of a person rather than directly, and when someone new joins partway through. Each is handled differently, on purpose, with its own exact wording.

01Why it doesn't just pick up where it left off

The instinct might be to assume that if a caller says “sorry, I got disconnected,” the safest thing is to just continue exactly where the conversation left off — the caller remembers what they were ordering, after all. Dohos doesn't work that way, and the reason is specific: a dropped connection is exactly the moment where trusting memory over verification is riskiest. The caller might remember precisely what they'd chosen. Or the drop might have happened mid-sentence, with the last thing actually recorded being incomplete, ambiguous, or from an earlier part of the conversation than the caller now remembers. Dohos can't tell which of those it's dealing with just from the fact that the line reconnected, so it treats the reconnection as its own moment requiring its own confirmation — the same discipline used everywhere else an order gets built.

That's a deliberate trade against speed, worth seeing in a concrete case rather than only in the abstract. A caller ordering three items loses the connection right after confirming the second one, then calls back well under a minute later. If the connection itself survived that brief a gap, picking back up covers this cleanly — the assistant states what it still has and asks for a quick confirmation before continuing, rather than repeating the whole order from scratch. If the caller instead had to redial, or enough time passed that the system can't respectably vouch for what's still accurate, it takes one of the three more careful paths below: state plainly what's uncertain, and let the caller decide how to proceed rather than guessing on their behalf. That trade only ever costs a caller a little repetition. It never costs them an order that was quietly built from a guess about what they meant.

02What's actually worth checking afterward

A finished call's own record doesn't carry a separate marker reading “this one dropped and reconnected” — so the thing actually worth checking isn't the call in isolation. It's whatever the call actually produced, and whether that result matches what the caller believes happened.

1. Start with the order, not the call. If the reconnected call ended in a placed order, Order status, explained covers what the console actually shows for it — but the fastest useful check here is simpler: read the items, quantities, and total back against whatever the caller says they meant to order.
2. If a caller specifically mentions the call dropped, treat that as a cue worth a second look rather than something to wave off. Dohos already runs its own confirmation before anything submits, but a caller who just went through a dropped line and is a little rattled benefits from a person doing the same double-check out loud, in their own words.
3. If there's any reason to suspect the same order might have gone through twice — most often because two calls landed close together from the same number, or the caller isn't sure whether their first attempt actually finished — that's its own separate situation with its own separate answer, covered on Duplicate orders and charges. Don't guess at it from the call alone; check the order records directly.
4. If the caller sounds unsure whether they're even talking to the same restaurant, or the conversation seems to have lost track of what was already said, that's the design being careful on purpose, not a sign anything is broken — the next section covers exactly why, and exactly what the caller hears in each case.

03The three ways a reconnect goes further than a clean pickup

A brief, clean reconnect is one thing, and it isn't this page's subject. These three are different, and each gets its own exact wording rather than one generic apology, because each is a genuinely different reason to be careful.

The earlier context can't be safely confirmed

Sometimes the gap is long enough, or the drop happened at an awkward enough point, that Dohos can't responsibly treat what was said before as still reliable. Rather than guess at what probably survived, it says so directly and offers a real way forward:

Starting over is a real cost to the caller's time, and it isn't a step Dohos reaches for casually — it's specifically for the case where continuing on unverified memory would risk sending the restaurant an order that doesn't match what the caller actually wants. A caller who'd rather not repeat themselves always has the human-help option named right there, in the same sentence.

The caller comes back by way of a person

A different situation: the caller wasn't reconnected automatically — somewhere in between, a human was involved, whether that's a restaurant staff member, a support agent, or another system that handed the call back. Dohos doesn't assume anything agreed to in that other conversation carried over into what it's tracking:

This matters because a conversation Dohos wasn't actually part of isn't something it can honestly confirm resulted in anything specific — someone might have told the caller “sure, that's fine” about a detail that was never recorded as agreed to on Dohos's own side. Rather than take the caller's word for what was decided elsewhere, it reviews only what it can verify itself before moving forward, and says so plainly instead of quietly picking up as if nothing happened in between.

Someone new joins partway through

A call's participants can change mid-conversation — someone else picks up the phone, a second person joins on speaker, or a different voice starts answering the questions. When that happens, Dohos doesn't quietly keep treating the call as if nothing changed:

The point isn't suspicion about who's on the line — it's that the disclosure a caller hears at the very start of any call, that they're speaking with software and not a restaurant employee, is worth repeating the moment there's a real chance someone new is now hearing it for the first time. Practically, it also means the order won't get finalized on the strength of an earlier confirmation from someone who's no longer the one actually speaking. Whoever is placing the order at the end still has to confirm it themselves, in their own voice, regardless of who confirmed anything earlier in the same call.

04What none of this means

None of these three is a sign that something went wrong with a restaurant's own setup, and none requires anything to be fixed on the account. They're the system doing exactly what it's built to do when a call's continuity genuinely can't be taken for granted — the honest alternative to guessing, applied to three specific, real situations, rather than a blanket policy that makes every ordinary reconnect start over from nothing. Most reconnects never reach any of the three; they're the short, clean case Calls already covers, over almost as quickly as it began.