An AI receptionist should only confirm an appointment after the authoritative booking system has accepted it. Before that point, it has collected a request. This distinction belongs in the spoken script, the interface, staff notifications and acceptance tests.
This checklist helps an appointment business scope reception and booking software, including a later voice integration. The example is hypothetical. It does not describe a live BrainGlow phone service or make a claim about recovered revenue.
Write the appointment rules before the script
Define services, appointment length, staff eligibility, working hours, breaks, locations and preparation time. Decide who can override a rule and whether a booking request needs manual approval. Include the business's timezone and the timezone presented to the customer.
Separate slot availability from customer eligibility. An open calendar slot might be unsuitable for a particular service, staff member or location. Identify the questions needed to select the correct appointment while avoiding unnecessary sensitive information.
Document cancellation, rescheduling and late-arrival handling as separate workflows. A cancellation request must identify the correct booking and follow the business's authorization rules. The first pilot can route these requests to staff while supporting a simpler new-booking path.
Identify the system that owns availability
Choose one authoritative booking source. If staff also maintain a separate calendar, specify how changes appear in both systems and what happens when synchronization fails. A demonstration calendar with seeded appointments does not prove that production scheduling is connected.
Check availability when proposing a time and again when creating the booking. Two people can request the same slot between those steps. A server-side conflict check should determine the result; a polite conversational response cannot reserve capacity on its own.
Google Calendar's event-creation documentation describes permission requirements, time fields and creating events through the API. A calendar integration still needs the business's scheduling rules, conflict handling and access design. Google Calendar event creation
Design a hypothetical collision and recovery
Suppose a salon offers a 45-minute appointment at 14:00. A caller accepts that time while a staff member books it for another customer. The assistant's create request is rejected because the slot is now occupied.
A useful response explains that the time became unavailable, offers freshly checked alternatives or passes the request to staff. The staff queue records the requested service, preferred time and conflict. It does not show a confirmed appointment that the booking source never accepted.
If the create request times out, the result may be uncertain. Check the booking source using a stable request reference before attempting another creation. Test this recovery with the actual provider: an application needs durable duplicate protection appropriate to its architecture.
Run the same scenario during a timezone change, with a long service crossing closing time and with two different locations. These cases reveal whether the rule is implemented consistently or only described in the assistant's instructions.
Give voice calls an explicit human route
For a phone integration, agree the greeting, disclosure, transfer destinations and out-of-hours behavior. The business should review recording and data-handling requirements for the places where it operates before using real customer calls.
Define when to transfer: caller request, unsupported service, unclear information, repeated recognition trouble or a staff-only decision. A reachable destination and provider-compatible route are part of the test. An assistant saying “transferring” is insufficient evidence that someone answered.
Vapi's transfer-call documentation describes routing to a phone number or SIP destination and checking transfer errors. Its available modes and downstream telephony requirements must be verified for the selected setup. Vapi transfer-call documentation
Evaluate speech quality using representative languages, background noise and names. Record whether the system extracted the correct service, date and customer contact. Have the caller confirm critical details before creating a request, and allow correction without restarting the conversation.
Set acceptance tests and an operating budget
A bounded pilot can focus on one location, one appointment type and one staff queue. Test a successful booking, a conflict, a repeated submission, a disconnected calendar, an unavailable transfer destination and a customer correction.
Use observable acceptance criteria:
- A confirmation contains the identifier returned by the booking source.
- A request awaiting staff approval is visibly labeled as pending.
- Failed or uncertain bookings appear in a monitored queue.
- Staff can stop the assistant and continue the conversation.
- Provider credentials and customer information are available only to authorized operators.
Budget telephony, model, speech and calendar/provider costs separately from implementation. Measure cost per completed workflow and manual recovery, using actual pilot observations. A low per-minute figure alone does not describe the operating cost.
ReceptionOS currently offers a web-intake and reviewed-booking foundation. Phone, SMS and external calendar integrations are excluded from its proposed pilot unless separately scoped. For those needs, review voice AI and reception systems and booking and scheduling systems.
The booking UX portfolio example illustrates a relevant journey, while its displayed outcomes remain examples rather than verified client results. Discuss a reception workflow with your appointment rules, booking provider and staff escalation route.