Hey Samuel,
Appreciate the response and agree, that idea you posted sounds more in line with what I was discussing. I suppose my point is that idea is exactly what the original person was wanting, they just didn't realize it based on this specific line in the use case:
so we can help identify and train those agents that may be impacting our service levels.
The only way I can see this metric being useful is if you have multiple agents that take calls for a single queue, but you only ever have 1 agent staffed on a queue at any point because if there is ever more than 2 taking calls at the same time (on-queue), you cannot trust this statistic because other agents will have a negative impact on your ASA.
I imagine that is not very common so my argument was that a metric was implemented that really can't be used, and again, was not the actual intention of the idea. There was another person from a different organization that posted this on the idea as well.
If there is another use-case for this metric please let me know. My major concern is this metric actually does harm because it is misleading. If someone isn't aware that other agents will impact this and you just see an agent with a very high ASA, they could be punished for something not their fault.
If I answered a call in 5 seconds, but 2 people before me with a 24 second alert didn't answer the call, my ASA is going to be 53 seconds in this instance and I don't think that should be the case.
Thank you,
------------------------------
Tristen Schwarzenberger
IT Engineer
------------------------------
Original Message:
Sent: 06-02-2025 07:30
From: Samuel Jillard
Subject: Concern with New Idea DARAR-I-1449 - Agent Performance average speed to answer
Hi Tristen,
I believe you are correct and would require a different metric. The ASA is based on how long the interaction waited to be answered and as you noted, this does take into account the time it alerted other agents. I believe the following idea is what you would want: Add average alerting time next to average handle/talk/hold/ACW in the agent performance view
------------------------------
Sam Jillard
Online Community Manager/Moderator
Genesys - Employees
Original Message:
Sent: 05-28-2025 10:42
From: Tristen Schwarzenberger
Subject: Concern with New Idea DARAR-I-1449 - Agent Performance average speed to answer
Hello Everyone,
I posed this in response to the idea itself, but I also wanted to post here for a discussion. There was a new idea mentioned in the subject that allowed us to add the 'ASA' column in Agent Performance reports, but with how it's working, I'm not sure this is what the intention of the idea was.
The metric does not appear to be useful. I could be wrong and please let me know if anyone has found a good use for it, but the problem with this metric is it factors in agents who are alerted after previous agents who didn't pickup the call.
For instance, we have an agent who received 1 call this week and their ASA is 38 seconds, but at no fault of her own. The queue the call was going into has an alert timeout of 24 seconds. The person before her didn't answer the call so the call waited in queue for that full ring cycle, until it started ringing the next agent which was picked up 14 seconds later.
This essentially punishes agents who come after agents not answering calls which feels like this opposite of what this idea wanted to accomplish.
To me, the actual metric being looked for is "Average Alert" but with the ability to filter that on queue associated calls only.
This was the Use Case mentioned in the idea:
We would like to be able to measure the ASA on particular agents on the Agent Performance dashboard so we can help identify and train those agents that may be impacting our service levels.
If an agent is the 3rd person to get alerted on a queue call, not only is that not their fault, but they also get a higher ASA than the other 2.
Sorry for the long post, but I hope that all makes sense, and would appreciate any feedback/further discussion.
#Metrics
#PerformanceViews
------------------------------
Tristen Schwarzenberger
IT Engineer
------------------------------