Hi Genesys Cloud Community & Product Teams,
As a Genesys Partner implementing solutions for various customer needs, we've encountered a specific challenge regarding voice call transfers that impacts agent workflow and customer experience.
The Problem:
Currently, in Genesys Cloud, an agent (Agent A) can initiate a blind transfer of a voice call to another agent (Agent B), even if Agent B's presence status is 'Busy', 'Meeting', 'Training', or any other non-routable state (i.e., not 'Available' or 'On Queue').
While the transferring agent (Agent A) can see Agent B's status in the transfer panel, they can sometimes overlook this or initiate the transfer anyway. This often results in the call being routed to Agent B's voicemail, which is an undesirable outcome for many clients who explicitly want to avoid voicemail for direct agent transfers. If voicemail is disabled, the transfer fails, and the call gets directly disconnected I suppose.
Desired Behavior:
We are looking for a mechanism to prevent the transfer action itself if the target agent (Agent B) is not in a state where they can accept a call (e.g., 'Available' or 'On Queue').
Specifically:
- When Agent A attempts to select Agent B for a blind transfer.
- The system should check Agent B's real-time presence status.
- If Agent B is not in an 'Available' or 'On Queue' status, the transfer action should be blocked or disallowed before it's initiated.
- The call should remain active with Agent A, allowing them to choose a different recipient or take alternative action, without the call ever leaving their control or attempting to reach the unavailable agent.
Analogy to Recent Digital Interaction Enhancement:
We noticed a somewhat related capability was recently introduced for transferring digital interactions (like chats or messages). In that scenario, the transfer request goes to the target agent (Agent B), who then has the option to accept or decline it as seen below.
While our request for voice is slightly different (we need to prevent the transfer attempt based on status before it even reaches Agent B), the digital enhancement demonstrates that the platform can incorporate agent state/interaction into the transfer process. We believe a similar logic – checking target agent availability before allowing the transfer – could be applied to voice calls to solve the issue described above. This is distinct from a standard 'Consult' transfer; it's about making the 'Blind' transfer conditional on target availability.
For context, this level of control was achievable in PureConnect using custom handlers (like CustomTransferRequest), allowing us to intercept and prevent transfers based on specific conditions, including agent status.
Business Justification:
- Improved Customer Experience: Prevents calls from unexpectedly hitting voicemail or failing during transfer.
- Increased Agent Efficiency: Avoids wasted time attempting transfers that are guaranteed to fail or go to voicemail.
- Meeting Specific Business Rules: Caters to clients with strict "no voicemail on direct transfer" policies.
- Reduced Agent Confusion: Provides clear feedback to the agent why a transfer cannot proceed.
Question:
We are aware of the highly-voted Ideas Lab entry "Granular Transfer Permissions (Blind and Consult) to Better Control Transfer Behavior" (which currently has significant community support and is marked as 'In Development'). This idea seems focused on improving control over who can perform transfers and to whom/what (agents, queues, external numbers, etc.).
Could you please clarify if the scope of this specific "Granular Transfer Permissions" enhancement will also include the capability we've described above? Specifically, will it allow us to configure the system to prevent a voice call transfer (Blind or Consult) from being initiated if the target agent's real-time presence status is non-available (e.g., 'Busy', 'Meeting')?
Or, is the focus of that existing Idea primarily on permission/role-based restrictions, rather than incorporating real-time target agent status checks to block the transfer attempt itself? Understanding whether our requirement (blocking transfers to busy agents) is covered by this ongoing development would be very helpful. If it's not included in the scope, we believe a separate focus or Idea for this specific real-time status check functionality would be highly valuable.
We believe adding this status-based check is crucial for truly granular control and would significantly enhance the agent and customer experience for many contact centers.
Thanks for considering this feedback!
#Omni-ChannelDesktop/UserInterface#PlatformAdministration