Review a conversation and its result

Use this task after an approved test or when investigating an unexpected interaction. Find the correct conversation, compare its actual behavior with the expected result, and collect the identifiers needed for follow-up. Opening a record or seeing a recording indicator alone does not establish that the interaction succeeded.

Availability and preparation

The Conversations list and full detail page require an eligible account in the selected team: Team Members and Team Admins, or a platform administrator. These pages use a stricter UI permission than some other read-only surfaces; a Team Viewer or platform Superviewer should not assume that broader read access opens this screen. If access is denied, ask the team administrator for an authorized review. A shared detail URL does not grant access to its data.

The evidence available depends on what the runtime recorded. Audio requires a retained, processed full-call audio output and accessible recording storage. Debug data depends on the observability connection, captured telemetry and retention. QA and Actions tabs appear only when the conversation contains their corresponding data. A missing tab is not, by itself, a failed call or an instruction to enable a module.

Have the application/team, approximate test time, intended endpoint and expected response ready. If the test provides a conversation link or call ID, keep it. For a flow change, also record the version you intended to publish using Change an application and verify its published flow.

1. Find the right conversation

1. Open Conversations and select the application in the app selector.
2. Choose the call matching your test time. The list is newest first and loads more entries as you scroll. Use the caller, duration and available status information as supporting clues; caller data may be absent or redacted.
3. Open the record and verify its header and Overview identifiers. Match the call ID to the test result when one is available. Do not select a neighboring call merely because its time looks similar.

Changing the app selection clears the selected conversation. The list URL can retain the application and selected record; the detail's maximize control opens /conversations/<conversation-id> for an authorized colleague. Previous/next controls help compare calls, but recheck the record after navigating.

The app selector filters the call list. Search and event filters within a detail tab filter that conversation's evidence; they do not search all calls in every application.

2. Start with Overview, then follow the evidence

Overview is the initial tab. Read the summary if present, check the interaction counts and error count, and note the call ID, trace ID and flow information. Treat a generated summary as a starting point and verify the relevant events yourself. Flow information helps correlation; it does not independently prove that every runtime component used the intended published configuration.

Tab or view	Use it to answer	Limit to keep in mind
Timeline	What was said, which nodes were entered, and which transitions, actions, keypad events or errors were recorded?	It is assembled from recorded conversation data and selected system events, not a complete network trace or an audio transcript guarantee.
Flow run	Which node visits and transitions were recorded, and where was time spent?	It uses node history; a missing history does not prove no execution occurred.
Tokens	What model/token and speech usage was recorded for the interaction?	Missing usage is not proof of zero consumption; use the recorded data for this call rather than treating it as a provider invoice.
Actions, when present	Which recorded actions were invoked and what results/details are available?	Only appears when action events exist. It is not a list of every tool that could have been called.
QA, when present	What score and evaluation details were stored?	Only appears when score or score details exist. Absence does not establish that the call failed.
Debug → Logs / Span tree / SIP ladder	What runtime, trace or signaling evidence helps explain the result?	Availability, capture and retention differ from the persisted conversation and recording data.

3. Inspect the interaction and errors

In Timeline, use Search for a distinctive word or event and use the event-kind checkboxes to narrow the view. Clear the search and restore relevant kinds before concluding an event is missing. Node exit events are hidden initially; enable them when investigating how a node ended.

Compare the recorded user input, response and next step with the expected result. If the flow made a wrong transition or stopped unexpectedly, use Flow run to inspect the associated node visits, timings and transition target. Examine recorded errors near that point. A displayed transcript may be incomplete or redacted; do not interpret a redacted value as the user's actual words.

For more detail, open Debug → Logs. Its search and filters apply to the loaded log rows. Open a row to inspect its details; check surrounding runtime events rather than treating an isolated error message as a full explanation. SIP capture rows are separately controlled by Show SIP captures. For trace correlation, retention and sensitive-data handling, use Logs and diagnostics.

For a telephone routing, hangup or signaling problem, continue with SIP diagnostics, using the call/trace identifiers and time. A missing SIP ladder for a browser-text interaction is not evidence of failure.

Review a QA result

Open QA when the conversation has a stored score or score details. The tab is data-dependent: a missing tab does not prove scoring is disabled, that a job failed or that the call was unsuccessful. Access to the conversation follows the account/team requirements at the start of this guide; seeing an aggregate widget does not grant access to the underlying conversation.

1. Read Overall alongside the summary and the four dimensions: Task completion, Communication quality, Efficiency and Error handling. Expand your investigation into Timeline/Flow run rather than accepting the generated explanation without evidence.
2. Read Caller satisfaction separately. This score is normalized to an integer from 0 to 10 by the scoring worker; it is not the same scale as the overall/dimension scores. A displayed hard-failure label identifies the scorer's reported issue, not an independently verified network diagnosis.
3. Compare Highlights and Improvements with the actual interaction and your intended outcome. Missing reasoning, lists or score fields can mean incomplete retained evaluation data; an em dash is not a zero score.
4. Use the raw JSON view when an authorized investigator needs the stored qaStatus, qaScore and details. Copy JSON copies that data to the clipboard; it can contain conversation-derived information. Share only the necessary redacted evidence. The view switch is a presentation preference, not an edit or a scoring action.

The overall/dimension display uses green at 80 or above, amber at 60–79 and red below 60, with no score shown as neutral. These are UI thresholds, not service guarantees. The worker checks for an overall numeric score and the expected top-level result shape, but does not clamp every overall/dimension score to 0–100; investigate an implausible value instead of treating its color as validation.

If an opened QA tab reports pending, failed or no details, note the state and ask the operator to inspect the scoring job and prerequisites. The worker can skip records without a transcript or without permitted platform/team/app/plan scoring. An already completed record is skipped by the normal scoring handler; reopening this tab does not request a re-score. This detail view has no manual score-edit or re-score button. Use Background jobs for operator diagnosis and QA configuration for future scoring behavior.

When comparing against the dashboard, remember that its caller-satisfaction average excludes hard failures and omits some apps without an eligible average sample. Keep the individual result, sample/exclusion rules and observed application outcome separate.

4. Check retained audio separately

When full-call audio is available, use the header's recording controls to select and play the retained recording. Compare what you hear with the event sequence; text events alone do not prove audible output reached the caller.

Recording state or symptom	Interpretation and next step
PROCESSING	Upload or processing is pending. The detail refreshes while this status remains; if it persists, ask the operator to investigate.
AVAILABLE but no playable audio	Check which outputs were selected and whether the audio lookup succeeds. A transcript-only recording has no full-call audio player.
FAILED	Investigate recording processing/storage; this status alone does not describe whether the conversation itself succeeded.
No recording section	Do not infer that the call did not happen. Capture selection, frequency, available artifacts and storage access can differ.

The Timeline text and a retained transcript object are separate evidence sources. Changing logging redaction does not necessarily change recording retention. See Choose what a call recording retains for future capture choices and Recording diagnostics for a missing artifact.

Do not use Delete recordings as a diagnostic step: it is a destructive action, not a refresh control. Review does not require changing recording or privacy settings.

5. Resolve a missing result and finish the review

If the result is missing or incomplete, distinguish these cases before repeating the test:

• No conversation found: confirm the team, app, endpoint and test time. A just-ended test may still be waiting for its conversation record. Reopen the result after processing; if it remains absent, give the operator the call ID and time rather than assuming an unrelated row is the result.
• Detail cannot be loaded: the record may be unavailable or outside your access. Ask an authorized team member to check the ID; a URL is not an access credential.
• Empty Timeline or Flow run: clear local filters and check which data was retained. Ask the operator to correlate the call with runtime evidence if the expected events are still missing.
• Empty or unavailable Debug: inspect the configuration/retention message and involve the observability operator. The persisted conversation can outlive its searchable telemetry.
• Wrong behavior after a flow change: confirm the endpoint, publication and runtime synchronization before changing the flow again. Use the application change procedure for deliberate recovery.

Record the outcome, conversation URL/ID, call and trace IDs when present, time, endpoint, expected versus actual behavior, and the relevant error. Share only necessary evidence through an authorized channel; raw logs, transcripts and signaling can contain sensitive data.

The review is complete when you can identify the tested interaction and support its outcome with the available evidence—or state precisely which evidence is missing and who must investigate it. A visible success indicator does not replace that comparison.