Why test first
Almost every problem a bot will have in production shows up on a single honest test call: a variable that never filled in, the wrong voice or language, an opening message that gets cut off, a tool that never fires, a transfer that fails, or a post-call push that maps the wrong field. Testing before you point a campaign at the bot is the cheapest way to catch all of these. Ori gives you two ways to test the same bot. Both open from the bot’s detail page (/dashboard/bots/[bot_id]).
Test Call
Ori places a real outbound phone call to a number you choose, through a real carrier. This is the closest thing to production — it exercises the carrier, the phone line, and the full pipeline. Use it before launch.
Test in Browser
Ori connects the bot to your computer’s microphone and speakers in the browser. No phone, no carrier, no call charges. Use it for fast iteration while you tune prompts and voice.
Test Call modal
The Test Call modal places a genuine outbound call from a carrier to a phone number you specify, using the bot exactly as a campaign would. You can also feed it mock customer data so the bot speaks names and amounts the way it will on a live call. Open it from the bot detail page. The modal title reads Test Call.Fields
Fill these in before you start the call.| Field | What to enter | Required |
|---|---|---|
| Transport | How the call is placed: SIP (uses your carriers) or Exotel (only shown if an Exotel integration is configured). Defaults to SIP. | Yes |
| Carrier | The carrier the call goes out on. The list shows only carriers that are synced and have outbound numbers. SIP transport only. | Yes (SIP) |
| DID | The outbound number (caller ID) the call uses, from the carrier you picked. Only numbers that can dial out are shown. SIP transport only. | Yes (SIP) |
| Exotel DID | The Exotel test number to call from. Shown only when Transport is set to Exotel. | No |
| Phone Number | The number that should ring — your own phone, so you can answer and talk to the bot. Use full international format, e.g. +91XXXXXXXXXX. | Yes |
| Template variables | One text box per {{variable}} Ori finds in the bot’s prompts and opening message. Type a test value for each so you can hear the bot use real data. See below. | No |
| Mock CRM Enabled | Sends the template-variable values above into the call as mock CRM data. Defaults on. Leave it on so the values you typed actually reach the bot. | No |
| Enable Pre-Fetch Simulation | If the bot has CRM pre-fetch configured, this simulates that fetch during the test. Defaults off. | No |
| Enable Post-Push Simulation | If the bot has post-call push configured, this simulates sending results to your CRM. Defaults off. | No |
Template variables
Ori reads the bot’s prompts and opening message and pulls out every{{variable}} it finds — for example {{crm.CUSTOMERNAME}} or {{call.amount}}. Each one becomes its own field in the modal.
Whatever you type here is what the bot will say. If the prompt greets the customer with Hello {{crm.CUSTOMERNAME}}, type a real name like Rajesh so you can confirm the bot says “Hello Rajesh” and not the raw {{crm.CUSTOMERNAME}} text.
Mock CRM Enabled must stay on for these values to be used. With it off, the bot runs as if no CRM data arrived — useful only if you specifically want to test the “missing data” path.
Buttons
| Button | What happens when you click |
|---|---|
| Initiate Test Call | Validates the form, then places the call: it rings the Phone Number you entered, from the chosen carrier and DID, carrying your mock variables. The modal switches to a connecting state and starts tracking the call’s progress. |
| Close Modal | Closes the modal. |
What you’ll see while it runs
The modal moves through these states:| State | What it means |
|---|---|
| idle | The form is ready; you haven’t started yet. |
| connecting | Ori is placing the call and the line is ringing. |
| live | You’ve answered and the bot is talking; an elapsed timer counts up. |
| ending | The call is wrapping up; Ori is waiting for the final result. |
| done | The call finished. The modal shows a summary — duration, disposition, and a recording link if one is available. |
| error | The call failed to connect or complete. The modal shows an error message explaining why. |
If you don’t answer, the modal keeps polling and then times out (after a few minutes). A timeout in the test modal usually just means the phone wasn’t picked up — answer the call to complete the test.
How to run a good Test Call
Pick how it dials
Leave Transport on SIP for a normal phone test. Choose the Carrier and DID you want the call to come from — pick the same carrier the campaign will use, so the caller ID and audio path match production.
Enter your own number
Put your own phone in Phone Number in full international format so you can answer and actually talk to the bot.
Fill the variables with realistic data
Type real-looking values into each template-variable field — a real first name, a real amount, a real due date. This is how you confirm the opening message and prompt render correctly. Keep Mock CRM Enabled on.
Optionally simulate integrations
If the bot uses CRM pre-fetch or post-call push and you want to test them, turn on Enable Pre-Fetch Simulation and Enable Post-Push Simulation.
Place the call and answer it
Click Initiate Test Call, answer your phone, and have a real conversation — including the awkward bits (see What a good test looks like).
Read the summary, then open the call detail
When the modal shows done, check the duration, disposition, and recording. Then open the full call detail to inspect the transcript, events, and analysis. See After the test.
Test in Browser modal
The Test in Browser modal connects the bot directly to your computer’s microphone and speakers. There is no phone and no carrier — you talk to the bot through your browser. It’s the fastest way to hear a prompt or voice change without spending a call. Open it from the bot detail page. The modal title reads Test in Browser. This test has no input fields — it starts as soon as you give the browser permission to use your microphone.Buttons
| Button | What happens when you click |
|---|---|
| Start Test | Asks your browser for microphone permission, connects you to the bot, and begins the conversation. The status changes to connecting and then live. |
| Mute / Unmute | Turns your microphone off and on. While muted, the bot can’t hear you; the timer keeps running. Click again to unmute. |
| End Test | Disconnects you from the bot, stops your microphone, stops the timer, and ends the test. The modal closes when the session ends. |
Microphone permission
The first time you click Start Test, your browser shows its own pop-up asking to use the microphone. You must click Allow.What you’ll see while it runs
| State | What it means |
|---|---|
| idle | Ready to start; nothing is connected yet. |
| connecting | The browser is asking for the microphone and Ori is connecting you to the bot. You’ll see “Connecting…“. |
| live | You’re connected and the bot is listening. The modal shows an elapsed timer (MM:SS) and the Mute button. |
| ending | You ended the test and Ori is disconnecting. |
| error | The connection failed — for example, microphone access was denied. The modal shows the error message. |
How to run a good browser test
Click Start Test and allow the mic
Click Start Test, then click Allow on the browser’s microphone prompt.
Wait for live
Watch the status move from Connecting… to live. The timer starts counting once you’re connected.
Have a real conversation
Speak to the bot the way a customer would. Interrupt it, go quiet, give short answers — see What a good test looks like.
The browser test does not let you provide mock CRM variables. If a prompt depends on customer data (names, amounts, due dates), use a real Test Call with the variable fields filled in to confirm those render correctly.
What a good test looks like
A useful test is more than “did the bot answer.” Deliberately walk the bot through the situations a real customer will create, and listen for the behaviour that breaks production conversations.Conversation paths to cover
| Path | What to do | What you expect |
|---|---|---|
| Normal success | Cooperate and let the bot reach its goal. | The bot completes the objective and ends the call cleanly; the analysis is correct. |
| Stay silent | Say nothing after the bot greets you. | Re-engagement fires, then the call ends with an RNR / no-customer-message disposition. |
| Hang up early | End the call from your side mid-conversation. | The result is stored with disconnected_by = customer. |
| Let the bot end it | Reach a point where the bot should close the call. | The bot ends it; the result shows disconnected_by = bot. |
| Tool path | Steer the conversation to trigger a custom tool or knowledge lookup. | The tool runs and shows up in the call events. |
| Transfer path | Ask for a human / trigger the transfer condition. | The bot transfers and result.was_transferred = yes; on failure, a transfer-failed reason is recorded. |
| Callback request | Ask to be called back later. | The analysis records the callback request and the time text (only when callback detection is enabled on both the bot and the campaign). |
| CRM data | Use a Test Call with variables filled in. | The opening message and prompt say your real values, never raw {{...}} text. |
Communication quality to listen for
| Check | What good sounds like |
|---|---|
| Opening message | Background noise on your end shouldn’t cut off the bot’s first sentence. |
| Short acknowledgements | Filler like “haan”, “hmm”, “okay”, or “ji” shouldn’t derail the bot or make it stop. |
| Real interruptions | Meaningful phrases — “wrong number”, “already paid”, “transfer me”, “agent” — should interrupt the bot promptly. |
| Tool / API waits | When a tool is running, the bot shouldn’t go silent for long; it should hold the conversation naturally. |
| Silence handling | Re-engagement should sound natural, not robotic, before the call ends. |
| Knowledge answers | The bot should answer from attached knowledge only when appropriate and avoid guessing. |
| Latency | The bot should respond without long, unnatural gaps. |
After the test
A test isn’t finished when you hang up — it’s finished when you’ve read the call record. Open the call from the bot’s call list or the call detail page and check:- Transcript — did the bot understand you, and did it say your variables correctly?
- Recording — does playback work?
disconnected_by— does it match how the call actually ended (bot, customer, voicemail, timeout)?- Call duration — does it look right for the conversation you had?
- Events — did tools, transfers, and knowledge lookups fire when expected?
- Post-call analysis and QC — is the summary, disposition, and quality scoring correct?
- CRM push / integration logs — if you simulated post-call push, did the right fields go out?
Common failures and what they mean
| Symptom | Likely cause |
|---|---|
Bot says {{FIELD}} out loud | A variable is missing or misspelled, or Mock CRM Enabled was off in the Test Call. |
| Test Call fails before the bot speaks | Carrier not synced, no outbound DID, a provider key issue, the bot is Inactive, or it’s outside the bot’s active hours. |
| Browser test errors immediately | Microphone permission was denied — re-allow it for the site and start again. |
| No recording on the call detail | Storage misconfiguration, an upload failure, or the call ended before recording started. |
| Post-call analysis missing | The call hit an auto-disposition path that skips analysis, or the analysis prompt is empty. |
| Transfer never happens | The Transfer Call tool isn’t enabled for the bot, or no transfer target is configured. |
| CRM push missing a field | The key mapper points at the wrong variable path. |
Whether you tested by phone or in the browser, the resulting call appears in the bot’s call history just like a production call, so you can re-open and re-inspect it at any time.
Related
- Create a bot — build or edit the bot you’re testing.
- Voice pipeline — tune the STT, LLM, and voice engines if a test sounds wrong.