Hi,
generally speaking I would suggest something like:
- Don't manage this in the front-end, leave the button always on the page. In this way you will not deal with API authentication from the front-end, which is inherently insecure.
- Instead let the bot act as a polite concierge. You can manage the following cases in Architect:
- When the user tries to escalate, in Architect you can obviously detect Closed/Holidays/Emergency schedules without using APIs, let the bot send a polite answer to the user if they try to escalate when the office is closed.
- Similarly when inside business hours, by using a Data Action in Architect it is easier to detect the status of the queue. I recommend using this (https://developer.genesys.cloud/analyticsdatamanagement/analytics/observation/activity-query), specifically /api/v2/analytics/routing/activity/query
- You might need to write your own little formula to determine, from the results of the query, if the interaction can be escalated or not and let the bot, again, reply to the user politely about the fact that there are no agents available, or the agents are too overwhelmed right now and to try later. Letting the bot answer the user with a polite message is better than removing the button completely.
Now, about the formula, this is what I implemented a while ago, use it as a starting point:
Availability = (oOnQueueUsers * (chatUtilization + extraQueue) - oInteracting - oWaiting) > 0 && (oOnQueueUsers >= minimumAgents)
chatUtilization, extraQueue and minimumAgents are custom variables that can be tweaked, the others come from the query.
I have chatUtilization set to 3. This should be set to the same value of the Agent Utilization capacity set in the Org for Webmessaging. Indicates how many chats an agent can handle at the same time.
extraQueue represents how many chats you want to allow waiting in an "extraQueue" per agent, I set this to 2.
minimumAgents represents the minimum number of agents to be available, for the queue to be considered available, I set this to 2 in my case.
For example with the values above you will allow dynamically:
if you have 5 agents available, they will be able to handle up to 15 active interactions, plus 10 waiting in an extra queue (5 * (3 + 2)). I set up in Architect an "In Queue" flow to let these users know that they will be connected shortly (optionally with EWT and position in queue). Note that extraQueue can also be 0 if you don't want an "extraQueue" like in your initial question, but in my opinion there is nothing wrong in letting the users to wait a few minutes. If there are more than 25 interactions (considering the ones already with agents and the ones waiting), then the bot will politely communicate that there are too many chats right now, etc.
A formula like this is dynamic because it establishes the availability based on the actual number of agents available, so it scales up when more agents go on queue.
------------------------------
Michele Scala
Solutions Architect
------------------------------
Original Message:
Sent: 07-21-2025 07:00
From: Anand Gangappa
Subject: Dynamic Web Chat Button Control Based on Queue Availability in Genesys Cloud
I have one chat queue where 3 agents are currently handling three conversations. Now, a fourth interaction is entering and waiting in the queue. Can we disable the chat button on the webpage for the fifth visitor?
#WebMessaging
------------------------------
Anand Gangappa
NA
------------------------------