Structured outputs

Turn every conversation into fields your systems can use — defined once as a schema, filled after each call or chat.

A transcript is for people. Your CRM wants fields: did the caller agree, what date did they pick, how satisfied were they. A structured output is a named schema the model fills in once the conversation is over.

Defining one

A structured output is a JSON schema: the fields you want, their types, and a description of each that tells the model what to look for. Definitions are versioned, so changing one does not silently change what earlier results meant.

{
  "type": "object",
  "properties": {
    "appointmentBooked": { "type": "boolean", "description": "Whether a date was agreed" },
    "appointmentDate": { "type": "string", "description": "The agreed date, ISO 8601" },
    "sentiment": { "type": "string", "enum": ["positive", "neutral", "negative"] }
  }
}

Where results go

Results are stored on the call or chat record alongside the transcript and recording, and come back through the API and in webhooks — no transcript parsing on your side.

The same structured outputs run on transcription jobs, so audio recorded outside Kilevel produces results in exactly the same shape as a call.

Numeric and yes/no results also become columns, averages and trends on the Performance page, with no extra configuration.

Metric packs

A metric pack is a ready-made structured output, written and locked so a metric means the same thing in January and in September and on every agent. Twelve of them ship — a core conversation-quality pack plus sector packs for sales, support, collections, healthcare, insurance, financial advice, technical support, booking, retention and two coaching reads. They behave exactly like an output you wrote yourself.

New transcription jobs start with the core pack attached. See Analysis and metric packs.

Written reasons

Judgement fields — scores, yes/no answers and classifications — can each carry a short written reason citing what was actually said. The model works the reason out before committing to the answer, so the answers themselves come out better, not merely more explainable.

Reasons are generated from the field names as they stand when the conversation is analysed and are returned as <field>_reason beside each value. Long-form fields are left alone, because they already explain themselves.

Managing them from the API

Structured outputs can be created, updated and deleted over the API — see Structured outputs.

Tip

Describe each field as you would to a colleague reading the transcript: what counts as "yes", which date format you want, what to return when the caller never said.