Skip to main content

Voice order assistant

A transcript is not a customer's order.

A voice order assistant turns spoken requests into a customer-reviewed cart using the current outlet menu, availability and prices. The pattern Werkon would validate asks focused clarifying questions and preserves item, modifier and charge details before submission. Customers confirm the order, the ordering system supplies acceptance, and staff retain responsibility for dietary questions, preparation, delivery and recovery.

Capture and accessible confirmation

Preserve recording notice and permitted capture, source audio where allowed, language, transcript versions, uncertainty and corrections. Voiceprint, caller ID, accent, room, table or prior orders do not prove identity, age, consent or payment authority. Offer text, touch or staff help, and evaluate recognition across supported accents, dialects, devices, noise, overlap and code-switching.

Read back exact items, variants, quantities, modifiers, removals, substitutions and itemized charges. Clarification should be short, interruptible and recoverable. Silence, background speech, impatience or repetition is not confirmation. Never silently add a size, side, cooking choice, tip, donation or paid replacement.

Menu truth and order acceptance

Use current outlet records for availability, ingredients, allergens, prices, taxes, fees, deposits, discounts and service terms. Marketing descriptions do not establish dietary suitability. Missing data or a product name cannot prove an item is allergen-free, halal, kosher, vegan or vegetarian. Preserve the customer’s requirement and route medical, allergy, alcohol, age and ambiguous preparation questions to accountable staff.

Recheck menu, price, location and capacity immediately before one authorized submission. Keep sent, validated, accepted, rejected, timed-out and unknown-effect states distinct and reconcile uncertainty before retrying. A spoken yes, network acknowledgment or printed ticket does not replace the ordering system’s acceptance receipt. Keep payment in hosted or tokenized paths outside audio and model context, then reconcile preparation, collection, delivery, refund and dispute evidence.

Order boundary

Hear the request without manufacturing customer intent.

Voice is an input channel, not commercial authority. Four boundaries keep speech uncertainty, menu truth and physical service inspectable.

01

Capture, speaker context, and transcript evidence

Bind the session to outlet, channel, local time, business date and allowed purpose; preserve capture conditions and transcript alternatives; and provide visible recording status, correction and an equivalent non-voice route.

Required evidence: Tenant and outlet, device or call, channel and session, local zone and business date, notice and consent where required, audio reference and retention, speech segment, language, transcript versions, alternatives, uncertainty, overlap, noise and customer correction.

02

Menu item, modifier, and safety truth

Map only to current outlet records, enforce required and allowed modifier groups, expose availability and price, and route ingredient, allergen, dietary, alcohol and ambiguous preparation questions to accountable sources and staff.

Required evidence: Menu and outlet version, item and variant identifiers, size, quantity, modifier group and option, minimum and maximum selections, exclusions, ingredient and allergen source, dietary statement, age rule, availability, price, charge and effective time.

03

Customer-reviewed cart and exact quote

Clarify uncertainty without defaulting, read back or display every consequential detail and full total, preserve the customer's changes and obtain explicit review of the final cart before submission.

Required evidence: Utterance-to-item candidate, clarification, selection and rejection, cart version, line item, removal and addition, disclosed warning, unit price, adjustment, tax and fee inputs, total, fulfillment, timing statement, confirmation words and review timestamp.

04

POS commit, payment, and observed service

Send one typed idempotent command, reconcile timeouts before retry, keep payment outside voice context and join only authoritative acceptance, preparation, collection, delivery, cancellation, refund and dispute evidence.

Required evidence: Command and idempotency key, POS destination, submitted cart hash, sent, received, validated, accepted, rejected, timeout or unknown-effect state, order identifier, payment states, kitchen or service status, delivery, cancellation, refund, complaint and recovery.

Speech-to-service path

Keep heard words, reviewed cart, and delivered order separate.

Every transition needs its own owner and receipt. A natural conversation cannot collapse commercial states safely.

  1. 01

    Open a scoped and accessible session

    Resolve outlet, channel, local time, business date, service mode, customer or representative context, language, recording rule and non-voice alternative before collecting order details.

    Owner
    Service, privacy, accessibility and channel owners
    Evidence
    Tenant and outlet, channel and session, service location, local zone, business date, requester role, language, notice and consent, retention, accessible alternative, human-help route and blocked context.
  2. 02

    Transcribe, map, and clarify

    Segment speech, preserve transcript alternatives, map words only to current menu candidates and ask focused questions when item, variant, quantity, modifier, fulfillment or safety meaning remains ambiguous.

    Owner
    Speech, menu, accessibility and service-design owners
    Evidence
    Audio segment, capture conditions, transcript candidates, uncertainty, menu version, item candidates, excluded match, ambiguity class, clarification prompt, customer correction, unsupported-language and staff-handoff state.
  3. 03

    Validate and confirm the exact cart

    Apply deterministic menu grammar, availability and arithmetic, disclose itemized details and safety limits, then read back or show every line and the complete total for customer correction and explicit confirmation.

    Owner
    Menu, operator, safety, finance and customer owners
    Evidence
    Validated item and modifier identifiers, availability read, ingredient or allergen route, quantity, unit price, adjustment, tax and fee input, total, fulfillment, timing source, cart version, confirmation and rejected or changed detail.
  4. 04

    Submit once and reconcile authority

    Re-read changing records, submit the confirmed cart with one idempotency key and report only observed POS state; investigate timeout and unknown effect before any retry or customer instruction.

    Owner
    Point-of-sale, integration and duty-manager owners
    Evidence
    Pre-submit source versions, confirmed cart hash, command, destination, idempotency key, transport attempts, POS response, accepted order identifier, rejection, timeout, unknown-effect query, reconciliation and manual disposition.
  5. 05

    Separate payment from physical service

    Use an approved non-audio payment path, preserve each payment state independently and reconcile order acceptance with preparation, readiness, collection or delivery, correction, cancellation, complaint, refund and dispute.

    Owner
    Payment, kitchen, fulfillment and service-recovery owners
    Evidence
    Payment destination and token reference, authentication, authorization, capture, settlement, void, refund or dispute, preparation and ready states, collection or delivery receipt, correction, cancellation, complaint, recovery and unresolved order.

Authority map

Separate speech assistance, commerce controls, and operator judgment.

A model can propose what the customer may have said. It cannot create menu facts, decide allergy safety, move money or declare an order served.

01

Deterministic order controls

Software owns tenant and outlet scope, session policy, menu identity, required modifiers, exclusions, quantity, availability, price arithmetic, tax and fee inputs, promotions, cart versions, confirmation gates, idempotency, POS transitions, payment isolation and receipts.

  • Outlet, channel, menu, item, variant, modifier, business-date and customer-context identifiers
  • Required-choice, cardinality, exclusion, availability, price, currency, quantity and total checks
  • Confirmed-cart hash, POS destination, command, idempotency and unknown-effect reconciliation
  • Transcript, correction, quote, order, payment, preparation, delivery and recovery receipts
02

Bounded AI assistance

Models can transcribe supported speech, propose language and item candidates, identify missing order fields, draft focused clarification, summarize the cart and prepare a staff handoff while exact catalog, safety, commerce and action rules stay outside the model.

  • Speech-boundary, transcript, language and uncertainty candidates
  • Item, variant, quantity, modifier and fulfillment mapping candidates
  • Clarification, read-back and plain-language explanation drafts
  • Unsupported request, safety concern and human-handoff summaries
03

Customer and operator authority

Customers own corrections, selected options and final cart review; accountable staff own menu, ingredients, allergens, access, age, availability, price, tax, substitution, capacity, preparation, service, cancellation, complaint, refund and recovery.

  • Customer language, interaction method, item correction, modifier selection and cart confirmation
  • Ingredient, allergen, dietary, alcohol, age and safety interpretation
  • Availability, pricing, promotion, substitution, capacity and timing decisions
  • Order acceptance, preparation, delivery, cancellation, refund, complaint and recovery decisions

Voice-order components

Build a correction and commit ledger, not a talking checkout.

Speech, menu and commerce fail in different ways. Four components preserve each uncertainty and commitment separately.

01

Session, audio, and transcript ledger

Bind outlet, channel, device or call, requester context, local time and business date, language, recording and transcription notice, consent where required, audio reference, capture conditions, speech segments, transcript candidates, corrections and retention.

Operating contract: Voice is not identity, caller ID is not authority, accent is not nationality, a voiceprint is not implied consent, background speech is not a customer request, transcript confidence is not correctness, silence is not acceptance and retaining audio is not automatically necessary or lawful.

02

Menu, modifier, and safety ledger

Version outlet menu, service period, item, variant, size, required and optional modifier groups, exclusions, ingredient and allergen information, dietary statements, availability, price, charges, promotion, substitution and responsible owner.

Operating contract: Item name is not ingredient truth, category is not dietary suitability, absent allergen data is not allergen-free, a kitchen note is not a safety guarantee, menu listing is not availability, default option is not customer choice, advertised price is not necessarily final total and another outlet's menu is not valid here.

03

Cart, confirmation, and quote ledger

Preserve utterance-to-item mappings, alternatives, clarifications, customer corrections, itemized cart versions, quantity, removals and additions, warnings, unit prices, adjustments, taxes, fees, fulfillment, timing source, full total and explicit confirmation.

Operating contract: Transcript is not intent, intent candidate is not selection, line-item read-back is not full-cart review, a yes to one question is not approval of later changes, quote is not order acceptance, timing estimate is not a promise and conversation completion is not informed agreement.

04

Order, payment, and service ledger

Link the confirmed cart hash to idempotent POS command, authoritative response, order identifier, isolated payment states, preparation, ready, collection or delivery, correction, cancellation, refund, dispute, complaint and recovery.

Operating contract: Sent is not received, received is not validated, acknowledgment is not accepted order, accepted order is not payment, authorization is not settlement, kitchen ticket is not preparation, ready is not collected, delivery attempt is not delivery and closed order is not satisfaction.

Delivery path

Prove one outlet, channel, and menu slice before broadening speech.

Start where recognition uncertainty, menu rules, customer confirmation, POS receipts and physical fulfillment can all be inspected.

  1. 01

    Choose one bounded ordering path

    Select one outlet, service period, channel, supported language set, menu slice and fulfillment mode with recording policy, an equivalent non-voice path, current menu owners, deterministic modifiers, observable POS acceptance and service evidence.

  2. 02

    Map speech, menu, and authority

    Inventory capture conditions, transcript and correction states, supported language and speech variation, item grammar, modifiers, ingredient and allergen owners, availability, price, charges, confirmation, POS commands, payment and recovery.

  3. 03

    Build exact clarification and commit

    Implement source-preserved transcription, candidate alternatives, focused clarification, deterministic menu validation, itemized read-back or display, full-cart confirmation, pre-submit revalidation, idempotent POS action and uncertain-effect reconciliation.

  4. 04

    Test difficult voices and orders

    Exercise background speech, overlap, interruption, accent and dialect variation, code-switching, unsupported language, speech disability, wrong item, near-name collision, missing modifier, unavailable option, allergy question, changed price, duplicate submission and POS timeout.

  5. 05

    Release narrowly and follow service

    Begin with staff review and a small customer cohort, compare transcript errors, corrections, cart agreement, inaccessible interactions, allergy escalations, accepted orders, duplicates, payment exceptions, preparation, delivery, complaints and refunds before expanding.

Release controls

Six controls before spoken words can become a submitted order.

A wrong modifier or duplicate commit affects money, safety and physical work. These controls keep every transition reviewable.

Audio use is scoped and replaceable
Show recording and transcription status where required, collect only approved audio and context, enforce purpose and retention, preserve correction and provide an equivalent text, touch or staff-assisted path without penalty.
Recognition uncertainty stays visible
Version transcripts and alternatives, preserve original words and capture conditions, ask focused clarification for ambiguous items and consequential fields, test supported speech variation and never use voice traits as identity or sensitive inference.
Menu and safety truth remain authoritative
Use current outlet items, modifier rules, availability, price and source-owned ingredient or allergen records; never infer dietary suitability; and route allergy, medical, alcohol, age and ambiguous preparation questions to accountable staff.
The customer confirms the exact cart
Never default paid or consequential choices; read back or display each item and modifier plus the itemized total, fulfillment and approved timing statement; preserve corrections; and require explicit review of the final version.
POS submission is idempotent and reconciled
Re-read changing records, send one typed command with the confirmed-cart hash and idempotency key, distinguish every transport and POS state and investigate timeout or unknown effect before retry.
Payment and service stay separate
Keep account data out of audio and model context, use hosted or tokenized payment, preserve authentication through dispute states independently and let operator systems and people own preparation, delivery, cancellation, refund, complaint and recovery.

Outcome evidence

Measure corrected carts and accepted orders, not voice containment.

A short call can still create the wrong item, an unsafe assumption or two orders. Proof joins speech evidence to authoritative commerce and service states.

Baseline

  • Outlets, service periods, channels, devices, supported languages and speech contexts, accessible alternatives, menu slices, modifier families, safety routes, POS destinations, payment paths and fulfillment owners
  • Current customer and staff time from capture through correction, clarification, cart review, POS acceptance, payment, preparation, collection or delivery, complaint and recovery
  • Current transcript and item-mapping errors, repeated clarifications, abandoned sessions, unavailable choices, modifier failures, allergy escalations, wrong prices, duplicate orders, timeouts, payment exceptions and service corrections
  • Current customer changes, rejected carts, accepted orders, kitchen or service exceptions, cancellations, refunds, disputes, complaints, remakes and observed fulfillment evidence

Outcome evidence

  • Correct outlet, session, transcript, item, variant, modifier, quantity, availability, price, charge, total, fulfillment, confirmation and POS-state handling against authoritative records
  • Transcript and intent correction, exact-cart agreement, accessible completion, safety escalation, POS acceptance and fulfillment evidence by channel, capture condition, language, speech group, item family and outlet
  • Unintended paid option, unsafe dietary inference, false availability, wrong total, duplicate order, spoken payment exposure, blind retry, false acceptance and false delivery prevention
  • Customer and staff effort, correction loops, overrides, abandoned orders, accepted commits, remakes, cancellations, complaints, refunds and physical service against the prior channel with demand and menu change visible

Guardrails

  • Wrong tenant, outlet, customer, representative, table, room, vehicle or order; recording without required notice or consent; excessive audio retention; voice identity inference; inaccessible voice-only path; and unsupported language silently processed
  • Low-confidence transcript hidden, background speech treated as selection, customer correction lost, paid modifier defaulted, unavailable item promised, wrong-outlet menu used, stale price shown and missing ingredient or allergen evidence called safe
  • Partial read-back called final review, ambiguous yes applied broadly, changed cart submitted, local validation called POS acceptance, timeout retried blindly, duplicate order created, payment data captured in audio and authorization called settlement
  • Kitchen acknowledgment called preparation, ready called delivered, delivery attempt called service, complaint closed without authority, refund promised by model, weak aggregate accuracy hiding group harm and voice containment presented as satisfaction or saving

Fit test

Use this pattern when exact carts and service states are observable.

Good reason to begin

  • One outlet has a current machine-readable menu with stable item and modifier identifiers, named ingredient and allergen owners, authoritative availability and price, exact arithmetic and clear substitution policy.
  • The channel has lawful audio and transcript handling, supported-language and speech-condition evaluation, an equivalent non-voice path, visible correction and reachable staff help.
  • The POS supports typed validated commands, durable idempotency, exact accepted-order receipts, current-state queries and safe reconciliation of timeout and unknown effect.
  • Preparation, readiness, collection or delivery, cancellation, remake, complaint, refund and dispute can be joined without exposing payment data or disrupting live service during testing.

Resolve before beginning

  • Audio purpose, notice, consent, retention, supported speech, accessible alternative, menu ownership, ingredient and allergen source, modifier rules, pricing, POS authority or service evidence is undefined.
  • The process cannot distinguish transcript from intent, item candidate from selection, cart from quote, quote from accepted order, payment authorization from settlement or kitchen ticket from physical service.
  • Success is defined by call length, transcription confidence, voice containment or order volume without correction, exact-cart agreement, group performance, accessibility, safety escalation, duplicates, staff burden, refunds and service evidence.
  • The assistant is expected to identify by voice, infer sensitive traits, guess menu items, default paid choices, guarantee allergy safety, take spoken card data, submit without final review, retry unknown commands or decide operator exceptions autonomously.

Source basis

Sources behind the control model.

  • 01

    International Organization for Standardization

    ISO 22483:2020: Hotels service requirements

    ISO states that this international standard was reviewed and confirmed in 2026 and remains current. Its public abstract covers hotel staff, services, events, safety and security, maintenance, cleanliness, supplies and guest satisfaction, including subcontracted services. It does not define voice capture, speech accuracy, menu grammar, ingredient or allergen truth, customer confirmation, POS acceptance, payment, fulfillment, certification or any operator result.

  • 02

    International Organization for Standardization

    ISO 10008:2022: Business-to-consumer electronic commerce transactions

    This published international standard provides cross-industry guidance for planning and improving consumer electronic transaction systems and describes fair, transparent and secure operation as aims. Its public abstract does not define spoken consent, speech recognition, menu data, modifier validation, price or tax calculation, order acceptance, payment result, legal compliance, customer satisfaction or commercial outcome.

  • 03

    World Wide Web Consortium

    Web Content Accessibility Guidelines 2.2

    The latest published WCAG 2.2 is a W3C Recommendation for testable web-content accessibility criteria, including keyboard operation, input help, focus and alternatives, and W3C says it does not address every user need. Conformance does not prove speech recognition quality, voice usability, accessible physical service, informed order confirmation, legal compliance or usability for every person and assistive setup.

  • 04

    PCI Security Standards Council

    PCI DSS v4.0.1

    The PCI SSC document library lists PCI DSS v4.0.1 as the published payment-account data standard while a 2026 feedback process informs a future iteration. It does not establish customer identity, spoken consent, menu or total accuracy, fraud disposition, payment authorization or settlement, order acceptance, delivery, refund, broad legal compliance or satisfaction.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Explore governed AI agents

Compare other bounded agent patterns and the evidence, authority and recovery contracts they require.

Open path02

Design hospitality and tourism operations

Frame menu, price, order, payment, physical service and recovery around current operator truth and accountable owners.

Open path03

Govern eligible additions

Separate helpful options from dark patterns through current catalog, eligibility, price, free choice, exact purchase state and service evidence.

Open path04

Design customer-service agents

Keep public input untrusted, permissions outside the model, typed actions bounded and accessible human transfer inside the service path.

Open path