What are Test Calls?
A test call is a real call to yourself. Your assistant runs the script exactly as it would with a customer — same voice, same flow, same tools — but instead of dialling a contact it rings your own phone or connects straight into your browser. It is the fastest way to hear a script before it goes anywhere near a real caller. Test calls are treated differently from production calls in two ways:- No Do Not Call Register check — the call only rings you, so DNCR screening does not apply.
- Tagged as Test — every test call carries a Test badge in the Call Log so it never muddies your production reporting.
Where you can start a test call
Most launch points preselect the script for you. If you arrive without one, the dialog shows a Call Template field with a Select Script dropdown first.
The Test Call dialog
The dialog is titled Test Call. Under Call Options you choose how to take the call, then click Start Call (it reads Starting Call… while connecting).My Phone
The panel shows My Phone Number with “The call will be made to:” and your saved number. When you click Start Call you’ll see Creating test call… followed by “Test call scheduled successfully” — the call is scheduled for immediate dispatch and your phone rings moments later. It dials from your team’s default outbound number, so what you see on your handset is exactly what your contacts will see. The first time you use it, the dialog asks you to Set up your contact information:
Click Save & Continue and the number is stored against your profile for every future test call. If your workspace manages profile details centrally, the dialog shows Profile contact details required instead — update your profile details before testing.
In Browser
The panel reads In-Browser Call — “The call will be initiated directly in your browser.” Clicking Start Call connects within the tab: the status shows Loading… then Connected, your browser asks for microphone access if it hasn’t already, and a Hang Up button ends the call whenever you’re done. There is no phone leg at all, which makes it the quickest way to iterate — but audio quality and turn-taking feel slightly different from a real phone line. Browser calls have a page of their own: see Web Calls.Messages you might see
The Do Not Call Register exemption
Normal outbound calls are screened against the Australian Do Not Call Register before they dial, and blocked with a Do Not Call Register Warning if the number is registered. Test calls skip this screening entirely: they only ever ring your own saved number or your browser, so there is nothing to wash. This means you can test freely even if your personal mobile happens to be on the register. The exemption applies only to test calls. The moment you call a real contact — even “just to demo it” — full DNCR screening applies. See Scheduling & Managing Calls for how the warning and override work on production calls.Billing
Test calls are billed the same way as any other call: the same 60-second minimum applies, on plans with included minutes the call draws down your allowance first, and past that allowance the time is charged to your wallet at your standard per-minute rate. A long rambling test session spends real credit, and a test call won’t go through if your account can’t cover it. See How Billing Works.Test calls in the Call Log
Every test call lands in the Call Log alongside your production calls, with a full transcript, recording, Call Summary and Call Objectives — reviewing them is half the value of testing. Three things set them apart:- The Test badge — the Environment column shows a Test badge on test calls and a Live badge on production calls. The same Test badge appears next to the script name in the call’s detail panel.
- The Environment filter — under Filters, add an Environment condition with the operator is or is not and the value Test or Live. Environment is not Test gives you a clean production view; Environment is Test isolates your testing history. Save either as a view with Save View so it’s one click away — see Call History.
- The version they ran — a test call runs the latest saved version of the script, including drafts that haven’t been published yet, and records that version against the call. Production calls run the published version. This is what makes the test loop safe: you can hear tomorrow’s script today without touching live traffic. See Script Versions & Publishing.
Letting your script know it’s a test
Two system variables tell your script which environment the call is running in, so you can gate copy or side effects that must not fire in testing:{{call.is_test}}— boolean,trueon a test call. Set automatically at call start.{{call.is_prod}}— boolean,falseon a test call,truein production.
<<bool[{{call.is_test}} == true]:Just so you know, this is a test call.>> — remember booleans compare with == true (lowercase), never == 1 or == 0. Insert either variable in any supported field by typing /.
Next Steps
- Environments: Test vs Live — how Test and Live are decided per call, and what each one runs.
- Testing Your Script — the builder side: the silent draft save, preparation stages, and validation errors that block a test.
- Web Calls — how browser calls behave, start and end, and how they differ in the log.
- Call History — the full Call Log: filters, saved views, search and export.
- How Billing Works — rates, the 60-second minimum, and how call costs are calculated.