Ten calls to test before your AI receptionist goes live
HeyDiane · Updated October 2026
Use ten realistic call scenarios to check accuracy, interruptions, urgent requests, failed notifications and honest booking language before a live rollout.
Use controlled details and a written scorecard
Have a colleague call from a controlled number. Use invented customer details and test destinations you own. Record the scenario, expected outcome, actual outcome, provider receipt and correction needed. Do not test real emergencies or surprise a customer.
Download the acceptance checklist (CSV). Repeat failed cases after changes using the exact version you intend to activate.
The ten scenarios
- Ordinary new enquiry: explain the problem in natural language. The assistant should collect necessary details without promising an unconfirmed slot.
- Corrected number: change the callback number halfway through. The final request should contain the correction; texting that number requires an appropriate verified destination.
- Rural address: use a range road or unfamiliar community. Check that the assistant asks rather than invents or changes the address.
- Noise and interruption: speak over a sentence or use speakerphone. Check recovery without repetitive questioning.
- Outside the service area: request work beyond your boundary. The assistant should follow your approval rule.
- Price uncertainty: ask for a firm price on work needing inspection. Only approved fees should be quoted.
- Existing customer: ask about a booking or warranty. Check your chosen message or handoff policy.
- Urgent request: test a non-dangerous simulated urgent issue. Verify notification, acknowledgement and resolution separately.
- Notification failure: in a controlled test environment, make delivery fail. The caller should hear an honest next step and the owner should see the failure.
- Wrong number or polite decline: decline to proceed. The assistant should finish courteously without forcing contact capture.
Grade outcomes as well as voice
A pleasant call can still fail operationally. Check the request in the dashboard, the intended recipient, the recorded details and actual delivery. Provider acceptance is one step; it is not proof that a person received or acted on the message.
For every test, note whether the caller knew what would happen next. Request captured, appointment confirmed, owner alerted and issue resolved are different outcomes.
Set a release rule
Do not activate a version with unresolved errors in customer details, service boundaries, prices, booking claims or urgent-call handling. Cosmetic preferences can have a separate list. Keep the previous working phone configuration available for rollback.
After activation, repeat an ordinary call, an after-hours call and the owner notification check on the actual business number. Simulations against a draft do not prove that the public line uses that draft.