Virtual agent to human agent transfers

You can use custom payloads with Gemini Enterprise for Customer Experience or Dialogflow to configure your virtual support agents to transfer a voice session directly to a human agent. You can identify the human agent using the agent's extension number or agent ID. Transferring directly to a human agent eliminates the intermediate step of transferring to a queue before transferring to the agent. This can improve wait times and customer satisfaction. Human agents can see conversation history in the call adapter when virtual agents transfer calls.

Deflections

If you've configured queue-level deflections for after hours or overcapacity, Google recommends using agent extensions to transfer calls from virtual agents to human agents. Transfers using agent extensions support deflections, while transfers using agent IDs don't support them.

Custom payload using an agent extension

The following is an example of a custom payload for a virtual agent to human agent transfer using an agent extension:

  { 
  
 "ujet" 
 : 
  
 { 
  
 "type" 
 : 
  
 "action" 
 , 
  
 "action" 
 : 
  
 "direct" 
 , 
  
 "escalation_reason" 
 : 
  
 " ESCALATION_REASON 
" 
 , 
  
 "allow_virtual_agent" 
 : 
  
 false 
 , 
  
 "agent_extension" 
 : 
  
  AGENT_EXTENSION 
 
 , 
  
 "fallback_menu" 
 : 
  
  FALLBACK_MENU 
 
 , 
  
 "language" 
 : 
  
 " LANGUAGE 
" 
  
 } 
 }

Replace the following:

ESCALATION_REASON : possible values:
- by_virtual_agent : a planned transfer.
- by_consumer : an escalation.
AGENT_EXTENSION : the extension number of the agent to transfer the call to.
FALLBACK_MENU : the menu ID for the queue to fall back to if the transfer fails. For more information, see Fallback behavior .
LANGUAGE : the queue language to fall back to. Default: the virtual agent's current language.

Custom payload using an agent ID

The following is an example of a custom payload for a virtual agent to human agent transfer using an agent ID.

  { 
  
 "ujet" 
 : 
  
 { 
  
 "type" 
 : 
  
 "action" 
 , 
  
 "action" 
 : 
  
 "direct" 
 , 
  
 "escalation_reason" 
 : 
  
 " ESCALATION_REASON 
" 
 , 
  
 "allow_virtual_agent" 
 : 
  
 false 
 , 
  
 "agent_id" 
 : 
  
  AGENT_ID 
 
 , 
  
 "fallback_menu" 
 : 
  
  FALLBACK_MENU 
 
 , 
  
 "language" 
 : 
  
 " LANGUAGE 
" 
  
 } 
 }

Replace the following:

ESCALATION_REASON : possible values:
- by_virtual_agent : a planned transfer.
- by_consumer : an escalation.
AGENT_ID : the agent ID of the agent to transfer the call to.
FALLBACK_MENU : the menu ID for the queue to fall back to if the transfer fails. For more information, see Fallback behavior .
LANGUAGE : the queue language to fall back to. Default: the virtual agent's current language.

Fallback behavior

If a transfer from a virtual agent to a human agent fails (for example, if the agent extension number or agent ID is invalid) the system initiates the following fallback sequence:

First fallback:The system transfers the end-user to the queue of the current session. If this fallback fails (for example, there are no human agents assigned to the queue), then the system attempts the second fallback.
Second fallback:The system transfers the end-user to the queue specified by fallback_menu in the custom payload. If this fallback fails, then the call ends.

Reporting

How transfers appear in dashboards depends on their escalation_reason value:

by_virtual_agent : appears as Planned Transfers.
by_consumer : appears as Escalated.