Retell AI Post-Call Analysis: The Fields I Set Up on Every Client Agent (2026)

TL;DR: Retell's post-call analysis is the step that turns a transcript into data. After a call ends, Retell reads the conversation and fills a call_analysis object with four built-in fields (call_summary, user_sentiment, call_successful, in_voicemail) plus any custom fields you define as Boolean, Text, Number or Selector. You read the results in the dashboard's call history, through the call_analyzed webhook, or with the Get Call API. The common mistake is leaving it on defaults and automating off a prose summary. I build production voice agents for US clients on Retell, n8n, GoHighLevel and Twilio, and I run VoiceDash, the white-label client portal agencies hand their clients. This is the exact field set I start every client agent with, how I write the descriptions so extraction stays reliable, and how I wire the output into CRMs and client reporting.

What post-call analysis actually does

A Retell agent's live job is the conversation. Post-call analysis is a separate pass that runs once the call is over. Retell takes the finished transcript, asks a model to answer the questions you have configured, and writes the answers onto the call record.

That split matters. The live agent never has to do bookkeeping mid-call, and the analysis sees the whole conversation, so it catches things the caller corrected halfway through, like a phone number repeated with a different last digit.

You configure it per agent on the post-call data extraction settings. Each custom field gets a name, a description, and one of four types:

• Boolean for yes or no questions. Did the caller book? Did they ask for a human?
• Text for free-form values. Caller name, a callback number, a short note.
• Number for quantities. Party size, number of units, a quoted figure.
• Selector for one value from a fixed list. Call reason, outcome, urgency.

One caveat from Retell's own docs that trips people up: custom fields are not populated for calls that never connected or where no conversation took place. Your downstream logic has to expect missing fields, not just wrong ones.

The four built-in fields and how I treat each

call_summary

A short prose recap. It is the most readable thing Retell produces and the least useful to automate on. I treat it as the note a person reads when they open a call and never parse it for decisions. Whether an appointment was booked belongs in a Boolean, not a regex over a paragraph.

call_successful

This is the one worth customizing. Retell lets you write the prompt that defines what success means, and the default definition is rarely what a client means. For a dental office, success is a booked or rescheduled appointment. For a law firm intake line, it is a qualified lead with contact details and a case type. For an after-hours HVAC line, it might be an emergency correctly flagged. I write that definition in one or two sentences per client, because it is the number they will ask about first.

user_sentiment

Useful as a triage signal and not much else. I do not report it to clients as a headline metric, because "74 percent positive" invites an argument about the other 26 percent. Internally, I filter for negative sentiment calls and listen to those first each week. That is where the prompt gaps live.

in_voicemail

Mostly matters for outbound. When I run reminder or follow-up campaigns, this is how I separate real conversations from voicemail drops so the retry logic and the reporting stay honest. The outbound setup around it is in AI outbound calling campaigns.

The custom fields I add to almost every agent

This is my starting set. I trim or extend it per niche, but I rarely ship an agent with fewer than six of these.

1. call_reason (Selector). The intent in the business's own categories: new booking, reschedule, cancel, pricing question, existing job status, complaint, other. This is the field that tells a client what their phone line is actually for.
2. outcome (Selector). What happened, as a closed list: booked, lead captured, transferred to a human, message taken, question answered, no action needed, spam or wrong number. This drives most reporting.
3. appointment_booked (Boolean). Redundant with outcome on purpose. Workflows that trigger on bookings should read a single Boolean, not match a string.
4. caller_name (Text) and callback_number (Text). The two things a human needs to follow up. I ask for the number exactly as the caller confirmed it, digits only.
5. service_requested (Selector). Niche specific. Cleaning versus implant consult for dental, repair versus install for HVAC, practice area for a law firm.
6. urgency (Selector). Emergency, same day, this week, not urgent. This is what routes a 9pm burst pipe differently from a quote request.
7. human_requested (Boolean). Whether the caller asked for a person at any point, even if the agent resolved the call. A rising rate here is an early warning, and it pairs with the handoff rules in voice AI call transfer to a human.
8. follow_up_needed (Boolean) with a short follow_up_note (Text). The catch-all for anything a human has to do next.

If the agent books appointments, I also extract the requested date and time as Text so I can reconcile what the caller asked for against what actually landed in the calendar. That reconciliation step is covered in voice AI appointment booking.

How I write field descriptions that extract reliably

The description is a prompt. Most bad extraction comes from vague descriptions, not from the model.

• Prefer Selectors over Text. A closed list gives you clean data you can count. Free text gives you "booked", "Booked appt", and "they scheduled for Tues" in the same column.
• Always include an escape value. Every Selector gets an "unknown" or "none" option. Without one, the model picks the closest wrong answer rather than admitting the call did not say.
• Define the edge cases in the description. "Mark booked only if a specific date and time was confirmed by the caller. If the caller said they would call back, use lead captured." One sentence of edge case beats three sentences of general guidance.
• One question per field. "Did the caller book and were they a new patient?" is two fields. Combining them makes both unreliable.
• Keep field names stable. Workflows, CRM mappings and monthly reports all key off the name. Renaming call_reason to intent in month three quietly breaks every comparison, so add fields instead of renaming them.
• Match the vocabulary to the prompt. If the live agent calls it a "consultation", the analysis field should too. The prompt side of this is in the voice AI receptionist prompt.

Wiring the output into real workflows

The rule from Retell's docs I repeat to every freelancer I help: listen to call_analyzed, not call_ended. The call_ended event fires before the analysis finishes, so reading analysis fields from it gets you nulls.

My standard flow in n8n looks like this:

1. Receive call_analyzed on a webhook node and ignore every other event type in that branch.
2. Guard for missing fields. If the call never connected, there is nothing to route. Log it and stop.
3. Switch on outcome. Bookings update the CRM contact and confirm the appointment. Leads create or update a contact with service_requested and urgency. Messages notify the right person with follow_up_note and the summary attached.
4. Branch on urgency. Emergencies page someone immediately. Everything else waits for business hours.
5. Write the fields to the CRM record, not just the summary, so the client's team can filter by reason and outcome later.

The node-by-node version is in how to connect Retell AI to n8n, and if the client lives in GoHighLevel, the field mapping for contacts and opportunities is in how to add voice AI to GoHighLevel.

Test the extraction, not just the conversation

Agencies test whether the agent sounds good. Fewer test whether the analysis is right, and a wrong outcome field is worse than an awkward sentence because it silently corrupts every report built on top of it.

On pre-launch test calls, I write down what I expect each field to say before I look, then compare. The ambiguous calls matter most: a caller who almost books and then wants to check with their partner, a caller who asks two things, a caller who corrects their number. If extraction gets those wrong, I tighten the description, not the agent. The rest of my checklist is in how to test a voice AI agent. After launch, I spot-check a handful of calls a week against their fields. Ten minutes a week is the difference between reporting you trust and reporting you hope is right.

Turning analysis into client reporting

This is where the configuration pays off. A client does not want to read two hundred summaries. They want to know how many calls came in, what people were calling about, what got booked, and whether anything slipped. With call_reason and outcome as clean Selectors, those answers are counts, not interpretations.

It also makes the ROI conversation concrete. When outcome separates bookings from answered questions and spam, you can show a client the recovered revenue rather than a raw call count, which is the argument I lay out in voice AI ROI. Which numbers to put in front of them, and which to keep for yourself, is in voice AI client reporting.

Where VoiceDash fits

Post-call analysis gives you the data. Your client still needs somewhere to look at it that is not Retell's developer dashboard, which makes a serious retainer look like a side project, a point I covered in what clients want to see in a white-label Retell dashboard.

That is the layer VoiceDash handles. Connect your Retell account once, agents, calls and transcripts sync automatically, and each client gets a branded portal on your own domain. They see their own calls, recordings, transcripts and AI summaries in one searchable place, plus live analytics on call volume, outcomes and durations, scoped so no client ever sees another client's data. It goes live in under ten minutes with no code, on Starter, Growth or Ultimate plans with a free trial. It works with Retell today, and VAPI and Bland support are coming soon.

The bottom line

Post-call analysis is the difference between an agent that talks and an agent that produces data a business can act on. Customize call_successful per client, add Selector and Boolean fields for reason, outcome, urgency and follow-up, write descriptions with explicit edge cases and an escape value, listen to call_analyzed instead of call_ended, and audit the extraction like you audit the conversation. Do that and every call becomes a clean row a CRM can route and a client can read at a glance.

Building Retell agents for clients and want the reporting side handled? Start free on VoiceDash or book a demo and I will walk you through it on a real Retell setup.