Genesys Cloud - Main

Hi Genesys Community,

I need help fixing an agent behaviour problem.

We manage several queues with different schedules. Sometimes, agents blind transfer customers to queues that already closed for the day.

This frustrates customers. They speak to the first agent, expect a transfer, and immediately hear a closed message.

I want to prevent this. Ideally, the system disables the transfer button or warns the agent when they select a closed queue.

Have you fixed this issue? I appreciate your advice.

Hello Philip,

One way we've done this before is:

• We added a consult transfer combo to the script, with all the queues in it, and when the agent select a queue from this combo, this transfer is sent to a flow that checks the queue's business hours. 
• If the queue in question is outside its business hours, the agent hears this message and returns to the customer.
• If the queue is open, the agent actually completes the transfer.

If you do it via blind transfer, the customer will be the one hearing the out-of-hours message, and the interaction will be ended instead of remaining in the queue.

I hope this helps you.

------------------------------
Camila Meneghini
------------------------------

I agree with Camila - using a consult transfer to an Architect flow feels like the cleanest approach for this requirement.

It lets the flow evaluate the destination queue's actual Schedule Group before the transfer is completed. If the queue is closed, the agent hears the message and can return to the customer; if it's open, the transfer can continue.

That avoids duplicating schedule logic elsewhere and, most importantly, prevents the customer from being blindly transferred into a closed queue.

Good Day Philip

Just to add on what Camila has mentioned.

There is currently an idea on the Ideas portal, status is "Future consideration - https://genesyscloud.ideas.aha.io/ideas/CEIH-I-221 
I would suggest also voting on this if possible,

Regards

------------------------------
Stephan Taljaard
EMBEDIT s.r.o
------------------------------

Hi @Stephan Taljaard,

Thank you for the information.

When I clicked your link, it didn't open, so I copied it and pasted it into the browser. I noticed there was a "." at the end of the link, which was causing the issue.

I was able to open it now, and I'll vote for the idea because having native control over this would be really useful.

Hi @Camila Meneghini

Thank you, must have been a copy/paste error on my side.  I removed the "." from the link in the chat and tested.

Have a nice day.

Regards

Thank you 😊

Hello,

The solution with the consult transfer to a flow mentioned by Camila works fine. We have been using it as well.

For blind transfer there is currently no way to prevent it, as the agent is immediately disconnected upon transferring. 

It is however possible to completely disable blind transfers to queues by configuring the agent role with transfer permissions accordingly:

Add agent-level permissions to transfer interactions - Genesys Cloud Resource Center

Regadrs,

Marcelo

Hi Filipe,

I would recommend working with the scripter. Creating logic that checks service hours when a queue is selected from a list, thereby enabling or disabling the transfer button. You could even add a message for the agent-such as "outside business hours" or something similar.
This way, the transfer would be disabled, preventing a poor customer experience.

I hope this helps.

Hi Philip,

Another approach, similar to Camila's proposed script-based solution, is to configure an in-queue flow with a schedule check and out-of-hours prompts, then assign the flow to the respective queue in the queue settings.

thank you

Philip: Does your contact center work on a 24/7 schedule? For us, blind transfers are an issue due to the sheer volume of calls, and agents are pressured to get to the next call.  One thing we have done to mitigate this problem is to apply a follow-the-sun approach and use the various regions around the globe. Granted, this works for us because we can pass NA/SA calls over to EMEA or APAC, and vice versa when one center closes for the day. The other avenue we use is that we have created a general support queue to handle those few calls that have to stay in region; it's staffed with a couple of off-hours agents that support multiple channels. We have some logic that, if a call is sent to a closed queue, it will redirect to the general support queue.