How do they work?¶
You can define several independent SLAs, however, ensure to have no overlapping SLAs as their calculations may not work as you intended them originally.
Updating existing SLA configurations may cause temporary performance issues depending on your instance size and affected tickets. You may want to perform those changes outside of your business hours.
Communication type articles are not enough for your SLA? You can also configure Zammad to allow public notes as fulfillment for SLA requirements, our console documentation tells you how.
Give your SLA a meaningful name to quickly see what or who is affected.
- Ticket selector
Specify the conditions on which tickets this SLA should apply to.
👋 Looking for more depth explanation on conditions? 🤓
Many condition settings in Zammad, no matter if in ticket scope or not, re-appear in several places of Zammad. For this reason we created a dedicated documentation section to reduce duplicate drag.
Have a look at Object conditions to learn even more! 🎉
In the preview you see the selection of the tickets and double check whether those are correct.
Zammad calculates ticket escalations based on your business hours. It makes no sense to escalate tickets when you’re not in.
Choose the correct calendar here. If you haven’t set your business hours yet, see Calendars to learn more.
- SLA Times
Define the escalation timings based on your working hours. Keep in mind that if you defined 8 hour business hours per day, a 16 hour escalation will take two business days.
- First Response
Time frame for the first response (external call, email). This time is calculated from the ticket creation.
The start time does not reset if you’re e.g. moving the ticket into new groups or different SLA calculations. That is because the creation time of the ticket does not change - keep this in mind.
- Update Time
Time frame for every following response (external call, email). This time either counts from ticket creation (if no first response is set) or after the first response was done.
- between agent updates
In this scenario your agent have to respond every
nhours depending on your configuration. This causes Zammad to not care if your customer replied or not.
This setting can be quiet stressful for your agents.
- for an agent to respond
From the moment your customer replied to the ticket, your agents have the configured time amount to respond until the ticket escalates.
- Solution Time
Time frame for solving the problem (setting the ticket to a closed state type).
This escalation timing does not care about ticket responses. It’s being calculated from the ticket creation.
It is up to you if you set one, two or all three times. When the SLA time is reached, the ticket escalates.
First response and Solution time can only apply once. Update time applies until the ticket has been solved or the SLA no longer matches your criteria.
The only way to stop escalations in default installations is to set the ticket to either a pending reminder or pending close. However: as soon as the ticket is being set to open (e.g. by a customer responding) the ticket may instantly escalate depending on its age and your configuration.