Chat Concurrency : Explore reporting is an incomplete replacement for Insights

Dave Dyson

It's now Q4, could you please let us know what Zendesk's plan is? Is this still even on the roadmap? 

Dave Dyson Any chance we could get an update on when agent status will be available? 

We're now days away from the end of Q2. Are there any updates on when the promised chat dataset for reporting agent statuses will be released? 

Clay Turk
Thanks for the link, but none of the things in that "agent activity" link are what I have been waiting on.  Again, this was called out in the pinned note: 
I am aware of something that was launched recently for people on Zendesk Enterprise Suite only, but also was pulled immediately down and not returned. Additionally, it had *no* historical status data, only the "live" status.  Are there any updates on when Explore Professional users will be able to see the historical agent status for chat data? 

Kelsa Henry +1 to your fantastic post. We have all of the same questions and concerns.

For anyone else who comes along, I'll share some of what I found after doing some digging.

1) Unable to view by Department

This would be really nice to have natively. If you are in desperate need of this though, you have a couple of options.

- Are your chat agents-to-departments 1:1? If so, create a custom Group attribute for Agent Name. You can group each agent together in the appropriate department and use that as a row/column or filter.

- If your agents are many-to-one, you can look at creating custom Set attributes for Agent Name instead. Unlike custom group, you would need a separate Set per department. Using a Set in this way will restrict the query to agents within that set, so unfortunately you can only look at a single department per query. 

Obviously these require constant maintenance as agents come and go, so it's really not ideal. But it's something  ¯\_(ツ)_/¯

2) Unable to view this Chat Concurrency in relation to Agent Maximum Chat Limit Set on their Profile. 

Right - potentially a similar workaround to the above using custom group attributes. 

• • Example: Group called "Chat limit 3" containing each agent who has chat limit of 3. Group called "Chat limit 2" containing each agent who has chat limit of 2.
  • Then, custom metric - I have not tested but it could look something like:

IF (
CONTAINS([Agent name],[Chat limit 3])
) THEN AVG(Average chat concurrency) / 3 (or whatever calculation you need to do against the limit of 3)
ELIF (
CONTAINS([Agent name],[Chat limit 2])
) THEN AVG(Average chat concurrency) / 3 (or whatever calculation you need to do against the limit of 2) 
ELSE
AVG(Average chat concurrency)
ENDIF

I'm not the best at math. I don't know if dividing by chat limit is actually what you want to do. But hopefully someone finds this useful.

3) Dataset rendering 0 values  results

cc: Clay Turk

I found a couple of things to be particularly "off" here. 

1. From what I can tell, minimum concurrency is always 0 if the agent had even a single minute during the hour with 0 chats. That could be pulling down the average and explains Kelsa Henry's chart where every date has an avg of less than one.

Mind you, I don't think it would be appropriate for minimum to be at least 1 either. What if the agent did spend the majority of the hour with 0 chats and only got one at the end? Either way, we need more granularity. Checking concurrency once per hour simply cannot provide meaningful data.

Okay, let's look at the opposite end of the scale. I found that the maximum concurrency was frequently HIGHER than the agent's actual chat limit. After some digging, and comparing against chat history for those specific hours, I see two issues:

1. When chats are queued, as soon as the agent's chat ends, they are routed a new chat. Because this happens in the same minute, it is counted as concurrent even though they actually are subsequent.

2. Perhaps the more serious flaw and hopefully the easier one to fix - I observed that the concurrency appears to be measured by the chat's start time! NOT when the agent actually joined the chat! 

Clay Turk You mentioned some potential upcoming fixes to some calculation issues. Is this by chance on your radar already? Can you clarify what those fixes will be?

Thanks!

Hi Dave Dyson, 
That's correct, I'm talking about reporting on what hours an agent was online for chat, and what times did that status change throughout their shift.

The top level comment has changed and no longer has the dates that were present previously, about agent activity, which, if I recall were listed as scheduled to go live in Q2 2022. Can we get an update on when agent activity will be included? This is the thread that I've been told to watch for these updates in. 

Hi Clay,

I thought I should also put this feedback on this dataset here on your radar as the product manager.

I'm glad that this data set is finally rolled out. My concern is however the number of fundamental /obvious limitations with it. 

1) Unable to view by Department
We are unable to view/filter this chat concurrency by department. My account has over 20+ department, 1.5k agents - working in various departments. How can I simply view average concurrency at a departmental level? 

2) Unable to view this Chat Concurrency in relation to Agent Maximum Chat Limit Set on their Profile. 

Each agent had a Chat Limit set on their profile. How can I view their chat limit and other metric e.g. average wait time, number of chats served in relation to their Chat concurrency? That way I can easily determine trends ect. 

3) Dataset rendering 0 values  results
According to the definition - the dataset should render results for agents who had AT LEAST ONE chat WITHIN THE HOUR. The below is for days of the month yet it renders below 1. My question is why are we seeing 0.56, 0.45 for example in our results? What does that mean? Is this even rendering accurate information? See below.

"Chat Concurrency dataset

The Chat Concurrency dataset contains metrics and attributes that relate to your agents’ handling of concurrent chat engagements. We only show data for agents who had at least a single chat within the hour. Chat agents who were signed in and available but did not accept any chats will not be reflected.

Your feedback, solutions and their timelines on this would be greatly. 

regards