Free working pack · Version 1.0

Before real
customers call.

Twelve practical tests for your AI receptionist. Check the conversation, the booking and the message that actually arrives.

6-page PDF + CSV · No email or sign-in required

Use the checklist in your browser ↓

12 call scenariosOrdinary calls and failure paths
An editable evidence logGoogle Sheets or Excel
A launch decision sheetOwner, fallback and review date

A useful result needs evidence

A good conversation
is one part of the test.

A phone demo can sound convincing while a message is lost or a booking fails. This pack helps you and your provider compare what the receptionist says with what happened in the connected system.

Use it before launch, or after changing the prompt, voice, model, routing or booking connection. The method comes from our own voice-system work.

  1. Set up a controlled test.Use invented names, business-owned test numbers and an isolated calendar or inbox.
  2. Make the call and listen.Where recording is permitted, listen to the audio. A transcript cannot prove pronunciation or silence.
  3. Open the destination record.Check the saved number, calendar entry, received message or transfer result.
  4. Fix, then try different wording.Retest the failure and an ordinary successful call before making a release decision.

Keep real customer information out of your test log. Tell test-transfer recipients what to expect. Have your provider isolate anything that would create a real booking, message or charge. Never disable a production connection just to test a failure.

Try it here

Your 12-call checklist

Open a test for the expected result. Change its status only after checking the evidence. This worksheet does not automatically approve a launch.

PASS Expected result verifiedFIX A result is wrong or missingNOT TESTED No conclusion yet
01An ordinary enquiry

Try: Ask what services the business offers and when it is open.

Pass when: The business details match the approved information, the first words are audible and the answer makes sense.

Evidence: Call reference and the information source used to check the answer.

02A question it cannot answer

Try: Ask about a service, price or policy absent from the approved information.

Pass when: It acknowledges the limit and offers the agreed next step. It does not invent a price, discount or exception.

Evidence: The unsupported question and the actual answer.

03A corrected callback number

Try: Request a callback at a different business-owned test number from the one you called on. Correct a digit once if needed.

Pass when: The supplied number is saved accurately. It does not guess or silently use caller ID instead.

Evidence: The final saved record checked against your test source.

04A caller who leaves early

Try: Give the agreed minimum message details, say you must go and end the call before the usual closing questions.

Pass when: The minimum information reaches the correct destination. Details never provided remain unknown.

Evidence: Received message and delivery time.

05A corrected name and second request

Try: Give an invented name, correct it, then add a second request after the first has been acknowledged.

Pass when: The final record has the corrected name and both requests. Continuing the conversation does not duplicate the original action.

Evidence: Final record and number of notifications.

06An unavailable booking

Try: Ask for an occupied slot in the test calendar, then choose another allowed slot if offered.

Pass when: It respects the booking rules and confirms only an entry that exists. The occupied slot stays untouched.

Evidence: Calendar entry, time, timezone and confirmation. If booking is out of scope, verify it does not offer to book.

07A transfer that is answered

Try: Request an allowed transfer and have a team member answer the agreed test destination.

Pass when: The correct phone rings, any agreed introduction is given and both people hear each other.

Evidence: Confirmation from both ends and the call reference. If transfers are disabled, test the approved message route instead.

08A transfer nobody answers

Try: Repeat the allowed transfer while the test receiver deliberately does not answer.

Pass when: The agreed fallback works. It does not ring indefinitely, drop silently or claim someone answered.

Evidence: Ring duration, fallback behaviour and received message. If transfers are disabled, test the message route without a transfer promise.

09An after-hours enquiry

Try: Call outside the defined hours, or use an isolated test schedule arranged with the provider.

Pass when: It follows the after-hours rule without promising an unavailable transfer or immediate attendance.

Evidence: Time, timezone, configured hours and received result.

10A connection that fails

Try: Have the provider simulate an unavailable connection in an isolated environment. Do not break a production service.

Pass when: It gives the agreed fallback without claiming success. The failure reaches the responsible person.

Evidence: Simulated failure, caller's answer and alert or recovery record.

11A pause, interruption and spoken address

Try: Pause midway through a sentence, interrupt an answer, and ask it to say a business website or email used in the script.

Pass when: You can finish, it handles the interruption and the address is intelligible. Agree acceptable response times before grading.

Evidence: Recording timestamps and measured delays; note clipped audio or repeated questions.

12The complete post-call result

Try: Make a normal message call and inspect each promised destination: inbox, CRM, calendar or portal.

Pass when: The right information reaches the right person once, within the agreed window. References match and expected recordings open for an authorised user.

Evidence: Call reference, destination reference and delivery time.

Your choices and notes stay only in this tab. There is no backend storage, and they are not submitted to Yes AI or saved by this tool. Export a copy before leaving. Use evidence references rather than personal information. A status you select is your assessment, not independent verification. Give a reason for anything marked not applicable.

After the tests

Make the launch
decision explicit.

GORequired tests pass, evidence exists and someone owns monitoring.
HOLDA required result is wrong, missing or untested.
LIMITED PILOTThe owner excludes an unready feature and tests the reduced service.

Record the approved version, the person watching initial calls and who can restore the previous setup. Recheck the downstream results after launch.

A practical worksheet, not a certification or a guarantee of business results.

Keep a copy

Take the pack
to your next test.

Need help with the failing steps?

Bring your completed log to Yes AI. We can discuss the systems involved and the work needed.

View consultation options

Or send an enquiry.