Question
How do I create an SLA for agent created tickets?
Answer
Creating a FRT SLA for agent created tickets is not possible. When your agents create a ticket on behalf of the customer, the SLA starts after the customer's initial response and not from the point when the ticket was created.
SLAs measure the average response and resolution times between your agents and customers. An important thing to realize is SLAs are based on ticket events. This means that for tickets to be matched to an SLA policy, something needs to happen to the ticket, like a ticket creation or update event. Otherwise, the ticket shows no SLA information or shows the old SLA information.
Other targets, like Agent Work Time, Requester Wait Time, Next Reply Time, and Periodic Update Time, will still apply and display if the ticket meets the SLA policy criteria immediately on agent created tickets.
Periodic update is likely the best option for applying an SLA to agent created tickets, as it can be applied immediately on the ticket.
Please note that a newly created SLA policy is not applied to existing tickets, so you need to update the ticket to apply the SLA.
24 Comments
Tickets that were reopened (from pending/solved) by light agents does not set the SLA since it was updated with an internal note. This is an issue since most tickets are missing SLAs when more than half of customers are full-service where light agents open tickets on behalf. Will this be addressed? Ideally a setting in option that allow us to treat light-agent tickets similar to end-user when it comes to SLA...
Hi John,
I had a look around and unfortunately there is no option to have the SLA to apply on the ticket, once it is re-opened by a light-agent.
As far I am aware there is nothing on the road map to have an option to make the light-agent comment to be public.
However, I would highly encourage you to post this request on our Product Feedback forum, since that forum is the primary channel used by our Product Management team and other Zendesk users to discuss possible new features and suggest workarounds. I also recommend subscribing to the article so you'll be updated of any further comments. We truly value customer feedback and your voice and votes in the forums help influence future Zendesk functionality.
Thanks!
The explanation for prohibiting the "first reply" SLA when an agent creates a ticket relies on the assumption that those tickets are created on behalf of customers. If you're using ZenDesk across multiple teams for multiple purposes it's possible that agents in one group could be considered internal "customers" when submitting tickets to another group.
I'm relying on the suggested "periodic update" hack to enable sorting by "Next SLA Breach." Ideally, there should be an option to define the agent group(s) excluded from the "first reply" SLA instead of assuming all agents should be excluded.
Steve - I am also facing the same predicament. What is the "periodic update" hack?
We are an Enterprise customer of Zendesk and have the same problem Steve and Gadi have.
We have multiple groups/departments (as any Enterprise does) and cannot apply first touch SLA to those tickets created by an Agent.
You would think, you could add a tag to the tickets, via a Trigger and then specify that tag to be included in the First Touch SLA also.
I agree. We are an enterprise customer as well and would like the SLA to begin anytime a ticket is opened, whether internally or from a customer. For us, an SLA should be applicable for every step along the away, whether the next step is internal or not (after first reply time). The ticket workflow demands movement, without and SLA in the ticket, we don't know unless we look at every ticket over and over again.
Has anyone found a work around for this?
I am thinking about taking the time stamp of when a case is created and making a custom tag or something to stamp the time when the first public comment is made by a ZD agent. Then create a formula to take the difference of the times and compare them to the SLA of the priority and get a 1 or 0 value if equals true or false and then get the percent that was within the SLA to figure out how much we are meeting or missing our first respond time.
I am new to Zendesk so still figuring out the ins and outs and was highly disappointed when I came across this post. Is the power of 1 useful in explore or am I going down a rabbit hole?
Desperately needing a solution to this as well.
If there was some way to automate adding an SLA after a light agent comment I think that would fit the bill for a lot of people.
Come on Zendesk. Love the product but this is a requirement for many of us How can we get this done?
Having an option to allow agent created tickets (public or no public comment) be included would be the best option. Just a switch that lets it count for SLA First Response or not. If you have integrations that create tickets then you need this option because you can't really work around things without just flagging it to count yes or no.
I have a workaround for this. It will immediately start the "next reply" SLA time though (not "first reply").
Since in our case first reply and next reply are mostly the same, maybe this could also work for you.
You can fake a customer comment by updating the ticket through an external target with this:
{
"ticket": {
"comment": {
"body": "",
"author_id": {{ticket.requester.id}}
}
}
}
So if you create an external target and send this to the {{ticket.id}} you want to update, it works.
@Fabio this sounds like it could be extremely useful for us. I tried sending this to an external target email address (a dummy mailbox) but it doesn't appear to be working.
An HTTP Target.
You need to create an API Token as well for Authentication.
Thanks, getting closer. I get told that the JSON isn't valid now. It doesn't like the
"author_id": {{ticket.requester.id}}in the JSON, and if I escape the braces around ticket.requester.id I get a message saying it needs to be an integer.
Do you mean invalid like this:
Because this doesn't matter. It works anyway. ;-)
Yeah I did mean that originally but then tested it and get a 422:
I don't know what the problem might be. But maybe this time somebody from Zendesk might be able to help you out. ;-)
No worries at all, I've already opened a support ticket with them.
I really appreciate your help in getting me even just this far.
I don't understand Zendesk's logic here. Light agents or agents open internal tickets on behalf of customers nearly 100% of the time, when customers call in for support. Those tickets may have to be sent to other departments for assistance. Don't these tickets deserve to be tracked with SLAs? This is EXTREMELY frustrating.
Hey Fabio, got this working, thank you very much.
The simple fact is that using the Zendesk 'Test' functionality breaks. But you're right, this does work!
@Russel & Fabio
What is it you guys are triggering. I couldn't find a trigger like "Ticket created by agent in the name of customer"
I'm using a Macro that adds a "sla_stop" tag. I have that as the condition.
Of course you need to remove this tag again in the Trigger.
Thanks for the answer Fabio.
In the meantime I found something myself:
This is based around the Channel Web Form:
In our instance agents are only supposed to answer questions, not raise them, so that works for us ;)
Zendesk may originally been designed as a product for a company to use to support external non agent only users, but I think we can all agree there is a large amount of customers at this point who user the tickets internally. Where one agent submits a request that will be worked on and resolved by an agent of another group. In all these cases there is no way to measure the first reply metric without external add-ons or tag work arounds that do not interface with the basic agent view of SLA timers.
Is there any update from Zendesk on this feature or SLA's in general being improved for Agent workflow in the future?
Please sign in to leave a comment.