Analysis and metric packs

Once a recording is transcribed, the job runs its analysis outputs over the transcript. These are ordinary structured outputs: a named schema, filled in per recording, stored beside the transcript.

Three kinds end up in the same list:

• Metric packs — ready-made and locked, so a metric means the same thing in January and in September and on every agent.
• Outputs from your catalog — the ones you already use on flows. Editing one changes it everywhere it is attached.
• Outputs written here — belong to this job alone.

What a new job starts with

Every new job opens with the Conversation Quality Core pack and the system output already attached. A job created without opening this section still produces comparable numbers rather than transcripts alone, and a first-time account gets something on the Performance page without having to know which pack to pick.

Both are ordinary rows in the list: visible, and removable before the job starts. A default you cannot see or undo would be a setting, not a default.

Leave the list empty for transcripts only.

Metric packs

A pack behaves exactly like an output you write yourself — it is simply already written, and locked so its meaning does not drift. Each pack writes into its own named output, so its fields never collide with yours.

The intended shape is the core pack plus one sector pack. Each pack is a separate schema in every analysis request, so three or more makes a large request and some providers cap schema size. The form shows the field count per recording as you select them, and warns if one of your own outputs is named the same as a selected pack — they would land in the same place and overwrite each other.

In the collections, healthcare and financial packs several items are worded so that true is the bad outcome. That is deliberate: a breach must never read as a high score.

Call script and Script Adherence

The Script Adherence pack measures each conversation against the call script the agents had to follow: overall and context-weighted adherence, required points, steps, questions and critical points covered, mandatory statements delivered and prohibited ones avoided, opening and closing, order, branches and if-then logic, information accuracy and verification, objection, scenario and escalation handling, deviation severity and rate, recovery after a deviation, and how naturally the script was used. Scores and percentages run 0–100; the nine problem rates are lower-is-better, and a metric the conversation gave nothing to measure is left empty rather than guessed.

It only runs against a script:

• Choose Call script the agents followed on the job — at creation, or later in the job's settings under the outputs. The pack cannot be ticked until a script is chosen.
• Each recording then gets a second analysis round of its own, containing only the script metrics, with the script's current version in the context. That is one more model call per recording.
• Without a script the pack is never evaluated, even if it is attached — it is never scored against nothing.
• Changing the script on a running job can re-analyse what is already there, exactly like changing its outputs.

Human call campaigns can carry scripts too — one for every stage, or one per stage — and measure each call against the script for the stage it was made in. The Script Adherence scorecard preset turns the pack into one weighted score.

Explain every judgement

On by default and recommended. Each score, yes/no and classification also gets 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. It costs more per recording, and long-form fields are left alone because they already explain themselves.

The reasons are stored beside the values, so a number on the Performance page can always be traced back to the sentence that produced it. Reasons are generated from the field names as they are at the time of analysis, so renaming a field in a copy of a pack keeps its reason.

Analysis context

One line describing what these conversations are — "inbound technical support, German market", "outbound debt collection". It is given to the model with every transcript.

It is also the single most useful thing you can fill in for role detection, because the cues invert: in inbound support the customer asks the questions, in outbound sales or collections the agent does.

Which speaker is the agent

Diarization says "Speaker 1" and "Speaker 2" — first voice heard, and the other one. Neither carries identity, and every agent-specific metric depends on getting this right. Four signals are tried in order, and whichever answered is recorded on the recording, so you can always tell a channel split from a guess:

A direction (inbound, outbound, internal) can be set as a job default and is used both as a filter and as a hint here. A direction supplied per recording always wins over it.

Measured metrics

Five metrics come from the utterance timings rather than from a model, so they exist for every recording with speakers separated, whatever analysis you attached:

They are kept visibly apart from model output on the Performance page. "Share of talk time" is a fact; "empathy" is a judgement, and a reader deciding how much to trust a column needs to tell those apart at a glance. The first two need the job to know which speaker is the agent.

Redaction

Removes personal data from the transcript before it is stored and before it is sent to the analysis model: email addresses, phone numbers, IBANs, card numbers, and the agent and customer names and numbers you supplied through enrichment (matched exactly — the reliable half, and the one that stops a transcript naming somebody your reports show as a pseudonym).

Each recording stores a count of what was removed, never the values themselves, so you can confirm it ran.