AI receptionist comparison checklist: eight calls to run

A convincing voice sample does not show whether a receptionist preserves a corrected number or explains a failed handoff. Compare the work your team receives after the conversation. Use the same eight scenarios, reviewed business facts and expected outcomes for each setup.

This is a proposed evaluation guide published by Vocapable, not completed test results or an independent service ranking. The scripts below do not establish that a product supports every workflow. An unavailable required feature is a buying constraint, even when you cannot run its test.

Download the blank evaluation scorecard. Keep one copy per provider and configuration. The download contains expected outcomes; observation, status and score cells are deliberately empty.

Prepare a small, controlled business example

Invent a service business with a simple knowledge sheet: Monday–Friday, 9 a.m.–5 p.m. in one stated timezone; closed Saturday; inspections offered; prices confirmed by a person. Use “Test Caller” and “Test Recipient,” never real customer records. Substitute only phone numbers and destinations you control for the bracketed placeholders. Keep actual numbers out of a scorecard you intend to share.

Document the tested plan, phone arrangement, configuration date, knowledge version and promised fallback. Use an authorized test account and permitted destinations. Confirm any carrier or usage charges beforehand. Do not interrupt a working customer line or generate traffic merely to exhaust an allowance.

A browser preview, when available, can help assess a short conversation. Vocapable’s preview ceiling is two minutes; it is not eight phone calls, a transfer test or activation of live answering. Use a supported phone setup for phone-specific scenarios. If the required test environment is unavailable, record unknown rather than treating the preview as proof.

Run these eight scenarios

1. An ordinary after-hours request

Say: “I’m Test Caller. Please ask your team to call [controlled number A] tomorrow morning about a routine inspection.”

Expect the final record to preserve the name, number, reason and requested timing. Inspect what an authorized teammate actually receives, not just what the voice says it saved. A callback request must not become a confirmed appointment.

2. A corrected callback number

Say: “Please call [controlled number A]. Correction: use [controlled number B] instead.”

Control both numbers. Expect the final callback field to use B and any uncertainty to be visible. If a follow-up action is part of the supported workflow, check its destination in the authorized test environment. A pleasant acknowledgment does not establish that the stored field or later action changed.

3. A question with a documented answer

Say: “Are you open on Saturday? What are your weekday hours?”

Expect the answer to match the reviewed sheet, including the stated timezone where relevant. Record the exact discrepancy if the response differs. Do not change the knowledge sheet between providers without documenting that difference; otherwise the comparison changes the task as well as the service.

4. A price the business has not supplied

Say: “What exactly will my inspection cost? Can you guarantee that price?”

Expect the receptionist to acknowledge the missing price and offer the configured next step. It must not invent a quote, discount or commitment. A request for human confirmation can be the correct result; confident detail unsupported by the business sheet is a failure.

5. A person who is unavailable

Configure Test Recipient as unavailable through the supported test controls. Say: “May I speak to Test Recipient?”

Expect the declared fallback: for example, an accurate explanation and a callback request. Write down the result the team receives. Do not assume a message was delivered because the caller heard a promise. If the service cannot support a fallback you require, record that feature gap separately from test status.

6. A handoff that fails

Where supported, arrange an authorized test destination that will not answer. Say: “Please put me through to Test Recipient.”

Expect the configured recovery after the unsuccessful attempt. The caller must not be told that a person answered when nobody did. Check that the useful request survives the failed handoff. If you cannot safely create this condition, leave the outcome unknown and ask for an observed demonstration before relying on it.

7. A changed reason for calling

Say: “I need an urgent repair. Actually, nothing is broken; I want a routine inspection next month.”

Expect the final request to reflect the correction. An earlier statement may remain in a conversation record, but the actionable summary should not present the withdrawn urgency as the current task. Review the record your teammate uses to choose the next step.

8. A capacity or allowance limit

Use a provider-supported test condition for the relevant limit. Then attempt the same ordinary request from scenario 1.

Expect the documented admission or fallback behavior, rather than an assumption of unlimited answering. Observe what the caller and team each receive. Do not buy extra usage or overload the service merely to finish this checklist. An untested limit stays unknown; a plan’s published allowance is not evidence of its exhausted-state behavior.

Score the task, keeping unknowns visible

Use this proposed rubric consistently: 0 means an observed wrong or missing outcome; 1 means a partly correct outcome requiring human repair; 2 means the expected outcome is complete and evidenced. Leave the numeric score blank when the result is unknown. These are your task observations, not published quality scores for a provider.

Mark pass only when the required outcome is fully met. Record partial completion as fail for that requirement, with the repair explained in notes. Unsupported features, unavailable test conditions and inaccessible records need separate explanations; none is a silent pass.

Treat truthful fallback, no unapproved promises and appropriate handling of your test data as must-pass requirements. A total cannot cancel a failure on one of those boundaries. Check who can access the test record and how the provider’s published policies apply. Do not infer privacy or security certification from this exercise.

Record timing and make the buying decision

If timing matters, use one declared interval: start when the caller finishes the question and stop when the useful answer finishes. Record seconds and the environment. Keep ringing delay and setup time separate. Preserve unsuccessful attempts; repeat a changed setup as a new version rather than replacing an inconvenient result.

Discuss unresolved cases before selecting a provider. Then compare the actual phone bill, allowance and required features using the cost guide, the small-business shortlist and the Quo/Sona comparison. Check current Vocapable pricing or entry offers before choosing a setup.