Genesys Cloud - Main

 View Only

Sign Up

Back to discussions
Expand all | Collapse all

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

  Thread closed by the administrator, not accepting new replies.

  • 1.  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

    Posted 06-03-2025 06:40
      |   view attached
    No replies, thread closed.

    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
    ------------------------------


  • 2.  RE: 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

    Posted 06-03-2025 14:37
    No replies, thread closed.

    Hello Jeremie,

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



    ------------------------------
    Jason Kleitz
    Online Community Manager/Moderator
    ------------------------------



  • 3.  RE: 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

    Posted 06-04-2025 03:33
    No replies, thread closed.

    Hello @Jason Kleitz,

    Yes, this is "normal" behavior on the Genesys side ('work as designed' apparently).

    And I haven't seen any improvement ideas at this subject. Maybe I didn't use the right keywords.

    If you can reconfirm that with them, that would be ideal. Our previous telephony solution prioritized ringing calls over the time waiting in the queue. If the agent didn't answer, the call was automatically rerouted back into the queue.

    According to how Genesys works, the ideal solution would be for the call to remain in the current priority (queue) flow until the ringing alert on the agent side is fully completed, and only then should the timeout be considered as reached - not before, as is currently the case. This way, if the agent doesn't answer, the call can move on to the next priority.

    Regards,



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

    Original Message


  • 4.  RE: 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

    Posted 06-04-2025 13:57
    No replies, thread closed.

    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
    ------------------------------



  • 5.  RE: 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

    Posted 06-06-2025 04:04
    Edited by Jeremie SIMON 06-06-2025 06:34
      |   view attached
    No replies, thread closed.

    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


  • 6.  RE: 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

    Posted 06-06-2025 08:53
    No replies, thread closed.

    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. 



    ------------------------------
    Eric Berkshire
    NA
    ------------------------------

    Original Message


  • 7.  RE: 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

    Posted 06-06-2025 15:59
    No replies, thread closed.

    Just curious...have you looked at Conditional Group Routing as an alternative?



    ------------------------------
    George Ganahl GCCX-AI, GCP, GCSME, ICCE, ICHD, etc.
    Technical Adoption Champion
    Genesys
    2024 Community Member of the Year
    ------------------------------

    Original Message


  • 8.  RE: 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
    Best Answer

    Posted 06-06-2025 09:03
    No replies, thread closed.

    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. 



    ------------------------------
    George Ganahl GCCX-AI, GCP, GCSME, ICCE, ICHD, etc.
    Technical Adoption Champion
    Genesys
    2024 Community Member of the Year
    ------------------------------

    Original Message


  • 9.  RE: 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

    Posted 06-06-2025 09:14
    No replies, thread closed.

    Also, vote for https://genesyscloud.ideas.aha.io/ideas/INB-I-1369



    ------------------------------
    George Ganahl GCCX-AI, GCP, GCSME, ICCE, ICHD, etc.
    Technical Adoption Champion
    Genesys
    2024 Community Member of the Year
    ------------------------------

    Original Message


  • 10.  RE: 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

    Posted 06-10-2025 03:27
    No replies, thread closed.

    Hello @George Ganahl,

    Thank you for your confirmation, and also for this idea !

    Posted on Developer Community 

    Hoping for some help with the configuration and implementation of this data action, as I'm not really an expert in this area.

    I also vote the idea ;-)

    Regards,



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

    Original Message


Related Content