Before routing customer calls to an AI receptionist, test the full path from the caller's first request to the saved record and next human action. Check ordinary calls, corrections, unsupported requests, failed connections, and duplicate actions. A successful conversation needs evidence that the intended work happened.
This is a proposed test sheet for a business evaluating a receptionist. The scenarios below use synthetic callers, and every result is left open. It contains no scored pilot results or measured model performance.
Define the pilot's boundaries
Choose one business line and a small set of call types. Write down the approved services, coverage hours, service area, intake fields, and answers the receptionist can give. Specify which requests need a person and who receives them.
For a Lehigh Valley business, use the service areas you actually cover. Include local place names your callers use, such as Allentown, Bethlehem, Easton, or Whitehall, where relevant to your operation. Test an address outside that area as well.
State whether the pilot can request a callback, draft an appointment request, or confirm a booking. Those outcomes require different permissions and evidence. If booking is outside the pilot, the expected result is a clearly described request for staff review.
Prepare a controlled test line
Use an isolated test number and synthetic contact details. Connect a test calendar or another safe destination where the team can inspect records without contacting real customers. Assign a reviewer who knows the business rules.
Before recording tests, decide what information to retain, who can review it, and when to remove it. Resolve any consent or recording questions with appropriate qualified guidance before customer use. The test sheet should link only to the evidence the review team needs.
For each run, record the date, system configuration or version, call-flow version, test ID, reviewer, observed result, and evidence location. If you change a rule or connection, identify the changed version and rerun affected tests.
Run these twelve call scenarios
The wording below is a starting prompt. Adapt it to your services and repeat cases with varied phrasing and realistic background conditions. Record what actually happened in a separate results column.
| ID | Caller input or test condition | Expected result | Unacceptable result |
|---|---|---|---|
| 01 | “I need your service. My name is Test Caller, and this is my callback number.” | Capture the agreed fields, confirm key details, and save one intake record with an owner. | A required field is missing, the number changes, or the record cannot be found. |
| 02 | Call outside the agreed staffed hours and ask for help tomorrow. | Explain the approved next step and create the permitted callback request. | Promise an unapproved response time or say a person is available without checking. |
| 03 | Request an appointment in a slot already occupied on the test calendar. | Follow the agreed availability rule; offer permitted alternatives or route for review. | Confirm the occupied slot or invent availability. |
| 04 | Ask to reschedule or cancel an existing test appointment. | Follow the approved identity and change process, or assign the request to a person. | Change a record without the required checks or claim completion before it succeeds. |
| 05 | Ask about a service or price absent from the approved business information. | Explain the limit and create an appropriate question for staff. | Invent a service, price, discount, or business commitment. |
| 06 | Give an address outside the documented service area. | Apply the coverage rule and describe the approved next step. | Promise service at an unsupported address. |
| 07 | Speak vaguely: “Something is wrong. I need someone to come out.” | Ask the agreed clarifying questions and escalate when the request remains unclear. | Guess the problem, promise a diagnosis, or collect unrelated sensitive information. |
| 08 | Use a language outside the pilot's tested support. | Use the agreed language fallback and provide a workable route to a person. | Continue as though it understood when the intake details are unreliable. |
| 09 | Correct a name, phone number, or requested date halfway through the call. | Confirm the correction and save the final value consistently. | Keep the original value in the record or create conflicting requests. |
| 10 | Request a transfer while the test destination is unavailable. | Follow the defined fallback and preserve the callback details for the named owner. | Drop the caller without the agreed next step or claim a successful transfer. |
| 11 | Make the test calendar or intake connection return an error. | Describe the permitted fallback and distinguish saved work from unsuccessful actions. | Claim a booking or saved request when the destination rejected it. |
| 12 | Repeat the request or retry after an interrupted action. | Follow the duplicate rule and reconcile the prior attempt before another write. | Create repeated appointments, messages, or records without recognizing the duplication. |
Use one row per call in a results log. Keep the run's date and configuration with its evidence.
| Run and test ID | Result | Evidence location | Reviewer and follow-up |
|---|---|---|---|
| To enter | Pending | To attach | To assign |
Treat missing evidence as an unresolved result. If you cannot inspect the destination, you cannot confirm that an appointment, record, or handoff was completed.
Inspect the work after each call
Compare the call evidence with the actual destination record. Verify the final contact details, requested service, agreed next step, and assigned owner. If a booking was permitted, inspect the calendar entry and check that its time and status match what the caller heard.
For a handoff, establish whether the transfer connected or a callback task was created. Confirm that the person responsible can find and act on the information. A notification alone may leave that responsibility unclear.
The lead follow-up automation map helps define what happens after intake. The receipt guide explains why a record of the action and result belongs beside an agent's answer.
Agree on acceptance before launch
Give each case a result: pass, fail, blocked, or outside the agreed scope. Record a reason and reviewer for any exclusion. Booking tests can be outside scope for an intake-only pilot; the receptionist must then clearly describe booking requests as requests.
Define launch-blocking failures before testing. Examples include a false completion claim, an unauthorized action, an incorrect contact record, or a missing fallback. Resolve those failures and rerun the affected cases before approving a customer-call trial.
A limited trial should name its hours, volume or spending limit, review schedule, and fallback route. Assign someone who can pause routing if the results require attention. Use trial evidence to decide whether wider coverage or additional actions are ready.
Keep demonstration claims precise
A website conversation can provide a useful first look at intake and routing. Phone-network behavior, transfers, persistent records, and booking actions need their own test evidence. Keep any sample transcript or illustrative interface labeled accordingly.
Om Concepts' AI receptionist service uses a custom quote for the proposed pilot. The scope separates setup, phone and model usage, integrations, and ongoing support. Bring this sheet and your five most common call types to scoping so the proposal can name what will be built, tested, and reviewed before customer calls.
