- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-01-2022 08:01 AM
Does anyone know how to configure assigning all agents a incoming chat in Agent Workspace, then first one to accept the chat can proceed? All other agents will notice the queue chat disappeared?
Solved! Go to Solution.
- Labels:
-
Agent Chat
-
Virtual Agent

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-01-2022 09:19 AM
As already stated, this is not possible with AWA/Agent Chat.
Just to add a little extra detail, this "assign-to-all" method was the only way that Connect Support worked, but Connect Support, while supported with Virtual Agent, is deprecated and has been replaced by AWA/Agent Chat so I can't advise you to use it. I understand the push to using individualized chat/work assignments based on availability and capacity, which is a big benefit of AWA over Connect Support, but unfortunately it came at the expense of a legitimate and potentially valuable assignment feature.
My advice with AWA would be to set a Max Wait Time and use short timeouts so that a chat doesn't stay in the queue of an inattentive agent for more than 30-60 seconds if possible. And you may want to set the "Timeout" Reject Reason to be "reassignable" so that, especially if there's only one or two active agents, it will loop through all the agents until the Max Wait Time is reached (we do 5 minutes).

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-31-2022 06:38 AM
OOTB, no. Custom Business Rule, yes. A very simple BR though, no scripting even needed. (See bottom for details.)
We actually do this for certain queues with AWA incidents/tasks - but note, the agent still needs to be marked Available so they can receive work items. So all this is doing is using ootb AWA functionality and just saving the agent the effort of clicking the Accept button. Personally, I don't advise this because it's actually removing power and control from your agents with minimal benefits. If you don't have auto-accept, as ootb, then a) the agent has an opportunity to reject - because they may have very legitimate reasons to not accept the work item and/or prioritize other work items in their inbox and b) on the chance that the agent has stepped away without changing their status or just missed the notification, you may have sent a work item to somebody who isn't around to work it. For tickets, this isn't a huge deal since they don't usually need to be worked immediately but this would be a TERRIBLE user experience for chats and skirt around the timeout protections that are provided ootb to avoid situations exactly like this.
As such, I really do not recommend doing auto-accept for chats. Disclaimer: now that I think about it, this very well may not work for chats, because even if you auto-accept the chat this way, I'm guessing the chat UI probably won't be triggered, so the agent won't even be able to see the chat they just got auto-accepted and they'd have no idea.
But if you want to do auto-accept for other work items, this is a simple way:
- Create dedicated Assignment Rule(s) for auto-assignments and include/start the name with "Auto-assign"
- Create a Business Rule on the awa_work_item table:
- When: Insert/Update (Before)
- Condition: assignment_rule starts with/contains "auto-assign" AND state=pending_accept
- Fields set: state=accepted
That's it - so all you're doing is beating the system to the punch. It shows up in the assigned agent's inbox when the State = Pending Accept, so if you intercept it and set it to Accept, it won't appear in their inbox and will just appear in their regular assignments.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-01-2022 01:12 AM
Thank you, this insight is very helpful.