Best practices: Using automations to create service level targets Follow

Important: There is an updated version of SLAs for Professional and Enterprise. See Defining and using SLA policies . This article applies to the previous version of SLAs.

Customers expect a higher level of customer service now more than ever before. The key to a high customer satisfaction rating is not only providing an answer that solves your customers question, but providing it in a timely manner.

Businesses need to be able to monitor how long it takes for tickets to pass through different stages in the support lifecycle. This article will detail best practice recommendations for setting up your service level agreements in Zendesk using automations.

To help explain this concept, I’d like to introduce Melody, the customer service manager for FlyLo (a fictitious airline). As the customer service manager, Melody has specify targets for her support team to meet:

  • Assign a new ticket to an agent within two hours of it being created
  • Respond to tickets that are waiting for a reply within three hours

For Melody to monitor whether her Support team is meeting these targets, we'll create automations. Automations allow actions to be performed according to a specified timeframe (from 1 hour to 28 days). If you’re not familiar with automations, this article is a great place to start.

Tip: If you have the Professional or Enterprise plan, you should enable Business Hours . This option enables you to specify time conditions in business hours rather than calendar hours. This is useful if your Support team is not operating 24/7. When business hours are specified, your service level agreements only take into account the hours that you work. To enable this option, click the Manage icon in the sidebar, then click Account and select the Localization tab.

Business Hours

You should be proactive when it comes to SLAs rather than reactive . In this scenario, being proactive involves sending email notification to the Support team one hour before the SLA is breached, so the team knows that the clock is ticking but they still have time to meet the target. Being reactive involves sending an email notification only after the SLA target is breached.

It’s always better to be one step ahead. So we’ll create two automations to ensure new tickets are assigned to an agent within two hours of it being created. The first automation will notify the Support team by email when a ticket hasn’t been assigned for an hour, but it is still within the SLA. The second automation will notify the Support team when a ticket hasn’t been assigned more than two hours and also escalate the priority of the ticket to high.

Tip: When creating business rules (triggers or automations) in Zendesk, be sure to give them meaningful titles. This is really helps when it comes to maintaining your business rules, so you can easily identify what each one does. Avoid naming them Trigger 1, Automation 1, and so on.

Let’s now go create an automation to make sure the FlyLo Support team assigns a new ticket to an agent within two hours of it being created.

Automation 1 - SLA: Assign ticket warning after one hour

This is the proactive automation that warns agents that a ticket hasn’t been assigned but there is still time to act before the SLA is breached. The automation below will execute when the following conditions have been met. Let me explain the reason for each condition:

  • Status Less than Pending: When a ticket first arrives in the FlyLo Zendesk, it is unassigned and has a status of New. However, during the triage process, an agent might add additional information to a ticket or update ticket fields. If this occurs, the status changes from New to Open but the ticket is still unassigned. Because we want this automation to execute for tickets that are New or Open, the status condition is less than Pending.
  • Hours since created (business) Greater than 1: We want this automation to execute after one business hour. Notice that we are using business hours rather than calendar hours. This means the SLAs are only in effect during the hours FlyLo operates.
  • Assignee is - : We want this automation to execute only on tickets that are unassigned.
  • Contains none of the following ‘sla_assign_warning’: This is essential to ensure the automation is not executed in a loop. I will explain this in further detail shortly.

Automation: Assign ticket warning after 1 hour

Now that we know why those conditions have been chosen, let’s take a look at the actions this automation will perform:

  • Email group Support: An email notification will be sent to the group Support warning them that they need to assign a particular ticket but they still have an hour before the SLA is breached.
  • Add tags ‘sla_assign_warning’: This is a crucial action to ensure the automation is not executed in a loop. This is used in conjunction with the condition “Tags Contains none of the following ‘sla_assign_warning’.” This means that when this automation executes, a tag is applied to the ticket indicating it has been executed. The automation won’t execute in a loop because one of the conditions of the automation is that a ticket doesn’t already have the ‘sla_assign_warning’ tag. This is called nullifying an automation.

Tip: There are two key differences between the actions set tags and add tags . When you use set tags , it replaces all existing tags on a ticket with the tag that you specify. When you use add tags , it will simply add another tag to a ticket while preserving all the tags that already exist on the ticket.

T here are other ways to nullify an automation rather than using tags. For example, you could use the ticket status. If a condition of an automation is that a ticket has a status of New, the action performed by the automation could change the status to Open. By doing this, there is always a clear difference between when an automation has been executed and when it hasn’t.

SLA warning actions

Tip: Instead of sending email notification, you could use Zendesk targets to send notifications to external destinations. For example, if the SLA of a ticket is breached, you could notify a Twilio target that sends an SMS to the Support team manager. To configure targets, click the Manage icon in the sidebar, then click Extensions and select the Targets tab.

Automation 2 - SLA: Assign ticket within two hours

Now let's set up a reactive automation that sends email notification to alert the Support team that the SLA has been breached. It only executes when the following conditions have been met. We’ve already talked about these conditions, the only difference is that the time condition is two hours rather than one.


Additionally, this automation escalates the priority of the ticket to High to get the attention of the Support team.


Now that you understand how an SLA automation is created, let’s look at another example.

Automation 3 - SLA: Update ticket within three hours

This automation executes when a customer is waiting for a reply (since the status will be either New or Open) and the last update from the assignee was greater than three business hours ago.



Tip: To check when your automations have executed, click Events in the upper-right of a ticket. Not only is this great for checking that your automations are working, but also for seeing a full audit trail of all the updates that have been made to a ticket.



Monitoring your SLA Performance

Throughout the automation examples in this article, tags were applied when automations executed. An example of these are sla_assignee_breached and sla_update_breached. You can use these tags in views and reports to monitor your SLA performance.

Views provide a simple way to gain insight into a collection of tickets based on conditions that you specify. Whenever you’re creating views in your Zendesk, make them meaningful to your business. You aren't limited to the default Views that are provided in your Zendesk. Customize or create views to suit your own business processes.

Let’s look at a view created to monitor FlyLo’s SLA performance.


This view lists tickets that have breached the update time SLA since it requires tickets to have the ‘sla_update_breached’ tag. What’s more, if you only want managers to see this view, you could restrict it to a group of users or individuals.



Using Advanced Analytics (on Professional and Enterprise plans), you can create a report that shows the percentage of tickets that breached SLAs by filtering tickets with the SLA tags that are applied by automations.

Have more questions? Submit a request


  • 0

    Really helpful article.

    Still believe it is essential to automatically set some form of due date (which is paused when calls become pending) based on priority/sla so that agents know how long they have got left to work on the call and clients ahve a rough idea of when they can expect a resolution.

    Once again though I think its worth mentioning this is a really useful article, especially like the case study format.

  • 0

    Sammy, glad you liked the article. And thanks for the feedback! We appreciate it.

  • 0

    One problem about "Automation 3 - SLA: Update ticket within three hours", if things happened by the following steps:

    1. Agent replied and set the ticket to Pending;
    2. 3 hours passed;
    3. Customer replied and the ticket is auto put back to Open;

    The automation rule could be triggered any time from the 3rd step on. But I think the reasonable behavior is to wait another 3 hours after the 3rd step.

    Haven't figured out a good solution for this. Any suggestion is appreciated!

  • 0

    @Wei Wei I believe 'Hours Since Update' field will help you.

  • 0

    Hi Wei Wei,


    If you add another condition that says 'Hours since Open' is greater than 3, it will prevent the Automation from firing immediately after the customer responds in your example.

  • 0

    This is a great article, and very helpful..but I'm trying to wrap my brains around how to set up a SLA for first reply. Here's what I have:

    Ticket: Status less than Pending

    Ticket: Hours since Created: Greater than 1

    Ticket: Assignee: is not  (null)

    Ticket: Tags: contains none of the following: sla_update_violation

    Ticket: Priority: is Urgent

    and here's where I get stuck. I don't want to judge against constant updates, only the first update right now

    I would think that Ticket: Hours since assignee update is the field I want, but I can't figure how to go. It won't take a null field, and greater than 1 would fire off on subsequent updates.




  • 0

    @Craig, I think you'd need a trigger and then an automation for this. The trigger would tag a ticket if an agent replies on a ticket. Here's an example of what that would look like:

    Then you can build an automation that fires if hours since created is greater than 1, but that tag is not in place (just add it to the existing 'Ticket:Tags' 'Contains none of the following' condition). It will only fire once as long as you don't remove that original tag. 

  • 0

    I'm just starting to poke around. If there is an SLA set up for a group of tickets, can one or more of those tickets be assigned a revised SLA without assigning he revised SLA to the entire group of tickets? Thanks

  • 0

    Hi James, 

    Would you mind providing a specific example of why a ticket would require a revised SLA? This will help me help you.

  • 0

    This strikes me as rather useless given my current understanding of automations (which to be fair may be wrong, so please do correct me) -  especially the last part on setting up reporting metrics based on these tags. This is extremely inefficient given you will end up with a set of data that is factually inaccurate.

    If automations run on the hour then given the below scenario, it's easy to see how your reporting can become completely skewiff.


    Automations run at say 10:00, next running time is therefore around 11:00

    A ticket was raised at 10:05 with an SLA fix time of 1 hour

    Automation runs at 11:00 but doesn't pick up the breach condition because the ticket still has 5 mins left to run on its clock

    11:05 and the ticket has breached SLA but automation won't run again until around 12:00 - leaving the support agents with a deficit of 55 mins.

    12:00 and automation runs and then emails support agents that ticket has breached SLA and tags ticket as being breached - great, but you've just lost 55 mins of time that could have been spent fixing the issue, apologising to the customer etc.

    This will of course also extend to any warnings that you have in place for letting agents know that an SLA breach may be imminent.

    These automations are good for guidelines, but I wouldn't want the support department to rely on them or reporting for that matter.

    There has to be some kind of granular control that will send out notifications at the exact time a ticket breaches an SLA. This is a fundamental feature of any ticketing software, otherwise what's the point?

  • 0

    @Toby Roger

    Love the way you explained this concept.

    I think that tag 'sla_update_breached' will remove this ticket from future SLA violations for ever. You need to remove that tag by creating a trigger like

    When Ticket is updated,
    Ticket comments is public,
    Other: Current User is agent
    Ticket tags contains at least one of the following 'sla_update_breached'

    In preform these actions
    Remove ticket tags 'sla_update_breached'.

    This trigger will then make this ticket available for future SLA violations.


Powered by Zendesk