Acceptance Criteria for a Business Call-Routing Change

A routing change is complete only when the intended caller path works and the fallback path remains safe. Configuration screenshots and successful deploys are useful evidence, but neither proves what a real phone call experienced.

Use a test number, fictional caller details, and a destination controlled by the test team. Record the configuration version and the time window before the first call.

Criterion 1. The entry route is correct

Call the exact business number affected by the change. Confirm that the call reaches the expected receptionist or queue. A test against a direct internal number does not prove the public forwarding route.

Capture the call identifier and the configured destination. If several numbers share one receptionist, verify that the number-specific greeting or behavior did not leak across routes.

Criterion 2. The primary destination behaves as configured

For a transfer change, answer the destination once and let it ring out once. The answered test must connect both parties with usable audio. The unanswered test must reach the documented fallback without silence, repeated transfer loops, or a false claim that somebody answered.

For a booking or message route, verify the result in the destination calendar, inbox, or CRM. The conversation is not the system of record for an external action.

Criterion 3. Caller context survives the handoff

Give a fictional name, callback number, and short reason for calling. Correct one detail before the handoff. The final message or task must contain the latest value once and enough context for the recipient to act without replaying the whole call.

Criterion 4. Failure is observable

Create one safe failure. Use an unavailable calendar slot, decline the transfer, or temporarily choose a controlled unreachable destination. The caller should receive a clear next step. The operational record should identify the failed action, the provider result when available, and the owner of the next step.

Avoid a generic failed label when the evidence can distinguish busy, timeout, provider rejection, invalid destination, and outcome unknown.

Criterion 5. The change does not duplicate work

Repeat one event or retry one provider callback in a safe environment. The system should create one booking, one message, or one follow-up task. External actions need stable idempotency keys because a timeout can occur after a provider accepts a request.

Closeout evidence

Store the call IDs, destination evidence, observed fallback, and configuration version together. State which criteria passed, failed, or were not observed. Do not replace a missing real-call check with a dashboard health badge.

These criteria apply to configurable receptionists such as SkipCalls and to conventional call-routing systems. The product or carrier can change, but the proof boundary remains the same.