AI agents / 02
Your AI receptionist passed the demo. Try the last appointment.
Two customers ask for the last appointment. The assistant sounds perfectly confident with both. This is the moment that tells you more than a polished greeting: can it complete a booking without creating a problem for the person at reception?
Give two people the same last slot
Use a test calendar with one appointment available. Ask for it from two conversations. The booking system must make the final decision about availability; a sentence from the assistant is not a reservation.
The unsuccessful conversation needs a useful next step: another time, a waiting list or a transfer. Keep the booking identifier in the confirmation. Repeat the test after rescheduling and cancellation so old reminders do not point to the wrong visit.
Define what a completed enquiry means
Before selecting a voice or writing the greeting, name the requests the receptionist is allowed to finish. Booking a standard service, answering a question from an approved price list and collecting a callback request are different tasks. Each needs a final state you can inspect. For a booking, that means a record in the calendar; for a callback, it means an assigned task with contact details and an expected next action, not simply a polite farewell.
Review a permitted sample of incoming enquiries and group them by intent. Include complaints, cancellations, questions about payment and callers who do not yet know which service they need. Count missed calls carefully: one person may call several times, and not every missed call represents a lost sale. Choose the first scope around a concrete service problem. A receptionist that reliably completes a limited set of tasks can be expanded after the team sees where people actually need help.
Write a service card before writing a prompt
For each bookable service, record its name, duration, eligible staff, location, preparation requirements and the rule for its price. Include buffers between appointments and restrictions on who may book. If “consultation” can mean either fifteen minutes or an hour, the assistant needs a short clarifying question. It cannot infer your scheduling policy from a marketing description. Review similar service names with the people who currently answer the phone; they know where callers regularly misunderstand the offer.
Choose the authoritative source for each fact and assign someone to maintain it. A price in an old PDF should not compete silently with a newer price in the booking system. Specify how an update becomes available in every supported channel. Missing information also needs a deliberate response: explain what can be confirmed and arrange a human follow-up for the rest. The knowledge base is part of the operating service, with ownership and revision history, rather than a one-time upload.
Separate conversation from permission to change records
The language model may understand what a caller wants, but the application should decide whether the proposed operation is permitted. A request to move an appointment needs an existing reservation, the appropriate identity checks and a valid replacement time. A request to change someone else’s contact details requires a different assessment. Do not treat confident speech, knowledge of a surname or an instruction in a message as proof that the caller may perform an action.
Ask the implementer to show the checks outside the prompt. Which tool can the assistant invoke, which fields can it send, and what happens when the request fails validation? Test ordinary pressure such as “the owner always does this for me” as well as overt attempts to override instructions. The assistant should preserve the request and explain the available next step. It should not invent approval simply to keep the conversation friendly or to avoid handing the call to a person.
Clarify
Service, duration, date and time zone.
Check
Read availability from the live calendar.
Reserve
Save the booking while checking for conflicts again.
Confirm
State the booked time only after a successful save.
No calendar confirmation → no promise to the caller. Keep the request and hand it to a person.
Treat rescheduling as a transaction with several steps
Moving a booking involves more than creating a new appointment. The old time must be released, the new one reserved and any reminders updated. Agree the order of operations and the recovery state if only part of the change succeeds. For example, a new slot might be held while the old reservation is still awaiting cancellation. The operator needs to see that state clearly; otherwise a well-intentioned retry may leave the customer with two appointments.
Try the operation during an intentional service interruption in a test environment. Inspect both the calendar and the message sent to the customer. Then repeat the original request and verify that the system can recognise the earlier attempt. A caller should not have to understand the technical distinction between a timeout and a rejected booking. Give them a truthful status, retain their request and assign unresolved work. These checks are especially useful when calendar, CRM and messaging services are supplied by different vendors.
Interrupt the assistant and change the subject
Voice conversations include hesitation, corrections, background noise and people speaking at the same time. Ask for Thursday morning, interrupt with a different date and then return to a question about price. Check which details survive in the final booking. Evaluate the complete conversation, including pauses while tools respond. A short explanation that the calendar is being checked is useful; repeating a long scripted reassurance after every action quickly becomes irritating.
Names, email addresses and street names deserve their own tests. Decide when the assistant should repeat a value, ask for spelling or offer another way to enter it. A secure follow-up link may be easier than asking someone to dictate a complicated address five times. Do not optimise only for the fastest call. A slightly longer exchange that obtains the right details can avoid a failed confirmation, an unnecessary callback and a frustrated member of the reception team.
Test languages through the whole task
A translated greeting is not evidence that the service supports a language. Test the service name, clarification, date, confirmation, correction and handoff in each advertised language. Use natural expressions rather than literal translations of a single script. People may describe the same appointment differently, mix languages or pronounce a local name in an unexpected way. Include these situations in the acceptance examples so language support has an observable meaning beyond a switch in the interface.
Make the time zone explicit for appointments across borders. Store a clear time reference and show the customer which local time is being confirmed, especially around daylight-saving changes. Date formatting also needs attention: a numeric day and month can be interpreted differently by different audiences. Prefer an unambiguous confirmation with the written month where appropriate. Ask a person familiar with the target language to review difficult exchanges before expanding the service to a larger audience or promising unrestricted language coverage.
Design the handoff for the person receiving it
An operator should receive a short, actionable summary alongside access to the permitted conversation history. Include the customer’s goal, verified contact route, relevant booking identifier, actions already completed and the unresolved question. If the assistant already attempted a change, say whether it succeeded. Simply forwarding a long transcript forces the operator to repeat the assistant’s work and increases the chance of taking the same action twice.
Check what happens when nobody is available to accept a live transfer. Offer a callback or another agreed route, explain the next step and create an owned task. Test the request “I would like to speak to a person” without making the caller argue with the system. Review the handoff with the actual reception team: can they continue without asking the customer to start again? Measure completed transfers or resolved follow-ups separately from transfers merely initiated; those represent different outcomes for the customer.
Make logs useful without keeping everything forever
Decide which records are necessary to investigate a booking dispute or an operational failure. A tool result, timestamp and booking identifier may answer a question that a full audio recording does not. Access to conversations, recordings and exports should follow the purpose of the role. Agree retention and deletion procedures with the business owner and obtain appropriate advice for the applicable requirements. There is no single universal recording policy that can safely be copied across every market.
Check how a reviewer sees the evidence when something goes wrong. Can they connect a conversation to the calendar operation without downloading a folder of unrelated calls? Can sensitive details be kept out of routine notifications? Test how access is removed for a departing employee and who can authorise an export. These controls belong in the implementation and operating instructions. A checkbox saying “secure” on a supplier’s landing page does not describe how your own reception team will handle customer information.
Compare cost per resolved request
A price per minute is only one part of the operating model. Include telephony, speech services, model usage, integrations, numbers, supervision and support where applicable. Then distinguish incoming calls, handled conversations and successfully resolved requests. A short call that ends with an unresolved booking is not automatically cheaper in practical terms: someone may have to call back, find the conversation and repair the calendar entry.
Estimate costs using an explicitly hypothetical workload, then replace the assumptions with pilot observations. Include periods with more exceptions and longer conversations. Ask which activities are billed when a call is transferred or a tool is retried. Compare the total with the work that remains for people. Do not turn every answered call into assumed revenue. The outcome might be faster response, more reliable scheduling or fewer interruptions at the desk; each should be measured with an indicator that actually reflects it.
Launch narrowly and keep a repeatable test set
Start with a defined channel, set of services or operating period. Name the person who reviews unresolved conversations and the person who can pause the assistant. Keep the previous reception route available while the team learns how the new one behaves. Before increasing traffic, inspect bookings, callbacks and failures together. A single overall “success rate” can hide a serious problem in a particular service or language, especially when the easy enquiries dominate the total.
Retain the acceptance conversations as a regression set. Run them when a prompt, service rule, knowledge source or integration changes. Record the expected action as well as the expected wording, because a fluent response can still leave the wrong state in the calendar. Include a few tests that should deliberately end in human review. The aim is not to eliminate all handoffs; it is to make both automatic completion and escalation predictable enough for staff to rely on them.
Change the answer after the conversation starts
Update a service price or remove an offering in the approved source. Ask again through the website and the messaging channel. Check where the new answer comes from and what happens while information is being refreshed.
A knowledge assistant using RAG retrieves source material; that does not make every response correct. Test missing information as well. A clear admission that a price needs confirmation is more useful than a plausible number invented to keep the conversation moving.
Test the conversations a demo usually avoids
Try a caller who interrupts, a noisy connection, a misspelled name and a customer switching languages halfway through. For international bookings, state the time zone explicitly. Someone in Toronto and a business in Prague should not have to guess whose nine o’clock appears in the message.
Then ask for something the assistant is not allowed to approve. A refund, an unusual discount or an uncertain request should follow the agreed permission rules. Test that boundary with ordinary language, not only with a prepared script.
Scroll sideways to see all columns.
| Situation | Expected behaviour | Hand over when |
|---|---|---|
| Two callers want the last slot | Confirm one booking; offer the other caller available alternatives | The calendar returns an ambiguous result |
| The caller changes the date mid-conversation | Repeat the new date and check availability again | The existing booking cannot be changed safely |
| The connection drops during confirmation | Look up the operation by ID; do not create a duplicate | The operation status remains unknown |
| The caller asks for an exception to policy | Explain the authority limit and preserve the context | An administrator must decide |
Make the handoff worth receiving
The human needs the customer’s request, verified contact details, actions already taken and what remains unresolved. Sending a transcript without a clear next action simply moves the work.
Keep a small set of these conversations as a repeatable acceptance check. Run it after changing prompts, tools or source information. A warm voice helps; a reception team that can trust the next step matters more.
Before you start
- Book the same last slot from two conversations.
- Change a price, cancel a booking and check the follow-up message.
- Ask for a person and inspect the context they receive.
Editorial note. Examples illustrate a decision or a test; they are not client results.