The moment a call or an order needs a person, a real signal goes out.
Not a phone ringing somewhere. What happens today is an alert landing on whatever screen the shift is already running from. This page walks that mechanism start to finish: the three real doors into it, what today’s notification does and does not do, and — because the same two words describe a genuinely different mechanism elsewhere on this site — a direct look at how the two differ.
Three doors in.
None of them a mood Dohos infers.
Three different moments send a call or an order toward a person. All three funnel into the same place, and what happens next never depends on which one got there first.
The third one does not wait for anything else to finish first. A wrong guess there is a materially worse outcome than a wrong guess on an ordinary menu question, so it does not sit and wait for the item to be finished before it matters.
None of the three is inferred from tone, hesitation, or how a caller sounds. A direct ask has to be asked. A threshold has to actually be crossed. An allergy question has to be asked in words. Dohos does not read between the lines here — it responds to what is actually there.
One channel is live.
It is the screen.
There is exactly one path a notification takes today, and it is worth naming plainly rather than leaving a reader to assume the more familiar one. It shows up as an alert on whatever screen the restaurant’s shift is already running on — the owner console, or the tablet propped at the pass — the same surface a manager would already be glancing at to run the shift. Nothing rings. Nothing arrives as a text. Nothing lands in an inbox.
That is narrower than the underlying system could technically support. The notification record has fields built for a phone call, a text, and an email — structurally ready for all three — but none of those fields is wired to anything that fires. If the person meant to see that screen is not looking at it in the moment, nothing fails over to a ringing phone or a buzzing pocket to catch their attention a second way. The request sits, counted against the same window that applies whenever a manager doesn’t respond at all.
This page never describes the notification as reaching whichever channel is set up for it. There is exactly one channel live today, and it is the one named above.
The same sequence runs
whichever door it came through.
A caller who simply asked for a person and an order that tripped a configured threshold on its own end up on the same path the moment either arrives. The chain itself belongs to escalation — it is narrated here rather than redrawn, because that page owns it in full.
IT LANDS AT THE SHARED POINT
Whichever of the three doors it came through, it arrives at one place. Nothing about entering this chain is a dead end, a queue nobody is watching, or a decision quietly being made without the restaurant’s own rules behind it.
THE MANAGER ON DUTY IS SIGNALLED
Whoever the restaurant has named manager on duty for that shift sees it on the screen they are already running the shift from. The caller is told honestly that somebody needs to look, with nothing promised about exactly when that happens.
IF NOBODY RESPONDS, IT REACHES THE OWNER
Past the window the restaurant configured, the request escalates once to the owner fallback, exactly as the chain is built to. It is not left stuck waiting on one person who is not looking.
AND IF NOBODY RESPONDS AT ALL
The request is marked plainly as still waiting. It is never described as complete, resolved, or handled when it isn’t — and it never quietly disappears while it is being sorted out.
The caller is not left guessing while any of that happens. The moment is acknowledged, what is being tried is stated as an attempt rather than a guarantee, and a real outcome gets told plainly once it is actually known:
This order is over the size this restaurant reviews by hand, so someone there needs to look at it before I can confirm it. I’ve sent it to them with everything you told me. I can’t promise when they’ll get to it — would you like to stay on, or have them call you back on this number?
AN ILLUSTRATION OF THE SHAPE, NOT A TRANSCRIPTION · THE VERBATIM WORDING FOR EVERY ASK-FOR-A-PERSON BRANCH — INCLUDING WHAT PLAYS WHEN A TRANSFER FAILS — IS QUOTED IN FULL ON ESCALATION, NOT RE-QUOTED HERE
The same two words.
Two genuinely different mechanisms.
Manager, then owner, describes something else entirely elsewhere on this site. The only honest way to keep them apart is to show both at once rather than trust a reader to remember a distinction made in passing.
| ESCALATION — THIS PAGE | RELIABILITY | |
|---|---|---|
| WHAT TRIGGERS IT | A business decision — a direct ask, an order past a line, an allergy question. | A technical failure — the system itself running into trouble mid-call. |
| HOW IT REACHES SOMEONE | A signal on a screen, waiting to be seen. | A live phone call, dialed in real time. |
| WHAT IT'S ASKING FOR | A person's judgment on something Dohos correctly won't decide alone. | A person to actually pick up and keep the call going. |
| WHETHER A PHONE RINGS | No — not today. | Yes — an actual outbound call attempt. |
Neither is a lesser version of the other, and neither substitutes for the other. An order sitting in review because it crossed a large-order line is never resolved by a phone call, and a call that drops because something behind the scenes failed is never resolved by a message waiting on a tablet. Reliability covers that second mechanism in full — it belongs there, not folded into this page’s chain even as a passing comparison.
Three settings decide how this behaves.
None of them is a Dohos default.
NO NUMERIC VALUE APPEARS ANYWHERE IN THIS SETTING LIST · SETUP COVERS WHERE ALL THREE ACTUALLY GET DECIDED
A large order, and what happens next
A caller is finishing a catering order large enough that its total crosses the restaurant’s own configured line for a second look. At the moment of confirmation, that is exactly what happens — the order is not rejected, and it does not quietly slip through. It enters through the order-side trigger, the structural one, not the direct-ask branch.
The manager on duty’s own tablet, already open for the shift, picks up the alert. The caller is told honestly that someone needs to look the order over before it is confirmed. The manager sees the signal, responds inside the window the restaurant configured, and the order proceeds. The caller is told plainly that it was accepted.
A second version of the same moment: this time the manager doesn’t respond inside that window. Rather than leaving the order stuck, the request escalates once to the owner, exactly as the chain is built to. If the owner responds, the same honest outcome follows. If nobody does, the request is marked plainly as still waiting — never dressed up as resolved when it isn’t.
Asked plainly, answered plainly.
So does someone actually see this fast?
No number exists to answer that with, and this page doesn’t borrow one from anywhere else to sound more reassuring. What happens is the signal described above, with no timing commitment attached to it.
What if this is really a technical problem, not a business one?
That’s a different mechanism entirely, covered on reliability — a live transfer attempt triggered by something failing mid-call, not the signal-based chain this page describes.
Can a caller just push and get a person on the line?
Pushing harder doesn’t summon somebody who genuinely isn’t reachable right now. What happens next — escalation names the real options — is decided by what’s actually available at that moment, never by how insistent the caller is.
What if nobody ever responds?
It isn’t left to quietly disappear. Past both configured windows, the request is marked plainly as unanswered — never described as resolved when it isn’t.
Whether an alert gets seen right away or sits for a while depends on the restaurant, the shift, and how busy that shift happens to be — a real variable stated honestly rather than averaged into a promise.
The same way anything sitting on a screen can. This page says so plainly rather than describing a mechanism that always works.
Someone facing a genuine emergency is pointed straight at local emergency services rather than left waiting on a chain that was never built to handle it.
GO DEEPER
Escalation
The moment a boundary is crossed, a person is in it — manager on duty, then owner fallback.
OPEN →PLATE Nº 015Reliability
It fails open: when something breaks, callers hear the truth and reach a person — never dead air.
OPEN →PLATE Nº 017Setup
Forward your number, load your menu, place a test call. No new hardware.
OPEN →See your own chain.
Request access and set the same three entry points, the same manager-then-owner sequence, on your own restaurant's schedule.