Skip to main content
Everything here works before a single real caller reaches the assistant.

​
Talk to it

Talk to Assistant on the assistant’s page starts a real call in your browser — same prompt, same voice, same tools, same recording. It’s the fastest loop you have, and it costs a call’s worth of model usage rather than a phone call. Try the awkward things, not the happy path:
  • Interrupt it mid-sentence. Does it stop?
  • Go quiet. Does it check in sensibly, and in the right language?
  • Ask for something it can’t do. Does it say so, or invent an answer?
  • Mumble a reference number. Does it ask you to repeat, or guess?
  • Ask it to do something it shouldn’t. Does it hold the line?

​
Test tools on their own

Open a tool and click Test. Give it the arguments the assistant would have worked out and check what comes back — before any call. Test against a specific assistant so variables resolve as they would in production. Worth checking: what your API returns when the thing isn’t found. That’s the response the assistant will have to explain to a caller, and it’s the one nobody tests.

​
Keep playbooks in draft

A playbook only runs when it’s published. Draft is a real workspace — build the whole procedure, leave it in draft, publish when it’s right.

​
Keep campaigns in draft

A campaign dials nothing until you start it. Build it, import a handful of contacts, and check the settings before adding the full list. Start with calls at once set to 1. You’ll hear the first few calls go out at a pace you can follow.

​
Test on an actual phone

A browser call runs the same assistant, but it doesn’t run the same audio. Phone lines are narrowband, noisier, and carry accents differently. Before you go live, point a number at the assistant and ring it from a mobile — ideally from a car or a station, not a quiet room. Transcription problems that don’t exist in your browser show up immediately.

​
Read the call back

After each test, open the call:
  • Accuracy — low means transcription struggled. Add keyterms.
  • Average response — see making calls feel fast.
  • Conversation — check the tool calls, their arguments and what came back.
  • Details — did the outcomes get recorded correctly?
That last one catches a specific failure: an outcome whose description is vague enough that the model fills it in differently every time. You only see it by looking at several calls.

​
Test the webhook too

If you’re integrating, use Send test event on your webhook endpoint before relying on it, and check the Logs tab of a real call to see what we actually sent.