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

Jacob Saaby Ni1 · ‎11-09-2020

Actually, there's a better solution (in my view) for solving the limbo state issue, which I think is completely bonkers. I personally think it must've been a collective brainfart on ServiceNow devs part.

I've solved it by creating a flow that goes looking in the awa_work_item_rejection table.

Trigger: If a record has been created within the last minute, with the reason of Time Out, and Work Item Exceeded Queue Target Wait Time is false, then

If: The triggering work item rejection item.work item.state is queued and ditto work item state changed at or after the work item rejection record was created

Then: I simply delete that record

This way, the chat will keep being offered for the duration of the max queue wait time, after which it will die of natural causes 😉

By deleting the timed out items from the awa_work_item_rejection table, you basically make the chat system think it hasn't been offered to that agent (there's one rejection record per agent). And by deleting it right away, you can basically keep the offered chat rotating for as long as you set the max queue wait time.

And by only doing it for Timed Out work item rejections, you can still keep the other ways of rejecting a work item.

You could refine this, if you want to make sure that it's always offered to the one who least recently had the chat offered, comparing the number of available agents to the number of records for that particular work item in the awa_work_item_rejection table. And then always just delete the oldest of the records, thereby creating your own carousel, that always offers to the one who least recently had the chat offered.

Personally, I felt this was a bit much. I'd rather just let the chat-system itself handle that.

I've tested it on 3 different instances, where I let a chat cycle between 3 agents for 15 minutes. It works like a charm. I've noticed this:

It's as if it takes a run or a couple of minutes if you commit it on another instance, before the platform gets up to speed, thereby missing a rejection record or two for the first run. After that, it's been running like a charm.
After the chat's been cycled through all agents, there's a brief pause. I haven't been able to observe if this pause corresponds to "one agent timeout" or if it's been a coincidence. In any case, I haven't tampered with that, as the chat will be offered again, and the enduser won't notice anything anyway.

Sam190 · ‎11-09-2020

That's interesting. I don't think I had access to a table called awa_work_item_rejection in Madrid. Definitely would have made things simpler!

I agree that this is a huge miss by ServiceNow developers about how users get stuck in Limbo after going through all the agents, but I believe an OOTB solution was integrated in NY or Orlando (not sure this has been a while)

Jacob Saaby Ni1 · ‎11-09-2020

Hi Adrien.

No OOTB solution has been implemented, not even in Paris, which is where I created my solution.

However, if you bring a NEW agent online, then that agent will have the chat offered as long as it's within the max queue time. That's because that agent doesn't yet have a rejection item record. As soon as he does, the chat will go back into its zombie state and wait for queue timeout.

But no existing agents who have had the chat offered, will have it re-offered. Not in Paris either.

Jacob Saaby Ni1 · ‎11-23-2020

A correction. The platform can now do this, I have since found out.

If you go to Advanced Work Assignment -> Assignment Rules, you can now set "Reassign on timeout".

Additionally if you go to Reject Reasons, you can set specific reject reasons to be reassignable. So, if you make the timed out reject reason reassignable, the chat will just keep on cycling between agents until queue timeout.

This is a much better solution than doing my flow solution, since this is out of the box.

Steve Kelly · ‎11-24-2020

Hi Jacob,

Looking into this issue myself. On our instance the 'Time out' reject reason does not allow for 'Reassignable' to be checked, its read only. Do you know if there is a reason for this?

Thanks,

Steve