We pulled the transcripts from 10,000 outbound calls made by a UK SaaS company's booking agent over six weeks. The agent's conversion rate sat at 14%. Hidden inside the transcript data: 31% of calls ended within eight seconds of the prospect asking "who is this calling from?" — a trust-signal failure the flow design had no handler for. One new state added to the flow JSON recovered nine percentage points of conversion. The transcripts had been sitting in an S3 bucket, unread, since launch.
That is the shape of post-call analytics: the data exists, the insight exists, the recovery exists — but only if someone builds the pipeline to surface it. Most teams never do.
What post-call data actually contains: the six conversion signals buried in 10,000 call transcripts
When you process transcripts at scale, six signal categories determine where a campaign is losing calls:
Trust signals. How quickly does the prospect identify the caller and the purpose of the call? Calls that exit before turn three almost always have a trust failure. The signal appears in the first 15 seconds of transcript text.
Objection clusters. The same five objections appear in 70–80% of failed calls across every outbound campaign we have run. The exact phrasing shifts by industry, but the semantic cluster is consistent. NLP can surface these in hours from transcript data that would take weeks to review manually.
Turn latency gaps. Silence between the agent's response and the prospect's next utterance. A gap above 1.2 seconds correlates with abandonment at that specific turn, independent of call stage and independent of what was said.
Sentiment trajectory. Not just final sentiment, but the arc across the call. A prospect who starts neutral and turns negative between turns four and six is a different failure mode from one who is negative from the opening utterance. Trajectory reveals the specific moment the call tips.
Script branch coverage. Which branches of the flow JSON were actually taken? Dead branches tell you what the call flow designer assumed versus what actually happens. Branches taken by fewer than 3% of calls are candidates for removal; branches taken by 40% with no downstream refinement are candidates for A/B testing.
Conversion inflection point. The exact turn where a call tips toward booking or exit. In our SaaS campaign, it was consistently turn seven: if the agent had not resolved the trust objection by turn seven, the prospect disengaged 91% of the time. This single data point drove the entire flow redesign.
None of these signals live in your Retell or VAPI dashboard. They live in the transcripts — and only emerge at volume.
Transcript storage and retrieval: structured schema for call records, metadata, and searchable outcomes
Store raw transcript JSON from Retell or VAPI verbatim in S3 at s3://calls/{{campaign}}/{{date}}/{{call_id}}.json. Add a Postgres row per call for queryable metadata. This is the schema we use:
CREATE TABLE call_records (
call_id TEXT PRIMARY KEY,
agent_id TEXT NOT NULL,
campaign TEXT NOT NULL,
started_at TIMESTAMPTZ NOT NULL,
duration_sec INTEGER,
turn_count INTEGER,
outcome TEXT CHECK (outcome IN (
'booked','no-answer','hung-up',
'disqualified','transferred')),
sentiment_end NUMERIC(4,3), -- -1.0 to 1.0
sentiment_arc TEXT, -- 'pos-neg', 'neutral-pos', etc.
objection_tags TEXT[], -- populated by scoring pipeline
latency_p95_ms INTEGER, -- 95th percentile silence gap in ms
s3_path TEXT NOT NULL,
scored BOOLEAN DEFAULT FALSE
);
CREATE INDEX idx_call_outcome ON call_records (campaign, outcome);
CREATE INDEX idx_call_started ON call_records (started_at DESC);
CREATE INDEX idx_call_unscored ON call_records (scored) WHERE scored = FALSE;
The objection_tags column is a Postgres text array. Populate it in the scoring pipeline, not at call time. For full-text search across transcript content, add a ts_vector column loaded by a nightly job that fetches from S3 — this keeps the ingestion path fast and the search capability available without per-call S3 fetches.
At 10,000 calls per month, a Fly.io Postgres instance and standard S3 costs roughly £8/month combined. No dedicated analytics platform required.
Sentiment analysis on voice agent calls: what works reliably and where classification breaks down
Short conversational call turns — three to eight words — break most off-the-shelf sentiment models trained on review text. VADER will score "yeah sure I guess" as neutral when it signals soft disengagement in a sales call context.
What works reliably: RoBERTa variants fine-tuned on dialogue, specifically cardiffnlp/twitter-roberta-base-sentiment-latest, handle short utterances better than models trained on Amazon reviews. Apply utterance-level scoring, then weight turns after turn five more heavily — by then the prospect has decided whether to engage and the filler-to-signal ratio improves. Track the trajectory (e.g. pos-neg, neutral-abandoned) rather than a single end-of-call score.
What breaks: models trained on product reviews fail on filler-heavy British English speech. "Fair enough," "not bothered," and "cheers" all confuse review-trained models — the first two are often negative signals in an outbound context, the third is positive. Sentence-level averaging over an entire transcript produces near-neutral scores for almost every call because early filler pulls the mean toward zero.
The counterpoint worth reading: CMU researchers showed acoustic features — pitch, speaking rate, energy — improve sentiment accuracy by around 12% on short dialogue turns over text-only models. For a weekly coaching report, text-only classification is sufficient. For real-time supervisor flagging, acoustic input warrants the added complexity.
Objection pattern detection: using NLP to surface the three objections that kill 40% of conversions
Cluster prospect utterances from failed calls using TF-IDF vectorisation, then k-means (k=10–15). In our SaaS booking campaign, three clusters accounted for 41% of non-converted calls:
| Cluster | Representative utterances | % of failed calls |
|---|---|---|
| Trust / identity | "who gave you my number", "how did you get this number", "who is this calling from" | 22% |
| Timing | "not a good time", "call me back", "I'm in a meeting right now" | 12% |
| Already sorted | "we use X already", "we've sorted that", "happy with what we've got" | 7% |
Label each call_records row with its dominant objection tag using an LLM classification call. The prompt we use:
{
"model": "gpt-4o",
"messages": [
{
"role": "system",
"content": "Classify objections in outbound sales call transcripts. Label with zero or more types from: [trust_identity, timing, competitor, price, no_decision_maker, no_interest, already_solved]. Return JSON only: {\"tags\": [...], \"primary\": \"...\"}."
},
{
"role": "user",
"content": "Prospect turns only:\n{{prospect_turns_joined}}"
}
],
"response_format": { "type": "json_object" }
}
Running this across 10,000 calls at average 480-token inputs costs approximately £19 at current GPT-4o pricing. Once tagged, track how each flow change shifts the objection distribution week on week.
Turn-latency analysis: correlating sub-second latency gaps with call abandonment rates
Retell logs per-turn timestamps in the call detail record. VAPI does the same. Extract the gap between each agent end_time and the following prospect start_time. This silence gap — not the provider's reported processing latency, but the perceived pause the prospect experiences — is the metric that matters.
Plot a histogram of silence gaps against call outcome. In every campaign we have measured, the pattern is consistent:
- Gaps under 400ms: no statistically significant effect on abandonment at that turn
- Gaps 400–800ms: 8–14% higher hang-up rate at that turn compared to sub-400ms calls
- Gaps above 1.2 seconds: 31% hang-up rate at that specific turn, independent of what was said
The diagnostic is important because this latency does not appear in provider dashboards. A Retell call can complete without error while a specific turn hit 1.4 seconds — the dashboard reports aggregate call status, not per-turn silence. Transcript timestamps tell you exactly which turn is slow and how often it exceeds threshold.
From this data you can build a targeted fix: identify the top three most-travelled branches, pre-generate their TTS audio, and cache it. The implementation detail is covered in our TTS caching for voice agents post. The latency data tells you which branches justify the caching overhead.
See also voice agent monitoring and alerting for how to wire real-time latency alerts that fire before your weekly report.
Automated coaching reports: the weekly summary that tells you where the call flow is losing calls
The weekly coaching report runs every Monday at 07:00 UTC from a scheduled n8n workflow. It queries Postgres, pulls the top objection clusters for the week, computes sentiment drift, flags any turn-latency spikes, and generates a plain-English summary. The output lands in Slack:
Week of 18 Aug 2026 — Campaign: SaaS-Booking-UK
Total calls: 1,847 | Conversion: 16.2% (+2.1pp vs prev week)
Avg turns (converted): 9.1 | (abandoned): 4.3
Top objections this week:
1. trust_identity 19% of failed calls (↓3pp)
2. timing 14% of failed calls (↑2pp)
3. already_solved 6% of failed calls (—)
Latency alert: Turn 4 ("confirm-interest") avg gap 1,100ms (threshold 800ms)
→ 34 calls hit >1,500ms. Likely TTS cache miss on this branch.
Sentiment: 112 calls went positive→negative by turn 5.
→ Review opener phrasing on the "warm-intro" branch.
No dashboard login needed. The analyst spot-checks the five calls the report flags by name, not 200 calls at random. This structure replaces 45 minutes of weekly call review per ops lead and surfaces only the decisions that need a human.
Building a post-call analytics pipeline in n8n: transcript ingestion, scoring, and dashboard delivery
The pipeline runs in four stages.
Ingest. Retell fires a call_ended webhook to n8n. The workflow fetches the full call object, writes raw JSON to S3, and inserts a skeleton row in Postgres with scored=false.
Score. A second n8n workflow polls for scored=false rows every five minutes. It fetches the S3 transcript, calls GPT-4o for objection tagging, runs the sentiment scorer (a Flask container on Fly.io exposed as an HTTP function), computes per-turn latency from the timestamps, and updates the row to scored=true.
Aggregate. A Monday 07:00 UTC cron job runs the weekly SQL aggregation and writes a summary row to a weekly_reports table.
Deliver. The cron triggers a Slack message via webhook. A Looker Studio connector reads from a Postgres view for a persistent dashboard — though in practice ops leads use the Slack push 90% of the time and the dashboard only for quarterly reviews.
Infrastructure cost at 10,000 calls/month: approximately £28 (S3 + Postgres + GPT-4o scoring). Full comparison of ASR cost trade-offs is in our guide to Deepgram vs Whisper vs AssemblyAI for UK voice agents.
For quality gate automation on top of this pipeline, see how we structure voice agent QA scorecards to feed scored calls into human review queues.
What changed in 2025–2026: native conversation intelligence APIs from Retell, VAPI, and Deepgram
The biggest shift in 2025–2026: Retell and VAPI both added structured post-call analysis endpoints. Retell's call_analysis object now returns configurable boolean and text extraction fields without a separate LLM call. You define the extraction schema in the agent config; Retell runs it after every call and includes the results in the webhook payload.
Deepgram's Audio Intelligence API now returns sentiment, topics, and intent detection in a single transcription pass. Running Deepgram STT plus Intelligence costs less than running Whisper followed by a separate NLP model, and batch processing speed is materially faster.
If you are building a new pipeline today, use Retell's native call_analysis for standard objection fields and end-call sentiment, and reserve GPT-4o for the weekly narrative summary and edge-case tagging. Combined pipeline cost drops by roughly 60% compared to an all-LLM approach.
What has not changed: provider dashboards still do not expose per-turn silence gaps. That analysis still requires transcript timestamp extraction.
Good / Bad / Ugly: three analytics approaches and what each revealed about a real campaign
Good — Postgres + S3 + weekly Slack report
Campaign: UK SaaS booking agent, 10,000 calls, six weeks. What it revealed: The trust-signal failure above. 31% of calls exiting on "who is this from?" was invisible until cluster analysis. One flow state change delivered +9pp conversion. Cost: £31/month all-in. Build time: five days including the n8n pipeline, scoring container, and Slack template.
Bad — Real-time sentiment dashboard
We spent three weeks building a live Grafana dashboard updated per call. The problem: individual call sentiment is too noisy for real-time actioning. Ops leads saw a negative-sentiment spike with no context for whether it was one difficult call or a systemic pattern. They stopped looking at it within two weeks. Weekly aggregates are actionable. Per-call real-time scoring is not — unless a human supervisor immediately reviews flagged calls, which costs more than the insight is worth at SME scale.
Ugly — Off-the-shelf conversation intelligence platforms
We evaluated two established conversation intelligence SaaS tools for a mid-market UK campaign. Both required audio file upload rather than transcript JSON. Neither had a Retell webhook integration. Workflow: manual export, upload, wait four hours, log into their dashboard. Pricing for our call volume: £1,100–1,400/month.
The Postgres plus n8n approach at £28/month produced more targeted output. The lesson: these platforms are designed for human sales rep workflows inside Salesforce-heavy enterprise stacks. Voice agent call data has a different shape — structured turn-by-turn JSON, machine-generated turns mixed with human turns, high volume, low average duration. Build for your data, not the platform's assumptions.
The full story of how our voice AI and document analysis work fits together is in the Voice AI & Doc Analysis portfolio case study.