One call, every layer: reconstructing a Genesys Cloud conversation end to end

It is 08:55 and the complaints team has forwarded an email: Mrs Smith says she was on hold for nine minutes, transferred twice and cut off. The ticket holds one thing of value – a conversation ID. The supervisor needs to know, before the 09:30 stand-up, whether the IVR sent her to the right queue, who answered, how long each hold lasted, and whether the line quality dropped. Those questions have answers in Genesys Cloud CX, but they are spread across several views and several APIs.

This is the question Conversation Analyser exists to answer: what exactly happened on this one call? Paste a conversation ID, press Analyse, and a few seconds later the tool renders a forensic report – a caller and agent swim-lane, a plain-English timeline, timings and counters, per-leg audio-quality scoring, the custom participant data your flows attached and, on demand, a step-by-step replay of every Architect flow the call traversed, with click-to-play prompt audio. GUIDs become names, and the raw record stays one click away.

To reconstruct a conversation you have to respect how Genesys models it. The analytics conversation detail record, served for a single conversation by GET /api/v2/analytics/conversations/{conversationId}/details, starts with the conversation itself: its ID, start and end, originating direction and divisions. Under it sit the participants – the customer or external party, the IVR, the ACD and each agent – identified by purpose. Each participant has sessions, one per media leg, and each session is sliced into typed segments: ivr, queue, alert, interact, hold, wrapup and more. Sessions also carry metrics, the t-prefixed durations and n-prefixed counts such as tTalk, tHeld, tAcw and nTransferred.

That nesting is the record's great strength and the reason it is hard to read raw. A call with a blind transfer and one hold can easily produce a dozen sessions across five participants, each with its own segment list on its own clock. A supervisor does not want to scroll through nested JSON; they want one picture. So the app's server walks the whole structure and lays every segment of every participant on a shared time axis, one lane per participant, customer first, then IVR, ACD and agents.

Around that authoritative record the app gathers four more sources: the live conversation object for recording flags, display names and participant attributes; the users, queues, wrap-up codes, flows, divisions and skills endpoints for names; the flow instances APIs for execution traces; and the Architect prompts API for audio. The figure below shows how they converge on the single report.

Genesys Cloud CX already gives supervisors a capable place to start. The interaction details page, opened from the Interactions view and related views, is the central location for an interaction: an interaction overview, plus tabs for details, the timeline, quality summary, transcripts, audit trail and customer journeys. The timeline tab shows each part of the interaction as a separate segment that you can click for its duration, drag across and zoom. Quality managers can expand a Participant Data section on the Details tab, and the Interactions view can be filtered by MOS range.

Architect, meanwhile, offers its own flow execution history and a Replay Mode for debugging once historical execution data storage is enabled. We use all of these every week. What Conversation Analyser does differently is assemble them into one read-only, shareable report for a single conversation: the swim-lane and narrative timeline, participant data per participant, the flow replay ordered by execution, prompt playback and audio-quality ratings sit on one page, with the complete payload downloadable as JSON for a ticket or a root-cause document.

The report is built from two Genesys views of the same interaction, and the engineering choice that matters is which one is allowed to fail. The analytics detail record is the authoritative source, retained for months; if it is missing there is nothing to analyse and the request fails clearly. The live conversation object, GET /api/v2/conversations/{conversationId}, is a best-effort extra, retained far more briefly. If it has aged out, its error is carried through as a badge in the raw data panel and every analytics-based card still renders.

Name resolution follows the same pragmatic philosophy. The server collects every user, queue, wrap-up, flow, division and skill ID it finds, resolves them against the matching Genesys endpoints through a bounded pool of eight concurrent lookups, and caches the results. Two free enrichment passes fill the gaps: a flow that transferred directly to a user carries that user's name in its transfer target, and the live object names its participants. Anywhere no name is found, the raw GUID is shown, so the tool stays fully usable with nothing more than the analytics:readonly scope.

Security is designed in rather than bolted on. Operators sign in with an OAuth client-credentials grant attached to a read-only role; the credentials and bearer token stay on the server and the browser never holds a Genesys token. Every Genesys call is a read – the only POSTs are the flow-instance query and the download-job creation, which create no org data. There is no database: conversation payloads are fetched live per request and never retained.

Most disputes about a call are really disputes about the IVR. What did the caller press? Did the data action fail? Which queue did the flow transfer to? Press Load flow replay and the server runs a four-step pipeline against Architect's Historical Flow Execution Data: query the flow instances for the conversation ID, start a download-preparation job, poll the job every 800 milliseconds for up to 30 tries, then fetch the step traces from their short-lived download links. Each flow the call passed through – a main IVR, then an in-queue flow – becomes its own card, earliest first.

Each card is a flowchart of the steps the call actually executed: audio, menus, decisions, data-table lookups, set-data actions, called tasks and the transfer, each with its clock time, dwell and the branch taken – Found, Not found, Timeout or the digit pressed. Prompts and DTMF always come from the real execution trace, never from static flow configuration. Steps that played a prerecorded user prompt show a chip; click it and the app resolves the prompt from the Architect prompt library and plays the recording in the browser, one player per language.

The honest limits are part of the design. Flow replay only works where historical execution data was being captured when the call ran, and only within the 10-day retention Genesys documents. Text-to-speech lines have no recording, so the trace shows their spoken text instead, and Genesys system prompts such as hold music are not in the user-prompt library. The app explains each of these cases in place, and the rest of the report is unaffected.

When the complaint is that the line was poor, the question is always which leg. Conversation Analyser reads the media-endpoint stats on every voice session in the detail record and shows, per participant and media window, the MOS, R-factor, maximum latency and packet loss, each with a rating pill and meter. The thresholds are fixed and printed under the card: a MOS of 4.3 or above is excellent, 4.0 good, 3.6 fair, 3.1 poor and anything lower bad; latency of 150 ms or less is good and anything above 500 ms bad.

Packet loss is calculated as invalid plus discarded packets over the total received, invalid and discarded, and rated from 0.5 per cent or less as good to above 3 per cent as bad. The reading guide is practical: bad MOS with high loss on the customer leg points at the caller's network, while the same on the agent leg points inside your own estate. Chat, email and callback legs carry no RTP stats and show a dash, while voice legs of the same conversation still score.

Conversation Analyser went through the same lifecycle as any client deliverable. Requirements came from real investigations our support engineers run; the design separates the authoritative and best-effort sources so that partial permissions or aged-out data degrade gracefully; and the build was peer reviewed against the Senior Platform Practice Lead's engineering standards. A bundled synthetic conversation – inbound call, IVR, queue, agent, hold, blind transfer and wrap-up with a deliberate mid-call quality dip – exercises every card, including a two-instance flow replay, so we can test without touching customer data.

The tool is part of the QVCCS App Suite included with every Managed Professional Services tier, and it pairs naturally with its bulk sibling: Conversation Detail exports every conversation over a date range, so you find the interesting conversation there and dissect it here. Behind both stands a multidisciplinary squad from our own bench – solution architects, senior developers, IT systems, telecoms and SIP engineers and support engineers – who use the same report when they take on an escalation for you.