What a field is
Every post-call analysis field has three parts. You define them in the dashboard under View All Finn → your Finn → Edit → Post-Call Analysis, then Add Field. There is no API for creating or editing fields.
| Part | What it does | Example |
|---|---|---|
| Field name | Internal key used in analytics, exports and webhook payloads. Use snake_case. | appointment_booked |
| Question to AI | 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 |
|---|---|---|
| Yes / No | true or false | Did one specific thing happen |
| Enum | One of the N choices you defined | Known buckets: intent, sentiment, urgency |
| Free text | What the caller said, or what the AI inferred | Open-ended captures: pain points, callback time, names |
| Number | A numeric value | Scores, quantities, prices mentioned |
| Date | A date, or date plus time | Requested appointment time, when an issue started |
Pick the narrowest type that answers the question. Free 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 (Date). 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 free text 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 enums for anything you plan to chart. A free-text intent field returns "booking", "Book", "wants appointment", "appointment booking" and "want to book" as five distinct values. You cannot chart that. An enum with book / reschedule / cancel / question / complaint / other you can.
Start with 3 to 5 fields. You can define up to 50 fields per Finn (contact support for a higher limit), but 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.
Backfilling a new field across historical calls is not self-serve. Contact support for a one-off re-analysis pass.
Renaming versus rewording
Renaming a field changes the key used in exports and in the call.analyzed 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 is marked as extraction failed rather than guessed. Most common cause: the call ended before the topic came up.
- Every extracted value carries a confidence score. Low-confidence values are flagged in the per-call sidebar, and you can filter exports to high-confidence rows only.
- Free-text extraction is constrained to exact transcript quotes where possible.
- You can override any value manually from the per-call sidebar. Overrides are flagged as human-corrected in exports.
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 (free text), decision_maker (Yes/No), meeting_booked (Yes/No), objection (free text) |
| Receptionist | intent (enum), appointment_booked (Yes/No), transferred (Yes/No), caller_sentiment (enum), 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 (free text), top_negative (free text), would_recommend (Yes/No) |
| Debt collection | outcome (enum: 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.