最近搜索
没有最近搜索
Service Level Agreements - please share your feedback!
已于 2021年11月05日 发布
Over the next few quarters we'll be working on a range of improvements to our SLA feature set. We'd love to learn more about what you need, and where we should focus our efforts.
Current State:
Our SLA feature set works for some customer facing use cases, but less well for any internal ones. It's also not consistent and available in all channels (e.g. Chat/Messaging). There's also no way to get notifications in real-time or in-product.
Our questions for you:
-
What works well today with the SLA feature?
-
What limitations do you hit while using it?
- What do you wish it would do differently for you? Why?
-
What is the impact on your business?
How to help:
Please let us know your thoughts in the comments below. This post will remain open for one month, at which point we’ll close it and incorporate our findings here into the rest of our research.
We are also interested in having a 1:1 conversation to dig deeper with a few customers. If you’re interested in participating in our research that way, please please indicate that in your comment as well and we’ll follow up via email.
Thank you!
3
34 条评论
Heather Rommel
@...,
I think I've posted this before but I can't find it for the life of me so here goes:
What works well today with the SLA feature?
SLAs are easy to apply in vanilla instances where a ticket is created and FRT or Next Reply SLAs are needed.
What limitations do you hit while using it?
For Pausable Update, our biggest frustration is there MUST be a comment submitted as OPEN for the timer to ever appear. Well, support reps as part of their normal cycle are taught to make a comment and submit as Pending, because we're usually waiting to hear back from the customer. Well, when we want to apply Pausible update, no timer ever appears because we don't ever make comments and submit as Open.
Pausible Update should apply if we make a comment in Pending and just pause the timer. That's expected behavior and therefore a bug in our eyes at the moment. Do you know how hard it is to get 100+ agents to remember to take extra steps on every ticket? Please allow the Pausable Update to apply when we make a comment and hit Submit as Pending!!!
We wish we could get pausible update timer to appear if we make a comment and submit as pending. LOL. I think you get that.
Also, we have needs to change the priority of a ticket or apply a different SLA and want the timer to count FROM THE TIME OF THE CHANGE, not from the ticket created time or last comment time. So in other words, I have Next Reply time on a ticket. But my assignee determines they need to move the ticket to a different team. We want to re-apply next reply time from the time of group change, not from last reply.
Lastly, we need to be able to check via trigger whether an SLA timer is applied on a ticket. In other words, I want to alert someone via email that a ticket does not have a timer applied. We need a condition in triggers to check for whether an SLA is present and which SLA policy please!
What is the impact on your business?
Agent frustration is the biggest impact. We don't understand why it's not more flexible. We struggle daily to educate and reeducate assignees, but it's just not intuitive with the Pausible Update in particular!
5
Dan Cooper
What works well today with the SLA feature?
What limitations do you hit while using it?
What do you wish it would do differently for you? Why?
What is the impact on your business?
0
Katie Cerrone
Need SLAs to accurately report on tickets that transfer between agents.
We use "tiers" as different levels of support. When creating a report to show us our % of SLA achieved broken up by tiers, we noticed that if we sort by "tier" the tier is actually measuring the response time from when the ticket first appeared, and not the response time of the tier the ticket is currently in. For example, T3 shows as 100%, but that is only because the ticket was initially on T1 and T1 responded in SLA. So, the tier is only reflected as the tier the ticket is currently in, not the tier in which the SLA was achieved or breached.
Each tier should have it's own SLA. If a ticket comes into tier 1, it has a specific SLA. If it is transferred to tier 2, it should have a new SLA. We want to see a report with the % achieved for both of those tiers to see how well the tier 1 team did AND how well the tier 2 team did. It seems though like the way it is set up now it only checks when the ticket was created and then from that point onwards it only checks resolution times.
When I reached out to Zendesk, they let me know that this is a current product limitation. "The SLA belongs to the ticket as a whole, not each individual and ultimately the last assignee will inherit all of the SLA targets in reporting. For this reason, SLAs do not accurately report on tickets that transfer between agents."
We really need this in order to more effectively understand how our teams other their Tier 1 are doing.
0
Scott Allison
Thank you all for providing your feedback on this thread, it's truly appreciated. We have been monitoring and collecting your comments, and feel we have the information we need to make our ongoing product decisions. We are now going to close out this thread for comment. There are still specific requests for SLA enhancements in the Community, and I'd encourage you to upvote those if you have not already. We still have an exciting roadmap ahead for SLA enhancements and will publish announcements with every release. If you want to follow those, you can click on the follow button on this page.
0