Operations
The ambient state of a shift — not any single call, not any single order, but whether the tools an operator and their staff actually depend on are working the way they're supposed to across every call and order happening during it.
A customer never experiences any of the three situations here as one isolated interaction the way they might experience a dropped call or a stuck payment link. Each is closer to a piece of infrastructure sitting underneath the whole shift — either behaving correctly for everyone using it, or quietly not, in a way that only shows up once someone notices something feels off across several calls or several tickets rather than just one.
The three sit in a rough sequence, even though nothing requires reading them in that order. Before anything else can happen, a call has to actually be reaching Dohos at all. Once it does, whatever the assistant tells that caller about how long things will take has to reflect reality, not a guess. And once an order comes out of that call, whatever staff see on the tablet has to actually match what's really happening. Arrival, what's said, what's shown — each capable of quietly drifting from the truth independently of the other two.
Current wait time carries more weight than the other two, because that number gets spoken out loud to nearly every caller who asks — a stale or wrong wait time is something a customer notices directly, on the call, in a way neither a forwarding problem nor a tablet problem usually is. The other two sit further back from the caller, closer to the machinery than the conversation: a call has to actually arrive before any wait time gets quoted or any order gets taken, and staff have to actually see what a call produced once it's over.
None of the three assumes the other two are also broken. Calls can be reaching Dohos perfectly while the quoted wait time is stale because nobody's updated it this shift; the wait time can be accurate while the tablet showing tickets in the kitchen is the thing actually out of sync. It's tempting, when one of the three looks wrong, to assume the other two must be involved too — usually it's exactly two separate things with two separate causes that happened to surface around the same moment. Treating them as one combined incident risks fixing the wrong thing first, or missing that a real second problem is sitting underneath what looked like a single symptom. It's also worth naming who actually notices each one first: a wait-time problem is felt by a caller directly, on the phone; a forwarding problem is felt by whoever would have taken that call, who instead never even knows it happened; a tablet problem is felt almost entirely by staff.
Every situation in this topic is meant to be checked before a shift gets busy, not discovered for the first time in the middle of one. A wait time worth trusting is one that's been looked at and updated before the dinner rush starts. A forwarding problem is far easier to diagnose calmly, with no caller waiting, than during a stretch where every unanswered ring is a missed order. A tablet worth relying on mid-shift is one confirmed working — sound on, sync current — before the first ticket of the day needed to show up on it. None of the three is impossible to fix reactively, but all three are considerably easier as routine, proactive checks than as emergencies discovered under pressure.
It's also worth being honest that none of the three has a caller-facing “correct” answer the way a payment status does. There's no single right wait time independent of what's actually happening in the kitchen right now — it changes shift to shift, sometimes hour to hour. There's no single symptom that always means forwarding is broken rather than merely slow. A tablet that looks wrong for a moment during a real network hiccup isn't the same as one that's genuinely stuck. Each article spends real time on exactly that kind of judgment call — telling a genuine problem apart from an ordinary, temporary blip — rather than a fixed checklist to run through mechanically.
None of the three articles above is about a single call's own specific outcome — a drop, a transfer, a caller who was hard to understand — which belongs under Callsinstead, even though a forwarding problem and a dropped call can sometimes look similar from a distance. A dropped call is one specific conversation failing after it started; a forwarding problem is calls failing to arrive at all, before any conversation can start. Likewise, none of the three is about a single order's own contents or status once it exists — that's Orders & menu, a question about one specific record rather than about whether the system underneath every record is behaving correctly.
Setting any of this up for the first time — provisioning a number, forwarding it for the first time, getting a tablet ready before a restaurant has taken any real calls yet — is also not what this topic covers. That's getting-started material, read once before going live; what's here instead is for after that setup is done, when something that was working stops working, or when a number that's always been set needs to be checked or changed mid-operation. One more boundary: none of the three articles here is about a restaurant's account settings in general — billing, team members, or plan details live elsewhere entirely, not in anything about how a shift is actually running day to day.
Taken together, the three articles here are less about any one dramatic failure and more about the unglamorous, easy-to-overlook maintenance that keeps an ordinary shift ordinary — and if one of them still doesn't hold up against what you're actually seeing, write to support — a real person reads it. Name the location, what you were doing, and any order or call reference you have.