Genesys Cloud - Main

Hello,

When a call is on hold according to the threshold configured in the data table, Genesys does not take into account that a call is already ringing on an agent.

As a result, it switches to the next priority instead of waiting for the ringing alert to end.

This behavior causes several issues:

- The call rings for less time than the ringing alert configured for the queue.
- It creates stress for the agent, who feels they are not being responsive enough, even though it is the system that switched the call to the next priority (e.g., after 2 or 3 seconds instead of the configured 25 seconds).
- The call switches to a lower priority (overflow), even though it could have been answered if the ringing alert had lasted the configured time.

The system should dynamically take into account the state of a call.
If a ringing alert is active before the end of a wait threshold, it should wait until the threshold ends before considering it reached.
The goal is for the call to be answered by the agent it is ringing on, rather than being transferred to other queues or dropped, even though it could have been answered.
In fact, 
It's not possible to predict the wait time before an agent becomes available.

In this example (attached), the call waited for 230 seconds (the wait threshold defined in the data table), even though it only rang for 2 seconds, while the alerting timeout configured for the queue is 25 seconds.

If you are experiencing this issue, please vote for this improvement request : The system should consider the call state | Genesys Cloud Ideas Portal

Regards,

Hello Jeremie,

Thank you for submitting that Idea to the Product Ideas Lab. Did you check with Customer Care about this issue?

Hello,

When a call is on hold according to the threshold configured in the data table, Genesys does not take into account that a call is already ringing on an agent.

As a result, it switches to the next priority instead of waiting for the ringing alert to end.

This behavior causes several issues:

- The call rings for less time than the ringing alert configured for the queue.
- It creates stress for the agent, who feels they are not being responsive enough, even though it is the system that switched the call to the next priority (e.g., after 2 or 3 seconds instead of the configured 25 seconds).
- The call switches to a lower priority (overflow), even though it could have been answered if the ringing alert had lasted the configured time.

The system should dynamically take into account the state of a call.
If a ringing alert is active before the end of a wait threshold, it should wait until the threshold ends before considering it reached.
The goal is for the call to be answered by the agent it is ringing on, rather than being transferred to other queues or dropped, even though it could have been answered.
In fact, 
It's not possible to predict the wait time before an agent becomes available.

In this example (attached), the call waited for 230 seconds (the wait threshold defined in the data table), even though it only rang for 2 seconds, while the alerting timeout configured for the queue is 25 seconds.

If you are experiencing this issue, please vote for this improvement request : The system should consider the call state | Genesys Cloud Ideas Portal

Regards,

Hello,

When a call is on hold according to the threshold configured in the data table, Genesys does not take into account that a call is already ringing on an agent.

As a result, it switches to the next priority instead of waiting for the ringing alert to end.

This behavior causes several issues:

- The call rings for less time than the ringing alert configured for the queue.
- It creates stress for the agent, who feels they are not being responsive enough, even though it is the system that switched the call to the next priority (e.g., after 2 or 3 seconds instead of the configured 25 seconds).
- The call switches to a lower priority (overflow), even though it could have been answered if the ringing alert had lasted the configured time.

The system should dynamically take into account the state of a call.
If a ringing alert is active before the end of a wait threshold, it should wait until the threshold ends before considering it reached.
The goal is for the call to be answered by the agent it is ringing on, rather than being transferred to other queues or dropped, even though it could have been answered.
In fact, 
It's not possible to predict the wait time before an agent becomes available.

In this example (attached), the call waited for 230 seconds (the wait threshold defined in the data table), even though it only rang for 2 seconds, while the alerting timeout configured for the queue is 25 seconds.

If you are experiencing this issue, please vote for this improvement request : The system should consider the call state | Genesys Cloud Ideas Portal

Regards,

Just so I'm clear regarding the behavior you describe...what "data table" are you referring to in your first sentence?

------------------------------
Gcp Ganahl GCCX-AI, GCP, GCSME, ICCE, ICHD, etc.
Technical Adoption Champion
Genesys

Original Message:
Sent: 06-03-2025 06:40
From: Jeremie SIMON
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Hello,

When a call is on hold according to the threshold configured in the data table, Genesys does not take into account that a call is already ringing on an agent.

As a result, it switches to the next priority instead of waiting for the ringing alert to end.

This behavior causes several issues:

- The call rings for less time than the ringing alert configured for the queue.
- It creates stress for the agent, who feels they are not being responsive enough, even though it is the system that switched the call to the next priority (e.g., after 2 or 3 seconds instead of the configured 25 seconds).
- The call switches to a lower priority (overflow), even though it could have been answered if the ringing alert had lasted the configured time.

The system should dynamically take into account the state of a call.
If a ringing alert is active before the end of a wait threshold, it should wait until the threshold ends before considering it reached.
The goal is for the call to be answered by the agent it is ringing on, rather than being transferred to other queues or dropped, even though it could have been answered.
In fact, 
It's not possible to predict the wait time before an agent becomes available.

In this example (attached), the call waited for 230 seconds (the wait threshold defined in the data table), even though it only rang for 2 seconds, while the alerting timeout configured for the queue is 25 seconds.

If you are experiencing this issue, please vote for this improvement request : The system should consider the call state | Genesys Cloud Ideas Portal

Regards,

#ArchitectureandDesign
#Routing(ACD/IVR)
#Telephony

------------------------------
Jeremie
IT
------------------------------

Hello @George Ganahl,

I use integer value in data table to define a threshold (in seconds) by priority with data table lookup in Architect.

For example :

- threshold 1 for priority 1 (with queue 1 or group of queues 1)

- threshold 2 for priority 2 (with queue 2 or group of queues 2)

- threshold 3 for priority 3 (with queue 3 or group of queues 3), etc...

When the call interaction reached the waiting time in queue defined in the data table and an agent is alerted with a ringing call, the system does not take into account that the call is ringing before switch to the next priority (in this example, Outcome-Global - in line with our routing strategy, as no one is immediately available [idle status] in the other priorities).

I added another screenshot to give a different view of the wait time in the queue (251 sec = 250 +/1s)

I hope I have answered the question accurately.

Regards

------------------------------
Jeremie SIMON
IT

Original Message:
Sent: 06-04-2025 13:56
From: George Ganahl
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Just so I'm clear regarding the behavior you describe...what "data table" are you referring to in your first sentence?

------------------------------
Gcp Ganahl GCCX-AI, GCP, GCSME, ICCE, ICHD, etc.
Technical Adoption Champion
Genesys

Original Message:
Sent: 06-03-2025 06:40
From: Jeremie SIMON
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Hello,

When a call is on hold according to the threshold configured in the data table, Genesys does not take into account that a call is already ringing on an agent.

As a result, it switches to the next priority instead of waiting for the ringing alert to end.

This behavior causes several issues:

- The call rings for less time than the ringing alert configured for the queue.
- It creates stress for the agent, who feels they are not being responsive enough, even though it is the system that switched the call to the next priority (e.g., after 2 or 3 seconds instead of the configured 25 seconds).
- The call switches to a lower priority (overflow), even though it could have been answered if the ringing alert had lasted the configured time.

The system should dynamically take into account the state of a call.
If a ringing alert is active before the end of a wait threshold, it should wait until the threshold ends before considering it reached.
The goal is for the call to be answered by the agent it is ringing on, rather than being transferred to other queues or dropped, even though it could have been answered.
In fact, 
It's not possible to predict the wait time before an agent becomes available.

In this example (attached), the call waited for 230 seconds (the wait threshold defined in the data table), even though it only rang for 2 seconds, while the alerting timeout configured for the queue is 25 seconds.

If you are experiencing this issue, please vote for this improvement request : The system should consider the call state | Genesys Cloud Ideas Portal

Regards,

#ArchitectureandDesign
#Routing(ACD/IVR)
#Telephony

------------------------------
Jeremie
IT
------------------------------

I've just tried to tackle the same problem. The only solution I could come up with was to add a skill no one has at the point where any agent assigned wouldn't have enough time for a full ring. For example, if I have it configured to alert for 16 seconds, I'm adding the skill with 15 seconds left in queue wait. It's not a perfect solution as I'm going to have some calls flow out that may not previously, but it stops the agents from not being alerted the full time. 

Hello @George Ganahl,

I use integer value in data table to define a threshold (in seconds) by priority with data table lookup in Architect.

For example :

- threshold 1 for priority 1 (with queue 1 or group of queues 1)

- threshold 2 for priority 2 (with queue 2 or group of queues 2)

- threshold 3 for priority 3 (with queue 3 or group of queues 3), etc...

When the call interaction reached the waiting time in queue defined in the data table and an agent is alerted with a ringing call, the system does not take into account that the call is ringing before switch to the next priority (in this example, Outcome-Global - in line with our routing strategy, as no one is immediately available [idle status] in the other priorities).

I added another screenshot to give a different view of the wait time in the queue (251 sec = 250 +/1s)

I hope I have answered the question accurately.

Regards

------------------------------
Jeremie SIMON
IT

Original Message:
Sent: 06-04-2025 13:56
From: George Ganahl
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Just so I'm clear regarding the behavior you describe...what "data table" are you referring to in your first sentence?

------------------------------
Gcp Ganahl GCCX-AI, GCP, GCSME, ICCE, ICHD, etc.
Technical Adoption Champion
Genesys

Original Message:
Sent: 06-03-2025 06:40
From: Jeremie SIMON
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Hello,

When a call is on hold according to the threshold configured in the data table, Genesys does not take into account that a call is already ringing on an agent.

As a result, it switches to the next priority instead of waiting for the ringing alert to end.

This behavior causes several issues:

- The call rings for less time than the ringing alert configured for the queue.
- It creates stress for the agent, who feels they are not being responsive enough, even though it is the system that switched the call to the next priority (e.g., after 2 or 3 seconds instead of the configured 25 seconds).
- The call switches to a lower priority (overflow), even though it could have been answered if the ringing alert had lasted the configured time.

The system should dynamically take into account the state of a call.
If a ringing alert is active before the end of a wait threshold, it should wait until the threshold ends before considering it reached.
The goal is for the call to be answered by the agent it is ringing on, rather than being transferred to other queues or dropped, even though it could have been answered.
In fact, 
It's not possible to predict the wait time before an agent becomes available.

In this example (attached), the call waited for 230 seconds (the wait threshold defined in the data table), even though it only rang for 2 seconds, while the alerting timeout configured for the queue is 25 seconds.

If you are experiencing this issue, please vote for this improvement request : The system should consider the call state | Genesys Cloud Ideas Portal

Regards,

#ArchitectureandDesign
#Routing(ACD/IVR)
#Telephony

------------------------------
Jeremie
IT
------------------------------

Hello @George Ganahl,

I use integer value in data table to define a threshold (in seconds) by priority with data table lookup in Architect.

For example :

- threshold 1 for priority 1 (with queue 1 or group of queues 1)

- threshold 2 for priority 2 (with queue 2 or group of queues 2)

- threshold 3 for priority 3 (with queue 3 or group of queues 3), etc...

When the call interaction reached the waiting time in queue defined in the data table and an agent is alerted with a ringing call, the system does not take into account that the call is ringing before switch to the next priority (in this example, Outcome-Global - in line with our routing strategy, as no one is immediately available [idle status] in the other priorities).

I added another screenshot to give a different view of the wait time in the queue (251 sec = 250 +/1s)

I hope I have answered the question accurately.

Regards

------------------------------
Jeremie SIMON
IT

Original Message:
Sent: 06-04-2025 13:56
From: George Ganahl
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Just so I'm clear regarding the behavior you describe...what "data table" are you referring to in your first sentence?

------------------------------
Gcp Ganahl GCCX-AI, GCP, GCSME, ICCE, ICHD, etc.
Technical Adoption Champion
Genesys

Original Message:
Sent: 06-03-2025 06:40
From: Jeremie SIMON
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Hello,

When a call is on hold according to the threshold configured in the data table, Genesys does not take into account that a call is already ringing on an agent.

As a result, it switches to the next priority instead of waiting for the ringing alert to end.

This behavior causes several issues:

- The call rings for less time than the ringing alert configured for the queue.
- It creates stress for the agent, who feels they are not being responsive enough, even though it is the system that switched the call to the next priority (e.g., after 2 or 3 seconds instead of the configured 25 seconds).
- The call switches to a lower priority (overflow), even though it could have been answered if the ringing alert had lasted the configured time.

The system should dynamically take into account the state of a call.
If a ringing alert is active before the end of a wait threshold, it should wait until the threshold ends before considering it reached.
The goal is for the call to be answered by the agent it is ringing on, rather than being transferred to other queues or dropped, even though it could have been answered.
In fact, 
It's not possible to predict the wait time before an agent becomes available.

In this example (attached), the call waited for 230 seconds (the wait threshold defined in the data table), even though it only rang for 2 seconds, while the alerting timeout configured for the queue is 25 seconds.

If you are experiencing this issue, please vote for this improvement request : The system should consider the call state | Genesys Cloud Ideas Portal

Regards,

#ArchitectureandDesign
#Routing(ACD/IVR)
#Telephony

------------------------------
Jeremie
IT
------------------------------

If I am understanding correctly,

1. You set the threshold when the call enters the In-Queue Call flow.
2. When it hits the threshold you transfer the call to another flow (based on the Timeline showing it going to another IVR segment)

Thus, you programmed the flow to do exactly what you are seeing. An In-Queue Call flow continues to run while the call is alerting, so your logic is purposely telling the call to stop alerting and transfer to the other flow.

The Transfer action has no functionality built in to detect whether the call is Alerting...it just performs the transfer per the flow logic.

If you want to prevent that, you might be able to use a data action to query the conversation details and see if the conversation is currently in         "segmentType": "alert". You can post in the Developer Community to ask about that possibility.

However, your best option is probably to use auto-answer to connect the calls right away rather than counting on the agent to pick up. 

Hello @George Ganahl,

I use integer value in data table to define a threshold (in seconds) by priority with data table lookup in Architect.

For example :

- threshold 1 for priority 1 (with queue 1 or group of queues 1)

- threshold 2 for priority 2 (with queue 2 or group of queues 2)

- threshold 3 for priority 3 (with queue 3 or group of queues 3), etc...

When the call interaction reached the waiting time in queue defined in the data table and an agent is alerted with a ringing call, the system does not take into account that the call is ringing before switch to the next priority (in this example, Outcome-Global - in line with our routing strategy, as no one is immediately available [idle status] in the other priorities).

I added another screenshot to give a different view of the wait time in the queue (251 sec = 250 +/1s)

I hope I have answered the question accurately.

Regards

------------------------------
Jeremie SIMON
IT

Original Message:
Sent: 06-04-2025 13:56
From: George Ganahl
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Just so I'm clear regarding the behavior you describe...what "data table" are you referring to in your first sentence?

------------------------------
Gcp Ganahl GCCX-AI, GCP, GCSME, ICCE, ICHD, etc.
Technical Adoption Champion
Genesys

Original Message:
Sent: 06-03-2025 06:40
From: Jeremie SIMON
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Hello,

When a call is on hold according to the threshold configured in the data table, Genesys does not take into account that a call is already ringing on an agent.

As a result, it switches to the next priority instead of waiting for the ringing alert to end.

This behavior causes several issues:

- The call rings for less time than the ringing alert configured for the queue.
- It creates stress for the agent, who feels they are not being responsive enough, even though it is the system that switched the call to the next priority (e.g., after 2 or 3 seconds instead of the configured 25 seconds).
- The call switches to a lower priority (overflow), even though it could have been answered if the ringing alert had lasted the configured time.

The system should dynamically take into account the state of a call.
If a ringing alert is active before the end of a wait threshold, it should wait until the threshold ends before considering it reached.
The goal is for the call to be answered by the agent it is ringing on, rather than being transferred to other queues or dropped, even though it could have been answered.
In fact, 
It's not possible to predict the wait time before an agent becomes available.

In this example (attached), the call waited for 230 seconds (the wait threshold defined in the data table), even though it only rang for 2 seconds, while the alerting timeout configured for the queue is 25 seconds.

If you are experiencing this issue, please vote for this improvement request : The system should consider the call state | Genesys Cloud Ideas Portal

Regards,

#ArchitectureandDesign
#Routing(ACD/IVR)
#Telephony

------------------------------
Jeremie
IT
------------------------------

If I am understanding correctly,

1. You set the threshold when the call enters the In-Queue Call flow.
2. When it hits the threshold you transfer the call to another flow (based on the Timeline showing it going to another IVR segment)

Thus, you programmed the flow to do exactly what you are seeing. An In-Queue Call flow continues to run while the call is alerting, so your logic is purposely telling the call to stop alerting and transfer to the other flow.

The Transfer action has no functionality built in to detect whether the call is Alerting...it just performs the transfer per the flow logic.

If you want to prevent that, you might be able to use a data action to query the conversation details and see if the conversation is currently in         "segmentType": "alert". You can post in the Developer Community to ask about that possibility.

However, your best option is probably to use auto-answer to connect the calls right away rather than counting on the agent to pick up. 

Hello @George Ganahl,

I use integer value in data table to define a threshold (in seconds) by priority with data table lookup in Architect.

For example :

- threshold 1 for priority 1 (with queue 1 or group of queues 1)

- threshold 2 for priority 2 (with queue 2 or group of queues 2)

- threshold 3 for priority 3 (with queue 3 or group of queues 3), etc...

When the call interaction reached the waiting time in queue defined in the data table and an agent is alerted with a ringing call, the system does not take into account that the call is ringing before switch to the next priority (in this example, Outcome-Global - in line with our routing strategy, as no one is immediately available [idle status] in the other priorities).

I added another screenshot to give a different view of the wait time in the queue (251 sec = 250 +/1s)

I hope I have answered the question accurately.

Regards

------------------------------
Jeremie SIMON
IT

Original Message:
Sent: 06-04-2025 13:56
From: George Ganahl
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Just so I'm clear regarding the behavior you describe...what "data table" are you referring to in your first sentence?

------------------------------
Gcp Ganahl GCCX-AI, GCP, GCSME, ICCE, ICHD, etc.
Technical Adoption Champion
Genesys

Original Message:
Sent: 06-03-2025 06:40
From: Jeremie SIMON
Subject: The system should consider the call state (e.g., ringing alert) before determining that the configured wait time in the data table has been reached

Hello,

When a call is on hold according to the threshold configured in the data table, Genesys does not take into account that a call is already ringing on an agent.

As a result, it switches to the next priority instead of waiting for the ringing alert to end.

This behavior causes several issues:

- The call rings for less time than the ringing alert configured for the queue.
- It creates stress for the agent, who feels they are not being responsive enough, even though it is the system that switched the call to the next priority (e.g., after 2 or 3 seconds instead of the configured 25 seconds).
- The call switches to a lower priority (overflow), even though it could have been answered if the ringing alert had lasted the configured time.

The system should dynamically take into account the state of a call.
If a ringing alert is active before the end of a wait threshold, it should wait until the threshold ends before considering it reached.
The goal is for the call to be answered by the agent it is ringing on, rather than being transferred to other queues or dropped, even though it could have been answered.
In fact, 
It's not possible to predict the wait time before an agent becomes available.

In this example (attached), the call waited for 230 seconds (the wait threshold defined in the data table), even though it only rang for 2 seconds, while the alerting timeout configured for the queue is 25 seconds.

If you are experiencing this issue, please vote for this improvement request : The system should consider the call state | Genesys Cloud Ideas Portal

Regards,

#ArchitectureandDesign
#Routing(ACD/IVR)
#Telephony

------------------------------
Jeremie
IT
------------------------------