The decision this workflow supports
An ordering button should take guests to the destination the restaurant has approved. A link that points to the wrong location or an outdated service can create confusion even when the button itself works.
Put the review process in place
Have the owner supply the exact destination and intended location. Open it from the published website on a phone and check the displayed restaurant identity. Do not place a real order during the check. If the destination is unavailable, remove any claim that ordering is currently available through it.
Worked example for your team
A fictional restaurant has two locations using different ordering destinations. Test the button on each location’s page and inspect the restaurant identity shown after opening it. Do not add items or place an order to prove that the link works. If both buttons lead to the same branch, record the mismatch and ask the owner for the correct URL. Avoid replacing it with the first search result. The intended location is part of the acceptance criterion, not an assumption made because a page opened successfully.
Sample wording to approve
“This button opens our approved ordering destination. Orders and payment are handled there; Ava does not accept food orders or card details during a conversation.” This wording is a draft for the restaurant owner to approve before use.
Fields for the staff handoff
Staff need button location, approved URL, restaurant identity shown, check date, and issue owner. Mark uncertain details explicitly and keep the requested action separate from anything restaurant staff have already confirmed.
Acceptance tests before use
The destination shows the intended location. The link is tested without submitting an order. A broken destination leads to a reviewed correction rather than a guessed replacement. Record the observed result, assign any mismatch, and repeat the affected scenario after correction.
Further reading
Catering inquiry value calculator ↗
Try Ava with your business’s public information ↗