Genesys Cloud - Main

Hi All, 

Hoping someone can assist me. 

our queue design for "ABC queue" has below 

• call route:
• schedule 9-5pm Mon-Fri and national holidays when applicable.
• DID only has 1 internal phone number 03XXXXXXX

When you try to call this number 03XXXXXX directly outside of business hours you will get after hours message or public holidays which ever applies. 

However for some reasons we have had some calls that had come through the queue and stayed in the queue for hours during public holidays or out of business hours.

Genesys has confirmed that they were "consult transfer" by an agent from another queue. 

For my life I cannot replicate the issue so im trying to understand how is this even possible? and is there a way to stop this?

This is clearly a Genesys issue? has anyone experienced this?

the entire purpose of having schedule setup was to stop calls coming in after hours/public holidays.

Any help would be great.

Thanks

Adam

#Routing(ACD/IVR)

------------------------------
Adam Kim
Australian Unity Group Services Pty Ltd
------------------------------

Hi Adam,

This is showing me a bug.

If the call has a BYE, it should be disconnected.

Att,

------------------------------
Breno Canyggia Ferreira Marreco
https://www.linkedin.com/in/brenocfm-40b62182/
------------------------------

Hi Breno

Thanks for your reply but what is a BYE? can you please tell me more? 

------------------------------
Adam Kim
Australian Unity Group Services Pty Ltd
------------------------------

Original Message:
Sent: 03-12-2024 15:31
From: Breno Canyggia Ferreira Marreco
Subject: Internal call transfer stuck in queue After Hours and Public Holidays

Hi Adam,

This is showing me a bug.

If the call has a BYE, it should be disconnected.

Att,

------------------------------
Breno Canyggia Ferreira Marreco
https://www.linkedin.com/in/brenocfm-40b62182/
------------------------------

The "Bye" is information to send, and then the interaction ends.

Below example of simple signalization. When one point sends BYE, another receives information for the close of interaction.

In your scenario, when a "consult transfer" is executed we have two points connected, We change one point for another point. 

One needs to send BYE the close of interaction on these points.

Att,

------------------------------
Breno Canyggia Ferreira Marreco
https://www.linkedin.com/in/brenocfm-40b62182/
------------------------------

Original Message:
Sent: 03-12-2024 15:36
From: Adam Kim
Subject: Internal call transfer stuck in queue After Hours and Public Holidays

Hi Breno

Thanks for your reply but what is a BYE? can you please tell me more? 

------------------------------
Adam Kim
Australian Unity Group Services Pty Ltd
------------------------------


Original Message:
Sent: 03-12-2024 15:31
From: Breno Canyggia Ferreira Marreco
Subject: Internal call transfer stuck in queue After Hours and Public Holidays

Hi Adam,

This is showing me a bug.

If the call has a BYE, it should be disconnected.

Att,

------------------------------
Breno Canyggia Ferreira Marreco
https://www.linkedin.com/in/brenocfm-40b62182/

Hi Adam

My guess is your logic to check the schedule and play closed messages is in your inbound call flow.  The problem is when someone transfers a call to a queue, it's the in-queue flow that plays not the inbound one.  This is a bit of a headache for a lot of us out there.  So much so that there's a few ideas that have been raised to allow a more granular queue schedule function. 

In the meantime, beyond agent training and communications your best bet here is to replicate some of that schedule checking in the inqueue flow associated with that queue.  If you want to go down a rabbit hole you could also look to put your transfer functions within an agent script and have some API lookups to check schedules against queues and present to the agent whether or not that queue is open.  That's a bit overkill though in my opinion for most use cases whereas your in-queue flow is a quick solution to handle it.  The problem though with this is also that if there's an agent on that queue even after hours, it will try to route to them and not immediately play the inqueue flow.

------------------------------
Vaun McCarthy
------------------------------

Thanks Vaun

I see your point. I will start working on the In-Queue flow and test and see if this works. Fingers crossed. 

------------------------------
Adam Kim
Australian Unity Group Services Pty Ltd
------------------------------

Original Message:
Sent: 03-12-2024 17:07
From: Vaun McCarthy
Subject: Internal call transfer stuck in queue After Hours and Public Holidays

Hi Adam

My guess is your logic to check the schedule and play closed messages is in your inbound call flow.  The problem is when someone transfers a call to a queue, it's the in-queue flow that plays not the inbound one.  This is a bit of a headache for a lot of us out there.  So much so that there's a few ideas that have been raised to allow a more granular queue schedule function. 

In the meantime, beyond agent training and communications your best bet here is to replicate some of that schedule checking in the inqueue flow associated with that queue.  If you want to go down a rabbit hole you could also look to put your transfer functions within an agent script and have some API lookups to check schedules against queues and present to the agent whether or not that queue is open.  That's a bit overkill though in my opinion for most use cases whereas your in-queue flow is a quick solution to handle it.  The problem though with this is also that if there's an agent on that queue even after hours, it will try to route to them and not immediately play the inqueue flow.

------------------------------
Vaun McCarthy
------------------------------

Thanks heaps Vaun... your suggestion has worked.

I've tested after hours call and transferred to the queue and as expected it went through the call route of the "In-Queue-Flow" design and hence I've put some evaluation on it to direct the call accordingly to Open/Closed/PublicHolidays hours and it works flawlessly.

now im comfortable that even if an internal transfer was to happen after hours or any public holidays it will be mitigated and no more impact to the queue Abandonment ect.

------------------------------
Adam Kim
Australian Unity Group Services Pty Ltd
------------------------------

Original Message:
Sent: 03-12-2024 17:07
From: Vaun McCarthy
Subject: Internal call transfer stuck in queue After Hours and Public Holidays

Hi Adam

My guess is your logic to check the schedule and play closed messages is in your inbound call flow.  The problem is when someone transfers a call to a queue, it's the in-queue flow that plays not the inbound one.  This is a bit of a headache for a lot of us out there.  So much so that there's a few ideas that have been raised to allow a more granular queue schedule function. 

In the meantime, beyond agent training and communications your best bet here is to replicate some of that schedule checking in the inqueue flow associated with that queue.  If you want to go down a rabbit hole you could also look to put your transfer functions within an agent script and have some API lookups to check schedules against queues and present to the agent whether or not that queue is open.  That's a bit overkill though in my opinion for most use cases whereas your in-queue flow is a quick solution to handle it.  The problem though with this is also that if there's an agent on that queue even after hours, it will try to route to them and not immediately play the inqueue flow.

------------------------------
Vaun McCarthy
------------------------------