Hi! We tested out the PushNext conversation timer and received feedback from our advisors, that they kept getting cases pushed at the set interval, while they were already working on conversations.

We have our PushNext setup as such, that it should stop pushing new cases if an advisor has even a single conversation in their "Assigned to me" queue, because we want to focus on continuing and wrapping up existing conversations before moving on to new ones.

At the same time, we allow for up to 6 concurrent "Assigned to me" conversations per advisor. This means that this queue can populate and grow up to 6, if an advisor is currently working on a case and customers that they've previously interacted with come back with a reply.

The feedback we've received was that with a PN conversation timer enabled, they're getting new cases pushed, even though they're actively working and drafting a reply to a conversation that's a reply from a customer that is now in their "assigned to me" queue.

We'd like to know if this new feature correctly adheres to the "Stop pushing from Available when agent has X conversations assigned to them." setting or it pushes a new case after a response is sent, regardless of the current state of the "Assigned to me" queue.

Hoping you can help us bring some clarity into this DianeL. Thanks in advance!

hi, encemil. thanks for your question. LizH, can you provide some insight into this? 

also, not sure if this helps, but the timer has a few stipulations (here's an excerpt from this article)

Thanks DianeL , would be lovely if we can get some more insight.

Aware of the stipulations and technically, the 2nd bullet point might be the culprit, if "navigates to an open conversation that was previously assigned to them" includes a conversation where a user replied and that got added back to the advisor's "assigned to me" queue. However, I would consider this not a "previously" assigned convo, but a currently assigned one (by definition it's currently in their assigned queue). I'm really not sure what's going on.

The same article you reference has an explanation of the "Stop pushing from Available when agent has ___ conversations assigned to them" setting and as it reads, our expectation would be that, since the Conversation Timer basically pushes cases, to correctly adhere to that setting and pause pushing if an advisor is at "capacity". Which at least according to the feedback of our advisors is currently not the case.

encemil I spoke to a developer about this and he said that the timer should be triggered only after the agent has sent their response. the timer's main function is to clear conversations from view that have already been acted upon so that agents address their assigned conversations in a timely manner. agents should not be pushed another conversation while in the midst of drafting a response.

furthermore, if the agent is at capacity after sending their response, the next conversation the timer pushes to them should be a conversation that already exists in their Assigned to Me queue and not a new conversation from the Available queue. in other words, the timer should be adhering to the Stop pushing from Available when agent has ___ conversations assigned to them setting.

it sounds like this is not the behavior you're seeing in your instance, so what you're describing may very well be a bug. the developer I spoke to also mentioned that there's an open Jira ticket to address some erroneous behavior with how the timer is being triggered, so your issue could be related.

I recommend submitting a ticket to Support with this information so that they can assist you further. thank you for bringing this to our attention!

encemil 

RE: "The feedback we've received was that with a PN conversation timer enabled, they're getting new cases pushed, even though they're actively working and drafting a reply to a conversation that's a reply from a customer that is now in their "assigned to me" queue."

If the most recent post for the conversation in view was by the agent, then the timer will continue to run and push the next conversation. The next conversation could be a current assignment that came out of pending due to a author reply, an conversation that came out of snooze, or a new conversation assignment.
If the agent needs to wrap up all of their open conversations at the end of their work day or enter some notes, then the best practices is to do that while in the agents yellow state. The Push Next will not push new conversations to agents in the yellow state, because Yellow means they are not available for a new conversation.

RE: We'd like to know if this new feature correctly adheres to the "Stop pushing from Available when agent has X conversations assigned to them." setting or it pushes a new case after a response is sent, regardless of the current state of the "Assigned to me" queue.

The Push Next Timer is an enhancement to Push Next and will continue to push conversations the same as if the agent manually selected "x" to clear the current conversation (to be pushed the next conversation). All rules for push next will still apply, including limits on the number of assignments.

DianeL 

Hi both, thanks for responding and helping me figure this out.

LizH If I understand you and DianeL  correctly, and the limits to assignments do apply, then it seems we do indeed have some sort of issue on our hands. We have it set that push next should stop pushing cases from Available if an advisor even has a single assigned conversation as we do want to prioritise existing over new convos. I'll attach a screenshot of our current settings so you have some visual aid of how this looks on our end.

Thanks for the tips on the WrapUp. Luckily we don't have an issue with that and do utilise a WrapUp yellow status exactly as you describe. The issues seem to happen only with the new timer, everything is working as expected otherwise when we turn it off.

I went ahead and opened a support case as recommended: 00425170 - [ ref:_00D2E12dgH._500Uv1AHwk:ref ]

Hope we can have this looked into, as we do want to utilise the timer in order to prevent advisors from artificially working around PushNext by keeping cases open on screen without the need to do so. The encountered issues are however an absolute blocker as they prevent us from focusing on assigned cases and wrapping those up vs. giving advisors new cases to work on before they're done with their assigned ones.

encemil 

You may want to review this article on Push Next for agent capacity.

https://community.khoros.com/t5/Managing-Conversations/About-the-Push-Next-work-queue-configuration/ta-p/721434

An agent’s capacity is determined by:

• The maximum number of conversations that an agent can have in their Assigned to Me queue before they are no longer pushed conversations from the Available queue.
  
  Note: Snoozed and pending conversations are not included in the count for this value.
  
  
• The total number of conversations that an agent can have in their Assigned to Me queue

If your agents have all of their assignments snoozed or in pending, then that opens up their push next capacity to take on additional conversations. This is a Push Next setting, not dependent on the timer setting. It also means that if the conversation in view is in a snoozed or pending status the timer will push the next conversation into the agents view. This is by design to automate pushing the next most priority case into an agents view that requires a response.

Hi LizH ,

Ah, I remember this article, I see I was chatting with Diane and Dave on that one as well. The info Dave gave me helped us configure our new priority based push next config that uses the Smart Views, can't thank him enough for that.

Anyhow, we are aware that conversations have to be in the assigned status in order to be counted and anything snoozed or pending does not count. That is actually great that it works like that and is one of the main reasons we want to use the timer - we want to avoid advisors cheating some of their metrics by working on cases that are snoozed. When I got the feedback that they were getting cases pushed while working on cases, I thought we had a "gotcha!" moment and I specifically asked if maybe they were drafting their responses while the case is snoozed or if the cases they referred to as "assigned" were actually also snoozed or pending.

They were adamant that this was not the case and that they were actively working on open and assigned conversations when they encountered the issues. I managed to check a couple of logs out and unless I was being blatantly lied to and provided the wrong cases, those were never snoozed. I also made sure to perform 1:1 interviews with tenured advisors in good standing, so at this moment I don't have a reason to distrust them. And as mentioned, all issues stopped once we turned the timer off, but then we open the doors to that one bad habit of keeping them snoozed/pending conversations open which is a big part of the reason we want to use the timer.

So yeah, aware of the design, we actually love the design, but unfortunately it doesn't seem to be doing exactly what it's supposed to. Hoping that with some investigation on the open ticket, we could get to the bottom of this.