Turn restaurant text enquiries into confirmed kitchen orders

Proposed inputs

1. Name

   Approved service reference

   Owner

   Restaurant owner

   Minimum scope

   One location’s current item identifiers, prices, hours and supported fulfilment area.

   Quality check

   Name an accountable owner and version; do not infer safety information from ingredient descriptions.

2. Name

   Order-state and handoff rules

   Owner

   Operations lead

   Minimum scope

   Required fields, customer confirmation wording, retry handling and a staff escalation route.

   Quality check

   Specify which system acknowledges receipt and how repeated messages map to the same order.

Access and setup — proposed or unknown

Proposed minimum

1. Tools to check for a later pilot: a Claude API agent, authorized messaging access and test kitchen/CRM endpoints. Start with disconnected fictional conversations and verify current access before connecting anything.

2. Reconcile the dialogue into a draft, request confirmation of its current version, then test the acknowledgement logic using mock downstream responses.

Compatibility unknowns

1. Unknown: merchant integration support, payment verification, kitchen acknowledgement semantics and actual runtime safeguards.

External actions requiring approval

1. Access to customer messages, payment-session creation, sending replies, writing kitchen/CRM records and any live order pilot.

Why use this

1. Conversational requests arrive in pieces and may change midway through an exchange. A correct-looking final ticket can still contain the wrong branch or an earlier item quantity.

2. The agent could help maintain the order state and ask for missing details, but the valuable result is agreement plus acknowledged fulfilment. A claimed high accuracy percentage is not a substitute for these checks.

Why an agent / simpler alternative

Useful judgment

Reconcile revisions in a conversation, distinguish requests from confirmations and recognize when the approved menu cannot answer a question.

Simpler alternative

Use a conventional online-order form connected to the kitchen when customers can choose items directly.

Unsuitable when

No trained person is available for allergen questions, current menu data is unavailable, or the system cannot distinguish a failed handoff from a completed order.

Expected deliverable and review checks

Proposed artifact

A draft order state with branch, item identifiers, quantities, totals, unresolved questions and separate customer-confirmed, payment-verified and kitchen-received markers.

Critical checks

1. Apply the latest explicit revision; do not reuse confirmation of an earlier total.

2. Keep an unanswered allergy or safety question with trained staff, without providing an unsupported assurance.

3. A payment link is not proof of payment, and a sent ticket is not proof of kitchen receipt.

4. A retry must reuse the same order identifier or escalate; it must not create a second meal.

Missing output evidence

No integration code, order receipt or independently measured production result was inspected.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

A fictional café dialogue changes two wraps to one after an initial total, asks an unanswered allergy question, and receives a mock kitchen timeout. Use no real people or payment details.

Acceptance checks

1. Require revised confirmation and staff handling of the safety question.

2. Retain one order identifier and leave kitchen receipt unknown after the timeout.

Stop conditions

1. Any real customer contact, live payment, kitchen action or safety assurance would be required.

Failure signals and proposed responses

1. Signal

   The customer changes quantity after confirming the earlier total.

   Why it matters

   The merchant and customer no longer share one agreement.

   Proposed response

   Invalidate the previous confirmation and show the revised order before progressing.

2. Signal

   The reference lacks an answer to an allergen question.

   Why it matters

   A guessed answer can cause serious harm.

   Proposed response

   Stop that response and hand the question to trained restaurant staff.

3. Signal

   The kitchen request times out after submission.

   Why it matters

   Blind retries can duplicate the order while silence can lose it.

   Proposed response

   Mark receipt unknown, look up the same order identifier if authorized and escalate before resubmitting.

Effort and cost — unknown

Setup work

1. Define authoritative menu ownership, order states, escalation coverage and duplicate prevention.

Ongoing review

1. Review exceptions and reconcile confirmed orders with acknowledged fulfilment.

Unknowns

1. Unknown: current API and messaging charges, human coverage, error rates and recovery effort.

Limits

1. The original account is a builder’s unverified report. This proposed oversight is stricter than the described deployment and does not validate its reliability or food-safety handling.