What a field is
Every post-call analysis field has three parts. You define them in the dashboard: click Edit on the Finn's builder page, open the Post-call analysis tab, then Add question. You can also set them through the API as the post_call_analysis array on a Finn. See post-call-analysis and api-finns.
| Part | What it does | Example |
|---|---|---|
| Question label | Internal key used in analytics, exports and webhook payloads. Use snake_case. | appointment_booked |
| Instruction prompt | What you want the AI to read out of the transcript. Phrase it as a natural question. | "Did the caller successfully book an appointment?" |
| Answer type | The value type the AI is constrained to return. | Yes/No |
The question does the work. "Booking?" and "Did the caller successfully book an appointment?" are not equally good, and the second one is what produces a value you can chart.
Answer types
| Type | What you get | Use it for |
|---|---|---|
| Text | What the caller said, or what the AI inferred | Open-ended captures: pain points, callback time, names, dates |
| Selector | One of the choices you defined | Known buckets: intent, sentiment, urgency |
| Yes/No | true or false | Did one specific thing happen |
| Number | A numeric value | Scores, quantities, prices mentioned |
There is no date type. Capture dates and times as Text. Pick the narrowest type that answers the question. Text is the fallback, not the default.
Wording that survives contact with real calls
One question per field. "Did they book and what time?" is two fields: booked (Yes/No) and booking_time (Text). Combined questions produce messy or empty answers.
Ask yes/no questions if you want yes/no answers. "Did X happen?" extracts reliably. "How did X go?" is a Text question wearing a Yes/No label, and it will fail unpredictably.
Name the success criterion. "Was the call successful?" fails because the AI does not know what success means for your business. "Did the caller agree to a follow-up?" or "Did the caller make a purchase commitment?" are concrete and repeatable.
Use a Selector for anything you plan to chart. A Text intent field returns "booking", "Book", "wants appointment", "appointment booking" and "want to book" as five distinct values. You cannot chart that. A Selector with book / reschedule / cancel / question / complaint / other you can.
Start with 3 to 5 fields. A wide schema on day one means fields nobody looks at and questions nobody tuned. Add fields once you know which decisions you are actually making.
Editing fields after launch
You can add, edit or remove fields at any time. None of these changes are retroactive.
| Change | What happens |
|---|---|
| Add a field | Populated for calls completed after the field was added. Older calls stay blank for it. |
| Edit a field's question | Future calls use the new question. Past calls keep the value extracted under the old question and are not re-extracted. |
| Remove a field | Extraction stops. Historical values stay in the data unless you delete the call records. |
The failure mode is silent. If you edit a question three months in, one export column holds answers to two different questions with nothing in the row marking the cut. Charts built on that column will look continuous and be wrong. Either give the reworded field a new name and retire the old one, or record the change date and split your analysis at it.
New and edited fields are not backfilled across historical calls. There is no re-analysis pass, so plan your fields before the calls you want to measure.
Renaming versus rewording
Renaming a field changes the key used in exports and in the call.completed webhook payload. Anything downstream keyed on the old name stops receiving that field, and it fails quietly rather than erroring. Check your webhook consumers and warehouse mappings before renaming. See webhook-post-call and webhook-events.
When extraction does not produce a value
If the transcript lacks the information, the field has no usable answer. Most common cause: the call ended before the topic came up.
A field that reliably fails is usually a prompt problem, not an analysis problem. If budget_range is empty on 80% of calls, the agent is not asking about budget. Fix the agent, not the question. See agents-prompting.
Starting sets
| Use case | Fields |
|---|---|
| Lead qualifier | qualified (Yes/No), budget_range (Text), decision_maker (Yes/No), meeting_booked (Yes/No), objection (Text) |
| Receptionist | intent (Selector), appointment_booked (Yes/No), transferred (Yes/No), caller_sentiment (Selector), follow_up_needed (Yes/No) |
| Appointment reminder | confirmed (Yes/No), rescheduled (Yes/No), cancelled (Yes/No), opt_out (Yes/No) |
| Satisfaction survey | nps_score (Number, 0-10), top_positive (Text), top_negative (Text), would_recommend (Yes/No) |
| Debt collection | outcome (Selector: paid / payment-plan / dispute / refusal / no-answer), amount_paid (Number), disputed (Yes/No), callback_scheduled (Yes/No) |
For where these values surface, see post-call-analysis, call-logs and exports.