IVR Sankey

1What it is

Genesys Cloud’s built-in “Journey Flows” view is shallow: it samples, drops low-volume edges, can’t explain why callers left, and forgets everything when you close it. IVR Sankey harvests one flow’s conversations into a private warehouse and renders the whole population’s journey — with the forensic detail the native view can’t give you:

• Full population, not a sample — the journey backbone is built from analytics conversation records: every call in the window, real volumes, real dispositions (transferred to queue / handled by agent / abandoned in queue / transferred elsewhere / self-served / IVR hang-up).
• Deep detail where it matters — a capped sample of flow-execution traces adds the within-flow story: menu choices, the prompts callers actually heard, data-action hit/miss results, the last thing heard before hanging up.
• Outcome attainment — full-population success/failure per Architect flow outcome from the flow-aggregates API, annotated onto the map and boarded in Insights.
• A participant-data lens — the complete raw attribute map is captured for every call; split the diagram by any attribute (stackable), filter to any cohort, and read per-bucket outcome correlations.
• An Insights area — auto-ranked findings (“which attribute values move the escalation rate”), the outcome board, a saved per-flow self-service funnel, a pivot builder and a milestone funnel — all computed from data already harvested.
• Explainability — click the Disconnect node for the hang-up breakdown, click a prompt to play its audio per language, hover a Switch for the Architect conditions behind the branch, drill into any real call’s step-by-step journey.
• Reporting — a one-page PDF of the diagram exactly as toggled, a branded KPI summary PDF, and an opt-in AI-written analyst narrative (aggregate metrics only).

The three data layers

2Quick start

1. Sign in — region + OAuth client-credentials Client ID/Secret. Tokens are exchanged on the server and never reach the browser; see §9 for the permissions the client needs.
2. Pick a flow — the launcher lists the org’s inbound / in-queue / secure-call / bot / digital-bot flows with a name filter.
3. Set the window — explicit From/To UTC pickers (default: the last 7 days, maximum 31 days per run, end clamped to now). The coverage calendar under the picker shades days already in the warehouse (green = fully cached, amber = partial) with per-day volumes — click one day, then another, to select a range.
4. Set the trace cap — “Max traces” bounds the granular sample (50–20,000, default 1,200). The full population is always mapped regardless.
5. Build journey map — progress streams live (enumeration → macro extraction → trace downloads with cached/new counts → attainment). You can navigate away and come back; Abort stops cleanly and keeps everything already saved.
6. Explore — the run lands on the journey map. Toggle layers, hover edges, click the Disconnect node, open Participant data to split/filter, open Summary for KPIs, or press the green Insights button for the analysis area.

No credentials to hand? The demo works signed out on a deterministic synthetic corpus (~200 conversations through “Main Contact Centre IVR”): the demo map, demo Insights and demo single-call journey exercise the whole feature set — layer toggles, the lens, every Insights tab, both PDFs and a canned narrative — with zero Genesys calls.

3Harvesting & the warehouse

How a harvest runs

1. Enumerate only the gaps. The requested window is compared against the flow’s coverage intervals (a gap-aware set, not a single range); only uncovered time is fetched, plus a 6-hour recency re-scan of the latest covered boundary for stragglers. Per gap the app submits an asynchronous analytics details job filtered to the flow, polls until Genesys compiles it, then cursor-pages the results (up to 50,000 conversations per run).
2. Macro extraction. Each conversation’s sessions are sorted chronologically and walked into a cross-flow path: Start → Flow → Bot → … → Transfer to ACD → Handled by Agent / Abandoned in Queue, or a Disconnect/exit terminal. Queue outcome comes from the same record’s session metrics; caller-choice attributes (language, menu choices, transfer reason/location, dialled number, generic data-action results) and the full raw participant-data map are captured alongside.
3. Granular traces. Up to cap conversations get their flow-execution trace downloaded (batched ≤20 ids with automatic halving on a 422) and distilled into a step path — menus, prompts, data actions, outcomes, milestones. Conversations already traced (checked all-time, not per window) or known to have no trace are skipped; traces save incrementally in batches of 50, so an abort keeps progress.
4. Attainment. One flow-aggregates query stores full-population outcome success/failure on the run, with outcome ids resolved to their Architect names.

Progress is reported live and survives a reload — earlier progress replays when you reconnect, and if the job is no longer running the page reports its real final state instead of hanging. Runs interrupted by a service restart are marked failed rather than lingering as zombies.

The warehouse — harvest once, reuse forever

Conversations are stored once per (org, flow, conversation, layer) — not per run — because conversation data is immutable. A “run” is metadata pinning an (org, flow, UTC interval); its map, KPIs and Insights are rebuilt on read from the cached conversations inside that interval. Re-harvesting a covered window re-polls nothing and only fetches genuinely new calls; a miss record remembers “this conversation has no trace” so capture-disabled calls are never re-fetched.

• Re-fetch execution traces (launcher checkbox) — re-pulls and re-extracts traces that are already cached, for picking up extraction improvements. Safe by design: a successful re-fetch overwrites with the richer extraction; an expired trace keeps its cached data.
• Participant-data backfill — runs harvested before full-pdata capture (or before the longer attribute-value limits) can be refreshed in place: one click re-runs the analytics details job for the run’s window (a couple of API calls, no trace fetches) and updates the stored rows. See §5.

4The journey map

The map is rendered with Graphviz (left-to-right ranks) and shipped to the browser as SVG in a scroll + zoom container. This is deliberate: real IVR journeys are cyclic (callers loop back through menus, every bot converges on the same transfer node), and a strict Sankey/funnel cannot represent that without dropping edges or breaking conservation. A DOT flow graph draws cycles honestly — which is also exactly what the native Genesys journey view is underneath.

Reading the diagram

• Node label = reach. count (pct%) is the number of distinct callers whose path includes that step, as a share of all callers. Because journeys loop, intermediate node percentages do not sum to 100 — only the terminals do.
• Edge label = branch split. count (share%) where the share is relative to the source node’s total outgoing volume — a node’s labelled out-edges sum to ~100% (slightly less when sub-threshold branches are pruned). Edge width encodes absolute volume.
• Connectivity-preserving pruning. Edges under ~0.5% are pruned for readability, but every node always keeps its top two outgoing edges and its top inbound edge — no real step is ever a false dead-end.
• Colours — flows/transfers blue, bots purple, menus indigo, data-action results teal (note shape; failures red), prompts cyan, outcomes green/red hexagons, Handled by Agent green, Abandoned in Queue amber, Start slate.

The header shows journeys mapped, step and stage counts, how many immediate hang-ups are included, and the run’s harvested UTC window. Data-action and prompt nodes are placed into the macro spine at the position learnt from the trace sample (one interleaved precedence order across both), so the aggregate sequence mirrors the true caller sequence — the summary carries a placement-fidelity badge saying how faithfully that holds for this flow.

The Data actions picker

The Data actions button opens a panel listing every data action, lookup and decision table the traced calls executed: how many callers reached it, the split of result paths it took (Success / Failure / Timeout / Found / Not found …) as a bar and a table, its success percentage, and the flow it runs under. By default the diagram draws the most-run actions automatically (“Auto”); press Show on any action to draw it — or hide it — and the selection becomes explicit (“Show all” / “Show none” / back to “Auto”). The pick lives in the page URL, so a view with exactly the data actions you care about is shareable, just like a participant-data split. Each drawn action splits the flow at the point it ran, so the diagram itself shows what share of callers came through each result path.

Where the names come from. Architect blocks are often left with their default names (“Data action”, “Data table lookup”), which say nothing about what was called. The app therefore identifies each executed step from the flow design: the step’s tracking id is matched to the block in the flow’s published configuration, and that block’s integration action or data table is named from the org’s data-action catalogue. A block the engineer renamed keeps its name if nothing better is known. Because trace rows store the projected steps, calls traced before this identification existed still carry the default name — the panel offers re-trace this run, which re-fetches the run’s execution data and relabels every call Genesys still holds (execution traces expire after roughly a week; expired calls keep their current label).

Layers & toggles

Four independent toggles sit on the diagram (the flow/transfer/queue backbone always shows):

Toggling never re-harvests — the app re-renders from the warehouse and caches per run + toggle + lens combination. The zoom control extends the scrollable area, so you can pan the full drawing at any magnification; toggling a layer keeps your zoom.

Click-through & hover

• Hover any line — it highlights royal and a fixed panel shows origin → target with the call count and branch share (works on unlabelled sub-threshold edges too).
• Click the Disconnect node — “Where callers hung up”: the split between true in-IVR hang-ups and calls that had already reached the queue, and for IVR hang-ups the last node, last prompt heard and last lookup result before the drop (trace sample), alongside the full-population disposition for context.
• Click a prompt node — prerecorded prompts open a player with one audio lane per language, fetched live from the org’s Architect prompt library (presigned URLs play directly in the browser).
• Hover a “Switch N: …” node — a tooltip explains the decision: each case’s readable condition from the flow’s Architect design, which branch this population took, and what Default means. (Main flow only — switches inside subflows report “detail unavailable”.)
• Drill into a real call — the single-call journey view replays a single conversation step-by-step in the pictorial per-call renderer (containers per flow, prompts, DTMF with think-time, lookups, transfers).

5Participant-data lens

The harvest captures the complete raw participant-data map for every call — every attribute across all participants, merged, unfiltered and unredacted (a deliberate decision for this owner-scoped warehouse: name-based screening would silently discard exactly the lenses analysts ask for, like “ANI Match”). Values are end-of-call state from the analytics record; capture costs zero extra API calls because the async details job already carries the attributes. Defensive caps only: 150 keys per call, values clipped at 300 characters.

The catalogue panel

The Participant data button on the map opens the catalogue: every key with its coverage %, inferred class and value buckets, most useful keys first.

• Classes — boolean (every value normalises to True/False: true/yes/y/1 · false/no/n/0), enum (≤12 distinct values, one bucket each), or text/id (high-cardinality: the top 10 values + Other). Bucket labels clip at 40 characters; “(not set)” is always a bucket, so incomplete attributes confess their coverage.
• Expand a key — its bucket chips (click one to filter) and a per-bucket outcome table: calls, transferred %, contained %, abandoned-in-queue %, handled-by-agent %, average steps. This is where “ANI-match failures transfer at twice the rate” jumps out before you touch the diagram.
• Split — builds the attribute into the diagram as a stage straight after Start. Splits stack without limit, in pick order (Start → ANI Match → Caller Segment → …); the normal aggregation renders cohort counts and percentages, and failure-toned values read red.

Splits vs filters

A split shows all cohorts on one map — but cohorts re-merge at shared downstream nodes (the renderer deduplicates by label), so read the split stage for cohort sizes and the correlation table for outcome deltas. For a cohort’s exact end-to-end pathing, filter to one bucket instead: the whole map re-renders for just those calls. Full-population outcome annotations hide under a filter (they describe the whole run, not the subset).

Lens state lives in the page address — splits and filters (up to 12 each), and whether the panel is open — so every lensed view is shareable, and the Insights area links straight into cohorts this way. Active splits/filters show as a chip bar with per-chip ✕ and Clear all, and apply to the diagram PDF export too.

Backfilling older runs

Runs harvested before full-pdata capture show an amber banner with “Fetch it from Genesys”: one click re-runs the analytics details job over the run’s window in the background (poll-able status, no trace fetches, no new conversations) and updates the stored rows in place — both the raw pdata map and the caller-choice attributes (older harvests clipped attribute values at 40 characters; the backfill restores full-length values, healing truncated sentence-valued summaries). The lens, Insights and diagram caches invalidate automatically.

6The Insights area

The green Insights button on the map opens a dedicated analysis area (the demo version works signed out) focused on flow outcomes, milestones and participant data. Everything is computed from the run’s already-harvested data (zero new Genesys calls), memoised per run, and the active tab lives in the page address. The header shows the population KPIs: calls, to-agent %, transferred %, queue-abandon %, self-served %, and trace coverage.

Findings — auto-ranked, deep-linked

The landing tab scores every eligible participant-data value by how far it moves the escalation rate (calls leaving self-service: agent, queue abandon, or transfer) and ranks what it finds into cards:

• Key-lift findings — per enum/boolean bucket with ≥10 calls and ≥12 points of lift, scored |lift| × √n (“(not set)” cohorts down-weighted ×0.25). Duplicate key spellings are collapsed, and near-identical cohorts (≥85% overlap — e.g. everything a screen-pop writes on transfer) keep only the strongest finding.
• Outcome-attainment findings — outcomes succeeding ≤45% of the time with ≥15 attempts, from the full-population aggregates.
• Queue-abandon hour concentration — the hour whose abandon rate most exceeds the window average (likely staffing/volume mismatch).
• Data-quality flags — the same concept written under two spellings (Architect cleanup candidates) and keys ≥80% placeholder values.

Every key-lift card carries two deep links: View cohort in journey (opens the map with that cohort filter applied) and Pivot this key (jumps to the Participant-data tab with the key preset as rows). Below the cards: stacked traffic & disposition charts by hour (UTC) and by day, coloured by disposition, plus the data-quality panel.

Outcomes — the attainment board

One row per Architect flow outcome: attempts, a success/failure bar and the success % (colour-graded), all full population from the flow-aggregate API — no sampling. Flows that define no outcomes get an honest empty state. Where the trace sample’s outcome labels resolve to the aggregate names, rows are drillable per conversation; where they don’t, the board says so rather than pretending.

Funnel — defined once per flow, saved

An ordered self-service funnel evaluated full-population over participant data. Each stage is an independent predicate: up to 6 conditions (is set / = / ≠ / is one of) combined with match ALL or match ANY; up to 10 stages. Stage tiles show count, % of all calls and stage-to-stage conversion, and drops are annotated with the top values of a configurable leak reason key (e.g. Transfer Reason) among the dropped calls.

The definition is saved per flow (per org) and reused on every future harvest of that flow. First visit auto-drafts a scaffold from the catalogue (“All calls” plus a stage per verification-style boolean) — edit it in the built-in editor (catalogue-driven key pickers) and Save & recompute.

Participant data — catalogue + pivot builder

The full key catalogue as a searchable table (class, coverage, distinct count, top values) next to a pivot builder: any key as rows × disposition or any other key as columns (top 14 rows by volume, cells heat-shaded by row share). Click any row label to open that cohort in the journey map. The pivot can also take an outcome axis (success / failure / not reached for a named outcome) — trace-based, and annotated as such when coverage is partial.

Milestones — the ordered funnel

When the flow sets Architect milestones, this tab orders them by their median position in the call and shows reach bars, caller counts/percentages and the disposition split of reachers per milestone. Genesys cannot aggregate milestones (verified — the aggregate API rejects the dimension), so this is trace-based: with partial trace coverage it says so; at 100% coverage the counts are effectively full-population. Flows without milestones get an empty state that explains what adding them in Architect would unlock — they appear here on the next harvest with no app changes.

7Summary & PDF export

The Summary panel

The map’s Summary button opens the client summary for the run: the data-range line, KPI tiles (transferred to queue · handled by agent · abandoned in queue · transferred elsewhere · self-served · IVR hang-up), top terminals, successful outcomes and friction hotspots, the most common full paths, caller choices and data actions & lookups distributions, “Heard before abandoning” (the last prompts before IVR hang-ups), full-population outcome attainment, milestones where defined, and the placement-fidelity badge.

AI analyst narrative (opt-in)

The panel’s Generate AI analysis button sends the run’s aggregate metrics — KPIs, choice distributions, attainment, top paths; never per-call or caller data — to a large language model service configured by QVCCS and renders a structured analyst report (executive summary, key findings, strengths, review areas). Nothing is transmitted until you click; viewing a run never calls the API. The report is cached per run and can be regenerated on demand. Where the feature is not enabled it simply shows as unavailable, and everything else works.

Summary PDF

The summary PDF is a branded KPI one-pager. It opens with a “Summary date range” block — “For all data from the first call received at X to the last call received at Y (Zulu time / UTC)” — the true first→last call span of the analysed population (which can be narrower than the harvest window), ahead of the executive summary. The layout is adaptive: short categorical distributions flow two-up, while any dimension carrying sentence-length values (e.g. call summaries) switches to full width with wrapped labels, so nothing clips. The AI narrative is included only if it was already generated — the PDF never triggers an API call. The in-browser Export summary produces the same report through the print dialog.

Diagram PDF

Diagram PDF on the map exports the journey graph itself — a single page sized exactly to the drawing (no tiling, no shrink), with a branded header (flow name, volume, harvest date, active layers, any active splits/filters) and a colour legend. It honours whatever layer toggles and lens state you have on screen, and downloads as <flow>-journey.pdf.

8Reading the numbers

The disposition partition

Every call lands in exactly one of: transferred to queue (reached the ACD — splitting into handled by agent and abandoned in queue), transferred elsewhere (phone number / voicemail / direct), or contained (ended inside the IVR). The three sum to 100%. Containment further splits into self-served (reached a success outcome before disconnecting) vs IVR hang-up — a distinction only the outcome data can make.

All-callers basis

Percentages are of all callers, matching how Genesys presents Journey Flows. Immediate hang-ups (disconnect within the first steps, no engagement) are included in the population and in the Disconnect terminal, and reported separately as “immediate hang-ups” in the header.

Node % vs edge %

Two intentional bases: a node shows absolute population reach (distinct callers who hit the step); an edge shows the source-relative branch split. Only terminal nodes sum to ~100% — intermediate steps are pass-throughs, not funnel slices.

Full population vs trace sample

Journey backbone, menus, data actions, dispositions, outcome attainment, funnel and pivots are full population. Prompts, milestone reach, the hang-up forensics and the “where does each outcome fire” placement come from the granular sample — the UI labels these, and the Insights header shows trace coverage.

End-of-call state

Participant data is the attribute map as the conversation ended; a value overwritten mid-call contributes only its final state. Point-in-time splits are a possible future trace-based refinement.

Placement fidelity

The single interleaved order used to place data/prompt nodes into the macro spine is scored against the true per-trace sequences; the badge reports sequence fidelity and the retry-loop rate, and stays hidden when there is no trace sample to verify against.

Mixed-generation values

A run whose coverage spans the capture-length upgrade can hold the same attribute value in two spellings (a 40-character clip and the full sentence). Displays fold exact-prefix pairs automatically; the participant-data backfill normalises the stored rows.

9Genesys endpoints & permissions

OAuth client permissions: analytics:conversationDetail:view and analytics:flowAggregate:view (core), architect:flow:view (flow list + switch logic), architect:flowInstance:search/:view (traces), architect:flowOutcome:view (outcome names), architect:userPrompt:view (prompt player), directory:organization:view (org name). Missing scopes degrade the matching feature and surface a scope hint in the error — the harvest core needs only analytics + flow-instance access.

10Storage, privacy & security

• Warehouse — harvest runs, conversations (journey steps, caller-choice attributes and participant data), flow coverage and saved funnel definitions are kept in the app’s own private store.
• Narratives — cached per run.
• Owner scoping — everything is keyed to the org credentials that harvested it, so different orgs never see each other’s data; the same org signed in again sees its own warehouse.
• Sessions & credentials — Genesys secrets are held encrypted on the server and never sent to the browser; no Genesys token ever reaches the browser. Sessions end after a period of inactivity.
• Participant data is stored raw — deliberately unredacted (see §5); the mitigations are restricted access, owner scoping and a read-only Genesys client. Treat the harvested data and exports with the same care as call recordings. Prompt text is PII-redacted at extraction, and the diagram/summary’s curated choice dimensions are shape-screened against identifiers.
• What leaves the service — Genesys API calls to your org, and — only when you click Generate — aggregate KPI metrics (names and counts, no caller data) to a large language model service configured by QVCCS. Nothing else.

11Technology

• Web application — the harvest engine with live progress, the conversation warehouse, Graphviz rendering of the journey diagram (SVG and PDF), the summary PDF, and the optional AI analyst narrative.
• Browser interface — the journey map, lens and Insights views, with state kept in the page address (layers, lens, Insights tab) so every view is a shareable link.
• Caching model — conversations are stored once and reused across runs; diagrams are cached per run + toggle + lens combination and Insights are memoised per run, so exploring a harvested run costs zero extra Genesys calls.

12Troubleshooting

“Authentication failed” / 403 with a scope hint.

Wrong ID/secret, a non-client-credentials OAuth client, or the wrong region — or a missing permission: the error names the scope (see §9). Genesys mints token scopes at sign-in, so after granting a permission, sign out and back in.

Zero granular traces / high “capture misses”.

Flow-execution capture is opt-in per flow in Architect (“capture execution data”) and traces are retained only ~7–10 days. Calls before capture was enabled have no trace; they are counted as misses, remembered, and never re-fetched. The macro layer still covers every call — you lose menu/prompt detail, not volumes or dispositions.

No prompt nodes on the map.

Prompts render only from harvested traces, never from the flow design. Enable capture and harvest a fresh window (or use the “Re-fetch execution traces” option within the retention window). If the app was just updated, hard-refresh the browser — a cached page can hide new layers.

The harvest looks frozen right after starting.

Genesys compiles the analytics job asynchronously — several minutes on a busy org. The progress page says “Genesys is compiling conversation data”; it has not hung, and the stream reattaches if you navigate away.

“This harvest is no longer running” after a restart.

Runs interrupted by a service restart are marked failed rather than left as zombies. Re-run the harvest — cached conversations and traces are reused, so it is fast.

Window rejected.

Harvests are limited to 31 days per run and cannot extend into the future. Harvest month-by-month for longer baselines — coverage accumulates in the warehouse.

“No data for this layer yet”.

The run has no conversations in that layer (e.g. granular with zero captured traces). The default macro journey always renders once the harvest stored conversations.

The summary PDF fails while the diagram PDF works.

They use different renderers. The in-browser Export summary (print dialog) produces the same report as a fallback; if the failure persists, contact QVCCS support.

“The written analysis is not configured on this server”.

The AI narrative isn’t enabled for this service. Everything else works; the panel just can’t generate. Ask QVCCS to enable it.

The Participant data panel is nearly empty for an older run.

The run predates full-pdata capture. Click “Fetch it from Genesys” on the amber banner — the backfill re-reads the analytics window in place (§5), no re-harvest needed.

The same value appears twice in the summary, one truncated.

Mixed-generation capture (older 40-character clips beside full values). Displays fold the pairs automatically; run the participant-data backfill to normalise the stored rows.

A Switch tooltip says “detail unavailable (may be in a subflow)”.

The explainer reads the main flow’s Architect configuration; switches inside subflows aren’t in it. The branch percentages on the diagram are still real.

Findings tab says nothing crossed the thresholds.

Not a bug — findings require ≥10-call cohorts moving escalation by ≥12 points (and outcomes ≥15 attempts under 45% success). Small or uniformly-behaved runs legitimately produce none; the pivot builder still lets you explore manually.

Per-day calendar counts look implausibly low.

Days are UTC — an overnight UTC slice of a US-hours flow is genuinely quiet. The per-day badges show cached volumes so a quiet day reads as low-volume, not broken.