Reading what an order's status actually shows

This page walks through what each of those three labels actually means, what's deliberately not shown, and what a caller was actually told at each end of the process.

01Three separate facts, not one status

Every order on the orders screen shows three independent labels rather than one combined status word. None of the three implies the other two — an order can be accepted and still unpaid, paid and still not yet accepted, or accepted and paid with the kitchen not yet started. Reading all three, not just the first one that catches your eye, is the only way to actually know where an order stands.

The acceptance label is usually the first thing worth checking, because it answers the most basic question — did this order actually get through, or is a person's decision still needed. “Accepted” covers the ordinary case: nothing about this order tripped any of the restaurant's own configured review triggers. “Needs review” means something about the order sent it to a person before it goes any further, and it's genuinely waiting on a decision, covered in full on When a call needs a person. “Rejected” means a person looked at it and it didn't go through.

The payment label is worth reading on its own, never assumed from acceptance. “Paid” and “Cash due” are both entirely normal, expected states — plenty of accepted orders sit at “Cash due” for their entire life, settled directly with the customer rather than through any online payment step. “Declined” means a card attempt didn't go through. “Refunded” means money that was collected has been sent back. None of the four payment labels tells you anything about whether the kitchen has started, which is exactly why fulfillment is tracked as its own, third fact — the label most directly useful to whoever's actually working the order in the moment.

02One order, watched across all three

Seeing the three axes move independently is easier with an actual order than with the definitions alone. A pickup order comes in for two sandwiches and a drink, comfortably inside the restaurant's own ordinary limits. The moment it's confirmed on the call, acceptance shows “Accepted” — no review trigger, no person needed. Payment shows “Cash due,” because this caller is paying at pickup. Fulfillment shows “Pickup,” reflecting how the order is being handled rather than anything about its progress yet.

None of that changes when the kitchen actually starts working on it — acceptance and payment stay exactly where they already were, because neither of those facts has changed. What moves is fulfillment alone, once there's real progress to reflect. And when the customer arrives and pays in person, only the payment label updates, from “Cash due” to “Paid.” Three labels, three independent timelines, each updating only when its own underlying fact actually changes.

Compare that with a much larger catering-sized pickup that crosses the restaurant's own configured size threshold. Acceptance opens at “Needs review” instead of “Accepted,” because the order itself triggered a check before anything else could happen — payment and fulfillment don't even become the relevant question until a person actually decides whether the order goes forward at all. That's the entire reason the three are kept separate: an order can be stalled on exactly one of the three facts while the other two are either not yet relevant or already settled, and knowing which one is actually the open question is what tells you what to do next.

03What's not on screen, and what to do instead

It's worth being direct about two things that aren't part of any of the three labels above, because looking for them wastes time an operator doesn't have in the middle of a call. There's no “Cancelled” chip anywhere on the acceptance label. There's no “Voided” or “Unknown” chip anywhere on the payment label. Both exist as ideas — a fully cancelled order, or a payment whose result genuinely can't be confirmed — but neither has its own dedicated on-screen label today.

What that means practically: if an order needs to be treated as cancelled, the real path is to reject it if it hasn't gone through yet, or to contact the customer directly if it has, rather than hunting for a status that would say “cancelled” for you. And if a payment result genuinely can't be confirmed, the honest read is whatever the closest real label shows plus a direct check — a payment that looks stuck rather than clearly paid or declined is worth verifying with the customer or through support rather than assumed either way. Neither of these is a bug to report; it's simply not how the screen is built today.

04What a caller was actually told

Two moments are worth knowing about specifically, because they're the two ends of the same honest principle: a caller is never told more certainty than Dohos actually has.

The moment right after a request is sent, before any restaurant has actually acted on it, gets a direct, unambiguous answer if a caller asks whether it's already gone through:

That's the acceptance axis, stated in plain language a caller actually asked for — sent is not the same as accepted, and Dohos never lets a caller believe otherwise just because the review already happened on the call.

Later, once an order's actually moving, a status question gets an answer with the same honesty built in — real information, paired with a clear statement of what Dohos can't personally verify. What a caller actually hears names the current fulfillment value plainly — accepted, preparing, ready, completed, or canceled, as of a stated time — and pairs it with an explicit boundary: Dohos is relaying exactly what the restaurant's own system reports, never something it watched happen directly. Questions is where that exact line lives, word for word, as the caller's own side of the same status check this page walks through from the console. That boundary matters as much as the status itself — a caller gets the real, current answer, stated with an honest boundary around where that answer actually comes from.

05When something doesn't add up

Two situations come up often enough to plan for directly.

1. A status looks stuck — an order's fulfillment label hasn't moved in a while, or payment shows pending longer than seems reasonable. Check the order's own event history before assuming anything's actually broken; a status that hasn't visibly changed on screen sometimes just means nothing new has happened yet to report, not that an update was lost. If it genuinely looks wrong after that check, that's worth a direct look rather than a guess either way.
2. A caller says they were told something that doesn't match what the screen shows right now — most often because time has passed and the order has moved since the caller last heard an update. Read the caller the current state plainly, the same honest way Dohos itself would, rather than assuming either the caller misheard or the screen is wrong. If the mismatch involves whether an order might have been submitted more than once, that's a distinct question with its own answer on Duplicate orders and charges, not something to resolve from the status labels alone.

Neither situation usually points to anything broken. Reading all three axes, checking what actually changed and when, and being straightforward with the caller about what's currently known resolves almost every version of “this doesn't look right.”