Before your AI receptionist answers customers: a practical acceptance checklist

Approve a completed customer journey, not a good demonstration

A receptionist can sound helpful and still leave a customer without an appointment, a callback or a person who understands the problem. The owner decision is not simply whether the voice sounds natural. It is whether the system reliably completes the limited job you have assigned it and makes unfinished work visible.

BGA's checklist is an original operating method for a controlled trial. It is not a vendor comparison, certification or claim that a particular product passed. NIST describes its AI Risk Management Framework and companion Playbook as voluntary resources for evaluating and managing AI risk. The Playbook organizes suggested actions around Govern, Map, Measure and Manage. The specific call tests below are BGA recommendations, not a NIST-mandated checklist.

Write the receptionist's authority on one page

List what the system may tell a caller, what it may record and what it may actually change. Separate an information request from a confirmed appointment. If the receptionist can only request a callback, it should say that clearly. If it can reserve an appointment, identify the calendar or system that is authoritative and the confirmation the customer must receive.

Write the approved business hours, service area, price language, escalation route and fallback message. Give each item an owner who can keep it current. An owner might permit a published diagnostic fee but prohibit an estimated repair price. That is a business rule to encode and test, not something the receptionist should infer from a persuasive conversation.

Run a small, repeatable set of fictional inquiries

Use controlled internal tests and fictional customer details first. Start with an ordinary inquiry during business hours, then repeat it after hours. Ask about an address outside the service area, an unavailable appointment, an unclear service request and a question that is absent from the approved information. The expected result should be written before the test begins.

Include a caller who corrects a phone number midway through the exchange, a caller who asks for a person and a caller who disconnects before finishing. Test a duplicate inquiry too. Decide whether the second contact should update an existing record or create a separate task; the correct behavior depends on your workflow. Do not use a real customer's private details just to make a demonstration feel realistic.

For urgent or safety-related language, define a narrow escalation policy with a responsible human. Do not ask a general receptionist to improvise diagnosis, emergency triage or technical safety instructions. Where a service needs specialist legal, medical or safety review, obtain that review before launch. A smooth answer is not evidence that the system has the authority or knowledge to give it.

Check the downstream record yourself

For each test, inspect the actual calendar entry, lead record or callback task. Confirm the name, corrected contact details, service request, time zone and assigned person where applicable. Then verify that the intended employee can see the task through the channel they actually use. A receptionist saying that it notified the team is not a notification receipt.

Distinguish a task being created from a person accepting responsibility. A useful internal record includes a test ID, scenario, expected action, observed action, destination record ID, responsible person and result. Keep test details identifiable as tests so they do not contaminate sales reporting. Remove or archive them through your normal authorized process when verification is complete.

Deliberately test the handoff and the outage

Ask for a human and follow the entire transfer path. What happens when the person answers, does not answer or is unavailable? Does the caller return to a clear fallback or reach a dead end? Check whether the human receives enough context to continue without asking the customer to restart.

In a controlled test environment, have the implementer simulate a failed calendar or lead-system action. The receptionist should not announce a successful booking when the destination rejected it. Decide how the customer will be informed, how an employee will discover the failure and who owns reconciliation. Avoid repeating an uncertain booking blindly: confirm whether the original action completed before creating another.

Score business outcomes without hiding critical failures

Consider an illustrative test batch of 12 scenarios. Suppose 11 pass, but the failed scenario is the only request for a human. An overall 91.7% pass rate would hide the most consequential defect. These are hypothetical numbers, not vendor performance data. Classify failures by consequence as well as frequency.

BGA recommends blocking release when the system invents a commitment, loses an urgent escalation, exposes inappropriate information or reports an action that did not occur. For less serious issues, record the correction, owner and retest. Keep a dated copy of the approved configuration and the test evidence so the next change can be compared with the version that passed.

Release narrowly, with a working return path

Start with a limited workflow you can supervise rather than immediately routing every customer interaction through the new system. Assign someone to review unfinished tasks and complaints, and define how to restore the previous reception path. Set the review interval according to the consequence and volume of the calls, not a universal schedule.

Measure answered inquiries, complete contact records, accepted callbacks, confirmed appointments and fulfilled work separately. Only the last stages establish whether the business received and delivered the opportunity. Use BGA's related quote follow-up guide after a lead becomes a real estimate; improving the first answer does not remove the need for ownership further down the process.

Original sources

• NIST — AI Risk Management Framework; checked October 30, 2026
• NIST — AI RMF Playbook, updated June 10, 2026; checked October 30, 2026