Benny Samuel

I am trying to add a colleague with a company email address and am also getting the "Email is already in use" error. No one by her name or email address appears in our Zendesk system, so not sure why its saying this. 

Pedro Rodrigues That's an excellent idea, but, just to confirm: will this rule still count solves that came by way of merges? If I as an agent merged 3 tickets into 1, do I get credit for 3 tickets going to solve status, or would these 3 solves be considered non-agent solves?

Who do I contact for Slack/Zendesk help? I followed some of the other Community guidelines for how to set up email triggers when a Slack is responded to, but those triggers are not working. I followed the examples pretty closely if not identically. In certain cases, I'll get an email when I respond to the Slack I initiated within Zendesk (so if I write from the Zendesk ticket out to the Slack channel, I'll get an email, but I don't get an email when Slack responds back.  Is this a Slack issue (and so I have to contact Slack) or is this a ZD thing? 

I feel like this article is not accurate, and that Erin O'Callaghan is leading us to more true numbers. The article says we should be using the "Tickets" dataset. Correct me if I'm wrong please, but that evaluates how many tickets are in solved status -and you can add parameters like assignee's name, in solved status Yesterday, etc.  BUT... that doesn't necessarily mean the ticket was actually solved by the assignee during that period, just that there is a ticket in solved status to that assignee during that time period. The difference is that a ticket can be in solved status for any amount of days according to your configuration (I think default is 28 days, we have it set to 7 for our purposes). So if a ticket is in Solved status for 7 days, it will still show up for that agent. As opposed to doing the same query in the "Ticket Updates" dataset, which shows tickets that were updated by an assignee. So if the status change happened during the parameters set, it will show the ticket solved (and just for fun, Zendesk decided to term this metric as "Tickets Solved", as opposed to "Solved Tickets" in the main "Tickets" dataset - can be confusing). 

I discovered this issue when we had been tracking the "Solved Tickets" metric in the main ("Tickets") dataset all this time, just like the article says, and we'd tally up how many tickets were "solved". But when we tallied all our agent's solves, it did not add up at all to the larger amount we had been publishing to our upper management. The "Tickets Solved" metric in "Tickets Updated" dataset is much more closer to the actual number of tickets the agent solved in that timeframe. 

If what I'm saying is true, this article should be removed and revised. 

Dane  Thank you for your response. I hope Zendesk knows how ridiculous this metric is, and how useless it is, and how aggravating it is to us clients, as well as our customers. First of all, if you tell us on our live dashboard that the current wait time is 25 minutes, that's the true wait time, and that's what the customer should hear. There's no rationalizing that. Secondly, there's no value in calculating a non-business hour, and things should be configurable enough that we can checkmark what our hours are so that it includes or excludes a zero-wait time at 4am when we're closed.

I still haven't received a true response for why our callers hear 8 minutes as the max. 8 minutes would only make sense (according to Zendesk logic) if for that 24 hour period thus far, the average was taken down to 8 minutes max. I ran the numbers for 2/3/22, when we had our highest call volume with majority of customers having close to 20 minute wait time on average (according to your query's wait time metric for those hours). If I look at the wait time for the entire day of our business hours, the average wait time is 19.8 minutes! Not 8 minutes.  Even if I pretend we had 200 calls from midnight to 9pm, and each were only 0.1 minutes of wait time, the total average wait time for those fake 200 calls plus our real ones still is 16.7 minutes. Not the 8 minutes our callers are being told. Our callers are being told by Zendesk that their wait time is half of what it really is. And we're the ones who then have to deal with the irate customers. This should be resolved ASAP. It's not a nice-to-have, its a deficiency and inaccuracy in your current process. 

Hello, why is our average wait time announcement always 8 minutes max? We have had a very busy year thus far and there are days where we're hitting 25+minutes in wait time. This is VERY irritating to our customers who think they'll only have to wait 8 minutes for someone to talk to them but actually wait so long they've just wasted their lunch break. 

I'm posting this for everyone's education as far as the "abandoned in voicemail" metric goes. It seems that, according to a Zendesk chat agent, that if a caller hangs up while listening to your voice prompt and you do not have IVR enabled and even if you do not have voicemail enabled, that hang up counts towards "abandoned in voicemail". So if someone gets tired of hearing this message for the 8th time that they've tried to call "Hello, thank you for calling the Company, please listen carefully as our options have changed... we're experiencing a high call volume..., your wait time is 8 minutes", etc.), and they hang up, that gets counted as abandoned in voicemail, even though you don't have voicemail enabled. We've been trying to figure how we could possibly have any calls routed to voicemail. 

If I'm wrong on this, someone please let me know how! 

This certainly seems like it should be a different metric and an enhancement on the backend, with this sort of hang up being counted towards something like "abandoned in greeting." 

Rob Stack Can you please post a diagram for the different ways a call can enter voicemail? We're surprised at how many calls are abandoned in voicemail and want to understand the various paths to voicemail for the caller. Thank you!

We're in an extremely busy season at our company, exacerbated by external factors such as freight/supply chain issues, etc.   For that reason we are seeing an extremely high number of calls in our queue, but, our view is limited to the 50 call cap that Zendesk has placed in the Talk Live view settings. Our account manager says Zendesk has no way to provide us with a view that shows the actual number of calls in the queue in real-time beyond the 50 limit they've set.

Does anyone have a workaround to this? Perhaps a 3rd party app? We really need to understand how many customers are waiting for us, for staffing and planning purposes. 

In the event that a phone call ends prematurely, we need to know whether the customer hung up or disconnected themselves by accident, or if the agent hung up on them or disconnected themselves by accident. When an agent who is working the system continuously is claiming his callers hang up on him (as opposed to him actually taking the calls and addressing them), having that visibility would be helpful to track (metric).