Connect by JBRH Open Connect

Call transcripts

A transcript is the sequence of turns on a call — what the caller said and what the voice said — assembled as the conversation happens rather than reconstructed afterwards. The latency shown against a reply is measured on the wire, from the caller's last word to the first audio back, not from the gap between two transcript rows. It is not a recording of the audio.

Status
Available What this means
Audience
both
Channels
phone
In the app
#/calls
Last verified
Product version
6.3.2

How it is assembled#

Each sentence in either direction becomes a turn as it completes. On the realtime path the worker posts every sentence the voice speaks to /api/voice/engine/spoken, where the guardrails are re-checked after the fact, and posts events separately. On the turn-based path the carrier's transcription of a caller's sentence arrives as the webhook that prompts the reply. Either way the turn list grows during the call, so a colleague watching a live call is reading the same rows a reviewer reads afterwards.

Some things deliberately never enter the turn list. Supervisor guidance is the clearest example: an instruction from a colleague goes into the system prompt and nowhere else — not into the spoken reply, not into the transcript, not onto the wire. If guidance appeared as a turn, anybody reading the transcript later would believe it had been said aloud.

The number beside a reply#

The first real call reviewed on the realtime path showed "8 ms" beside replies the caller had visibly waited seconds for. Nothing was broken about the measurement except its source: a transcript row is written when a sentence is *complete*, so the gap between two rows measures how quickly text was finalised, not how long a human sat in silence.

Latency is now taken on the wire. The worker's TurnClock starts when the caller's user state leaves speaking — their last word — and stops when the agent state enters speaking — the first audio back. Each reply posts a turn_timing event carrying that measurement, and a separate barge_in event records how long the voice kept talking after the caller spoke over it.

turn_timing
One per reply: caller's last word to first audio back. This is the number a review judges.
barge_in
How long the voice continued after the caller interrupted. Past two seconds counts as ignored, and is reported as a finding.
eou
End-of-utterance events from the host turn-detection path, where the endpointing is done in-process rather than by the model.
entity_heard / entity_readback
A phone number, email address or code heard in the caller's own words, and whether the next two lines confirmed it.
language_steer
Written only when a reply came back in a script the caller has not used. A pinned language is never steered, and a Hinglish line is not a switch unless the contact's city or state had already made that language likely, where a few words of it are enough.

What a transcript is not#

  1. It is not audio. Call recording is foundation and is not enabled on the live carrier, so there is no file behind the text. If a dispute needs the recording, it does not exist.
  2. It is not a perfect rendering of speech. Transcription is a model's best reading of a noisy line. A Telugu reply transcribed in Latin letters is still Telugu — the layer marks it romanised_script rather than treating it as a language switch — and a single garbled line does not undo an established language.
  3. It is not the timing record. The turn list says what was said and in which order; the events say when, and they are the ones a quality review reads.

One consequence is worth stating plainly: a mumble is not reliably distinguishable from a word. The model writes an unclear noise as a word in some language and answers it. That behaviour is measured — is_murmur, murmur_reactions and murmurs_accepted exist precisely to count it — and it was not fixable with prompt wording, so it is documented rather than papered over.

Reading one usefully#

  1. Read the caller's lines first, ignoring the replies.

    Result You see what the person actually wanted, without the voice's framing of it.

  2. Look at the turn_timing values rather than the visual gaps.

    Result Anything past four seconds is a slow reply by the review's own threshold; 2.5 seconds is the target.

  3. Check any entity_readback for confirmed.

    Result A number or address that was heard but never confirmed is the most likely thing in the call to be wrong.

  4. Check for promised_unbooked.

    Result That finding means the voice made a commitment with nothing scheduled behind it, and somebody needs to keep it manually.

Questions#

Why does the transcript show a reply the caller says they never heard?

Most often because they interrupted it. The turn records what the voice produced; the barge_in event records that the caller spoke over it and how long it continued. Past two seconds, the interruption counts as ignored — the caller experienced being talked over, and the review says so.

Can I search transcripts across calls?

Yes, through the same screens and the #/data grid that hold the calls themselves. This is the practical argument for text over audio: a transcript is searchable, quotable and comparable across a month of calls in a way a folder of recordings never is.

Does the transcript include the greeting?

The greeting is spoken from pre-synthesised audio during the ring, so it is the one line the voice says without generating it in session. The call record carries the greeting event, including whether the warmed copy was used or it had to be synthesised live.