Most route problems are visible within a week, if you look for them in the right order. This plan is the one our routing team uses internally and with customers who are evaluating us. It moves from a small, controlled baseline to production volume, checking CLI delivery, answer supervision, capacity and stability along the way. It works with any carrier, and the scorecard at the end gives you a defensible go/no-go decision.
Key takeaways
- Test a new route in a fixed order over seven days, increasing volume as each check passes.
- Record a baseline first, and keep list mix and hours constant so results reflect the route.
- Sample CLI on real handsets, test for false answers, and ramp to your real burst CPS.
- Decide with a scorecard covering CLI, false answers, ASR, capacity and support.
- After go-live, move traffic in stages over two to three weeks and keep weekly CLI and FAS checks running permanently.
On this page
Before day one
- Pick destinations. Choose the three to five destinations that represent most of your volume.
- Define success. Write down your current ASR, ACD, PDD and NER on those destinations so you have a baseline to beat.
- Arrange handsets. Get at least two mobile SIMs and one fixed line in each destination, or a test-call service with real numbers there.
- Agree limits. Confirm channel and CPS limits for the test with your carrier.
- Prepare capture. Make sure you can run sngrep or tcpdump on the sending server.
The seven days
Day 1 — Connectivity and baseline
Confirm the trunk is reachable, authentication works and codecs negotiate. Place 20–30 manual calls per destination to your own handsets. Check audio both ways, DTMF and that CDRs match on both sides.
Day 2 — CLI sampling
Place at least ten calls per handset across morning, afternoon and evening, presenting approved CLIs. Record what the handset displays. Target: your CLI on 100% of calls.
Day 3 — Answer supervision
Run ring-out tests (do not answer), late-answer tests (answer after 15 seconds) and invalid-number tests. Compare 200 OK timestamps with handset answer times. Target: zero false answers.
Day 4 — Live traffic, low volume
Send 5–10% of real traffic on the test destinations. Compare ASR, ACD, PDD and NER with your baseline on the same hours.
Day 5 — Capacity ramp
Increase to your expected burst CPS and peak channels in steps. Watch for 503, 486 and 403 responses as you ramp. Target: no rejections below the agreed limit.
Day 6 — Peak-hour stability
Run 25–50% of traffic through your busiest hours. Plot metrics per hour, not just per day, to catch time-of-day re-routing.
Day 7 — Review and decide
Fill in the scorecard, review open tickets and support responsiveness, and decide go, conditional go, or no-go.
What to measure each day
| Metric | Source | Pass guidance |
|---|---|---|
| ASR | CDRs, same hours as baseline | At or above baseline |
| ACD | CDRs | Within 10% of baseline |
| Calls under 6 s | CDRs | No jump versus baseline |
| PDD | SIP capture or portal | At or below baseline |
| NER | CDRs with response mapping | Above 95% |
| CLI delivered | Handset log | 100% of sampled calls |
| False answers | Day 3 tests | Zero |
| Rejections under limit | Day 5 ramp | Zero |
Use the formulas in ASR, ACD, PDD and NER, map responses as described in SIP Response Codes for Dialer Operators, and check FAS with the method in False Answer Supervision.
Logging template
day,timestamp_utc,destination,handset,cli_sent,cli_displayed,answered_on_handset,cdr_status,billsec,pdd_s,notes
2,2026-11-03T09:12:00Z,UK mobile,SIM-A,+442071234567,+442071234567,yes,ANSWERED,34,3.1,
2,2026-11-03T09:14:00Z,UK mobile,SIM-B,+442071234567,Unknown,yes,ANSWERED,29,4.0,CLI lost
3,2026-11-04T10:02:00Z,UK mobile,SIM-A,+442071234567,,no,NO ANSWER,0,3.4,ring-out okKeep one row per test call. The "CLI lost" and FAS rows are your evidence if you need to raise a ticket or request credits.
Go / no-go scorecard
| Check | Go | Conditional | No-go |
|---|---|---|---|
| CLI delivery | 100% | ≥ 95% with explanation and fix | < 95% |
| False answers | None | — | Any confirmed |
| ASR vs baseline | ≥ baseline | Within 5% | > 5% below |
| Capacity | No rejections under limit | Brief rejections, fixed | Persistent rejections |
| Support | Tickets answered with analysis | Slow but resolved | Unresolved |
Who does what
| Role | Responsibilities during the test |
|---|---|
| Telephony engineer | Trunk setup, SIP captures, capacity ramp, response-code analysis |
| Operations / WFM | Selecting test traffic, scheduling agents, keeping list mix constant |
| QA or team leads | Handset tests, agent feedback on audio, dead air and ringing |
| Commercial owner | Scorecard, decision, follow-up with the carrier |
| Carrier contact | Limits, answers to tickets, review on day 7 |
Agree a single channel for the test, for example a shared ticket thread, so findings and responses are in one place.
Collecting agent feedback
Agents notice problems before dashboards do: echo, clipped first syllables, delays before the customer hears them, calls that connect to ringing. Give agents on the test a simple disposition set for audio issues and ask team leads to collect examples with timestamps and numbers. Ten well-documented examples are more useful than a general impression that "the line was bad".
- Dead air on connect: possible one-way audio or false answer; correlate with SIP captures.
- Ringing after connect: strong FAS indicator.
- Echo: usually impedance or handset issues on the far end; note whether it is destination-specific.
- Choppy audio: jitter or packet loss; check your own network first.
Common testing mistakes
- Changing the list during the test. Keep list source and mix constant, or results reflect the list, not the route.
- Testing only during quiet hours. Many problems only appear at peak, when carriers re-route to save capacity.
- Comparing against a different week. Run the incumbent route in parallel on the same traffic if you can.
- Ignoring your own errors. Remove 403s for unapproved CLIs and malformed numbers before judging the route.
- Deciding on ASR alone. ASR can rise for the wrong reasons; always check ACD, short-call share and handset results.
After acceptance: the first 30 days
Move traffic over in stages, for example 25%, 50%, then 100% across two to three weeks, keeping the previous route warm as a fallback. Keep the daily metric review going for the first month and move to weekly once results are stable. Record the baseline you accepted against so you can spot drift later, and schedule the weekly CLI and FAS checks described above as a permanent routine.
Adapting the plan for IVR and inbound
For IVR campaigns, add DTMF reliability to day 1 (press each key on test calls and confirm it registers), and on day 5 ramp to the CPS your campaign will start with, since IVR bursts are usually larger than agent bursts. Track key-press and transfer success alongside ASR. For DID numbers and inbound trunks, replace the CLI sampling day with caller-ID delivery inbound (call your DIDs from several networks and check the number shown in your platform), and on day 5 generate simultaneous inbound calls up to your Erlang B estimate to confirm no calls are blocked below the agreed channel count.
For SIP trunking used by a PBX rather than a dialer, the capacity ramp can be shorter, but add a failover test: take the primary endpoint offline deliberately and confirm calls move to the secondary within the time you expect.
Documenting the decision
Write a one-page summary: destinations tested, dates, baseline and results for each metric, issues found and how they were resolved, and the decision. Attach the call log and key captures. When someone asks in six months why traffic is on this route, or when results drift, this page is the reference point. It also makes the next acceptance test faster, because you can reuse the format and compare like with like.
Running this plan with CLIRoutes
After onboarding, our routing team can review the plan with you, confirm limits for your test, and look at results with you on day 7. Your portal shows live ASR, ACD, PDD and NER per destination and per endpoint, and CDRs can be exported for reconciliation. Open an account or talk to routing to arrange a test.
Comparing several providers? Use the questions in 12 Questions to Ask a Wholesale CLI Provider to shortlist, then run this plan on your top two with the same traffic.
About the author
Mara Lindqvist, Head of Routing
Mara has spent fifteen years building wholesale voice networks, from TDM interconnects to SIP-only carrier exchanges. She owns route selection, carrier onboarding and quality policy at CLIRoutes.
Published · Last reviewed