Search

Why is the Syndicated or Standard Proactive Chat widget not showing to the end user when I have agents logged into chat and available?

Environment:

Chat
Oracle B2C Service

Resolution:

If you have the syndicated or standard proactive chat widget deployed on your web site, and end users are not seeing the option to chat, even though you have agents logged in and available, here are a few things you can check to remedy this situation:

• Are we within hours of operation?
• Are the queues setup for external use?
• Is the profile assigned to the queue?
• Does the profile have push or pull mode?
• Is the widget setup for sessions or agent availability?
• Does the widget set seconds greater than 0? 

Scenario:  Type of Agents and Pull Mode

• Profile is setup to use "pull" mode
• Agent is logged in and available but has not requested a chat i.e. has not clicked on the 'Request Chat' button in the agent console
• Widget is setup with min_agents_avail_type set to "agents" and min_agents_avail set to 1

Result: Chat will not be offered.

• Value returned for number of agents available to push chats to will be 0.
• The reason for this is to allow supervisors to be logged in and be available with pull-mode configured, but not be counted as available for proactive chats.

For example (assuming no no_chat cookie is present):

One agent is logged in and available for chat who is a Supervisor with pull mode enabled. You have a Proactive widget deployed on your site with min_agents_avail_type of "agents", and min_agents_avail of 1. The returned value of the number of agents available to push chats to will be 0, so the widget is NOT displayed.

if min_agents_avail is set to 0:
One agent is logged in and available for chat who is a Supervisor with pull mode enabled. You have a Proactive widget deployed on your site with min_agents_avail_type of "agents", and min_agents_avail of 0. The returned value of the number of agents available to push chats to will be 0, so the widget is displayed since we've met the minimum count of 0.

Scenario:  Type of Agents and Push Mode

• Profile is set to use "push" mode (default permission)
• Agent is logged in and available
• Widget is setup for min_agents_avail_type of "agents".  Note that the value of the number of available agents that is returned is equal to the number of agents available in push mode.

For example (assuming no no_chat cookie is present):

One agent is logged in and available for chat with push mode enabled. You have a Proactive widget deployed on your site with min_agents_avail_type of "agents", and min_agents_avail of 1. The returned value of the number of agents available to push chats to will be 1, so the widget is displayed.

Result: Chat will be offered.

Four agents are logged in and available for chat. One is a Supervisor with pull mode enabled, and three are agents with push mode enabled. You have a Proactive widget deployed on your site with min_agents_avail_type of "agents", and min_agents_avail of 4. The returned value of the number of agents available to push chats to is 3, so the widget is not displayed, since we have not met the minimum available requirement.

Result: Chat will not be offered.

Scenario:  Type of Sessions and Pull Mode

• Agent is logged in and has "pull" mode enabled on their profile
• Widget is setup for min_agents_avail_type of "sessions".  Note that the value of the number of available sessions that is returned is equal to the number of agents times their max sessions count.

For example (assuming no no_chat cookie is present):

One agent is logged in and available for chat with pull mode enabled, and their max sessions is 2. You have a Proactive widget deployed on your site with min_agents_avail_type of "sessions", and min_agents_avail of 1. The returned value of the number of agents available to push chats to will be 2, so the widget is displayed.

Result: Chat will be offered.

Four agents are logged in and available for chat. One is a Supervisor with pull mode enabled, and three are agents with push mode enabled. Each of the four agents are allowed 2 max sessions. You have a Proactive widget deployed on your site with min_agents_avail_type of "sessions", and min_agents_avail of 1. The returned value of the number of agents available to push chats to is 8, so the widget is displayed. This is because when counting available sessions, the Supervisor with pull mode is included in the number of available sessions count.

Result: Chat will be offered.

Scenario:  Type of Sessions and Push Mode

• Agent is logged in and has "push" mode enabled on their profile
• Widget is setup for min_agents_avail_type of "sessions".  Note that the value of the number of available sessions that is returned is equal to the number of agents times their max sessions count.

For example (assuming no no_chat cookie is present):

One agent is logged in and available for chat with pull mode enabled, and their max sessions is 2. You have a Proactive widget deployed on your site with min_agents_avail_type of "sessions", and min_agents_avail of 1. The returned value of the number of agents available to push chats to will be 2, so the widget is displayed.*

Result: Chat will be offered.

Four agents are logged in and available for chat. One is a Supervisor with pull mode enabled, and three are agents with push mode enabled. Each of the four agents are allowed 2 max sessions. You have a Proactive widget deployed on your site with min_agents_avail_type of "sessions", and min_agents_avail of 1. The returned value of the number of agents available to push chats to is 8, so the widget is displayed. This is because when counting available sessions, the Supervisor with pull mode is included in the number of available sessions count.*

Result: Chat will be offered.

*These examples are the same as for "Type of Sessions and Pull Mode").

If you're unsure how your agent profiles are setup, refer to this answer for more detail:

Understanding Chat Permissions: Pull Chat Mode and Push Mode