Skip to main content

​
Overview

The fastest way to improve a script is to talk to it. The script editor is built around a tight loop: make a change, click Test Call, speak with your assistant, and refine. Test calls always run against a saved version of your script, so what you hear on the call is exactly what you have on screen — the editor takes care of saving and preparing that version for you. You can start a test call from two places:
  • Scripts → (your script) → Test Call — the flask-icon button in the editor header, alongside Save and Publish. This is the main loop while building.
  • Scripts → Test Call — the row action on the Scripts page. This skips preparation and calls the latest saved version straight away.
This page covers the builder side of testing: what happens when you click the button and what can stop it. For the operational side — the In Browser and My Phone call modes, billing, the Do Not Call Register exemption, and how test calls appear in the Call Log — see Test Calls.

​
The Test Call loop

​
Nothing unsaved? Straight to the call

When you click Test Call with no unsaved changes — the yellow Unsaved Changes badge is not showing — there is nothing to prepare. The Test Call dialog opens immediately with the call options, and the call runs against your current saved version.

​
Unsaved changes? A silent draft save first

When you do have unsaved changes, the dialog opens as Preparing your test call and works through two stages, with a progress bar and a tick as each completes: The save is silent — you won’t see the usual “Script saved successfully” toast — but it is a genuine draft save, not a throwaway copy:
  • A new draft version (for example v1.4) appears at the top of the version history, and the Unsaved Changes badge clears.
  • The test call runs against that exact version, and you can return to it later like any other draft.
  • Edits you make after the call starts don’t affect the call in progress.
Draft saves bump the version’s minor number; publishing promotes to the next whole number — see Script Versions & Publishing for how versions work. Closing the dialog during preparation abandons the test call. The draft may already have been saved by that point (stage 1 completes quickly), which is harmless — it is the same save you’d have made yourself.

​
Choosing how to take the call

Once preparation finishes, the dialog shows Call Options with two ways to take the call: Pick one and click Start Call. For a My Phone call you’ll see “Test call scheduled successfully” and your phone rings moments later; for an In Browser call the dialog shows Connected once the call is live, with a Hang Up button to end it. The full detail of both modes — contact setup, browser call behaviour, the Test badge in the Call Log, billing, and the DNCR exemption — lives on Test Calls. Browser calls have some quirks of their own, covered on Web Calls.

​
Validation errors that block saving

The flow editor validates your step conditions live as you edit — errors appear in red under the offending step, not just when you save. Three rules are enforced: While any of these errors exist:
  • Clicking Save is blocked with the toast “Please fix validation errors before saving”, and a summary naming the offending steps appears in the editor — for example “Voice steps must end with otherwise: Greeting, Wrap Up”.
  • Clicking Test Call fails at the Saving your changes stage for the same reason — the dialog closes with “Could not save your changes.” Fix the highlighted steps and try again.
  • The Publish button is disabled entirely.
Validation only blocks the save when something has to change; it never rewrites your flow for you. See voice step condition routing for how conditions and otherwise work.

​
Other messages you might see

​
Tips for effective testing

  • Test after every meaningful change. The loop is cheap — a silent save and a short call — and catching a mis-routed condition now is far easier than diagnosing it in a live call.
  • Gate test-only behaviour with {{call.is_test}}. The engine sets {{call.is_test}} (boolean, e.g. true) on test calls and {{call.is_prod}} (boolean, e.g. true) on production calls. A bool text function can add a line only your test calls speak: <<bool[{{call.is_test}} == true]:Just so you know, this is a test call.>> See Script Text Functions for the full comparison rules and Variables for the full variable reference.
  • Say the awkward things. Real callers interrupt, change their minds, and answer the wrong question. Push your script off the happy path deliberately.
  • Review the call afterwards. Every test call appears in the Call Log with its transcript, Call Summary, and Call Objectives — see Call Details for what to look for.

​
Next Steps

  • Test Calls — the ops view: In Browser vs My Phone, billing, DNCR exemption, and the Test badge in the Call Log.
  • Script Versions & Publishing — how draft and production versions work, and how calls pin a script version.
  • Script Editor Guide — a tour of the editor the Test Call button lives in.
  • Call Details — reading the transcript, summary, and objectives of your test call.