Testing your pathway

You can have a conversation with your pathway before any real customer does. A test is a simulated caller with a personality and a goal, who talks to it while a set of checks decide whether it did the right thing.

No real call is placed and no real customer is involved. Tests run against your staging version, so you can break things safely.

123

1. 1Runs every enabled test. Each run costs credits, like a real conversation.
2. 2The test, its category, when it last ran, and how many checks it carries.
3. 3Turn this on and a failing test warns you before the pathway can go live.

Talking to it yourself first

Before you write a single test, use Test chat — the panel next to Tests in the toolbar. You type, the pathway answers, and the step it's currently on lights up on the canvas as the conversation moves.

1

1. 1Type as a caller would. No phone call is placed and no customer is involved.

This is the fastest way to catch a step that never gets reached or a branch that fires on the wrong answer. Tests are for locking that behaviour down once you're happy with it.

Writing a test

Three parts:

The caller profile — who is calling and how they behave. This is where the value is, so be specific. "A caller who wants a Saturday appointment, is in a hurry, and gets impatient if asked more than one question at a time" exercises your pathway far harder than "a customer".

The caller name — what the simulated caller is called, so transcripts read naturally.

The checks — what has to be true for this to count as a pass. Each check is one condition, and the run reports them individually ("3 of 4 checks passed"), so keep them single-purpose:

• The agent offered at least two appointment times
• The agent never quoted a price
• The agent asked for a callback number before ending
• The call ended with a booking

Write checks about outcomes and obligations, not exact wording:

Start from a template, or a real call

Two shortcuts worth knowing:

The template gallery covers the situations everyone needs and nobody thinks of first — happy path, edge cases, voicemail, voicemail screening, call screening, frustrated callers, hostile callers, confused callers. Clone the ones that apply to you and edit the details.

Reading a run

Run one test, or run them all. A run gives you:

• The transcript of the simulated conversation.
• Each check, passed or failed, individually.
• A natural conversation score — how well the conversation actually flowed, rated on things like pacing, empathy, and conciseness. A run can pass every check and still score poorly, which usually means the pathway is correct but stilted. That's worth knowing before customers tell you.
• Analyze failure on a failed run — an AI post-mortem giving a root cause and suggested fixes, so you're not re-reading a transcript hunting for the moment it went wrong.

The publish gate

Mark a test Required to publish and it becomes a gate: if it's failing, you're warned before the pathway can go live. Reserve this for the things that must never break — the booking actually completes, the disclosure is always given, the agent never promises a price it can't honour. A dozen required tests that fail for cosmetic reasons will train everyone to click past the warning, which defeats the point.

A practical routine

1. Before a pathway's first publish, write tests for the main path and each branch.
2. Add the templates that match your reality — voicemail if you dial out, frustrated callers if you handle complaints.
3. Mark the two or three genuinely critical ones Required to publish.
4. Every time a real call goes wrong, make a test from it.
5. Run everything before each publish, and read the conversation score, not just the pass count.

Pathways that get tested get changed with confidence. Ones that don't get changed nervously, or not at all.