SLA based on internal notesGeplant
The ability to have internal notes to fire SLA policies. This would allow SLAs to fire after a light agent has responded to a ticket.
Meg Gunther We're actively working on SLAs right now. I don't have a more specific timeline I can share right now but these improvements will start launching in the first half of next year.
Scott Allison We are really excited to hear more about the capabilities that you are developing as our organization additionally has several reassignment workflows within our internal teams each with different desired SLAs. We'd love the ability to prioritize the SLA targets within an SLA policy, be able to reassign with ease and be able to have internal notes or public comments start SLAs for internal teams. If there is any way to share more about what features might be included in the release that you are mentioning as well as any guidance on timeframes, this would be really helpful!
Scott Allison Any update on this? I have the same Question as Krista above, are you able to share SLA features that are upcoming and the timeframes of them?
Thanks everyone for your patience and support! Last year I provided an update that SLAs were a top priority, and we had plans for a number of enhancements. I can confirm that work is in progress, and the very first customer facing change has rolled out: an easier way to see upcoming SLA breaches.
The next big change will be the ability to apply "Group SLAs" on tickets as well as SLAs. That will be available to early adopters in Q4 and be generally available in Q1. After that, we'll deliver alerts on SLAs in near real-time instead of once an hour for Automations.
We do plan to address this request as well, at some point in H1 2023. If this is functionality you cannot wait for I'd encourage you to check out one of our partners, Cloudset, who offer this kind of functionality today.
The last 3 years it was possible to activate a SLA with a ticket update via API and a empty end user comment body:
Since july 29 nothing happens anymore. Before the change, the SLA was started with such API request. See this screenshot:
We used this workflow for quite different cases, e.g.
- Starting the SLA for proactive tickets
- Starting the SLA after adding internal comments
- Restarting the SLA because only one public comment was sent as an intermediate message, but a follow-up message must be sent to the customer within a new SLA.
All these cases were realized with a trigger + webhook + the API call above.
So we have to know why was this changed? What are the new workarounds to realize the cases shown?
The last update was in September.
This needs to be fixed.
I have a triage group that assigns tickets to the general queue in a FIFO, which can be overridden by priority.
My agents need to see the SLAs on these tickets, and I need to report on them.
This is a relatively easy change; have the first-time response to measure when an agent added a public comment onto the ticket for the first time, regardless of how it was created.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.