Guide
Choosing an AI Receptionist
Work through four questions in order: whether you need this at all, what it must handle, what it must never do, and who will own it afterwards. Most poor deployments skipped one of them.
In this guide
- Establishing whether the problem is real
- Defining scope before looking at vendors
- Writing your exclusions first
- Assessing integration honestly
- Naming an internal owner
Start With the Problem, Not the Product
The first question is whether you are actually losing calls. Pull your telephony data before speaking to any provider, including ours, because a demonstration is persuasive regardless of whether you need what it shows.
If the unanswered volume is negligible, stop there. If it is substantial, you now have a number to weigh against cost, and you will evaluate vendors on whether they close that specific gap rather than on how impressive the demonstration was.
Businesses that begin with the product tend to buy capabilities they never use and miss the one thing that would have made a difference.
Define Scope Before You Shortlist
Write down the three enquiry types that dominate your phone line, and what a good outcome looks like for each. That single page becomes your evaluation criteria and prevents you being sold breadth you do not need.
Then write the exclusions. What must the system never claim, promise, diagnose or decide? Doing this before you see any demonstrations means the boundaries reflect your business rather than what a platform happens to support.
Sector-specific exclusions matter most. Clinics, childcare settings and security operations all have categories that must never be automated, set out under when not to automate calls.
Evaluation Checklist
Before you contact vendors
- Unanswered call volume for the last month
- Your three dominant enquiry types
- A written list of exclusions
- Which systems must be integrated
- Who internally will own the content
During the demonstration
- Ask something outside its scope
- Interrupt it mid-sentence
- Test with a strong accent
- Confirm it can write to your diary, not just read
- Ask what happens when it does not understand
Integration Determines Value
The difference between a system that takes messages and one that completes work is whether it can read and write to your diary, CRM or job system. That single factor changes the return more than any other capability.
Ask specifically about your platform by name, and ask whether the integration writes or only reads. “Integrates with everything” is not an answer, and the honest response is sometimes that a particular system cannot be connected.
Where integration is not possible, the deployment still works but delivers less. That trade is described under booking system integration.
Name an Owner Before You Sign
Someone in your business has to approve what the system says and update it when prices, services or policies change. Without a named person and allocated time, the knowledge base drifts and the deployment quietly degrades.
This is the single most reliable predictor we see. Deployments with an engaged owner improve over the first year; deployments without one are cancelled in month eight.
Questions People Ask
How many providers should we evaluate?
Two or three. Beyond that the differences become marginal relative to the time spent.
What is the most common mistake?
Automating too much at once. One flow done well outperforms four done approximately.
Should we run a trial?
Where the deployment is significant, yes. Out-of-hours is the usual low-risk starting point.
How long does selection take?
Less time than most businesses spend, provided the scope is written down first. Without that it can drift for months.
What if we decide against it?
That is a legitimate outcome, and the measurement work still leaves you better informed about your phone line.
Bring Your Scope Document
Come with your three enquiry types and your exclusions. The conversation will be considerably more useful than a generic demonstration.