Test an AI receptionist against written expected outcomes, then inspect the records and bookings it creates. Use controlled examples that represent your business rather than judging a single scripted demonstration.
Write expected outcomes before calling
A convincing conversation is easier to judge than a useful workflow. Prevent that bias by writing the pass condition before the demonstration. For a booking call, specify the correct customer name, confirmed address, permitted slot and destination calendar. For an exception, specify the handoff or callback instruction and the promises the agent must avoid.
Ask the provider whether you can run an agreed trial or supervised demonstration before committing. Do not assume every provider offers free access. Use fictional details and a test calendar wherever possible, with permission to exercise the workflow.
Use a six-call acceptance matrix
- Routine enquiry: collect the required fields and offer an allowed next step.
- Corrected address: retain the final version in the record.
- Unavailable appointment: offer only permitted alternatives.
- Outside service area: apply your boundary without inventing an exception.
- Request for a person: follow the agreed handoff.
- Interrupted conversation: establish what remains incomplete.
Score each result pass, partial or fail. Record the failed field or action, not a general impression. Run the corrected-address call twice with different phrasing so one successful script does not become your whole assessment.
Inspect the calendar rather than trusting the voice
“You are booked” is only meaningful if the appointment exists in the intended calendar with the right time zone, duration and details. Open the destination record. Check whether a blocked period remains unavailable and whether travel or preparation time is accounted for in your chosen scheduling arrangement.
Google Calendar documents availability checks and buffer settings. That does not prove another integration handles them correctly. Use your actual calendar configuration in the test, including a manually created busy event and a date when your usual hours change.
Rehearse a failure and a boundary
Ask the provider to demonstrate the agreed response when booking cannot be completed. The right outcome may be a callback request with an honest explanation. It should not be an invented appointment. Also ask a question the business has not supplied an answer to, such as an unusual warranty condition.
Check whether the record clearly identifies the unresolved question and responsible follow-up owner. Have the provider explain what happens if an integration is unavailable; do not disconnect a live production system yourself to create a test. Keep genuine customer calls out of your rehearsal.
Decide with an acceptance sheet
Summarise each test in four columns: expected action, observed action, evidence and required fix. Separate critical failures from wording improvements. Wrong addresses, false booking commitments and missing handoffs merit attention before a cosmetic change to the greeting.
Ask for the corrected workflow to be demonstrated again and agree who maintains the instructions after launch. Our buying guide offers comparison context, while the plumbing service page shows a relevant use case. A test establishes fit for the scenarios you exercised, not universal reliability.
Sources and editorial notes
Checklists, example wording and decision rules are KEDO Labs editorial recommendations, not measured results or guarantees of a provider’s features. Sources checked October 8, 2026.
See the workflow
Hear the call. See the booking.
Watch KEDO handle a service enquiry, then review the current setup fee and monthly price before you pay.
Reading in Google?
Make KEDO a preferred source
Add KEDO Labs as a preferred source in Google and our guides are more likely to appear with a 'preferred' badge in Top Stories, and can carry a badge in AI Mode and AI Overviews.