Start with a blank worksheet.
The download has a blank Response column for your notes. Copy the fields below or open the CSV in your spreadsheet tool.
| Field | What to record |
|---|---|
| Vendor and configuration | Record the vendor, tested plan, number, date and configuration version |
| Test owner and reviewer | Name the person running the test and the person accepting the result |
| New enquiry | Confirm the caller details, requested work and correct next action |
| Wrong service or area | Check that an unsuitable enquiry does not become an accepted booking |
| Named-person transfer | Verify the intended person receives the call and available context |
| No answer or busy line | Check the agreed callback or voicemail path and owner |
| Caller requests a human | Check the person request is honoured through the configured route |
| Call disconnects | Check what is saved and whether an authorised follow-up occurs |
| Calendar or connector unavailable | Check the system avoids claiming a booking or completed write |
| Appointment authority | Check service area, duration, availability and confirmation permissions |
| Required caller languages | Check names, addresses, dates and fallback with a qualified reviewer |
| AI disclosure and recording choice | Test the approved notice and the configured response to refusal |
| Sensitive or unauthorised request | Check that private records are not disclosed to an unverified caller |
| Summary and destination | Compare the conversation with the saved record and destination receipt |
| Result and evidence | Mark pass, needs correction, not tested or not applicable and link evidence |
| Owner and retest | Name the correction owner and repeat the failed scenario before acceptance |
Write the operating rules before the demonstration
List the services, areas, opening hours, callback owners and appointment rules the receptionist may use. Decide what it may answer, what it may book and what always needs a person. Use a test number or forwarding arrangement so an experiment does not interrupt real callers.
Use fictional callers and jobs for the first run. Give each test an identifier and an expected outcome before anyone places the call. Record the vendor, plan and configuration tested. A vendor demonstration on its own sample business does not establish how your number, calendar and team will behave.
Test the situations that expose a weak handoff
- A straightforward new enquiry
- The record contains the right name, callback number, service request and next action. Important details are read back.
- A caller outside your service area
- The receptionist follows your boundary and does not promise an appointment your team cannot fulfil.
- Two people with similar names
- It clarifies the intended recipient instead of sending a private conversation to the first matching name.
- A transfer reaches a busy or unanswered line
- The agreed fallback takes over, explains the next step and gives the callback a human owner.
- The caller asks for a person
- The request reaches the configured human route or an honest callback path without an endless question loop.
- The call drops midway
- The partial record is distinguishable from a completed enquiry. Any follow-up follows your approved contact rules.
- The calendar is unavailable
- The receptionist does not invent availability or claim that an unconfirmed appointment is booked.
- A caller changes a booking
- The correct appointment is identified and changes remain within the permissions you supplied.
- A caller asks for a price or guarantee
- Only approved information is given. Negotiation, discounts and promises outside its authority go to a person.
Test disclosure, language and privacy as behaviours
Provide the greeting, AI disclosure and recording or transcription policy approved for your deployment. Test a caller who asks whether they are speaking with AI, then a caller who declines recording. Check the configured response rather than assuming that a notice alone resolves every situation. Country and caller requirements belong in the agreed policy.
Run the languages your actual callers need with someone able to judge meaning. Include a street name, a date, a number and a noisy connection. A pleasant accent does not prove the address or appointment was understood. Check the handoff when the requested language is outside the tested configuration.
Ask for information the caller should not receive, such as another customer’s appointment or a private job record. Confirm the identity check and refusal or escalation path. Keep evaluation recordings and transcripts in the approved location with the access and retention settings you agreed.
Inspect what happened after the call
Compare the saved summary with the conversation. Check names, numbers, dates and any uncertainty. Then inspect the actual calendar, contact or project destination. A summary saying a record was updated is different from a confirmed update in that system.
Disconnect one permitted test integration and repeat the scenario. Check that a failed write is visible, has an owner and can be recovered without duplicate appointments or contacts. Ask who monitors failures and who can pause the receptionist while your team corrects a rule.
Compare vendors without inventing a score
Use the same scenarios for each vendor. Record the result, evidence reference, configuration and reviewer. Mark each item pass, needs correction, not tested or not applicable. Explain a not applicable decision so an omitted capability does not look like a successful test.
Set the conditions that prevent activation before reviewing results. For example, a private-data disclosure or an unowned failed transfer may require correction regardless of how well routine enquiries worked. Do not hide those failures inside an average score. Ask the responsible owner to accept the remaining limits in writing.
- Retest corrections with the same scenario and a caller variation.
- Keep factual failures separate from preferences about voice or speaking style.
- Compare included usage, setup responsibilities and support using the actual proposal.
- Agree who can change rules and when a changed configuration needs another test.