Agent Chat - Assign Interaction to all agents (First come / First Serve) or Restart Queue?

Sam190 · ‎03-20-2020

Hi,

I am currently setting up Agent Workspace and Agent Chat in my instance, and it's basically almost fully setup. I am having an issue with how interactions are provided to agents which seems to be a known issue that's been fixed in New York. Our instance currently uses Madrid.

Here's the hi ticket for the issue: https://hi.service-now.com/kb_view.do?sysparm_article=KB0754172

The resolution would be to continuously clear the queue from the awa_work_item table or to increase the timeout time, but this isn't really a solution for us.

The OOTB process for Agent Assignment is the following:

1. User requests live chat with Agent.

2. Agent receives request in Agent Workspace, and if not accepted within a minute, it moves the chat request to another agent.

This process is perfectly fine, but there are some issues that come with it. If no agents accept the request, the user will be stuck in an infinite wait-time of "Routing you to a live agent..." despite the fact that no agents can see his request anymore because they've all timed out.

I would like to know if there's a way to get one of the following functionalities in place, I've searched all over and couldn't find a solution.

1. Once all agents reject the request, it would restart the queue; effectively trying to get another agent to accept it, instead of keeping it in limbo. (Possible Solution: OnChange Client Script or business rule to mark work item as cancelled, which will put it back to Pending Accept when the item state is set to Queued [No Agents Accepted])

2. If all agents reject the request, kick user out of chat queue and tell them to try again later.

3. Assign a chat to all online agents, and whoever accepts first gets the chat (Timeout 1 hour)

Let me know if there's a solution that doesn't require scripting that I might have missed. I only need one of those 3 to work.

Sam190 · ‎05-19-2020

Hi Meenat!

Of course I can.

1. Create an event in the registry for the Work Item table (awa_work_item).

2. Create a Script Action that will be linked to the event above with the following code:

// A small delay because state is set to queued when moving from one agent to the other
gs.sleep(5000) 

var gr = new GlideRecord('awa_work_item');
gr.get(current.sys_id); // Work Item ID
gr.query();

// Check if the state is Queued after 5 seconds of it turning to Queued.
if(gr.getValue('state') === 'queued'){
     gr.state = 'cancelled';
     gr.update();
}

3. Create a business rule that will launch the script action above when a work item is set to 'Queued'

When : Async on Update

Condition: State is Queued

Script:

(function executeRule(current, previous /*null when async*/) {
	gs.eventQueue('Check if State is Queued', current, gs.getUserID(), gs.getUserName());
})(current, previous);

Hope this helps!

View solution in original post

Henri Lipsanen1 · ‎01-18-2021

Did anyone manage to find a solution to original question part 3 (3. Assign a chat to all online agents, and whoever accepts first gets the chat (Timeout 1 hour))? I guess it would make sense to provide the opportunity to accept the chat for all agents to provide shorter response time.

Steve Kelly · ‎01-25-2021

I believe I saw this feature is coming in Quebec.

Chris D · ‎01-27-2021

I can see you're on Madrid but note:

This (#1) is now doable ootb on Orlando Patch 9 (12/1/20) 😄

All you need to do is open the "Time Out" Reject Reason and check the "Reassignable" box:

This will allow the chat to recirculate back to anybody else still available, even if they missed the chat earlier.

As an option related to, but not directly resolving #2, you could also utilize the ootb Max Wait Time feature as I describe in a different thread. It's more a last resort option, not ideal though. Unfortunately for you (if in fact still on Madrid), this is a feature was added in New York.

Ren Magalona2 · ‎08-05-2021

We are in quebec but the max time out on the Queue level isnt working. Our agent assignment rule indicates that after timeout, the interaction will be reassigned. The timeout here is 2mins.

We have set the max time out on the queue level 3mins. The 2mins on the agent assignment rule level is working perfectly fine but the 3mins on the queue level isnt. It just keeps reassigning the interaction and end user is left with routing you to a live agent.