---
title: "Acceptance Criteria for a Business Call-Routing Change"
url: https://memory.wiki/qFyKsICV
updated: 2026-09-09T16:42:51.176Z
source: "api"
---

# 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](https://skipcalls.com) and to conventional call-routing systems.
The product or carrier can change, but the proof boundary remains the same.