A caller who was hard to understand

Not every call goes smoothly, and not every difficulty is the same kind of difficulty. This page deliberately keeps a clean line between genuine communication difficulty and language preference, because the two get confused easily and Dohos treats them as two different situations with two different responses.

01Two different moments that can sound alike

Language preference is its own moment, handled on its own terms: the system asks rather than assumes, and nothing about which language gets used is decided before that question is actually answered. The full mechanism for that — including exactly how a preference gets used once it's known — belongs to Languages, and this page doesn't restate it.

What this page actually covers is different: a caller whose speech isn't coming through clearly, for any reason — background noise, a bad connection, an unclear or fast speaking style, or speech recognition simply not managing to keep up in that particular moment. That difficulty can show up in any call, in any language, and the response to it doesn't depend on switching languages at all. It's a communication problem, not a language one, and the fix Dohos reaches for reflects that directly: slow down, repeat, offer a different way to communicate, and never guess when guessing would risk the order itself.

02What Dohos actually does

Three things happen, in a specific order, once a call shows signs of real communication difficulty — not three unrelated tactics, but three stages of the same underlying approach: offer real alternatives first, refuse to guess if the difficulty continues, and protect whatever's already been said from being changed without the caller's full, confirmed agreement.

Offering real alternatives, first

The first response to a caller showing difficulty isn't to keep repeating the same question louder or slower on a hunch — it's to name real, specific options and let the caller pick what actually works for them:

That last sentence carries real weight. A caller never has to explain why communication is difficult — not a hearing difference, not a speech difference, not anything about themselves — in order to get a genuinely different way of continuing the call. The options offered are named specifically, and only the ones actually available in that call.

Refusing to guess if it continues

If the difficulty doesn't resolve after that first offer, Dohos doesn't quietly start guessing at what it thinks it heard in order to keep the call moving. It says so plainly, and it says exactly what's still true about the order so far:

That's a genuinely different choice than most systems make under pressure to complete an interaction — it would be faster, in the moment, to take a best guess and let the caller correct it later if it's wrong. Dohos doesn't do that here, because a guessed order that turns out wrong costs the caller and the restaurant more than an honest pause does. The caller is also told, plainly, exactly where the order actually stands right now.

Protecting what's already been confirmed

Whichever path the call takes from there, one thing stays constant: nothing gets submitted or changed on assumption.

This is the same discipline that runs through every order Dohos builds — a full, explicit confirmation before anything moves forward — applied here specifically to reassure a caller who might otherwise worry that repeating themselves, or taking longer than usual, has somehow put their order at risk. It hasn't. Nothing changes without their say-so, difficulty or not.

03One difficult call, start to finish

It's easier to see how the three stages fit together with a concrete case than with the three scripts alone. A caller dials in from somewhere loud — a car with the window down, a busy street, a kitchen of their own in the background — and the first few exchanges come through garbled enough that speech recognition can't confidently parse what's being said. Dohos doesn't push forward on a partial guess. It offers the caller a real choice: slow down, repeat one thing at a time, or switch to a different way of communicating entirely, without asking the caller to explain why the call is hard to follow.

Say the caller tries slowing down, and it helps for a sentence or two before the noise picks back up and the same difficulty returns. Rather than cycling through the same offer again and hoping for a better result, Dohos moves to the second stage — it says plainly that it isn't confident it's following accurately, states exactly what's already been captured about the order so far, and asks whether to keep trying or switch to something else. Nothing about the order is quietly filled in with a best guess to keep things moving. If the caller says they just need a moment, the third stage is what makes that pause safe to take: everything already confirmed stays exactly as it was, repeated back rather than re-guessed, and nothing new gets added to the order until the caller actually says yes to the complete thing.

Most calls like this end there, a little longer than an ordinary call but with a correct order at the end of it. The caller never had to disclose anything about why the call was difficult, and nothing about the order was ever built on an assumption rather than an actual confirmation.

04When even that isn't safe to continue

Occasionally the difficulty is severe enough, or specific enough to the communication method itself, that continuing through an automated path risks the order being wrong in a way none of the three accommodations above can safely fix. Dohos has an honest answer for that case too, rather than forcing the call through anyway:

That's the fail-closed version of the same instinct behind everything above: when Dohos can't verify that continuing is actually safe for that specific caller's situation, it stops rather than pushing forward on a best effort. What a caller gets instead is a real, verified alternative — not silence, and not an apology with nothing behind it.

05What this means for your restaurant

Most calls with real communication difficulty resolve inside the three accommodations above — a caller who needs things repeated, or handled one item at a time, or given a little more time, almost always ends up with a correct order, just a slightly longer call to get there. Nothing about that needs a person's involvement, and there's nothing on a console to check afterward specifically for it — the resulting order looks like any other confirmed order, because it went through the same full confirmation everything else does.

The moment worth actually paying attention to is the fail-closed case: a caller who was told to use the restaurant's own verified alternative because the automated path genuinely couldn't continue safely. If that happens, that caller's next contact with the restaurant — a callback, a walk-in, a retry — deserves the same patience the call itself was trying to offer, not a restaurant assuming the caller simply gave up. And if a caller reports that none of the available alternatives actually worked for them, that's worth reporting as a real accessibility barrier rather than treating as a one-off bad call, covered in full on Reporting an accessibility barrier.

It's also worth remembering that a longer-than-usual call isn't, by itself, evidence of a problem worth escalating. Some calls simply take a little more back-and-forth to get right, the same way an in-person order sometimes does when it's loud at the counter. The distinction that actually matters is whether the call ended with a correct, fully confirmed order or with an honest handoff to a real alternative — not how many times something had to be repeated to get there.