Outcomes · What we measure
What each conversation cost, while the campaign is still running
Who picked up. Who qualified. What every outcome cost you. Each figure is computed on your own campaigns, off ledgers the platform already holds. Each metric is a live API report; supported CSV exports provide the underlying record types for downstream analysis. For enabled events, call completion reaches your signed webhook, while available call evidence stays behind the authenticated /v1 read.
The reports, and the grammar they share
The funnel, the disposition mix and the turn timings are reads on the same API your dashboards use. Each one takes a window, an optional grouping (by campaign, by published agent version, or by day) and an optional filter down to a single campaign. Same shape whichever one you ask for, so a query you write once keeps working.
The funnel
GET /v1/analytics/funnel
Attempts, dials, connects, conversations, outcomes and goal completions, plus four rates computed from them: connects over dials, conversations over connects, outcomes over attempts, and goal completions over conversations.
The disposition mix
GET /v1/analytics/dispositions
Every attempt lands on one value from a pinned vocabulary: completed, answered but incomplete, voicemail, no answer, opted out, refused by policy, and the rest. The report returns each value by name with its share of the group it sits in, so the mix reads the same way next quarter.
Turn timings
GET /v1/analytics/latency
Turn-level timing percentiles read off your own calls. This one needs the call-read scope as well as the campaign one, because a turn ledger is a transcript and is treated like one.
Ask for a window outside the bounds and you get a problem document naming the rule you hit, so you fix the query instead of squinting at a half-drawn chart. Longer histories leave through CSV export jobs: supported record types, the filters and columns you choose, and a signed download while the completed job is retained.
A stage with nothing beneath it reports empty, never zero. A campaign that dialed nobody has no contact rate, so your chart never carries a point no call produced. The rule lives in the code that computes the rate rather than in a dashboard's formatting, which is why it holds on the API read and on the screen.
What each scenario reports
Bare names are cheap, so every one below carries the sentence that says what it counts. If a name cannot take that sentence, it does not belong on the panel.
Speed-to-lead
-
Contact rate
How many of the leads you chose to call actually picked up and talked.
-
Qualification rate
How many conversations ended qualified against your own rubric, per campaign.
-
Disposition mix
Every attempt written from a pinned vocabulary, so the mix reads the same tomorrow.
-
Refusals, by reason
The dials the platform refused to place, each with the value that caused it.
-
Demos requested
Interested leads whose call captured the window they named, in their own words.
-
Cost per qualified outcome
Spend to date over the outcomes the same payload counted. Division, not a model.
Staffing calls
-
Contact rate
How many of the candidates you chose to call actually picked up and talked.
-
Confirmed shifts and decline reasons
Each response is saved as a structured shift-confirmation outcome, so the team can work confirmed coverage and clear decline reasons without replaying every call.
-
Cost per completed call
Read off the usage ledger for the exact calls this campaign made.
Feedback calls
-
Contact rate
How many of the customers you chose to ask actually picked up and talked.
-
Completed conversations
Feedback calls that reached the end of your questions, counted per campaign.
-
Survey responses and scores
Each recorded response is saved as a structured survey outcome, so feedback teams can work answers, scores, and CSAT/NPS rollups from the program they ran.
-
Cost per completed call
Read off the usage ledger for the exact calls this campaign made.
A name appears here once a read produces it, which is why every metric on this page works on the first campaign you run.
The one nobody else reports
Refusals, by reason
Every dial the platform held back is counted and named, each beside the value that caused it. It is the row that tells you a campaign stayed inside your own rules while it was still running, instead of six weeks later when somebody asks.
It is computed twice, on both sides of the dial. The batch run writes a breakdown of what it suppressed before the campaign launches, sorted and rendered in your own run report. The dial-time re-check writes the refusal onto the attempt with its sub-code, and the disposition report returns it by name with its share.
What the platform performs, named one by one: phone normalization, suppression against your own internal do-not-call list at the batch run and again at dial time, and the dialability gate. Those three are what a refusal count is made of.
The breakdown shows the reasons that actually fired on your calls, each with the count it took off the list.
A held-back dial still writes its file
A dial the platform holds back is written down as carefully as one that connects: the checks that ran, the value that stopped it, and the row it took off the list, exportable with the rest of the run. The answer to “why was this number never called” is on file the day somebody asks for it, not reconstructed the week after.
The whole shape of a call’s record is on the Trust Center.
Cost sits on the same counter as the outcome
Every campaign carries its spend to date beside its dials, its connects and its goal completions, on one payload your dashboards poll and your own code can read. The cost of a completed call is division over two figures you already hold, so you can check our arithmetic in a spreadsheet.
Why the figure is this small. It counts the platform’s own charges. Production calling runs on your own Twilio account, so your carrier bills you for the minutes at the rate you already negotiated, and a Vocapable invoice never carries a carrier line for you to reconcile.
Cost per completed call
Read off the usage ledger for the exact calls this campaign made.
Spend to date
On the live campaign counter, beside the dials and the goal completions it is divided by.
Usage detail
Event-level, per meter, on a read of its own, so you can reconcile the total rather than trust it.
The published rates behind every one of those figures are on the pricing page, and every field named here is a /v1 read before it is a tile.
Call completion arrives first; analysis follows
For the events you enable, the platform posts a signed call.ended event at call completion: the disposition, duration and end reason, the identifiers that tie it to the contact and campaign, and whether a transcript or recording is available. It marks post-call analysis as pending. Fetch available call evidence through authenticated /v1 reads; a later call.analyzed event carries the analysis result. Delivery retries when your configured endpoint is down, so a rep can work the next step in their own tooling while the conversation is fresh.
Your stack stays the system of record. For enabled events, shift confirmations emit shift.confirmed, and survey responses emit survey.completed; each is also its own /v1 resource. CSV export jobs cover supported record types with the filters and columns you choose, then provide a signed, time-bounded download when the job is complete.
Call evidence, when available
Fetch ordered turns, transcripts, or recordings through authenticated /v1 call reads.
One value, pinned
The disposition comes from a fixed vocabulary, so your reports keep their meaning.
Structured results, ready to use
Survey answers and scores, or a shift confirmation, are saved as their own resources and delivered through their corresponding configured signed events.
The trust close
Numbers you can produce, on calls you placed
You choose who gets called, and you and your advisors set the standard that choice has to meet. From there the platform does the work: it enforces the calling window, the frequency caps, the consent standard and the recording-consent class in force on every attempt, stricter-only, and it writes down which values bound the call.
Every call the platform places, and every one it holds back, writes an evidence-bearing call or attempt record: which checks ran, which were waived, and on whose signature. The corresponding authenticated /v1 read and supported CSV export job keep that evidence ready when somebody asks how a call happened.
The whole claim
The reports above read the same rows that evidence record does, so any figure on this panel walks straight back to the individual calls that produced it: in the contact record, in a CSV job for its supported record type, or on a /v1 read.
One number, one set of calls, one place to check it.
Questions people ask first
Where do these numbers come from?
From your own campaigns and nowhere else. Each figure is read off a ledger the platform already holds: the attempt row, the call record, the usage meter. The same /v1 reads that feed your dashboards return them, so every number on the panel is one your own calls produced and every one of them walks back to the individual calls behind it.
What does a rate show when nothing reached that stage?
It reports empty rather than zero. A campaign that dialed nobody has no contact rate, so the chart stays honest instead of drawing a point your calls never produced. The rule lives in the code that computes the rate, which is why it holds on the API read and dashboard view.
Do you report whether a meeting actually happened?
Your own calendar holds that fact, and your team is the one who marks it. What the panel reports is everything leading up to it: the conversation itself, the value the attempt was disposed with, the window the prospect named in their own words, and the record your team can retrieve through its configured delivery path.
What exactly does the refusal count cover?
The dials the platform held back before they were placed: your internal do-not-call list applied at the batch run and again at dial time, the dialability gate, and the calling window and frequency caps in force. Each one arrives named, with the value that caused it, so you can see a campaign staying inside your own rules while it is still running rather than six weeks later.
Can I get all of this without opening the dashboard?
Yes. Every report on this page is a /v1 read, and the dashboard is one consumer of it rather than the source. Longer histories leave through CSV export jobs for supported record types; a completed job provides a signed download for its time-bounded window. For the events you enable, call completion arrives as a signed call.ended event with post-call analysis marked pending; call.analyzed arrives when that analysis is ready. Structured survey responses and shift confirmations use their own enabled signed events.
Run a campaign and read your own panel
The sandbox runs the whole dial path with every gate live and failing closed, and it writes the same rows these reports read. The first numbers you see here will be yours.