A practical capability checklist and 12-call acceptance test for UK businesses
A useful AI receptionist should answer reliably, explain its role, understand why the person is calling, use approved information, confirm names and contact details, complete only permitted actions, and transfer or arrange human follow-up when needed. It should never guess, make unauthorised promises or trap a caller. Every call needs a clear record, owner, exception route, monitoring process and safe fallback.
That is a higher standard than sounding natural. A convincing voice can still produce a poor customer experience if it mishears an email address, books the wrong service, loses a complaint or leaves nobody responsible for the next step. This guide turns the buying decision into observable capabilities and a repeatable test plan.
The ten capabilities an AI receptionist should have
| Capability | Minimum acceptable behaviour | Evidence to request |
|---|---|---|
| 1. Reliable answer | Answers during the agreed hours, introduces the business clearly and sets honest expectations. | Coverage rules, response monitoring and the fallback used during an outage. |
| 2. Intent recognition | Identifies the caller's real reason, asks one useful clarification and can handle interruptions or corrections. | Results from representative test calls, including unusual wording and background noise. |
| 3. Accurate capture | Confirms names, numbers, email addresses, dates and other details that drive the next action. | Call record matched against a known test script, with correction rate recorded. |
| 4. Approved knowledge | Answers from maintained business information and says when an answer is outside its scope. | Knowledge owner, update process, source controls and examples of safe refusal. |
| 5. Permitted actions | Creates only agreed bookings, messages, tickets or follow-up tasks with validation before completion. | Action permissions, confirmation steps, duplicate handling and audit trail. |
| 6. Human handoff | Transfers or creates a priority callback with context; a request for a person has a direct route. | Live transfer test, callback ownership, service level and failed-transfer behaviour. |
| 7. Sensitivity and urgency | Recognises complaints, vulnerability, distress, safety concerns and unusual high-impact requests as exceptions. | Escalation scenarios, prohibited decisions and named human owners. |
| 8. Useful record | Produces a concise summary, confirmed contact details, reason, urgency, action and owner. | Example records in the system your team will actually use. |
| 9. Privacy and security | Collects only necessary information, follows retention and access rules and protects sensitive routes. | Data flow, supplier terms, permissions, retention, privacy information and incident process. |
| 10. Monitoring and resilience | Supports review of errors and outcomes, controlled updates, service alerts and a safe manual fallback. | Quality measures, review cadence, change log, outage test and exit route. |
Buy against the behaviour, not a feature label. Two suppliers may both say “appointment booking” while one merely takes a message and the other checks the correct diary, applies service rules, confirms the slot and handles a clash. Write the expected result before watching a demonstration.
The human handoff standard
Human handoff is not a failure. It is a designed capability for calls where empathy, judgement, authority or specialist knowledge matters. A caller should be able to ask for a person, and the receptionist should recognise defined triggers such as a complaint, distress, safeguarding concern, disputed payment, legal threat or request beyond approved knowledge.
A strong handoff carries the conversation forward. The receiving person should get the caller's confirmed name and number, the reason for the call, relevant answers already given, urgency and the promised next step. If a live transfer is unavailable, the system should state what will happen, create a named callback task and tell the team. It should never keep repeating the same question or imply that a person will call when no owner exists.
The UK's Competition and Markets Authority says businesses remain responsible for how they engage with consumers whether the interaction uses people or AI. Its 2026 guidance also stresses monitoring errors, complaints and unintended outcomes with regular human oversight. The practical lesson is simple: responsibility cannot be delegated to the voice on the phone.
Accuracy means confirmation, not confidence
A fluent answer is not evidence that the information is correct. For details that determine a booking or response, require the receptionist to read back or otherwise confirm what it heard. Test similar-sounding surnames, postcodes, email addresses, dates, times and service names. Include callers who change their mind halfway through a sentence or correct an earlier answer.
Approved knowledge should have an owner, version and update route. The receptionist should distinguish a stable fact such as opening hours from a decision that needs a person, such as whether a complex job is suitable, whether a complaint is valid or what price exception can be offered. “I do not have enough information, so I will arrange the right person” is safer and more helpful than an invented answer.
The 12-call acceptance test
Run these tests with your own wording, services and escalation rules. Use several speakers and repeat important scenarios at different times. The expected result should be written before the call so the evaluation does not move to fit the demonstration.
| Test call | Expected result |
|---|---|
| 1. Straightforward new enquiry | Captures the need and details, gives only an approved answer and creates the correct next action. |
| 2. Returning customer | Recognises the different intent, avoids unnecessary questions and routes to the correct existing-customer process. |
| 3. Difficult name and email | Confirms spelling and contact details accurately before saving or sending. |
| 4. Accent or background noise | Clarifies politely, does not pretend to understand and offers another route when needed. |
| 5. Interruption and correction | Allows the caller to interrupt, updates the corrected detail and does not retain the wrong value. |
| 6. Out-of-scope question | Does not guess; explains the limit and sends the question to an appropriate person. |
| 7. Complaint or upset caller | Stops the routine flow, acknowledges the need for a person and escalates with priority and context. |
| 8. Urgent or sensitive issue | Uses the agreed urgent route without making a decision outside its authority. |
| 9. Direct request for a person | Transfers or creates a clear callback immediately, without a repeated persuasion loop. |
| 10. Booking clash or change | Applies availability and change rules, confirms the final slot and prevents duplicate bookings. |
| 11. Payment-card request | Uses the approved protected route or hands off; it does not capture card security data in a recording or summary. |
| 12. Integration or service outage | Fails safely, preserves the caller's route to help and alerts the team rather than claiming an action succeeded. |
Ostina's recommended acceptance rule: every safety-critical test must pass, and at least 10 of the 12 scenarios should complete without manual repair before a limited pilot. Treat any invented answer, lost complaint, false booking confirmation, exposed sensitive detail or blocked human request as a stop condition. This is a practical recommendation, not an industry certification.
Privacy, recording and payment boundaries
Map what personal information is collected, why it is needed, where it goes, who can access it and when it is deleted. The Information Commissioner's Office says privacy information for AI processing should cover purposes, retention and sharing. It also notes that its AI guidance is under review following recent UK data-law changes, so check current guidance and obtain specialist advice for higher-risk or regulated use.
- Use a clear introduction and explain recording or transcription where relevant.
- Collect the minimum detail needed for the stated call purpose.
- Set access, retention, deletion and incident responsibilities before launch.
- Confirm supplier roles, sub-processors, data locations and exit arrangements.
- Keep health, legal, financial and other sensitive decisions with appropriately authorised people.
Telephone payments need a deliberately protected design. PCI Security Standards Council guidance says sensitive authentication data such as card verification codes must not remain in digital audio recordings after authorisation. For a first deployment, the safe default is to send payment calls to an approved payment route or trained person rather than letting ordinary recordings or summaries capture card details.
What to measure after launch
A passed demonstration is only the beginning. NIST's AI Risk Management Framework recommends testing AI before deployment and regularly while it operates, with documented measures, human oversight and safe failure. The UK government's portfolio of AI assurance techniques similarly places performance testing and ongoing testing across deployment and live monitoring.
- Answer rate and calls that reach a useful conclusion.
- Confirmed contact-detail accuracy and corrected fields.
- Intent, booking, task and routing accuracy.
- Human requests, successful transfers and callback completion.
- Out-of-scope answers, complaints, failed actions and incidents.
- Caller feedback and staff time spent repairing the result.
Review a representative sample, not only the best calls. Give one person authority to pause or narrow the workflow, and keep a change log for knowledge, prompts, routing and connected actions. Improvement should reduce pressure on staff while preserving customer access to people.
Frequently asked questions
Should an AI receptionist say that it is AI?
A clear, simple introduction is the prudent standard. It helps callers understand the interaction and supports transparent handling of personal information. The business should also explain recording or transcription where relevant and provide an easy route to a person.
Can an AI receptionist book appointments?
Yes, when it is connected to an approved diary and follows clear rules for service, location, availability, confirmation and exceptions. Test clashes, unavailable slots, changes and cancellations before launch.
Can an AI receptionist transfer calls to people?
It should be able to transfer selected calls immediately or create a priority callback with the caller's confirmed details, reason and urgency. A caller who asks for a person should not be trapped in a loop.
What should happen when an AI receptionist does not understand?
It should ask a short clarifying question, confirm the important detail and then move to a person or safe callback route after a defined number of failed attempts. It should not guess or invent an answer.
How should a small business test an AI receptionist?
Use representative calls covering routine enquiries, corrections, accents, background noise, complaints, out-of-scope questions, booking conflicts, payment requests, human transfer and service failure. Record the expected outcome and require every critical safety scenario to pass before launch.
Sources and further reading
- ICO: transparency when AI processes personal data.
- Competition and Markets Authority: agentic AI and consumers.
- NIST AI Risk Management Framework Core.
- UK government portfolio of AI assurance techniques.
- PCI Security Standards Council guidance on voice recordings and authentication data.
The practical next step
Take 20 recent calls, group them by reason and mark the expected answer, action, human trigger and owner. That becomes the first test pack for any supplier. If you are still deciding between service models, read our AI receptionist versus call answering comparison. If the capability standard fits your needs, explore Vox AI receptionist for UK businesses or plan a contained call-flow pilot with Ostina.
