Redirect an attempted food order to the approved destination

The decision this workflow supports

A visitor may begin listing dishes in chat because the interface appears conversational. The assistant should clarify the order boundary before collecting a basket, delivery instruction or payment information that it cannot process.

Put the review process in place

Recognize the intent to place an order and provide the owner-approved ordering route if available. Do not present the typed list as an accepted order or send it to the kitchen. Staff review any unresolved question about the ordering destination.

Worked example for your team

A fictional visitor types a list of dishes and says they want to collect at seven. The assistant should interrupt the apparent ordering flow with a clear explanation and the approved ordering destination. It must not total the list, issue an order number or send a kitchen instruction. If the visitor asks whether the typed list has been saved as an order, the answer must be no. Check the staff inbox as part of the trial: there should not be a record whose label makes the conversation look like an accepted food order.

Sample wording to approve

“I cannot take a food order in this chat. You can use [approved ordering link] to place an order through the restaurant’s chosen service. Please do not enter payment details here.” This wording is a draft for the restaurant owner to approve before use.

Fields for the staff handoff

Staff need ordering intent, approved destination used, location, unresolved link question, and staff contact if needed. Mark uncertain details explicitly and keep the requested action separate from anything restaurant staff have already confirmed.

Acceptance tests before use

A dish list is not turned into an order. No payment field appears. The link identifies the intended restaurant location. Record the observed result, assign any mismatch, and repeat the affected scenario after correction.

Related guides