> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qall.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing before you go live

> Find the problems yourself, not on a customer's call.

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](/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](/playbooks) 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](/campaigns) 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](/calls):

* **Accuracy** — low means transcription struggled. Add
  [keyterms](/assistants).
* **Average response** — see [making calls feel fast](/guides/making-calls-feel-fast).
* **Conversation** — check the tool calls, their arguments and what came back.
* **Details** — did the [outcomes](/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](/api-reference/webhooks) before relying on it, and check the
**Logs** tab of a real call to see what we actually sent.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.