Route a large-party dining request for staff review

The decision this workflow supports

A larger dining party may need a different review path from an ordinary table request. The restaurant should choose its own routing threshold rather than letting the assistant invent one from seating assumptions.

Put the review process in place

Have the owner define when a party moves to a group-dining reviewer. Capture the party size and preferred service, then explain that staff will review the request. Questions about seating together, menus or deposits must remain with the responsible team.

Worked example for your team

Suppose the restaurant owner has chosen a group-review threshold for the pilot. Test one fictional request just below it and another above it, using the actual owner-approved rule. The second should reach the group-dining reviewer without an automatic promise of a shared table or set menu. Ask the receiving staff member which question they need to resolve next. The threshold is a routing decision, not a capacity claim. A group request can be correctly routed even when staff have not yet decided whether the restaurant can accommodate it.

Sample wording to approve

“I can pass a group-dining request to the team. How many people are you expecting, and which date and service do you prefer? Staff will confirm the arrangements available.” This wording is a draft for the restaurant owner to approve before use.

Fields for the staff handoff

Staff need party size, requested date and service, together-seating preference, callback contact, and group-dining owner. Mark uncertain details explicitly and keep the requested action separate from anything restaurant staff have already confirmed.

Acceptance tests before use

The approved threshold selects the right queue. Seating together is not guaranteed. The assistant does not create a group menu or deposit requirement. Record the observed result, assign any mismatch, and repeat the affected scenario after correction.

Related guides