How to test an AI receptionist before it answers your customers
A demo shows you what an AI receptionist can do on a good day, with a script the supplier chose. Your customers will not follow that script. Before a single real call reaches it, you want to know how it behaves with your enquiries, your diary and your worst-case callers. This is a test plan you can run in an afternoon, whichever provider you use.
Decide what a good call looks like first
Before you ring anything, write down what should happen for each kind of call. Without that, every test call “sounds fine” and nothing is actually checked. For most businesses the outcomes fall into four groups:
- Booked: the job is in the diary, in an allowed slot, and the caller has a confirmation.
- Handed over: a person has the caller’s details and the reason, and knows they need to call back.
- Message taken: the details are captured and sent to the right place, with no promise of when.
- Redirected: an emergency, a supplier or a sales call went where your rules say it should.
If you have not yet written the rules behind those outcomes, start with what an AI call handler should never do. The three lists at the end of that piece are the rules you will be testing.
Build your test calls from real enquiries
Do not make up test calls from scratch. Open your call log, your voicemails and last month’s job sheets, and pick enquiries you actually received. Then add the ones your team remembers because they went wrong. A good set covers:
- Your most common enquiry, the one you could answer in your sleep.
- A caller just outside your area, or on the edge of it.
- A request for a price you have not approved, such as a quote that needs a visit.
- Anything touching safety: a smell of gas, sparking, brakes, a flood.
- A caller who asks for a person, or who is upset.
- An existing customer chasing a job that is already booked.
- A supplier, a recruiter or a sales call.
- Someone who is hard to understand: a poor signal, a noisy van, or a caller who rambles.
A heating firm will want a boiler breakdown in winter and a landlord with several properties. A garage will want a warning light, a registration read out quickly and a customer asking whether the car is ready.
Ring like a customer, not like the person who set it up
The person who wrote the rules knows which words trigger them. Customers do not. Ask other people to make some of the calls, and give them the situation, not a script.
- Call from a mobile, in the car or outside, as well as from a quiet office.
- Give information in the wrong order, or leave something out and see if it is asked for.
- Change your mind halfway through: a different day, a different address.
- Interrupt, go quiet, or ask “are you a real person?”. It should tell you plainly.
Keep a note of each call as you go: who rang, what the situation was and what you expected. You will need it for the next step.
Judge each call by what arrives afterwards
How a call sounds matters less than what it leaves behind. After each test call, check:
| Check | What good looks like | Common problem |
|---|---|---|
| The call record | Name, number, address and the reason for the call, correct and complete | Details misheard and not read back to the caller |
| The diary | The booking is there, in an allowed slot, with the right job type and length | Booked into a slot you keep free, or a job booked that should have been a callback |
| The alert | The right person was told, by the method you agreed, promptly | The alert went to a shared inbox nobody watches |
| What the caller was told | Matches the record: the same time, the same next step | The caller was promised a callback time nobody agreed to |
| The rules | Anything outside your rules was handed over, not handled | It answered a question it should have passed on |
Ask to read the transcript for every test call, not only the ones that seemed to go wrong. A call can sound smooth and still book the wrong job. If a provider cannot show you what was said and what was done, that is worth knowing before you sign. The record a Ringbridge call leaves is on the sample calls page.
Break it on purpose
The calls that matter most are the ones where something is unavailable. Ask the provider to show you, or help you set up, each of these:
- The diary cannot be reached. The caller should get a clear next step, never an invented booking.
- A handover goes unanswered. The details should become a callback, and the caller should be told who will ring.
- Two calls arrive at once. Find out what the second caller hears.
- A call comes in outside your hours. It should follow your out-of-hours rules, not your daytime ones.
Which of these apply depends on how the service connects to your systems. The integrations page covers what each Ringbridge connection does.
Switch the routing on last
Most businesses keep their existing number and divert calls when busy, when unanswered, out of hours or all the time. Test the divert itself before customers rely on it:
- Ring your normal number from outside and let it divert. Check it arrives, and that the caller hears the right greeting.
- Try each divert you plan to use: busy, no answer and out of hours are set up separately with some phone providers.
- Check the call record shows the caller’s real number, not your own.
- Write down how to switch the divert off, and make sure more than one person knows how.
Check divert charges with your phone provider as well. The practical guide to AI call answering covers keeping your number and the other set-up decisions in more detail.
Keep checking after go-live
Testing does not stop when the divert goes on. Read the records from the first week yourself, every one. Real callers find the gaps no test list covered, and a gap is cheap to fix while call numbers are small. After that, a regular look at the calls that were handed over or ended without an outcome tells you where the rules need work.
With Ringbridge, completed calls are checked as part of the service, and any change to a rule or booking option is tested against real calls before it goes live. Whoever you use, ask how changes are tested, and ask to see the result.
Frequently asked questions
How many test calls should I make before going live?
There is no magic number. Make enough calls to try every rule at least once, and your most common enquiry several times, with different people calling. If a rule has never been triggered in testing, you do not yet know that it works.
Who should make the test calls?
Not only the person who wrote the rules. Ask a colleague, a family member or a regular customer who knows the business. People who did not set it up phrase things differently, and that is where the gaps show.
What if a test call goes wrong?
That is what testing is for. Note what was said, what should have happened and what arrived afterwards, then ask the provider to change the rule and run the same call again. Do not go live on a promise that it has been fixed.
Hear what an answered call sounds like.
Hear Ringbridge in actionRelated reading