Why are some chats waiting in queue longer than the time configured in the USER_WAIT_QUEUE_TIMEOUT setting?

Environment

Chat - Analytics
Oracle B2C Service

Resolution

The functionality of canceling requests based on the USER_WAIT_QUEUE_TIMEOUT setting is based on a timed event.  This timed event happens every 30 seconds.  This is why some extra time, up to 30 seconds beyond the setting's value is sometimes seen.  The chat server has timed processes for some functionality making some related configuration settings not exact.  This setting only works while the chat is not assigned to an agent.  At the point an agent receives a toast notification, the chat is assigned to that agent.  If they deny the chat, it goes back into the queue."

For sessions ending just over the time configured:
Due to the timed processes, when the USER_WAIT_QUEUE_TIMEOUT setting is set at 120 seconds, a chat session could end at exactly 2 minutes or it may take up to 2 minutes 30 seconds for it to end.

For sessions with longer wait times:
Another case to note is when chats are assigned to an agent but they do not accept the chat. When an agent is set to available and a chat is launched, the chat will be taken out of the queue and an invitation will be presented to the available agent. In some cases the agent has the ability to ignore the invitation. If they do this, the chat will be put back in queue at that time. Note that since the chat was taken out of the queue and put back in the queue, the wait time will start over. In cases that you see a very long wait time, check the chat transcript or chat session data to see if the chat had been assigned to an agent and the agent declined the invitation. Typically, for very long wait periods, it is likely that only one agent was available so the chat kept assigning to that one agent. The agent continued to decline the chat over and over so the wait time could never actually reach the configured threshold.

To help administrators monitor and/or verify wait times:
It is possible to create a custom report. A basic outline of such a report is as follows:

Filter 1: chats.termination_event = End-user was Queued Too Long
This is the specific chat event type that is based on the configuration setting.

Filter 2: chats.requested (select any date range needed)
It's important to include a date range to limit results to only relevant records.

Include output columns such as Chat ID, Account ID, Requested, Completed and a column to calculate Queue Wait Time. You can also include contact details such as email and name if you wish.

To calculate the Queue Wait Time, add a column and edit the definition. Under Functions > Date Functions, select the date_diff() function. Include chats.completed and chats.requested in the expression. The expression will look as follows: date_diff(chats.completed,chats.requested).

You may also want to edit the format of this column to ensure seconds are included in the output calculations. This will allow you to view, down to the second, how long an end-user was waiting in queue.

NOTE: When you generate the report, where the account ID field is blank, these wait times should be within the 30 second range of the USER_WAIT_QUEUE_TIMEOUT setting due to the timed process.

NOTE: Where the Account ID field is not blank, these wait times can be longer for the reason stated above.

Path to setting(s): Select Configuration from the navigation area > Site Configuration > Configuration Settings > and search by Key.

For more information on accessing the Configuration Editor and editing settings, refer to Answer ID 1960: Editing Configuration Settings.