Implementing Conversation Flow Visualization with Sankey Diagrams Showing Common Paths

How-To-Articles
1

Implementing Conversation Flow Visualization with Sankey Diagrams Showing Common Paths

What This Guide Covers

  • Architecting a “Flow Visualization” engine to map the common paths customers take through IVRs, Bot Flows, and Agent transfers.
  • Implementing Sankey Diagrams to visualize interaction “Churn” and “Containment” points.
  • Designing a data pipeline that converts raw conversation segments into a “Nodes and Links” format for behavioral analysis.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX 1/2/3.
  • Tools: Data visualization library (D3.js, Plotly, or Highcharts).
  • Data Source: Interaction Segment data from the Analytics API.

The Implementation Deep-Dive

1. The Strategy: Seeing the “Customer Friction”

Traditional reporting tells you “10% of customers dropped in the IVR.” A Sankey diagram tells you where they dropped (e.g., “7% dropped at the Billing menu, 3% dropped after the Balance prompt”). This allows you to identify the specific “Dead Ends” in your CX design.

The Strategy:

  1. The Segments: Extract the segmentType and segmentName for every part of an interaction.
  2. The Transition: Identify the “Source” (Stage N) and the “Target” (Stage N+1).
  3. The Weight: Count the number of interactions that made each transition.
  4. The Benefit: You can see the “Width” of the flow, making it instantly obvious where the most volume is flowing and where the “Leaks” are occurring.

2. Implementing the “Nodes and Links” Data Pipeline

To build a Sankey diagram, you must convert linear conversation details into a structured graph.

The Implementation:

  1. The Logic (Python/Pandas):
    # Group by the sequence of segments
paths = df.groupby('conversation_id')['segment_name'].apply(list)
# Create source/target pairs
links = []
for path in paths:
    for i in range(len(path)-1):
        links.append({'source': path[i], 'target': path[i+1]})
# Aggregate weights
sankey_data = pd.DataFrame(links).value_counts().reset_index(name='value')
  2. The Output: A JSON object with a list of unique nodes and a list of links with source, target, and value.

3. Designing for “Abandonment” and “Success” States

A Sankey diagram is most effective when it shows the Outcome at every stage.

The Strategy:

  1. Add virtual nodes for “DISCONNECT” and “RESOLVED.”
  2. The Visualization:
    • If a customer goes IVR_Menu → Disconnect, the link turns Red.
    • If a customer goes Agent_Support → Resolved, the link turns Green.
  3. The Insight: Identify “High-Friction Nodes.” If the link between “Account Lookup” and “Agent” is very thin, it means your automated lookup is failing and forcing customers to repeat their information to the agent.

4. Implementing “Drill-Down” Behavioral Analysis

Static diagrams are limited. Interactive Sankeys allow you to find the “Why.”

The Implementation:

  1. The Interaction: When a user clicks a “Link” in the Sankey diagram (e.g., the path from “Bot” to “Agent”).
  2. The Action: The dashboard displays a random sample of 5 Transcripts from that specific path.
  3. The Value: This closes the gap between “Quantitative” (the chart shows a leak) and “Qualitative” (the transcript shows the bot didn’t understand the word “Cancel”).

Validation, Edge Cases & Troubleshooting

Edge Case 1: “Spaghetti” Diagrams (Too many nodes)

Failure Condition: Your IVR has 500 different prompts, creating a Sankey diagram that is unreadable and looks like a tangled mess of lines.
Solution: Implement Node Grouping (Bucketing). Group similar prompts into high-level categories (e.g., all “Payment” prompts become one node: PAYMENT_STAGE). Use a “Depth Limit” to only show the first 5-7 stages of an interaction.

Edge Case 2: Circular Loops (The “IVR Trap”)

Failure Condition: A customer goes from Menu A → Menu B → Menu A, creating a circular loop that breaks many standard Sankey rendering libraries.
Solution: Append a Stage Index to the node name (e.g., Menu_A_Stage_1, Menu_B_Stage_2, Menu_A_Stage_3). This treats them as distinct points in time, allowing the flow to move forward linearly even if the customer is repeating an action.

Edge Case 3: Missing Segment Data (The “Black Box”)

Failure Condition: A transfer to an external carrier or a third-party application results in a “Loss of Visibility” in the flow.
Solution: Create a “Shadow Node” called EXTERNAL_TRANSFER. Use the disconnectType: peer or destinationUri to label where the call went, ensuring the diagram account for 100% of the interaction volume even if you can’t see the internal details of the destination.

Official References