SLA Policies - Different targets based on context – Available ApS

In a world where customer expectations are constantly rising, SLA Policies are not just a technical feature in Zendesk. They act as a central foundation for customer service and as a clear promise to customers. SLA Policies define what can be expected and give support teams clear, measurable targets for service delivery. With differentiated SLA Policies, it is ensured that enquiries are not handled identically, but that response and effort are adapted to the context and value of the individual ticket.

What is an SLA Policy?

An SLA Policy is a set of predefined rules that establish time targets for how quickly a customer's enquiry must be handled. The rules act as an automatic contract between the organisation and the customer and ensure consistency and transparency across support channels. Each policy is typically built around three central metrics:

First Reply Time (FRT): The maximum time from a ticket being created until the customer receives the first response from an agent. This metric is important for acknowledging the enquiry and aligning expectations for the further process.
Next Reply Time (NRT): The maximum time from the customer replying until a reply is given again. This metric reduces unnecessary pauses in the dialogue and supports a stable customer experience.
Resolution Time: The maximum time from the ticket being created until the problem is solved and the ticket can be closed. This metric reflects the overall efficiency and the ability to deliver a final solution.

By combining the metrics in different policies, a nuanced and dynamic system can be established that reflects business priorities.

Strategic value: Why differentiated SLAs are crucial

A uniform ("one-size-fits-all") SLA can lead to overloaded teams or dissatisfied customers. The greatest effect is achieved by differentiating targets based on business-critical factors, so that resources can be prioritised where they create the most value.

Based on brand

When supporting several brands, SLAs can help support each brand's service level and promise.

Premium brand: Customers expect a more exclusive service. A policy could, for example, be First Reply Time: 1 hour and Resolution Time: 4 hours.
Standard brand: Expectations are still high, but more moderate. A policy could, for example, be First Reply Time: 4 hours and Resolution Time: 24 hours.

Based on priority

Not all problems have the same business impact. Priority levels can ensure that critical issues are handled first.

Urgent: A system outage affecting all customers. First Reply Time: 15 minutes, Resolution Time: 2 hours.
High: A problem that blocks a single customer's core functions. First Reply Time: 30 minutes, Resolution Time: 4 hours.
Medium: A general enquiry or minor problem. First Reply Time: 4 hours, Resolution Time: 24 hours.
Low: An improvement idea or minor cosmetic error. First Reply Time: 24 hours, Resolution Time: 72 hours.

Based on customer type

Higher-value customers can be assigned faster and more dedicated targets.

VIP/Enterprise customers: Customers with a high lifetime value (CLV) can be assigned a dedicated SLA, e.g. First Reply Time: 30 minutes.
Standard customers: A standard SLA that balances service and efficiency.
Free Tier/trial period: Customers who are not yet paying for the service can be assigned a longer SLA in order to prioritise paying customers.

Based on channel

Expectations depend greatly on the chosen contact channel.

Phone: The customer is actively waiting in a queue. Here, the SLA is about response time in the queue, not ticket response.
Chat: A real-time channel with an expectation of a response within a few minutes. First Reply Time: 60 seconds.
Email: An asynchronous channel where the expectation is typically a response within a few hours or the same business day. First Reply Time: 4 hours.

In-depth look at SLA metrics

For effective use of SLAs, it is important to understand the nuances of each metric.

First Reply Time (FRT)

FRT is the first opportunity to create a good experience. A fast FRT reduces uncertainty and builds trust. Even without a final solution, a quick acknowledgement shows that the case has been received and is being handled.

Example: For enquiries via a chatbot that are escalated to an agent, you can aim for an FRT of under 90 seconds in order to preserve a perceived real-time feel.

Next Reply Time (NRT)

When the customer replies with additional information, the measurement starts again. A long NRT can give the impression that the case has been forgotten. The metric is particularly important in longer cases with many dialogue steps.

Example: If a customer sends requested log files, an NRT of 2 hours can be used to confirm receipt and provide a status update.

Resolution Time

Resolution Time is the overall measure of efficiency. The metric is not just about fast responses, but about solving the problem. A low resolution time is often associated with high customer satisfaction (CSAT). Speed should be balanced with quality, as a fast but incorrect solution is worse than a slower, correct solution.

Configuring SLA Policies: A step-by-step guide

Creating an SLA Policy in Zendesk is a process with flexible options.

Navigate to the Admin Center: Go to Admin Center → Objects and rules → Tickets → SLA policies.
Create a new policy: Click Add SLA policy.
Name the policy: Provide a descriptive name that clearly shows the purpose, e.g. "Enterprise - Urgent SLA" or "Standard - Email SLA". This supports administration and troubleshooting.
Define the targets: Set the time targets for FRT, NRT and Resolution Time. You can choose between hours, minutes or business days.
Choose a schedule: Link the policy to a schedule (e.g. "Denmark - Business Hours" or "24/7 Support"). The schedule determines when the clock counts.
Apply the policy via conditions: Define which tickets are covered. Conditions can be based on Brand, Priority, Group, Ticket form, Custom fields and others.
- Example of a condition: Ticket > Priority > Is > Urgent AND Ticket > Group > Is > Technical Support.
Save and activate: Save the policy and make sure it is active. It is also possible to create it as inactive until implementation is desired.

Schedules and working hours: When does the clock count?

An SLA of "8 hours" can mean different things depending on when the clock counts.

Business Hours: The SLA counter only runs during defined business hours (e.g. Monday-Friday 9-5). A ticket created on Friday at 4 pm will have 7 hours remaining on Monday morning. This is the standard for many B2B support teams.
24/7: The SLA counter runs constantly, around the clock, every day of the week. This is relevant for critical systems or global brands across time zones.
Custom Schedule: Custom schedules can be defined, e.g. extended service 8 am-10 pm or a schedule that only applies at weekends.

Holiday calendars and local public holidays

To ensure fairness and accuracy, holiday calendars can be integrated into schedules. Public holidays such as Christmas, Easter or Constitution Day are automatically deducted in the SLA calculation. This prevents teams being measured on days without expected staffing and supports a consistent service experience for customers globally.

Applying SLAs in practice

An SLA Policy is only effective if it is applied to the right tickets at the right time. Automation typically happens via three methods:

1. Triggers

Triggers are "if-then" rules that run when a ticket is created or updated.

Example:
- Condition (IF): Ticket is Created AND Custom field "Customer Tier" > Is > "VIP"
- Action (THEN): Set SLA policy to "VIP Support SLA"

2. Ticket forms

Each ticket form can have a default SLA Policy. This is relevant when the form indicates the type of enquiry. A "Payment problem" form can, for example, have a faster SLA than a "General enquiry" form.

3. Manual assignment

In special cases, an agent or team leader can manually change the SLA on a ticket. This is typically used for escalation or handling exceptions that automated rules do not catch.

Handling SLA breaches: From proactive warning to escalation

SLAs can be breached, even with clear targets. A clear plan for proactive handling and reaction is crucial.

Proactive warnings

The system can be configured to give advance notice before a deadline is reached.

For example, 30 minutes before an FRT breach: The ticket automatically gets a tag such as SLA Warning and appears in a specific view for the team leader. The agent can at the same time receive a notification. This creates a window for action before the customer experiences a delay.

Handling actual breaches

When an SLA has been breached, the handling should be quick and structured.

Automatic actions: A trigger can add the tag SLA Breached, raise the priority to High and escalate the ticket to another group (e.g. from L1 to L2 support or to a team leader).
Internal communication: The team leader receives a notification and can take ownership to ensure clarification.
External communication (important): The customer should be informed proactively. A message such as: "We apologise for the delay in our response. The case is more complex than expected, and we are actively working on a solution. We will provide an update within [new, realistic timeframe]." can support the customer experience.

Best practices for effective SLA strategies

To get the most out of SLAs, the following principles can be applied:

Start with data, not wishful thinking: Analyse historical data to set realistic targets. What is the current average FRT and Resolution Time? Targets should be ambitious, but achievable.
Differentiate meaningfully: Differences in SLA targets should be justified and noticeable for both the customer and the team. A VIP customer should experience markedly better service.
Communicate clearly: Ensure that both customers and agents understand the meaning of SLAs. Standard response times can be communicated on the website or in auto-response emails.
Monitor and report continuously: Use Zendesk's reporting to monitor SLA performance. How many tickets meet the targets, and where do bottlenecks occur?
Adjust and optimise: An SLA strategy is not static. Policies can be reviewed quarterly and adjusted based on performance data, agent feedback and changes in business strategy.
Document and communicate internally: Ensure that the support team knows the different SLAs and understands the rationale behind them. This supports ownership and motivation to reach the targets.

Troubleshooting and common challenges

Even a well-configured setup can cause challenges. Below are typical problems and their corresponding solutions:

Problem: The SLA counter runs even though the ticket is set to "Pending".
- Solution: Check the SLA Policy settings. There is an option to pause the clock when the status is changed to "Pending" or "On-hold". Make sure it is enabled.
Problem: The wrong SLA Policy is applied to a ticket.
- Solution: Review the triggers. A trigger higher up the list can override a trigger further down. Use the "Audit Log" in Zendesk to see which action changed the SLA, and which conditions were met.
Problem: Constant SLA breaches are experienced despite high activity.
- Solution: This may indicate unrealistic targets or understaffing. Analyse the load and consider adjusting SLA targets or internal workflows to improve efficiency.
Problem: SLAs do not count at the weekend, even though they should.
- Solution: Double-check the schedule that is linked to the SLA Policy. Verify that it is configured for 24/7 or includes weekend days.

The way forward: Implementation and optimisation

SLA Policies require ongoing work and adjustment. With a structured approach, customer service can be developed from reactive to proactive, data-driven and customer-centred.

Analyse and define: Start with a thorough analysis of current performance and customer needs. Define clear, differentiated targets.
Implement gradually: Roll out new SLA Policies in phases. Start with one ticket type (e.g. based on priority) to test and fine-tune before expanding.
Escalate and automate: Establish triggers and views for automatic allocation, warnings and escalation.
Measure, learn and adjust: Make reporting a regular practice, and use the insights for continuous improvement of both SLA targets and supporting processes.