Nothing about an order waits until the end to be checked.
A spoken request doesn’t turn into a ticket in one motion at the finish. It’s built up piece by piece, and each piece is confirmed against what the kitchen can actually deliver right now, the moment it’s said — not held back for one bulk review once the caller stops talking. This page follows that build, in order, from the first item to the ticket it produces.
Checked the moment it’s said. Again for the next. All the way through.
An order isn’t validated once, at the end, against everything a caller said. Each item is checked the moment it’s added — against what the menu actually has, what it actually costs right now, and whether it’s actually available — and that check happens again for the next item, and the next. By the time a caller stops adding things, there’s nothing left to verify in bulk, because nothing was ever allowed to sit unverified in the first place.
That’s a genuinely different shape from checking everything after “that’s it.” A price, an availability fact, or a modifier rule gets confirmed the moment it’s relevant, rather than reconstructed afterward from what was said several items ago.
It also means a caller never hears a pile of corrections at the end. If something needs a substitution or a clarifying question, it comes up right where it happened — next to the item it’s about, not bundled into one long list right before the readback.
Acceptance and payment don’t start or stop together.
An order runs on two separate clocks. The first is an acceptance clock — set the moment an order is confirmed, whether that confirmation goes straight through or lands with a person first. The second is a payment clock — set later, whenever money actually changes hands, which for a phone order today means when it’s collected at the counter or the door.
Neither axis is owned by this page in full — orders covers what “accepted” actually means, and payments covers how the payment clock resolves today. What belongs here is the fact that they’re two different clocks in the first place, since neither of those pages, on its own, states when they diverge.
What the caller says, matched against what the menu returns.
Every item a caller names gets matched against the restaurant’s own published catalog — its real price, its real modifiers, its real availability right now — not a separate summary that might have quietly drifted out of date. What a caller says on one side, what the menu actually returns on the other, checked item by item rather than trusted on the caller’s word alone.
That single source is why a price never has to be reconciled later. The number an item carries the moment it’s added is the same number it carries on the ticket — because it was never calculated twice. Menu intelligence covers how that one record stays consistent everywhere it shows up, including the 86 cascade — what happens when a component the menu depends on runs out mid-build.
The readback, the fork at confirmation, and the one hand-off.
Before anything moves anywhere, the whole order gets read back — the actual items, the actual total, the actual fulfillment details — and moving forward takes a clear yes, not silence or a change of subject. That readback is bound to the exact order it describes: change anything after the fact, even one more item tacked on right before it, and the confirmation the caller already gave doesn’t stretch to cover it. Orders carries the readback’s exact wording and effect; here, it’s the one moment every order passes through before it’s sent anywhere, however it got built.
Once confirmed, an order splits toward one of two paths. Most go straight through — nobody sits and approves each one individually. A short, named list of exceptions routes to a person instead, covering everything from an unusually large order to a single handwritten note left on an item; orders defines the exact list, not this page.
Not every order auto-accepts, and this fork is why. What sends an order to manager review is that short, named list — not a vague safety net that catches most orders, and not a judgment call made fresh each time. And where an order lands doesn’t change how it got built: the running check runs identically either way. The fork happens once, at confirmation, after all that checking is already done.
A delivery address gets entered, and the same three delivery rules the restaurant configured — how far it delivers, what that costs, and the smallest order it’ll take — apply the moment the address is given, not as a surprise later. What isn’t automatic is the exact pin on a map. That confirmation — this address, this exact spot — is still a person’s job today: the one place in the whole build where something hands off from the running check to an actual person before the order is even finished.
The whole build, on one real shape of call.
TWO ENTRÉES, CHECKED AS NAMED
A caller orders two entrées and a delivery to an address a few streets over. Each entrée is checked and priced the moment it’s named, the way every item is.
THE ADDRESS, RULED ON AT ONCE
The address goes in next, and the restaurant’s own delivery rules — how far, what it costs, the smallest order allowed — apply immediately, confirmed before the call goes further rather than surfacing at the end.
THE READBACK, THEN A CLEAR YES
The full order gets read back — both entrées, the delivery fee, the confirmed total, the delivery window — and the caller says yes to exactly that. Nothing about this order trips any of the restaurant’s configured review triggers, so it’s accepted straight through; its acceptance clock stops there. Its payment clock is still running — payment happens later, in cash, collected at the door.
THE PIN, CHECKED BY A PERSON
Once accepted, the order reaches staff as a ticket carrying the exact address the caller gave. Before it goes out, a person checks the actual pin on a map — the one step in this sequence that isn’t automatic — because confirming precisely where a delivery address sits is still a person’s job today. Everything before that point ran on its own; that last check didn’t.
The questions people actually ask.
Can the price change after I confirm?
Only with a new, explicit readback. The order that was read back and confirmed is the order that goes forward — a later change gets its own confirmation, never folded silently into the one that already happened.
What if an item runs out while I'm still ordering?
The running check catches it the moment it’s relevant, not after the fact — menu intelligence covers exactly what happens when a component the menu depends on becomes unavailable mid-build.
Does the kitchen see the order before or after payment?
Often before. Acceptance and payment run on two separate clocks, and for an order paid at pickup or the door, the kitchen can already be working from an accepted order well before that second clock finishes.
What if the restaurant doesn't actually accept it?
That’s handled honestly, not silently. Where acceptance genuinely can’t be confirmed, the honest move is to check again rather than assume either outcome — orders covers exactly how that’s handled.
Once accepted, the order still has to make its way onto the restaurant’s own POS by hand — a staff member keys it in, the same way they would any other ticket. Nothing in this sequence transmits it there automatically.
The restaurant’s configured rules govern whether an address qualifies and what it costs — but nobody’s cross-checking the street against a real map while the caller is on the line. Pinning the precise spot stays a person’s job today, handled after the fact.
Unless a manager has actually confirmed a current wait, a quoted time is an estimate, and it’s said as one. Nothing about how quickly an item was checked implies anything about how quickly it will be ready.
Orders
Sizes, halves, swaps, allergies — the whole order, read back in full for a yes.
OPEN →PLATE Nº 007Menu 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 →See the check run on your own menu.
Request access and watch an order get checked against your own prices, your own radius, your own rules — not a demo menu.