Orders
Nothing reaches the kitchen without being checked first. Pickup, delivery, and scheduled orders are each read back in full and checked against the restaurant’s own real menu, hours, and configured limits before anything moves. Ordinary orders go straight through. Only the ones that actually cross a boundary the restaurant itself set wait for a person.
Each fulfillment type asks for what it
genuinely needs — and nothing beyond that.
None of the three is guessed from context. A delivery order without a confirmed address and callback number isn’t submitted, and a scheduled time outside a restaurant’s own window is caught before it’s confirmed, not after.
Not a summary. Not “anything else.”
The actual reviewed total.
Before anything is sent anywhere, the whole order gets read back — and moving forward from there takes an explicit yes. That yes only ever applies to the exact total that was actually read back.
If anything changes afterward — a price, an item’s availability, even a line added a moment earlier — the earlier yes doesn’t carry over silently. The order gets reviewed again from the new total, covered a little further down this page.
Nobody sits and approves every
phone order one at a time.
An order inside a restaurant’s own configured limits, confirmed by the caller on the call, is accepted automatically. Not every order auto-accepts, though — only the ordinary ones do. What sends an order to a person instead is a short, specific list, not a vague safety net, and not most orders.
| THRESHOLD | WHAT TRIGGERS IT | WHAT THE CALLER IS TOLD |
|---|---|---|
| A LARGE ORDER | The order’s own size crosses a limit the restaurant configured. | The order still goes through review, not silently. |
| CLOSE TO CLOSING | The restaurant has set orders near close to route to a person rather than auto-accept. | Same — reviewed, not rejected outright. |
| A CONFIGURED SPECIAL REQUEST | The restaurant set a specific kind of request to require review rather than auto-allow it. | Handled as a real request, not ignored. |
| ANY HANDWRITTEN INSTRUCTION | A caller adds free-text wording to an item — no threshold, no exceptions, every time. | A person reads it before the order is accepted. |
That last row carries real weight on purpose. There’s no size or wording threshold attached to it — a single handwritten instruction on a line, of any kind, is enough on its own to route the order to a person, every time it happens. The other three thresholds are configured per restaurant; this one isn’t configurable away.
A material change never gets folded
into a confirmation that already happened.
The restaurant information changed after your review: [specific item / availability / substitution / price / fee / time change]. The new total is [total]. Your earlier confirmation does not apply to this change. Would you like me to review and submit the updated request?
An approved change after that point produces a clearly marked replacement ticket. The original stays on record exactly as it was — nothing gets overwritten, only superseded by something newer that points back to it. And occasionally, whether a restaurant actually accepted a request can’t be confirmed cleanly. When that happens, the honest move is to stop rather than guess and risk sending the same thing twice:
I can’t verify whether the restaurant accepted this request. Do not submit it again or pay again yet. I’ll check the same order reference or route you to verified support.
Once a restaurant does accept, that’s stated as its own fact — separately from whether payment has actually happened:
[Verified restaurant] accepted order [safe order reference] at [time] for [verified total]. [Pickup / delivery window and location]. [Payment status stated separately]. Review the listed items and contact the restaurant or Dohos support through [verified path] if anything is wrong.
One order, three separate facts
Deliberately three chips, not a progress bar — none of the three implies either of the other two. Clearing a manager review doesn’t by itself mean payment happened. Payment succeeding doesn’t by itself mean the kitchen has started. Each is its own fact, tracked on its own schedule. How a caller actually pays today is covered in full on payments — this page only states that payment is tracked as its own fact, never blended into whether an order was accepted.
The readback, the ticket, and the payment
step carry the same number.
The subtotal read back on the call, the total on the kitchen ticket, and the total at the payment step are the same number, because all three are calculated once, by one engine — never read back from the model’s own arithmetic and reconciled with the kitchen afterward. How that single record stays consistent everywhere it shows up is covered on the menu page.
CALCULATED ONCE, BY ONE ENGINE — NEVER THREE COPIES KEPT MATCHED BY HAND
One order, start to finish
A caller orders three items — a sandwich, a side, and a drink — comfortably inside the restaurant’s own ordinary range. Partway through, before the readback, the caller adds a fourth item: a second sandwich, large enough on its own to push the order’s total past the restaurant’s configured large-order threshold. Nothing about that fourth item is refused or flagged mid-sentence — the order keeps building normally.
When the readback runs, it reflects the new total honestly, four items and all, and the caller confirms it exactly as read. That confirmed order doesn’t go straight to the kitchen the way a smaller one would have. It’s accepted as a real, confirmed request — the caller isn’t told anything failed — but it lands with a person for review, carrying the actual configured rule attached to it: a large order, not a vague flag. The kitchen and the caller both know precisely why it’s waiting, not just that it is.
Asked before anyone trusts an order.
What if I want to change my order after I hang up?
A change becomes a request to the restaurant rather than something completed automatically over the phone — the same honest, non-binding handling any change or cancellation ask gets after a call ends.
Does everyone's order wait for a person?
No. The ordinary case goes straight to the kitchen with nobody’s input required. Only a defined, restaurant-set exception list waits, and it’s a short list, not most orders.
What if the price is wrong on the call?
Nothing about the total is guessed. The number read back is the same one the entire order runs on end to end, and a caller confirms that exact figure before anything is sent anywhere.
Can staff just ignore an order that needs review?
It stays visibly waiting rather than disappearing into a queue nobody’s watching — staff view covers how a flagged order actually shows up for the person who has to act on it.
Not every order auto-accepts, and not every call becomes an order in the first place — an answered question, a transfer, and a callback are each a real outcome on their own, covered on calls and questions. The kitchen gets the exact order and total the caller confirmed; what happens to it after that is the restaurant’s own equipment, run on its own terms — for the restaurant running Dohos today, an accepted order still gets entered into its point-of-sale by a person. Nothing reads it in automatically. A delivery order’s exact address isn’t checked against a live map on the call itself — the radius, fee, and minimum are enforced from what the restaurant configured, but confirming the pin on a map is still a person’s job. A quoted time is an estimate unless a manager has set a verified current wait — questions covers that difference in full. Staff still make the food, still handle the exceptions, and still run the kitchen — what’s removed is the interruption of approving orders that were never actually in question.
GO DEEPER
Menu intelligence
Your menu with its real rules: components, modifiers, the 86 cascade, pronunciations.
OPEN →PLATE Nº 008Payments
Pay at pickup tonight; the card moment is isolated by design. DRAFT — payment-capability copy pending the payments gate.
OPEN →PLATE Nº 019Order flow
How an utterance becomes a priced, structured, kitchen-ready ticket.
OPEN →See it priced against a real menu.
Request access and watch an order get checked against your own menu, not a demo one.