A restaurant needs to respond with hospitality without losing operational accuracy. Reservations, orders, pickup, delivery, menu questions, and incidents use different sources, owners, and priorities. The playbook classifies these intents, confirms what was agreed, and transfers exceptions before a promise is lost between front of house, kitchen, and delivery.
Make the conversation reflect real operations
The reply should consult the correct booking system, menu, delivery area, and order state. When information still depends on the kitchen or front of house, say it is being confirmed and provide a realistic return time. A note in chat becomes a commitment only when it reaches the operating process and someone owns it.
Brazil's Consumer Protection Code requires adequate and clear information about characteristics, composition, price, and risks. For service teams, that means not guessing ingredients, availability, or service conditions. Questions involving restrictions, safety, or preparation require confirmation from the responsible person and the restaurant's adopted source.
Model four hospitality workflows
| Intent | Standard action | Escalate when |
|---|---|---|
| Reservation | Confirm location, date, time, party size, and condition | Group, event, accessibility, or exception |
| Order and pickup | Record items, changes, value, and time | Unavailable item, material change, or delay |
| Delivery | State area, status, and next update | Address, delay, damage, or missing order |
| Menu and incident | Use approved information and record evidence | Restriction, possible risk, charge, or recurrence |
Every conversation needs a queue, owner, state, next action, and due time. “Forwarded” does not end ownership: the transfer is complete only when the new person or queue accepts the case. Department routing turns that handoff into a visible operating rule.
Turn notes into ownership
Table preferences, celebrations, and order notes help only when they reach the right team. Contact and address data should remain limited to necessary service. Anvisa's RDC 216/2004 establishes good-practice requirements for food-service operations, including manuals, procedures, and specific records; chat does not replace those food-safety controls.
- One booking source for each location and shift
- A menu and conditions with source and date
- Change confirmation before production
- Ownership for reservation, order, delivery, and incident
- A fast queue for possible food risk
- Records for charges, refunds, and commitments
- Handoff across service, front of house, kitchen, and manager
Respect expectations, consent, and the service window
If a menu or order involves alcohol, treat that portion as a separate regulated vertical: WhatsApp policy restricts promotion and commerce, allows alcohol messaging only on the Business Platform in listed countries, requires age, geography, and licensing controls, and does not permit an in-channel commerce experience. Do not assume the general restaurant workflow covers alcohol.
The WhatsApp Business Messaging Policy says a business may only contact people who provided their number and opted in to subsequent messages. Opt-out requests must be honoured. On the Business Platform, business-initiated messages use approved templates; outside the 24-hour window after the user's last message, replies also require an approved template. When automation is used, the policy requires a prompt, clear, and direct route to a person. Record the authorised message category, explain its purpose, and connect the workflow to template governance.
Pilot reservations or pickup, not everything at once
Choose the intent with the highest volume and most reliable information. For reservations, define capacity, tolerance, and confirmation. For pickup, define order closure, changes, expected time, and unavailability.
Start with one location, shift, or high-volume intent. Test normal cases, missing information, unavailability, disputes, opt-out, and transfers. Supervisors should review a sample of real conversations and correct the source of each failure, not merely rewrite the final reply.
Measure confirmations, no-shows, changes after closure, orders completed without repeat contact, delays by cause, accepted transfers, and recurring incidents. The metric should reveal where the process failed rather than blaming only the person who replied.
Measure volume by intent, first reply, time to resolution, accepted transfers, unowned conversations, repeat contacts, and exception causes. Use consistent customer-service metric definitions, and do not reward fast closures that leave the problem unresolved.