Journey Management and Journey Analyser: funnels for the inside of your IVR

Picture the IVR owner of a busy service line on a Monday morning. Over the weekend the Billing queue filled up with callers whose accounts should have been found automatically. The inbound call flow looks up the caller by their number with a data action called Get Contact By ANI; if that fails, a bot asks for the account number. Somewhere between those two steps, something changed. The questions are precise: how many callers took the Failure path, how many of those completed the bot, and how many reached an agent within five minutes?

Those are funnel questions, and Genesys Cloud CX already has a funnel tool: Journey Management. But they are funnel questions about the inside of one Architect flow, at the level of a single data action result, a menu option or a bot verdict. That is the gap we set out to close with Journey Analyser: Journey Management-style journeys, with the same four metrics, built over the step-by-step record of what each flow did on each call.

Journey Management is Genesys's customer journey analytics capability. Analysts drag event cards onto a canvas, filter each card by event attributes, connect them in the order customers should meet them, then save and calculate. Funnel analysis reports Customers, Moved forward, Dropped out and Conversion rate on the path. The events come from the Genesys Event Data Platform: analytics detail events, virtual agent events, knowledge events, web events, survey events and external events ingested from other systems.

Its strength is breadth. A single customer view stitches conversations across inbound voice, callbacks, outbound voice, email, SMS, web messaging and social messaging using an External Contact ID with phone number, email address, social ID and cookie ID. Each customer is counted once per step, and history starts with up to 90 days of data and rolls to as much as 400 days. It is included with Genesys Cloud CX 4 and is an add-on for CX 1, CX 2 and CX 3. If your question is about a customer who browsed, chatted and then called, Journey Management is the right tool.

Inside a voice flow, its analytics detail events are Flow Start, Flow End, Flow Milestone and Flow Outcome, plus the ACD, agent and after-call work events that follow. Genesys also offers journey flows in Architect: a Sankey view of one flow's milestones and outcomes over seven days, with counts Genesys describes as directional rather than exact. Both are designed around milestones and outcomes the flow author chose to emit. A data action's Failure path or a prompt the caller heard is visible only if someone instrumented it in advance.

When historical execution data storage is enabled, Genesys Cloud records a flow instance for every execution of an Architect flow: an ordered list of everything the runtime did, from startedFlow through each menu, play-audio step, data-table lookup, data action, switch and transfer to endedFlow, each with a timestamp and the output path it took. A call that runs the main IVR and then an in-queue flow produces one instance per flow. That trace is, quite literally, the caller's journey at step resolution.

There are two catches, both documented by Genesys. Execution data is kept for 10 days, and the platform does not aggregate it: Genesys notes that aggregate data such as counts of how often an action runs is not supported for execution data, which you retrieve per instance through the API. Architect's Flow Insights overlay shows how often components ran over up to seven days, which is excellent for a quick read, but it is not a funnel you can filter, branch and measure against a queue result.

So the engineering problem became clear. Collect the traces before they expire, join each one to the conversation's analytics record for what happened after the IVR, reduce every call to an ordered list of meaningful events, and then let people build Journey Management-style journeys over that store, with the numbers recalculated as they work.

Journey Analyser works per watched flow. Choosing an inbound flow and pressing Watch sets a daily harvest schedule, so history accumulates from that day onwards. Each harvest enumerates every conversation that touched the flow in a window of whole days through the analytics conversation detail APIs, fetches each conversation's flow execution trace through the flow instances API, and captures the queue, agent and wrap-up record from the analytics data. Traces are stored once per conversation for the whole organisation and reused by every later window, so a harvest only fetches what is new. Bots reached from the watched flow are traced with it automatically.

Because Genesys delivers calls to its analytics store hours late, a day harvested too early can look complete when it is not. We built a Check coverage control that asks Genesys, day by day, how many conversations touched the flow and compares that with the number held, marking each day complete, short by N, not harvested or still settling, with one click to re-harvest a day. Every scheduled run also re-scans the most recent period so stragglers are picked up.

Raw traces are kept untouched and the journey events are derived from them, together with the flow designs and the organisation's catalogues of data actions, data tables, queues and prompts, which supply the real names that traces rarely carry. When a flow is republished or a permission is granted later, Re-derive events rebuilds everything from the stored traces without fetching a single trace again. Twenty event types result, from Call start, Menu, Collect input, Prompt played, Data action and Decision or switch, through Bot start, Bot intent and Bot end, to Transfer to queue, Queue result, Agent handled, Wrap-up and Call end.

The posture is read-only by construction. The app signs in with a Genesys Cloud OAuth client-credentials grant, holds the client secret encrypted for the session, and only ever reads from the organisation. Missing permissions are reported by name, so an administrator knows exactly what to add to the OAuth client's role.

The Journey Builder will feel familiar to anyone who has used Journey Management: cards for the moments that matter, connectors for the order, attribute filters to say exactly which menu, data action, bot or queue you mean, and the four metrics on every connector. Three design choices make it different for an IVR owner. First, branches live on the card. Get Contact By ANI is one card, and Success and Failure are its two branches, each with its callers and a handle to connect from that branch alone. Menus branch on the option chosen, bots on their verdict, outcomes on their value.

Second, discovery replaces guesswork. Select a card or a branch and the left pane lists what those callers went on to do next, ranked by how many did, so one click adds the next card already connected. Third, there is no Calculate step: every filter ticked, card moved or time limit set recomputes the whole journey within a moment. A connector can carry a time constraint from 30 seconds to 60 minutes, which answers questions such as how many callers sent to Billing were answered within five minutes.

Most journeys now start from the flow itself. Import flow seeds the canvas from the Architect design version most calls ran, walking the bots, common modules and transfer targets it calls, with decisions, data actions and menus already split into their branches and live counts overlaid. Every case a switch defines is listed as a branch, with 0 when no caller took it, and a Remove unreached control clears blocks nobody reached. Counts default to callers who ran the imported version, because tracking ids are numbered per published version.

Aggregates tell you where; a single call tells you why. Every card has a Callers list of the conversations behind it, each linking to a transcript titled What this caller heard and did: the prompts the flow played, what the bot recognised, what the caller pressed or said, and every data action, outcome and transfer, with offsets from the start of the call and bands where the caller crossed into a bot and back. From there, a step-by-step replay shows the raw trace as an analysis and a diagram.

Two views sit above the Builder for people who do not want to build anything. Findings reads every traced call in the window and ranks what is failing, where and for how many callers, by an impact score that weighs hang-ups, failures and caller-minutes lost, with evidence, affected callers and a plain recommendation. Stories summarises each call as what the caller wanted, the first thing that went wrong and how the call ended. Saved journeys export to PDF as a diagram and to Excel as a five-sheet workbook of cards, branches, connectors, trends and callers.

We are clear with clients about the boundaries. Journey Analyser has no web, external or survey events, and a caller is one conversation: the same person ringing twice is two callers, with no identity stitched across calls or channels. Calls through flows without execution data have no trace and cannot appear. Journey Management covers all of that ground, with a single customer view and long rolling history, and we recommend it wherever the journey crosses channels.

Where the journey is a caller inside your IVR, the trade flips in the IVR owner's favour. Every prompt, menu option, collect-input result, data action path, switch case and bot verdict is an event without instrumenting the flow first. Numbers update as you edit instead of after a calculation. And every count is one click from the transcript of a real call. The two tools work well together: Journey Management for the cross-channel story, Journey Analyser for what happened between Call start and the agent.

Journey Analyser also has siblings in the QVCCS App Suite. IVR Sankey draws a full-population aggregate map of a flow and lenses it by participant data. Flow Journey replays one conversation's path through every flow it touched, on demand and without storing anything. Flow Mapper shows the flow as designed, walks a call through it and audits the configuration. Between them, an IVR owner can see the design, the population, the funnel and the single call.

Journey Analyser came out of the QVCCS method rather than a weekend hack. Our Senior Business Consultant captured the questions IVR owners actually ask as user stories with Given/When/Then acceptance criteria; the Solution Architect designed the harvest, the event model and the metric definitions so that every number has an exact, written meaning; Senior Developers built it under the Senior Platform Practice Lead's engineering standards with four-eyes peer review; and our Systems Integration Tester proved the counts against Genesys's own flow-outcome analytics and the negative paths: aged-out traces, missing permissions, late-arriving analytics data. It is one of the applications in the QVCCS App Suite, included with every QVCCS Managed Professional Services tier, backed by the whole practice.