Languages
When Dohos isn’t sure what language a caller wants, it asks. That’s the same rule that governs every uncertain moment in a call — ask rather than guess — applied here to language specifically. Nothing on this page claims a fixed list of languages, or a system that quietly detects one and commits to it. Dohos asks, and it fails honestly to a person when asking still doesn’t resolve it.
No language menu.
No silent commitment to a guess.
When it isn’t confident which language a caller wants, it asks directly — from very early in the call, before the order itself gets underway, because getting this wrong at the start costs more than pausing to check:
I’m an AI ordering assistant. Which of the available languages would you like to use? If I’m not understanding you accurately, I’ll offer the restaurant’s available alternative.
Asking once doesn’t always resolve it. If understanding is still shaky after that, Dohos says so plainly rather than pushing an order through on a guess:
I may not be hearing that accurately. I don’t want to guess about your order. I can try once more, review choices one at a time, or give the restaurant’s available alternative.
Three real options come out of that moment: try again, slow the order down to one choice at a time, or hand the caller to the restaurant’s own verified alternative. None of them is Dohos completing an order it isn’t confident about. Getting language wrong doesn’t just risk an awkward exchange — it risks the wrong item, the wrong modifier, or a price read back in a way the caller never actually confirmed. Asking costs a caller a few seconds. A wrong guess can cost them an order they didn’t actually place.
Confident continues.
Uncertain asks. Unresolved hands off.
A per-location fact that’s actually
been tested — not a marketing list.
Dohos doesn’t count a language as available until its whole path — the disclosure, the menu, the order flow, payment, safety wording, and human handoff — has been verified in it end to end, for the specific location. That’s a deliberately higher bar than a language merely working in a demo, or on a different restaurant’s account. A caller asking whether their language works isn’t answered from a general claim; it’s answered from what’s actually been checked for the specific restaurant they’ve called.
Six terms, three stops, mapped
Underneath that simple ladder sits a more precise, six-term system Dohos uses for readiness generally, not only for language — the same vocabulary that governs whether any capability is actually live for a given restaurant.
| THE UNDERLYING TERM | WHAT IT MEANS | WHERE IT LANDS ON THE LADDER |
|---|---|---|
| available | Tested end to end for this location, and turned on. | Live for this restaurant |
| available_not_enabled | The flow works, but this location hasn’t turned it on. | Tested, not turned on here |
| setup_required | Approved for this location, but configuration isn’t finished. | Tested, not turned on here |
| temporarily_unavailable | It was live, and isn’t reachable right now. | Tested, not turned on here |
| not_available | Not part of the current product for this location. | Not tested here |
| unknown | The current state can’t be verified, so it isn’t treated as available. | Not tested here |
If a caller asks for a language or communication method Dohos can’t verify as tested, it doesn’t attempt it anyway and hope the order comes out right. The exact line for that moment is quoted in full on a caller who was hard to understand — Dohos declines to continue on a path it can’t verify, says plainly it won’t risk the order over it, and points to whatever verified alternative actually exists. The same rule covers a communication method as much as a spoken language — an accessible format a restaurant hasn’t verified gets the identical honest answer, not a best-effort attempt.
An order placed in a language nobody has verified is a worse outcome than a caller reaching a person instead.
Three claims, struck on purpose.
Language shapes the conversation.
It never becomes a second menu.
Whichever language a call happens in, what reaches the kitchen doesn’t change. The order is built from the restaurant’s own catalog references, not from the words used to ask for them, so the ticket staff see is identical either way: item identity and price, modifiers and variants, tax and fees, the ticket format staff already read. Language is a communication layer on top of one restaurant-owned catalog — never a parallel translation someone maintains separately and might let drift out of sync with the original.
One caller, three real branches
A caller answers Dohos’s opening question in a way the system isn’t fully confident about — the response is short, and background noise makes it harder to parse. Dohos doesn’t guess and move on; it says so and asks again, offering to slow down and review one choice at a time.
Branch one: the second attempt resolves it, and the call continues in the language now confirmed, with nothing lost from the exchange that already happened. Branch two: it’s still not clear, even slower — Dohos doesn’t take a third guess; it offers the restaurant’s own verified alternative, the same fail-closed handoff described above. Branch three: the caller asks for a language or a method Dohos hasn’t verified for this restaurant at all — the automated path hasn’t been verified for it, so Dohos won’t risk changing the order incorrectly, and offers the alternative instead.
All three start from the same moment: uncertainty, met with a question first, never a guess. None of the three ends with Dohos silently deciding on the caller’s behalf — the caller always knows which of the three actually happened, and why.
Asked plainly, answered plainly.
Does it support Spanish?
Not a fixed list, and not a marketing claim to make here. Language readiness is a per-restaurant, tested fact — what’s actually live for a given location is asked for directly, never assumed from a checklist.
What if it guesses wrong?
It’s built not to. Where it isn’t confident, it asks rather than proceeding — that’s the entire mechanism this page describes, not an edge case bolted onto it afterward.
Can it switch languages mid-call?
No. This page corrects that exact claim directly: nothing here is built to detect a switch mid-conversation and silently follow it. A change in what a caller needs is handled the same way as initial uncertainty — asked, not assumed.
How does a restaurant get a new language tested?
Not covered on this page. Testing a language end to end is a setup question — what matters here is only that the testing happens before a language is ever counted as live, never after.
No specific list of supported languages, because it isn’t one fixed list — it’s a tested, per-restaurant fact that can differ location to location. No silent detection — where it’s genuinely unsure, it asks. No claim of mid-call switching. Accuracy in any given language isn’t measured or claimed here — including how accent, dialect, or regional variation within a single language might affect understanding. And this page doesn’t state how many languages any single restaurant currently has tested — that count, where it exists, lives on the restaurant’s own account, not as a published figure here.
RELATED
Voice
A voice your regulars compliment — chosen once, engraved into every greeting.
OPEN →PLATE Nº 033Language barrier
When language is uncertain, it asks — and the order still lands.
OPEN →PLATE Nº 010Escalation
The moment a boundary is crossed, a person is in it — manager on duty, then owner fallback.
OPEN →Ask about your own restaurant.
Tell us which languages your callers actually need, and find out what's tested and ready for your location.