Getting set up has a real shape. This page describes the shape — not a duration.
Eight phases, in a fixed order, thirty-two named steps between them — each one deciding something specific before the next one makes sense. No step comes with a clock attached, because no honest one exists for this sequence. What follows is the real shape of it, not a guess dressed up as a schedule. No new hardware anywhere in it.
Eight phases, each deciding what the next depends on.
Each phase depends on the ones before it in a specific way — a phone number configured in the second phase is what a test call in the last phase actually rings, and a menu published in the fourth is what a caller in the sixth hears priced back to them. Nothing here is an arbitrary checklist order; it’s the order each piece actually needs the one before it.
Policies is the largest phase after Menu, and it’s worth naming what it covers rather than leaving it as one word: special requests and how they’re worded, the large-order threshold, how payment is handled by fulfillment type, the confirmation and readback behavior, promotions, upsell limits, and whether changes or cancellations are allowed at all. Calls covers the settings that shape a call once it isn’t a straightforward order: status-call handling, the non-order behaviors, the escalation chain’s own timing and channel, and the voice itself.
Menu, the largest of the eight — made concrete.
A menu comes in first — uploaded or entered directly, parsed into a draft. It gets reviewed next, with whatever the parse got wrong or left ambiguous flagged for a person to fix. Modifiers get set — what’s included, what costs extra, how many of an option is actually allowed. Components get connected — the shared ingredients behind more than one item, and what happens to each item if one of them runs out.
Pronunciation gets handled — aliases and how the menu is actually said, generated first, then corrected by hand. Publishing is last, and it’s an explicit action, not something that happens automatically once the rest is done. Menu intelligence covers what that published catalog then does on every call.
This page doesn’t walk any single step’s fields or validation rules — that level of detail belongs to the sequence itself, worked through once an account exists, self-serve or hand-set-up. Once a restaurant has one, several of these tasks get an operational walkthrough of their own on getting started.
A named status, never a percentage bar.
Every step carries a plain status rather than a percentage or a projected date. That’s the full, named set a step can actually be in:
Activation only unlocks from exactly one of those — the step marked ready for activation — never from getting close, and never on a timer. A restaurant with one step still marked incomplete simply isn’t offered the activation action yet, regardless of how much else is finished. A step that’s blocking says specifically why — a missing answer, a failed test, a review still pending — rather than leaving a restaurant to guess.
A step marked complete stays that way until something actually changes it — reopening one later, to fix a phone number or adjust a threshold, doesn’t quietly unravel any of the others. Each step’s status is its own fact, tracked independently — the same discipline the rest of this site holds an order or a call’s own state to.
Where a restaurant’s own decisions actually live.
Nearly everything a call or an order does later traces back to a decision made somewhere in this sequence. The window before an unanswered request moves from the manager on duty to the owner, whether owner fallback is on at all, the voice a restaurant picked, the size that counts as a large order — none of that is a Dohos default running quietly in the background. Each is a real setting, entered once, here, and read from everywhere else it matters afterward.
That’s what connects this page to everything else the site describes. A call or an escalation only behaves the specific way it does for a specific restaurant because of a choice made during exactly this sequence, in the Calls or the Policies phase.
One restaurant’s path through it
LOCATION, THEN PHONE
An owner works through Location first, naming who’s actually the manager on duty for each shift, with a fallback in case that person isn’t reachable. In Phone, they choose to port an existing number rather than take a new one — the same number regulars already have saved, moved over instead of replaced.
MENU TAKES THE MOST WORK
The import brings in most of the catalog cleanly, but review flags two items that came through without a price attached, and those get corrected by hand before the phase can be marked done.
POLICIES — THEIR OWN LINE
They set the actual size that counts as a large order for their kitchen — not a number this page invents on their behalf, one they choose for their own volume.
CALLS — THE WINDOW, AND THE FALLBACK
The same owner sets the window an unanswered escalation waits before it moves from the manager on duty to them personally, and turns owner fallback on. That’s the exact setting a caller’s own request depends on the day the restaurant is live — decided here, once, read from everywhere else afterward.
Nothing about this account states how long any of it took, for this restaurant or any other. What it shows is the real order things happen in — and that each phase’s decision is still sitting there, unchanged, the next time it’s read from.
What people ask, and the one thing this page won’t state.
How long does this actually take?
No measured figure exists, for this restaurant or any other, so this page doesn’t estimate one. What actually determines it is how ready a menu is coming in, and how many corrections review turns up — not a fixed number of hours anyone could promise in advance.
Can steps be done out of order?
Some can; several genuinely depend on an earlier one already being decided — a test call in Launch needs a real number already configured in Phone, for instance. The status model above shows honestly what’s still blocking at any point, rather than forcing one rigid order for everything.
What happens if something's still incomplete?
It’s named specifically, not hidden. A step that’s blocking says why, and activation simply isn’t offered until every blocking step actually clears — never approximated or rushed past.
Who actually does this — us, or Dohos?
Handled with the restaurant, not handed to it. Menu review, phone porting, and the rest are real decisions a restaurant makes; getting started covers the operational detail behind several of them once an account exists — opened self-serve at signup, or set up with a person through access.
Does every restaurant go through the same eight phases?
Yes — the sequence itself doesn’t change from one restaurant to the next. What changes is how much correction a given phase needs, like how clean an imported menu already is — not which phases exist or what order they run in.
The same eight phases — with no clock anywhere on them
No duration is stated for this sequence anywhere on this page — not as a number, and not as a softer word standing in for one. Words that promise speed are duration claims wearing a costume, and this page holds the same line against them that it holds against a figure.
Start the real sequence.
Sign up at /signup to begin the eight phases described above yourself, on your own restaurant’s information — or request access and start them with a person instead. Neither is a demo account.