IVR Sankey: every call through your Genesys Cloud IVR, on one map

A contact centre manager opens the weekly review with a deceptively simple question: of everyone who rang the main number last month, how many were helped by the IVR, how many reached an agent, how many gave up, and where? The IVR owner knows the flow inside out, yet the honest answer usually starts with a caveat. Some of the data lives in queue reports, some in flow outcomes, some in the participant data the flow writes, and none of it sits on one picture of the whole population.

The follow-up question is the one that matters. Callers whose number did not match an account seem to end up with an agent far more often. Is that true, by how much, and what did those callers hear before they pressed zero? Answering it means joining the journey to the attributes the flow wrote on each call. That is what IVR Sankey does: one flow, every call in the window, drawn as a single journey map that can be split, filtered and explained.

Genesys Cloud already gives flow authors a journey picture. Journey flows open from the Insights and Optimizations menu of an Architect bot, digital bot, inbound call, outbound call, secure call, inbound message or inbound email flow. Nodes are the flow's milestones and outcomes, from a start node to terminal nodes such as agent escalation, disconnect or resolution; node size and connector width follow how many customers passed through. Click a node to drill into the paths through it, or filter by exit reason, such as Abandoned.

Genesys is clear about the design intent. Journey flows cover a single Architect flow and cannot visualise journeys across multiple flows. They use up to seven days of data, recalculated overnight. Their counts are directional, meant to support the qualitative reading of the journey rather than exact measurement, and busy flows may be limited to the most frequent paths. For analysis beyond that, Genesys points to Journey Management. Architect's Flow Insights overlay adds a quick frequency view of which actions, menus and tasks ran most often over up to seven days.

We use both regularly, and they are the right first look. What clients kept asking us for sat just beyond them: exact counts over a window of their choosing, the journey across the bots and in-queue flows a call passes through, the menus and data action results that were never instrumented as milestones, and above all the participant data that explains why one cohort of callers fares worse than another.

No single Genesys API holds the whole story, so IVR Sankey combines three, each used for what it does best. The macro layer comes from the analytics conversation detail jobs API, which covers every call in the window: each conversation's participants, sessions and segments are walked in order into a cross-flow path from Start through flows, bots and transfers to the queue outcome, and because job results carry participant attributes, the complete raw participant-data map of every call arrives in the same records at no extra cost.

The granular layer comes from flow execution traces, fetched through the flow instances API for a capped sample of calls you choose, from 50 to 20,000. Traces add what only the trace knows: the menu choices, the prompts callers actually heard, data action and data table results, outcomes and milestones as steps. They also teach the macro map where to place data and prompt nodes, with a placement-fidelity badge that says how faithfully that order holds for this flow. The attainment layer comes from the flow aggregates API: full-population success and failure for every Architect flow outcome, resolved to the names the engineer gave them.

Conversation data does not change after the call, so IVR Sankey stores each conversation once per flow and layer, not once per run. A run is just a window over the warehouse, and its map, figures and insights are rebuilt on read. When you ask for a window, the app compares it with the flow's coverage, a gap-aware set of intervals rather than a single range, and fetches only the uncovered time, plus a short re-scan at the latest boundary to catch stragglers.

Per gap, it submits an asynchronous conversation detail job filtered to the flow, polls until Genesys has compiled it, and pages through the results by cursor, up to 50,000 conversations per run. Traces download in batches of up to 20 ids, halving the batch automatically when Genesys rejects it, and save incrementally so an abort keeps every finished batch. Calls known to have no trace are remembered and never fetched again. A coverage calendar under the date picker shades days already held, with per-day volumes, so analysts can see what is cached before they press Build.

This matters because of retention. Genesys keeps flow execution data for 10 days, while the analytics records behind the macro layer last far longer. Harvest recent windows and the warehouse becomes the durable copy of the granular detail. Progress streams live and survives navigating away. The Genesys client is read-only by construction: GET-only, with an allowlist of the handful of analytics and trace query submissions it needs, rate-limited per session and retrying once on an expired token.

Real IVR journeys are cyclic: callers loop back through menus, and every bot converges on the same transfer. A strict Sankey or funnel cannot draw that without dropping edges, so the map is rendered as a layered directed graph, which draws loops faithfully, and scrolls and zooms in the browser. Each node shows the distinct callers whose path includes that step and their share of all callers; each edge shows the split relative to its source. Only terminal nodes add up to 100 per cent, because intermediate steps are pass-throughs, not funnel slices.

Edges under about half a per cent are pruned for readability, but every node keeps its top two outgoing edges and its top inbound edge, so no real step ever looks like a false dead end. Layers toggle without re-harvesting: menus, prompts, data actions and outcomes. A Data actions picker lists every data action, data table lookup and decision table the traced calls ran, with the split of result paths each took, and the chosen set lives in the page link so the view can be shared.

Explanation is one click away. The Disconnect node opens a breakdown of where callers hung up: true in-IVR hang-ups versus calls already in queue, and for IVR hang-ups the last node, the last prompt heard and the last lookup result. A prompt node plays its recorded audio per language from the Architect prompt library. Hovering a switch shows each case's readable condition from the flow design. And any real call can be replayed step by step in the per-call journey view.

Participant data is where a flow records what it learnt: whether the caller's number matched an account, the customer segment, the transfer reason. IVR Sankey captures the complete end-of-call attribute map for every call and builds a catalogue of every key, with its coverage, an inferred class (boolean, enum or high-cardinality text) and value buckets, always including a not-set bucket so incomplete attributes confess their coverage. Which attributes become diagram nodes is decided by value shape and cardinality alone, never by attribute names, because every client's flows are bespoke.

Expand a key and a per-bucket outcome table appears: calls, transferred, contained, abandoned in queue and handled by agent, side by side. Split builds the attribute into the map as a stage straight after Start, and splits stack in the order you pick them. Filter re-renders the whole map for one cohort, for its exact end-to-end pathing. Splits and filters live in the page link, so a lensed view is shareable and the Insights area can deep-link straight into a cohort.

The Insights area turns the harvested run into analysis without a single extra Genesys call. Findings scores every eligible participant-data value by how far it moves the escalation rate, meaning calls that left self-service for an agent, a queue abandon or a transfer, ranks them by lift weighted by cohort size, collapses duplicate key spellings and near-identical cohorts, and links each card to the cohort on the map. It adds outcomes that succeed 45 per cent of the time or less, the hour whose queue-abandon rate most exceeds the average, and data-quality flags such as one concept written under two spellings.

Alongside sit the outcome attainment board, full population from the flow aggregates API; a self-service funnel of up to ten stages defined once per flow over participant data, saved and reused on every future harvest; a pivot builder; and a milestone funnel from the trace sample. For the review meeting there is a one-page diagram PDF exactly as toggled and lensed, a KPI summary PDF that states the true first-to-last call span analysed, and an opt-in AI analyst narrative generated only from aggregate metrics, never per-call data.

IVR Sankey is the population view in a family of QVCCS flow tools. Journey Analyser builds Journey Management-style funnels with branches over the same kind of execution traces when you know the path you want to measure. Flow Journey replays one conversation through every flow it touched. Flow Mapper shows the flow as designed and audits its configuration. Start with the map to find the surprise, measure it with a funnel, and explain it with a single call.

We built it the way we build client solutions. A Business Analyst turned recurring review questions into acceptance criteria; the Solution Architect chose the three-layer model and the rule that diagram data is shape-filtered rather than tuned to any one organisation; Senior Developers implemented the warehouse and renderer under the Senior Platform Practice Lead's standards with peer review; and our testers worked through the failure paths, including expired traces, partially covered windows and runs orphaned by a restart. IVR Sankey is part of the QVCCS App Suite, included with every Managed Professional Services tier.