Designing Video Calling Escalation Paths from Text-Based Messaging Conversations

How-To-Articles
1

Designing Video Calling Escalation Paths from Text-Based Messaging Conversations

What This Guide Covers

This guide details the architectural configuration required to transition a customer session from a chat-based interaction to a live video call within Genesys Cloud CX. The end result is a seamless escalation flow where intent detection triggers a media channel shift without dropping the session context. You will implement specific Contact Type definitions, Architect Flow logic for media handoff, and Routing Rule configurations to ensure agent capability matching.

Prerequisites, Roles & Licensing

Successful implementation requires specific licensing tiers and granular permission sets within the Genesys Cloud Administration Console. Video calling capabilities are not enabled by default in all organizational plans and require explicit configuration of the Video channel type.

Licensing Requirements:

  • Genesys Cloud CX Premium License: Essential for advanced media routing and video channel support. Standard or Basic licenses may restrict video call initiation from chat flows.
  • WEM Add-on (Workforce Engagement Management): Required if you intend to use Speech Analytics or Quality Management to validate the escalation decision based on sentiment analysis prior to the switch.

Granular Permissions:
Administrators must possess the following permission strings within the Organization level:

  • Contact Types > Chat > Edit
  • Contact Types > Video > Edit
  • Routing > Rules > Edit
  • Architect > Flows > Create/Edit
  • Media Policies > WebRTC > Edit

OAuth Scopes (API-driven validation):
If you are automating the creation of these paths via API, ensure your OAuth token includes:

  • genesys/oauth/contact-types/read
  • genesys/oauth/contact-types/write
  • genesys/oauth/architect/flows/read
  • genesys/oauth/architect/flows/write

External Dependencies:

  • WebRTC-Compatible Browser: Agents and customers must use Chrome, Edge, or Firefox with WebRTC support enabled.
  • Network Infrastructure: Ensure outbound UDP ports 1024-65535 are open for STUN/TURN server connectivity to handle NAT traversal during the video session.
  • CRM Integration (Optional): If escalation logic depends on Customer History (e.g., high-value account status), ensure your CRM connector is active and latency under 500ms.

The Implementation Deep-Dive

1. Defining Contact Types for Channel Segmentation

The foundational step involves configuring distinct ContactType definitions within the Platform Administration console. You cannot escalate from one channel to another without explicitly defining how the system handles the target channel state. This ensures that routing engines understand the capabilities required for each session type.

Configuration Steps:

  1. Navigate to Admin > Omnichannel > Contact Types.
  2. Create a new definition for Video_Support_Escalation.
  3. Set the Channel Type to Video.
  4. Enable Allow External Users if customers will initiate video directly, though this flow typically pushes them from an internal chat session.

Architectural Reasoning:
Defining a dedicated Contact Type allows you to isolate video traffic from general telephony voice traffic. This separation enables specific routing rules that prioritize agents with active WebRTC clients over those connected via softphone only. Without this isolation, the routing engine may attempt to queue a video session against a skill group configured exclusively for voice, resulting in immediate failure upon connection attempt.

The Trap:
A common misconfiguration is conflating the Video contact type with the Voice contact type during escalation logic. If you route a chat escalation directly to a standard Voice Queue without defining the Video Contact Type as a valid target, the system will attempt to place a voice call instead of a video session.

Catastrophic Downstream Effect:
The customer receives a phone call while still on chat, or the chat session terminates abruptly with a generic “Transfer Failed” message because the agent cannot accept a video invite. This breaks the context continuity and increases Average Handle Time (AHT) as agents must re-establish the conversation verbally.

JSON Payload for Contact Type Creation:
When using the API to provision this type programmatically, use the following structure:

{
  "id": "video-escalation-type",
  "name": "Video Support Escalation",
  "channelType": "VIDEO",
  "contactableChannelTypes": [
    {
      "channelType": "CHAT"
    }
  ],
  "routingRules": [],
  "mediaPolicies": [
    {
      "id": "default-video-policy",
      "name": "Standard Video Media Policy"
    }
  ]
}

2. Architect Flow Logic for Session Transition

The core logic resides within the Genesys Cloud Architect flow that handles the chat interaction. This flow must detect the escalation trigger, validate agent availability, and initiate the video invite sequence while preserving the ContactId to maintain conversation history.

Configuration Steps:

  1. Open the Chat Flow in Architect.
  2. Insert a Flow Entry node at the start of the chat session to initialize variables.
  3. Add a Condition node to evaluate escalation criteria (e.g., specific intent detected, customer request, or sentiment score).
  4. Implement a Transfer or Queue node configured for the Video Contact Type.

Architectural Reasoning:
The flow must explicitly set the contact.variables regarding media preferences before initiating the transfer. Genesys Cloud relies on these variables to determine the handshake protocol for the WebRTC session. If the variable is missing, the system defaults to a voice fallback or drops the call entirely depending on your Media Policies.

Implementation Snippet (Flow Logic):
You must use the Set Contact Variable node before the transfer logic executes. Configure the following variable keys:

  • Escalation_Source: “Chat”
  • Target_Channel: “Video”
  • Agent_Skill_Requirement: “Video_Certified”

JSON Payload for Flow Variable Injection:

{
  "contact": {
    "id": "chat-session-id-12345",
    "variables": {
      "Escalation_Source": "Chat",
      "Target_Channel": "Video",
      "Agent_Skill_Requirement": "Video_Certified"
    }
  },
  "routing": {
    "queueId": "video-support-queue-01",
    "contactTypeId": "video-escalation-type"
  }
}

The Trap:
Engineers often attempt to initiate the video call by simply transferring the chat contact to a queue without specifying the Contact Type in the routing rule. They assume the system will infer the media type based on the agent’s capabilities.

Catastrophic Downstream Effect:
The transfer succeeds, but the agent receives a voice call notification instead of a video invite. This causes confusion for both the agent and the customer. The agent answers thinking it is a voice call, only to find no audio or video stream active because the underlying protocol handshake was initiated as SIP Voice rather than WebRTC Video.

3. Routing Rules and Agent Capability Matching

Routing rules determine which agents receive the escalated video session. You must configure Skill-based routing to ensure that only agents with verified WebRTC capabilities are selected. This prevents escalations to agents who have chat permissions but lack the necessary media client configurations.

Configuration Steps:

  1. Navigate to Admin > Routing > Skills.
  2. Create a specific skill named Video_Capable.
  3. Assign this skill to agents who have passed WebRTC certification and possess active camera/microphone hardware.
  4. Update your Routing Rules to prioritize the Video_Support_Escalation Contact Type when the Target_Channel variable is set to Video.

Architectural Reasoning:
Routing rules evaluate skills at the moment of engagement. By binding the Video_Capable skill to the escalation path, you ensure that the routing engine does not queue a video session against an agent who only has Voice and Chat capabilities. This enforces a hard constraint on media delivery, ensuring quality standards are met before the call connects.

JSON Payload for Routing Rule Configuration:

{
  "routingRule": {
    "id": "video-escalation-rule",
    "name": "Prioritize Video Capable Agents",
    "contactTypeIds": [
      "video-escalation-type"
    ],
    "skillRequirement": {
      "skillId": "Video_Capable_Skill_ID_998877",
      "requirementType": "EXISTS",
      "priority": 100
    },
    "targetQueue": {
      "id": "video-support-queue-01"
    }
  }
}

The Trap:
A frequent oversight is failing to update the Routing Rule when an agent loses their video capability (e.g., hardware change, network block). The routing engine continues to queue video calls to that agent because the skill assignment remains static.

Catastrophic Downstream Effect:
The session times out waiting for a connection. The customer experiences significant wait time during an escalation they requested specifically to resolve a complex issue quickly. This leads to immediate frustration and potential churn, as the promised “faster resolution” via video is negated by technical failures.

4. Media Policy and WebRTC Handshake Configuration

Media Policies control how the system negotiates the connection between the customer browser and the agent client. Proper configuration ensures that encryption standards are met (TLS/DTLS) and that bandwidth throttling does not degrade the experience during peak load.

Configuration Steps:

  1. Navigate to Admin > Media Policies.
  2. Select the policy associated with your Video Contact Type.
  3. Configure Bandwidth Limits to ensure stability on lower bandwidth networks.
  4. Verify Encryption Standards are set to TLS 1.2 minimum for compliance.

Architectural Reasoning:
WebRTC sessions consume significant upstream and downstream bandwidth compared to text chat. If the Media Policy allows unlimited bitrate without throttling, a single video session can saturate the network link of an agent or customer on shared Wi-Fi, causing packet loss and jitter across all concurrent chats.

The Trap:
Organizations often leave the default “Unlimited” bandwidth setting enabled for testing environments and forget to adjust it for production. This leads to quality degradation during high-traffic periods.

Catastrophic Downstream Effect:
Video freezes or audio desynchronization occurs frequently. The customer is unable to see the agent clearly, rendering the escalation pointless. Furthermore, this can cause network congestion that impacts other chat sessions routed to the same infrastructure segment, degrading the overall Omnichannel experience for all customers.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Agent Browser Permission Denial

The Failure Condition:
The routing engine successfully assigns a video session to an agent, but the agent’s browser blocks the camera/microphone permission prompt during the transfer. The session hangs in a “Connecting” state indefinitely.

The Root Cause:
WebRTC requires explicit user consent for media devices. If the agent’s browser has previously denied access or if Group Policy Objects (GPO) restrict permissions, the handshake fails at the ICE negotiation stage.

The Solution:
Implement a pre-check within the Architect flow before escalation. Use an external API call to verify the agent’s WebRTC status or implement a UI prompt within the flow that requires the agent to confirm their media readiness. Alternatively, configure a fallback rule in the Routing Rule that routes to a voice queue if the Video_Capable skill check passes but the Media Policy handshake fails after 3 attempts.

Edge Case 2: Customer Network NAT Traversal Failure

The Failure Condition:
The customer initiates the chat escalation from behind a strict corporate firewall or NAT device. The video stream never establishes, resulting in a black screen for both parties.

The Root Cause:
STUN/TURN servers are required to traverse asymmetric networks. If the Genesys Cloud TURN server is unreachable due to firewall rules blocking UDP 1024-65535 or specific IP ranges, the WebRTC ICE candidates cannot be exchanged.

The Solution:
Verify network connectivity using the Genesys Cloud Network Diagnostics tool prior to deployment. Ensure that outbound UDP traffic is allowed to the Genesys TURN server endpoints. Document these firewall requirements in your change management process and include a test case for customers connecting from restricted networks during UAT.

Edge Case 3: Context Loss During Handoff

The Failure Condition:
When the session switches from Chat to Video, the agent interface displays a blank conversation history, forcing the customer to repeat their issue.

The Root Cause:
The ContactId is not passed correctly between the Chat flow and the Video flow components. The new video session is treated as a fresh interaction rather than an escalation of the existing contact record.

The Solution:
Ensure the contact.variables include the original ContactId in the payload sent to the routing engine. In Architect, verify that the Transfer node uses the “Same Contact” option rather than creating a new one. Validate this by inspecting the data.contactId variable in the logs immediately following the transfer node execution.

Official References