Where testing lives
Open a Finn from View All Finn, or stay in the Create Finn wizard after saving. Two buttons sit in the top right:
| Button | What happens | Use it for |
|---|---|---|
| Test on Call | The Finn calls your phone | Voice, pacing, interruptions, how the welcome message actually lands |
| Test on Chat | Text simulation in the browser | Prompt logic, knowledge base retrieval, fast iteration |
Both are dashboard actions. There is no public API endpoint for triggering a test, so testing is not something you can wire into CI today.
Test calls are free and do not count against trial credit. Nothing you do here is live to the outside world. A Finn only reaches real callers once you create a deployment, covered in outbound campaigns and inbound routing.
Chat first, call second
Chat is the faster loop. It exercises the same identity text, guardrails, response guidelines, and knowledge base, without the latency of a phone call. Use it to settle what the Finn says.
Chat does not exercise the voice, TTS, or STT stack. It will not surface a mispronounced brand name, a voice that sounds wrong for the use case, an idle timeout that fires too early, or the Finn talking over the caller. Those only show up on a real call. See voice, tts, and stt.
Move to Test on Call once the script is roughly right, then keep alternating.
Phone number format
Enter the number with a country code. US: +15551234567. India: +919876543210. The dashboard shows a preview of the format it parsed before it dials. Read that preview. A number without a country code is the most common reason a test call never arrives.
What to test, not just that it works
A test that only covers a cooperative caller answering in order tells you little. Cover:
- Callers who go off-topic or ask something outside the knowledge base
- Callers who are confused and ask the same thing twice
- Hostile or impatient callers, to check the guardrails hold
- Accents your speech recognition may not handle, and brand names or SKUs that need custom vocabulary
- Silence, to see when
max_idle_durationfires and what the idle reminder says - Answers in an unexpected format, for example a date with no time
Reading the result
Every test call lands in Analytics alongside real calls. Open the call to get the transcript, the audio, and the side panel. Clicking a line in the transcript jumps the audio to that moment.
The Data Extractor Sidebar has a Knowledge tab showing which knowledge base snippets were retrieved for that call. When the Finn answers a question wrongly and you believe the answer is in your documents, look there before editing the prompt. Wrong snippets mean a knowledge base problem, not a prompting problem. See knowledge base and call logs.
Things that will go wrong
| Symptom | Cause | Fix |
|---|---|---|
| Call never arrives | Missing country code | Re-enter with + and country code |
| Call never arrives | Number on the Do Not Call list | Settings, then Compliance, then Do Not Call List |
| Call never arrives | Carrier or handset spam filter dropped it | Try a different from-number |
| Finn silent on pickup | Welcome message set to defined with an empty field | Add text, or switch to dynamic. See welcome |
| Finn sounds wrong or fails to speak | Voice not assigned, or voice needs a region match | Re-select the voice |
| Post-call analysis fields blank | The field was added after this call ran | Add the field, then make a new test call |
| Post-call analysis fields blank | Call was too short to extract from | Run a longer test |
| Finn ignores your instructions | Contradictions across Identity, Style, Welcome, and Workflow | Audit all four for conflicts. See prompting and guardrails |
Post-call analysis is the trap most people hit. It runs on calls that complete after the field exists, never retroactively. Define your fields before a long test session, not after.
Edits during testing
Saving a Finn does not interrupt anything. Changes apply to new calls. A call already in flight finishes under the configuration it started with, so a config edit mid-call will not show up until you dial again.
The platform keeps a history of configurations under View All Finn, then the Finn, then History. If a change makes behavior worse, roll back rather than trying to reconstruct the earlier prompt from memory. See versioning.
When testing stops being enough
Manual testing catches obvious breakage. It does not tell you whether a change improved behavior across many calls, because you cannot hold twenty transcripts in your head. Once the Finn is roughly right, move to evaluations for repeatable scoring and post-call analysis for measurement across a real call volume.