When a campaign misbehaves, most problems fall into a handful of patterns. This page lists those patterns, the first checks you can run yourself in the Ori console, and the cases where you should stop and escalate to engineering rather than keep changing settings. The golden rule: change one thing at a time, then watch the live activity on the campaign monitor before changing anything else. Most campaign issues are configuration or data problems you can fix from the dashboard. A smaller set are backend problems you should hand off.

​
Quick triage

Start here. Find the symptom, run the first checks, and only escalate if the checks all pass and the problem remains.
ProblemFirst checks (you)Escalate when
Campaign will not startA bot is selected, the number pool is not empty, concurrency is at least 1, the time window is valid, and a CSV is uploaded (unless Always-on).All settings look correct but Start does nothing or fails.
Running but no calls go outThe current time is inside the calling window and today is a working day; the campaign has pending or retryable contacts left.Inside the window, contacts pending, but the Live Activity panel shows no dials for minutes.
Many no-answer or rejectedTime of day, number quality, and the carrier behind the number pool.The same SIP pattern (for example 5xx or 429) repeats across most calls.
Calls answer but the bot never speaksFleet has free capacity; the bot itself passes a test call.Customers connect but stay silent, or the campaign stalls at connect.
Bot says the wrong customer detailsCSV column spelling, prompt variable spelling, flat vs namespaced usage.Variables are correct in the CSV and prompt but still come through blank.
Retries are not happeningMax Attempts not yet reached, retry delay elapsed, the outcome is in your retry rules.Retry rules are correct but eligible contacts never re-dial.
Contacts stuck in a working stateWhether the campaign is paused or outside its window.Many contacts sit in an in-flight state long past when they should have moved.
Attempt report missing rowsThe attempt may still be in progress; let live calls finish first.A finished attempt never appears in the report.

​
Campaign will not start

A draft campaign that refuses to start almost always has a configuration gap. Open the campaign in the create/edit wizard and check each step.
1

Basics — a bot is selected

Step 1 must have a bot chosen. If the bot list is empty, the bot was never created — see Create a bot.
2

Number Pool — at least one number ticked

Step 2 requires at least one outbound number. An empty pool blocks dialling. Numbers come from your configured carriers.
3

Dialler Config — concurrency and window valid

Concurrency must be at least 1 (it clamps to a default of 50 if left blank). The time window must be a valid HH:MM start and end, and at least one working day must be ticked.
4

Upload CSV — contacts present

Step 4 needs a CSV with a phone_number column, unless the campaign is Always-on, where the CSV is optional. See Upload leads.
If the Next button in the wizard is greyed out, a required field on the current step is empty or invalid. There is no error pop-up — the button simply stays disabled until the step is complete.
If every setting is correct and the Start button still produces a “Failed to start” toast rather than moving the campaign to Running, escalate. That points to a backend or dialler problem, not a console setting.

​
Running but no calls go out

A green Running badge does not guarantee the dialler is actively placing calls. Open the campaign detail page and read the Live Activity panel. The panel’s status text tells you what is happening:
Status textColourMeaningWhat to do
Live ActivityGreenThe dialler is actively placing calls.Nothing — it is working.
Idle — Waiting for retriesAmberNo dials in the last 30 seconds; the campaign is waiting for retry delays to elapse or for eligible contacts.Check that contacts are still pending or due for retry. Normal between passes.
Paused — Outside time windowOrangeThe current time is outside the calling window, or today is not a working day.Wait for the window to open, or adjust the time window and working days.
Also check:
  • Pending count in the stats grid. If pending is 0 and retries left is 0, the campaign has nothing left to dial and will move to completed.
  • Last Dial age. If it shows minutes or hours ago in orange and the window is open with pending contacts, that is a stall — escalate.
If the Live Activity panel reads green or “Idle” with pending contacts inside an open window, but no new calls appear for several minutes, that is a backend stall. Note the campaign ID (use the copy button next to it) and escalate — do not restart or stop the campaign first, as that loses the state engineering needs to diagnose it.

​
Many no-answer or rejected calls

A high share of unanswered or rejected calls is usually a telephony or list-quality issue, not a bot or prompt issue. What you can check:
  • Time of day — calling at lunch or after hours lowers answer rates. Confirm the calling window matches when this audience actually picks up.
  • Number quality — old, ported, or wrong-format numbers in the CSV fail to connect. See Upload leads for accepted formats.
  • Outbound number reputation — if a particular DID in the pool is flagged or throttled by the carrier, swap it out under Carriers.
To read the failure pattern, open the call list on the campaign detail page and look at the Attempt Trail for several failed contacts. Hover an attempt to see the reason, including the SIP error where one is available.

​
SIP patterns

Repeated SIP status codes across many calls usually point outside bot logic.
PatternCommon meaning
408 / 480No answer, or the number was temporarily unavailable.
486 / 603Busy, rejected, or the call was declined.
429Rate limited by the carrier.
5xxCarrier, transport, or server-side problem.
How the dialler records the outcome: on an unanswered dial, a SIP code of 408, 480, or a missing code is recorded as no_answer; any other non-answer code is recorded as rejected. So a 486/603 (and most other failure codes) become rejected, while ring-no-answer and timeouts become no_answer.
A SIP 404 is not proof of a dead or unallocated number on every carrier. On some carriers a 404 arrives only after the line rings for many seconds, which is a genuine no-answer. Bucket failures by how long they rang before failing rather than assuming 404 means the number is invalid.
Escalate if the same SIP pattern — especially 429 or 5xx — repeats across most calls. That is a carrier or transport problem.
Do not change the bot prompt to fix SIP failures. SIP outcomes are decided before the bot ever joins the call; editing the prompt cannot change them.

​
Calls answer but the bot never speaks

If contacts connect but hear silence, the conversation pipeline did not attach to the call. What you can check yourself:
  • Fleet capacity — if every worker is busy, a connected call may not get a slot. Check the fleet page for available capacity, and lower the campaign’s concurrency if it is set higher than the fleet can serve.
  • The bot in isolation — run a test call against the same bot. If the bot is silent on a test call too, the problem is the bot’s voice pipeline configuration (its Speech-to-Text engine, Language model, or Text-to-Speech engine), not the campaign.
If the bot speaks fine on a direct test call but campaign calls connect and stay silent, that is a fleet attach or transport problem. Escalate with the campaign ID and the time of a specific affected call so engineering can match it to the logs.

​
Bot says the wrong customer details

If the bot reads a placeholder out loud, like: 
{{CUSTOMERNAME}}
then a variable was never filled in. The bot speaks the raw placeholder when it cannot find a value for it. Check, in order:
  • CSV column spelling — the column header in your uploaded file must match the variable name in the prompt, exactly, including case.
  • Prompt variable spelling — open the bot and confirm the variable names in the prompt match the CSV columns. See Prompts and variables.
  • Trigger metadata spelling — if contacts are added through the API, the metadata key names must match the prompt variables too.
  • Flat vs namespaced usage — {{CUSTOMERNAME}} and {{call.CUSTOMERNAME}} should both resolve, but a typo in either form will not.
If the CSV columns and prompt variables genuinely match and values still come through blank, escalate — the variable-resolution path may need a closer look.

​
Retries are not happening

Before assuming retries are broken, confirm the contact is actually eligible for one. A contact only re-dials when all of these are true:
  • it has not reached Max Attempts yet (check the X/max count in the call list);
  • its Retry Delay has fully elapsed since the last attempt;
  • its last outcome is in your retry rules — either a ticked Retry on System Disposition (no_answer, rejected, RNR, error, timeout) or a name listed under Custom Retry Dispositions.
See Pacing and retries for the full retry logic, including the order in which fresh and retry contacts are dialled.
Redial and stop-redial rules can also override a plain retry. If Stop redials after a meaningful connect is enabled and a call lasted longer than its threshold, remaining redials are cancelled on purpose. If both that rule and Redial after a short connect are enabled with overlapping thresholds, the wizard shows a warning and the stop rule wins. This is expected behaviour, not a fault.
If a contact is genuinely eligible — under Max Attempts, past its retry delay, with a matching outcome — and still never re-dials while the campaign is running inside its window, escalate.

​
Contacts stuck in a working state

Some contact states are normal waiting states and some are in-flight working states. Knowing the difference tells you whether to wait or escalate.
A contact scheduled for a callback or a retry is simply waiting for its due time. These hold deliberately and clear on their own once the time arrives and the campaign is running inside its window. Only treat a scheduled callback as stuck if it stays past its scheduled time while the campaign is actively running and inside its calling window.
A contact that is mid-dial or mid-conversation should move forward within the length of a call. If many contacts sit in an in-flight working state long after they should have finished — and the campaign is running, inside its window, with the Live Activity panel green — that is a stall. These states should advance on their own or be recovered automatically by the dialler’s stale-state handling. Persistent buildup means the dialler, the transport, the conversation pipeline, or the result path needs investigating.
Persistent buildup of in-flight contacts is an escalation trigger. Copy the campaign ID and report roughly how many contacts are stuck and for how long. Do not stop or restart the campaign first — that clears the very state engineering needs to find the cause.

​
Attempt report is missing expected data

The Attempt Report download on the campaign detail page produces an attempt-level CSV. If a call you expect is missing:
  • The attempt may still be in progress. A call that has not ended, or whose post-call result has not finalised, will not yet appear. Let live calls finish and download the report again.
  • Check the call list first. If the attempt shows in the on-screen call list but not in the downloaded report, note that and escalate.
While the report builds, the button shows “Preparing…”, then “Downloading [rows] · [MB]” as it streams, and finishes with a toast confirming the row count. If the download never starts or errors out, retry once; if it fails again, escalate.

​
What you can fix vs what to escalate

You can usually fix

  • Missing bot, empty number pool, or invalid time window stopping a start
  • Calling outside the window or on a non-working day
  • Concurrency set higher than available fleet capacity
  • Wrong or mismatched variable names between CSV and prompt
  • Retry rules that do not match the outcomes you want re-dialled
  • Poor-quality or wrong-format numbers in the contact list
  • A flagged outbound number that needs swapping in the pool

Escalate to engineering

  • Start fails even though every setting is valid
  • No dials inside an open window with contacts pending (a stall)
  • The same SIP pattern (429, 5xx) across most calls
  • Calls connect but the bot is silent, while it works on a test call
  • Variables correct everywhere but still resolving blank
  • In-flight contact states piling up and not recovering
  • A finished attempt that never appears in the report
When you escalate, include the campaign ID (use the copy button beside it on the list or detail page), the time of a specific affected call, and what you have already checked. That lets engineering match your report to the backend logs quickly instead of starting from scratch.
  • Monitor campaigns — the live activity panel, stats, and call list you read while triaging
  • Pacing and retries — how concurrency, retries, and redial rules decide what dials next
  • Create a campaign — every field in the wizard, including the ones that block a start
  • Carriers and Fleet — telephony and capacity, behind no-answer and silent-call issues