Running the first call test

This is the structured test built into onboarding — a fixed set of scenarios run against your own real configuration — rather than an informal call where you improvise questions and hope you'd notice if something were wrong.

01What needs to already be true

This test only tells you something useful once the two tasks before it are genuinely finished. A number that isn't actually forwarding, or a menu still sitting as an unpublished draft, doesn't produce a meaningful failure here — it produces a result that looks like a problem with the test itself, when the real issue is upstream. Confirming those two first is what makes a failure here trustworthy.

You don't place any of these calls yourself. Running the test triggers a real call through your configured number automatically, from the same screen where you start it. Your job is watching the result. The control disables itself for the duration, so a second tap can't stack a second run on top of one already in progress — if nothing seems to happen when you tap again, that's why.

02Why a fixed set, instead of just calling in yourself

An improvised test call only proves what you happened to think to ask, and a second attempt a week later rarely checks the same things — you end up with an impression, not a record. The structured test runs the same fixed situations every time, against whatever you've actually configured, so a pass means something specific was checked and a fail points at something specific to fix. A result from this week is directly comparable to one from before a settings change, and anyone on the team who runs it later checks the exact same ground.

It's worth having whoever set the relevant policies present while this runs — a failure is far faster to diagnose when the person watching also knows what the special-request wording or the on-duty schedule was supposed to say.

03The scenarios, and what each one actually proves

• Places a standard pickup order. The most basic promise the setup makes, and the scenario most tied to the two tasks before it: a caller understood, matched against your published menu, walked through pricing and a full order review, ending at a confirmed order — everything behind the call holding together end to end.
• Asks for a special request. Restaurants configure their own rule for off-menu asks — allowed outright, allowed without a guarantee, sent to manager review, or declined, each with its own spoken wording. This exercises whichever your restaurant actually configured: does the wording and routing behave the way you expected once a real call reaches it, not just how it read on the settings screen.
• Asks for the current wait time. The number a caller hears is the one set on the operations side, read back exactly as configured — the fastest way to confirm it's current before a caller hears something stale.
• Escalates to a manager. Walks the same path a real call takes when a caller asks for a person or something crosses a configured boundary — checking a manager is actually reachable on the schedule you set, before an actual customer tests it for real.

04Reading the result

Each scenario gets its own result — not run, passed, or failed — never one combined score. Three passing and one failing is a specific, fixable problem with one part of your setup, not a reason to distrust the three that proved themselves.

Running the test again re-runs every scenario from the start — there's no selective retry. That's a reasonable trade: after fixing a special-request wording, it costs little to reconfirm the pickup-order and wait-time scenarios still pass, since a change made to fix one thing occasionally lands somewhere unexpected. A clean pass across every scenario on the first attempt is a genuinely good sign, not a reason for suspicion — nothing further is required beyond moving on to the last task.

05When a scenario fails

• The pickup-order scenario fails. Start with the menu — an item, price, or modifier that didn't parse or publish as expected is the most common cause. Confirm the menu shows as published, not draft, then run it again.
• The special-request scenario fails, or the wording sounds wrong. Usually the policy step, not the call — check the exact wording configured against what you actually want said, adjust, retry.
• The wait-time scenario reads back a wrong or missing number. Check what's actually set — a wait time has to be entered before it can be read back accurately.
• The manager-escalation scenario fails. Check who's configured as on duty for the relevant time, and that the contact number is current — a schedule that looks right but points at an old number or an unstaffed window is the most common cause.
• A scenario keeps failing after a check and a retry. Treat it as a real question rather than something to keep guessing at — write to support with which scenario is failing and what you've already checked.

06Worth running more than once

Nothing about this test is meant for a single occasion before going live. Any time a setting a scenario exercises changes later — a new special-request rule, an updated on-duty schedule, a menu republished after edits — running it again confirms the change behaves as intended before a real caller finds out otherwise. The test stops being useful only once nobody bothers running it after something changes.