Begin with outcomes, not feature adjectives
Review a representative set of calls or staff notes that you are authorized to use. Group them by intent: pickup order, delivery order, reservation, change to an existing booking, menu question, hours, complaint and staff-only request. Use counts only if you actually have them. If you do not know your call mix, label the estimate and collect a baseline before using it in a business case.
For each intent, write one observable result. “Guest orders dinner” becomes “The confirmed items, quantities and modifiers reach the correct location's order workflow with payment state clear.” “Guest books a table” becomes “The booking appears in the existing reservation book with the correct party size, date and time.”
Separate essential requirements from preferences
Must-pass gates should be few and specific. Examples include the ability to reject unavailable items, preserve required modifiers, route staff requests correctly and prevent an unconfirmed payment from being treated as paid. A pleasant voice may be a preference; a readable kitchen ticket is a gate for ordering.
Do not silently treat every desirable feature as essential. A restaurant that wants only answering and transfer may not need payment or reservation writing. On the other hand, a concept buying complete order capture should not accept a message-taking workflow as equivalent. Write the boundary in the purchasing brief.
Map the owner for each source of truth
List the systems that own menu prices, modifiers, item availability, business hours, reservation availability and escalation rules. Name who can authorize a change in each. Include local variations such as a location-specific menu or a kitchen that stops accepting orders before the posted closing time.
Ask the vendor how it reads each source and what a failed update looks like. A setup process can be quick but still inherit incorrect information. Your test should deliberately include one changed price, one unavailable item and one special-hours rule. Verify the result in the destination system, not just the spoken answer.
Set measurable acceptance criteria
Define a test unit before choosing a target. Is an order correct only when every line, modifier and fee is right? Does a reservation pass only after it appears in the live book? Does a handoff pass only when the intended staff member receives usable context? Record failures and excluded cases rather than removing difficult examples from the sample.
Loman’s company-reported 99.6% figure is scoped to its proprietary simulated 1,000-call order benchmark. It can inform questions about evaluation, but it is not your acceptance test. Your own target must reflect the risk and workflow you intend to deploy.
A brief you can take to a vendor
- Restaurant and location scope, without guest personal information.
- Call intents to automate and intents reserved for staff.
- Installed product names, relevant versions and required destination records.
- Must-pass gates and weighted preferences.
- Who witnesses tests and who signs off on rollout.
- How unresolved issues are recorded, retested and escalated.
Use this brief to configure the scorecard. Keep commercial terms separate from capability evidence, then bring both together in the decision record.
Turn a feature into a testable requirement
Weak requirement: “Supports ordering.” Testable requirement: “A caller changes one quantity after readback; the correct final quantity and required modifier appear at the right location, with payment state visible.” The restaurant chooses its pass rule before the demo.
Start from Loman’s plan scope and the relevant Toast order workflow if that is your installed system. State what you must observe instead of copying product adjectives into the purchasing brief.