Test Call Forwarding: An End-to-End QA Checklist

Test call forwarding by placing real calls through the new number. Check each stage: ring timing, failover, caller ID, IVR keys, recording, caps, schedules, and logs. In 30–45 minutes, you’ll have a repeatable acceptance test you can run before every launch. This checklist works for cloud-routed business numbers in the US, India, the Philippines, Thailand, Bangladesh, and Pakistan.

How to test call forwarding (the 30-minute path)

You’ll finish with a clear pass/fail for each part of your flow and a short list of fixes if needed. You need two test phones on different networks (or one mobile and one landline or a VoIP line). Also have a headset or quiet room, a stopwatch, and your routing console open in a browser. Aim for this: the first target rings 2–4 seconds after dialing. Ring legs (one outbound attempt to a target) match your 20–30 second timers. The right fallback fires. IVR (a phone menu the caller presses) keys work. Recordings save. Caps and schedules route as set. Logs update in near real time. Note: star codes like *72 or *21# are carrier features for personal lines; this checklist is for a cloud number that forwards and routes calls in your platform.

1. Call the new number and measure the first ring.
   Start a stopwatch when you press Call. The first target should ring within 2–4 seconds. If it takes longer, note the delay and which network you called from.

2. Let the first leg ring out to test failover.
   Do not answer. Watch that the first target stops at its timer (for example, 20 seconds). Then the second target starts ringing right away. Measure both ring lengths.

3. Answer on the primary target.
   Call again. Answer on Target A between 10 and 20 seconds. Make sure audio is clean both ways. The whisper (a short message before connect that names the campaign or buyer) should play once and never over the caller.

4. Force a queue, then voicemail.
   Call again and let A and B time out. You should hear a queue (a holding line that plays music) for the time you set, for example 30 seconds. Then you should hit voicemail with the right greeting.

5. Check caller ID on the targets.
   While calling from each test phone, confirm the ringing device shows the original caller number, not your cloud business number. Note any “unknown” or “spam likely” flags.

6. Press IVR keys and confirm routing.
   If your number has a menu, press 1 for Sales and 2 for Support. Try an invalid digit and wait without pressing anything to confirm the timeout route.

7. Confirm recording and log detail.
   After each call, play the recording. Verify both sides are clear, the file attaches to the right call log, and the timestamps align with what you observed.

8. Hit daily and concurrent caps.
   Lower a cap temporarily (for example, set Target A’s daily cap to 1) and place two calls. On the second call, A should not ring. Start two calls at once to see the concurrent cap behave as set.

9. Test schedules and after-hours routing.
   Place one call inside business hours and one right after they end. Confirm the on-call or voicemail path takes over at the exact minute.

10. Validate geo and duplicate-caller rules.
    Call from two different regions or states (or use test numbers from those regions). Call twice from the same number within the duplicate window and confirm the second call follows the duplicate route.

If any step fails, note the device, carrier, exact time, and screen state. You’ll use that to fix issues fast. On CallFlow, you can set priority routes, IVR, caps, and schedules in one place; the same test works across all of them.

Prepare your test phones, numbers, and windows

We’ll use one running example so you can compare your results. A new local number routes by Priority to Target A (rings 20 seconds), then Target B (20 seconds), then Queue (30 seconds of hold music), then Voicemail. Business hours are 9:00–17:00 local time. After hours go to an on-call mobile. Recording is ON for all calls. Whisper is ON with a two- to three-second message. Each target has a daily cap of 30 calls and a concurrent cap of 2. The duplicate-caller window is 24 hours.

Turn off Do Not Disturb and any carrier call forwarding on the target phones. If a mobile’s personal voicemail answers at 15–20 seconds, it can “steal” the call before your platform can fail over. Set each mobile’s voicemail delay to at least 25–30 seconds, or use SIP phones (internet phones that use a standard called SIP) or desk phones for testing.

Pick two caller numbers from different networks. One should be a mobile, the other a landline or a VoIP line. In South and Southeast Asia, also place a test from a local mobile to a US toll-free if you will use one. Toll-free reach can vary by operator, and a cross-border test catches that early.

Set your console’s clock and time zone to match the buyer’s local time. Confirm business hours, holidays, and any per-target windows are in the right time zone, not your own. If your buyer sits in another city or country, check daylight saving rules where they are.

Call flow and timers: ring, failover, queue

Make three calls to prove the flow. On Call 1, answer on Target A between 10 and 20 seconds. Note the first-ring delay and the total ring time.

On Call 2, let A time out. Target B should start within a second. Answer on B and confirm audio and the whisper.

On Call 3, let A and B both time out. You should hear queue music for about 30 seconds, then voicemail with the right greeting.

Watch for the first ring delay (the time from dial to the first ring at the target). Across most networks, you should hear ringing at the target within 2–4 seconds. Measure each ring leg with a stopwatch and compare to your timers. If the queue music does not play or seems to loop forever, check the queue timeout. If the voicemail is not your platform’s but a mobile’s, that mobile’s voicemail answered too soon.

Two edge cases come up often. First, a mobile’s voicemail races your routing rule. Fix it by extending the mobile’s voicemail delay or lowering the leg timeout to 15–25 seconds so the platform fails over sooner. Second, timeouts that are too short can push calls away from a willing agent. If agents need a little longer to pick up, raise the leg timer in small steps to avoid hitting the queue too early.

If you see “no ring” or one ring then drop on any leg, run through the checks here: Forwarded calls not ringing.

Caller ID, whisper, recording, and IVR checks

The target should see the original caller’s number. If it shows your cloud business number, “unknown,” or a random local number, write down the call leg and device it happened on. Some carriers present caller ID differently on forwarded calls, and some desk phones hide it by default. If a device flags calls as “spam likely,” note it; the label often depends on the target’s carrier and the caller’s history, not just your number.

Whisper messages help agents know which campaign or buyer the call belongs to. The message should be short and at a clear volume, then drop as soon as the caller connects. If the whisper masks the first few words of the caller, trim its length or reduce its volume.

Recording must capture both sides, save to the right call log, and be playable within a minute or two. Spot-check after each test call. If a recording is missing or one-sided, confirm recording is ON for the number or route. Also check that any SIP or browser phone has permission to send and receive audio.

If you use a menu, run a short IVR testing checklist. Press 1 for Sales and 2 for Support, and confirm you reach the intended targets or sub-menus. Press an invalid digit and listen for the invalid prompt, then confirm you get another try or the fallback route. Wait without pressing anything; after the no-input timeout, you should reach the default route.

DTMF (the tone when you press a key) can fail if the endpoint uses the wrong mode. On SIP phones or browsers, set DTMF to RFC2833 or the platform’s recommended setting. Reduce loud background audio in prompts so tones are not masked. For more menu setup and tips, see IVR for business. If caller ID still looks wrong after device checks, walk through this guide: Forwarded caller ID wrong.

Caps, schedules, geo and duplicate rules

Daily caps protect each target. Set a low cap on Target A (for example, 1) and place two calls back to back. The first should ring A. The second should skip A entirely and go to B, the queue, or voicemail as your route defines. Confirm the cap counter increments in the logs.

Concurrent caps limit how many simultaneous calls a target can take. Start two calls at once to the cloud business number. If A’s concurrent cap is 1, only one of the calls should ring A. The other should move to B or the next path. If both hit A, check that the cap is per target, not per campaign.

Schedules must switch at the exact minute you set. Call at 16:59 and again at 17:01. The first should follow business hours (for example, ring A and B). The second should go to the on-call mobile or voicemail. If it doesn’t flip, check the time zone on both the number and the targets.

Geo or caller-state routing matches the caller’s area to the right target. Place a call from two states or regions, or use test numbers tagged to those areas. Confirm each route hits the intended target. If you don’t have two real caller numbers, ask a teammate in another region to place one call during this test window.

Duplicate-caller rules take the second call from the same number within a set window (for example, 24 hours) and route it differently, often to a separate path or an IVR. Call twice from the same test phone within the window. The second call should follow the duplicate path. If it doesn’t, confirm the scope (campaign vs platform) and that your test numbers are not excluded.

Reports and logs: confirm tracking and buyer access

Keep the live log open while you place test calls. You should see each call leg appear in near real time with the target, ring time, and any fallback. The timestamps should match what you measured. If a leg shows repeated rejections or fast failures, capture the details. That points to the target’s phone service declining the call or a network issue on that leg.

Check that recordings, tags, and buyer names sit with the right call and target. If a call was capped, the log should mark it. If a call went after hours, it should show the schedule route taken. Keep notes for anything out of place.

If you use a buyer or agent portal, confirm access is scoped. Log in as a buyer and verify they see only their calls. Make sure they can play their recordings and view their current caps and schedules. If that portal allows edits, test a small change (for example, their off-hours number) and place another call to confirm the change takes effect.

Schedule a daily email report and wait for the first run. Compare the counts and durations to your live analytics. They should line up. If the email aggregates by a different time zone, adjust it now so buyers are not confused.

Stay alert for fraud red flags, even in testing. Watch for a burst of very short calls, repeated failed connects to the same target, or caller patterns that do not match your region.

When a test fails: quick fixes and what to check

Wrong or missing caller ID: turn on the setting that passes the original caller ID on the second leg. Check the target phone’s presentation settings, which can hide or overwrite caller ID. Test to a different target carrier or device to see if the issue is carrier-specific. If it persists, see the caller ID guide linked above.

No ring or drops after one ring: extend the mobile’s voicemail delay so your platform can take back control. Set per-leg timeouts to 15–25 seconds to balance answer time with failover speed. Test on a wired connection or a different phone to rule out local Wi-Fi or device issues.

DTMF or IVR issues: set DTMF to RFC2833 (often called “Out of band”) on SIP endpoints or browser phones. Re-record prompts at a steady level and reduce background music that can confuse tone detection. Always try the menu from both test phones to rule out a single-network quirk.

Caps or schedules not honored: confirm the time zone on the number, targets, and the scheduled report. Check that the cap is set per target if that’s what you need, not per campaign. Make sure the duplicate-caller window is enabled and that your test number is not whitelisted.

Always validate with live logs while you test. If a call leg shows repeated rejections from the target’s phone service, contact that provider. It may be blocking unknown caller IDs, or it may have a feature like spam blocking or call screening that you need to disable for business lines.

Make this QA part of every launch

Save this checklist, keep two test phones handy, and block 30–45 minutes on the calendar the day before go-live. Run the same steps again when you add a new buyer, change timers, or start a geo route in a new region. If you want a routing console for this kind of testing—priority, weighted and round-robin routes, IVR, caps, recording, live logs, and buyer portals—create an account at our signup page when you’re ready. If you prefer a quick review of your setup, contact the team and we’ll help you test.