Reservation to guest care
Carry the guest from reservation to recovery
A reservation is only the beginning of the guest relationship. This blueprint uses a verified availability pathway and branch context to handle routine enquiries, reservations, and permitted modifications, then captures the issue and routes a manager when the conversation involves food safety, event terms, deposits, compensation, or a serious complaint.
AI workers
- Guest enquiry worker
- Reservation coordinator
- Guest care worker
- Restaurant manager
Orchestrated process
- Identify branch and guest contextGuest enquiry worker
- Check availabilityReservation coordinator
- Confirm or modifyReservation coordinator
- Capture notesGuest care worker
- Escalate exceptionRestaurant manager
- Close the loopGuest care worker
4 guardrails · 4 decision rules · 4 channels · tamper-evident audit
- The team
- 3 AI worker roles escalating into 1 human decision owner.
- The process
- 6 orchestrated stages, each with a named decision owner.
- The channels
- Voice, WhatsApp, Web chat, Email on one shared context.
The shift
What breaks today, and what changes
The challenge
- Multi-site groups receive enquiries, changes, and complaints across channels without a consistent view of the branch, booking, or prior contact.
- Teams lose time calling back for routine reservation details while guests wait for an answer on the channel they already used.
- Allergy, dietary, event, deposit, and complaint conversations carry decisions that should not be improvised by a general responder.
What changes
- Guests can receive verified branch, reservation, and permitted modification information without repeating their context.
- Dietary and accessibility notes are captured verbatim and presented to the manager or operational team rather than interpreted.
- Dissatisfaction and serious complaints reach a named manager early, with the reservation and conversation history available.
The team
Every seat has one job and a defined level of autonomy
This is what gets configured in Team Canvas: role-scoped AI workers, the humans they escalate into, and a trust level on each connection that sets what a worker may do on its own. Trust starts tight and widens on evidence.
AI workers
Guest enquiry worker
Answers approved branch, menu, access, and reservation questions with the current guest context.
- Owns
- Routine guest response
- Trust level
- Acts within policy — approved information only
Reservation coordinator
Checks the configured availability pathway and records permitted bookings or modifications.
- Owns
- Reservation coordination
- Trust level
- Acts within policy — within configured rules only
Guest care worker
Captures concern details and makes sure notes and history travel with the escalation.
- Owns
- Concern record and handoff
- Trust level
- Suggest-only on complaints and exceptions
Human decision owners
Restaurant manager
Owns food-safety, event, deposit, compensation, and serious complaint decisions.
Owns: Guest recovery and exception authority
The process
The conversation starts the work. The workflow finishes it.
Each stage records the decision that was made and the role accountable for it — which is what makes the run reviewable afterwards rather than a black box. Where the platform executes a stage rather than a person or agent performing it, that is named too, and accountability still sits with the role.
- 1
Identify branch and guest context
Which branch, reservation, and service context are verified for this contact?
Guest enquiry worker
- 2
Check availability
What live availability and permitted options can be offered through the configured pathway?
Reservation coordinator
Run by integration
- 3
Confirm or modify
Is this booking or modification inside the configured rules, or does it need a manager?
Reservation coordinator
- 4
Capture notes
What dietary, accessibility, event, or dissatisfaction information must be recorded verbatim?
Guest care worker
- 5
Escalate exception
Does food safety, a deposit, compensation, event terms, or a serious complaint require manager ownership?
Restaurant manager
- 6
Close the loop
What approved update or next step can be shared with the guest after the manager decision?
Guest care worker
Run by workflow
Decision rules
The non-negotiables encoded in the workflow, not left to a prompt.
- Availability and reservation changes use the configured pathway and rules; the team does not invent capacity or terms.
- Dietary and accessibility notes are captured verbatim and are not interpreted as food-safety advice.
- Allergy or food-safety decisions, event terms, deposits, refunds, compensation, and serious complaints route to a restaurant manager.
- A guest-facing resolution is sent only after the accountable manager has decided any exception.
Controls & guardrails
What makes this safe to run in production, and provable afterwards.
- No food-safety, allergy, event-term, deposit, refund, or goodwill decision by the worker team.
- Reservation facts and availability are read from the configured pathway, not guessed from conversation context.
- Serious complaints move to a named restaurant manager with the complete guest thread.
- Guest notes remain contextual records; the team does not infer medical or dietary suitability.
Platform
Surfaces that run this blueprint
The four tools inside Voxistry that compose, execute, monitor, and govern this team.
Channels on one shared context
- Voice
- Web chat
Systems it reads and writes
- Configured reservation and availability pathway
- Branch and service information
- Guest relationship record
- Manager escalation queue
Measurement
What we instrument from day one
These are the measurements the pilot puts in place, not benchmark results. You set the targets against your own baseline — and the same instrumentation is what decides whether a worker's trust level widens.
- Enquiry-to-confirmed booking
- Measures the share of routine enquiries that reach a confirmed booking through the verified availability pathway.
- Completion without recontact
- Tracks whether a guest needed to contact the team again after a routine confirmation or permitted modification.
- Dissatisfaction-to-manager latency
- Measures the time from a recognised dissatisfaction signal to a named manager receiving the complete context.
By branch and channel
Routine reservation work
Serious guest issues
Rollout
How this one goes live
A deliberately narrow start, supervised, with autonomy widened per role once the record supports it.
Weeks 1–2
One branch, routine enquiries
Start with approved branch information and routine reservation enquiries while managers review any modification outside the agreed rules.
Weeks 3–4
Verified reservations and changes
Use the configured availability pathway for permitted confirmations and modifications, recording the guest context for each handoff.
Week 5+
Multi-site guest-care routing
Add more branches only after their manager escalation, event, deposit, and food-safety boundaries are documented and tested.
Questions we get asked
Reservation to guest care, in practice
- Can it advise a guest about allergies or suitable dishes?
- No. It can capture a guest’s words verbatim and make sure the restaurant manager or responsible operational team sees them with the booking context, but it does not interpret an allergy, confirm ingredient safety, or recommend a dish as safe. Food-safety judgement depends on current kitchen conditions and accountable staff, so it remains a human decision from the first signal.
- Can it take deposits, change event terms, or offer a refund?
- No. Routine reservations and only the modifications permitted by the configured pathway can be coordinated. Deposits, event terms, refunds, discounts, and goodwill gestures have commercial and relationship consequences, so they route to a restaurant manager. The worker team can preserve the reason for the request and keep the guest informed once a manager has made the decision.
- How does this work across several branches?
- The conversation starts by identifying the relevant branch and the available reservation context, then uses that branch’s configured information and availability pathway. A group should not assume that a policy, table layout, event rule, or manager is interchangeable across sites. The rollout therefore starts with one branch and expands only when each branch has clear information ownership and escalation boundaries.
What changes in Restaurants & food service
Reservation and guest context follows the branch and the visit, while food safety, event terms, deposits, and recovery decisions stay with managers.
Read the full Restaurants & food service analysisRelated blueprints
Teams that run next to this one
Next step
Build this team around one measurable win.
We map your version of this process, compose the worker roles, connect your systems, and agree the escalation points with the people who own them — then run it supervised.