What "outcome" means
A call has two separate things worth knowing: whether it connected at all, and whether it achieved anything. Keep them apart. Connection is a telephony fact. Achievement is a post-call analysis fact that you define yourself. Mixing them produces numbers that look bad for the wrong reason.
The per-call record in the Data Extractor Sidebar carries both: the call status and end reason, and the post-call fields you configured in post-call-analysis.
Ways a call ends before a conversation happens
| Ending | What happened | What to do about it |
|---|---|---|
| No answer | Rang out. Nobody picked up. | Normal. Use a sequence if you want retries. |
| Busy | Line engaged. | Normal. Retry with a sequence. |
| Carrier rejected | The carrier refused the call. | Check the from-number's Health score. See spam-labeling. |
The call status recorded per call is one of completed, failed, busy, no-answer, or canceled. The record also carries a separate voicemail value.
None of these are Finn problems. They are list, number, or carrier problems. If your completion rate is low but the calls that do connect perform fine, stop editing the prompt.
Ways a connected call ends
A connected call ends when one side hangs up or the platform terminates it. The end reason is recorded per call.
The case that trips people up: very short connected calls. A call that connects and ends within a few seconds produces almost nothing for post-call analysis to read, so its extracted fields come back empty.
An average duration under 20 seconds across a deployment means people are hanging up on the opening. Fix the welcome message, not the rest of the script. Over 5 minutes means the Finn is not closing the loop.
Transfers
A call that is handed to a human ends as far as the Finn is concerned, but it is still a connected call with a transcript up to the handoff point. If you need transfers counted, define a post-call field for it (transferred, yes/no) rather than looking for a built-in transfer status. See tools-transfer.
Outcome as you define it
The platform does not decide what a good call is. You do, by defining a primary success field in post-call analysis. Success rate is then calls where that field is true, divided by calls that connected and completed.
success rate = (calls with appointment_booked = true) / (calls that connected and completed)
Because the denominator is completed calls, a bad list drags completion rate down without touching success rate. That separation is deliberate. Read both.
For an enumerable outcome, use an enum field rather than free text. A free-text outcome field will give you "booked", "Book", "wants appointment" as three distinct values and you will not be able to chart it.
| Field | Type | Values |
|---|---|---|
outcome | Enum | paid / payment-plan / dispute / refusal / no-answer |
intent | Enum | book / reschedule / cancel / question / complaint / other |
When an outcome is missing
| What you see | Why |
|---|---|
| Post-call fields blank on older calls | The field was added after those calls completed. Analysis only runs forward, and old calls are not re-analysed. |
| A value that looks wrong | Open the call in the sidebar and read the transcript. Tighten the field's description in post-call analysis so the extraction has less room to guess. |
Getting outcomes out
The call.completed webhook event is the path for pushing outcomes into a CRM or warehouse. When the Finn has post-call questions, delivery waits until the analysis exists (or an hour has passed), so the analysis arrives with the call. See webhook-events for the payload and webhook-retries for delivery behavior.
CSV export includes every field as a column. Both are per-deployment.
Deployment-level endings
A deployment stopping is not a call outcome, but it looks like one when calls suddenly stop. Check the deployment in Live Deployments: the usual causes are an exhausted audience, a drained buffer, or a manual pause. See outbound-campaigns and troubleshooting.