SLA Policies

What Are SLA Policies?

SLA (Service Level Agreement) policies define response and resolution time targets for tickets based on specific conditions. They help you track and meet customer commitments by setting time-based goals and escalation workflows.

SLA policies run automatically and measure metrics like First Reply Time, Next Reply Time, and Resolution Time.

What Configly Captures

For each SLA policy, Configly stores:

• Basic Information

  • Policy title and description
  • Position (evaluation order)

• Filter Conditions

  • All/any condition logic
  • Ticket filters (priority, status, tags, custom fields, etc.)
  • Determines which tickets this policy applies to

• Policy Metrics

  • Metric type (First Reply Time, Next Reply Time, Resolution Time, etc.)
  • Business hours vs calendar hours
  • Time targets by priority (Urgent, High, Normal, Low)

• Metadata

  • Created and updated timestamps

Viewing SLA Policies

Navigate to SLA Policies from your connection dashboard to see all your policies. You can:

• Search by title or description
• Sort by position or last updated
• View filter conditions
• See metric targets by priority
• Compare SLA configurations across connections

Policy Evaluation Order

Like triggers, SLA policies have a position value that determines evaluation order. When a ticket meets multiple policy conditions, Zendesk applies the first matching policy based on position.

Lower position = evaluated first.

Configly displays position values so you can understand which policy applies to which tickets.

SLA Metric Types

First Reply Time

Measures time from ticket creation until the first public agent response.

Use case: Ensure customers get an initial response quickly, even if it's just acknowledgment.

Next Reply Time

Measures time from customer reply until the next agent response.

Use case: Track ongoing responsiveness throughout the ticket lifecycle.

Resolution Time

Measures time from ticket creation until ticket is solved.

Use case: Ensure issues are resolved within committed timeframes.

Requester Wait Time

Measures cumulative time ticket spends waiting for agent response.

Use case: Track actual time customer waits, excluding time when ticket is pending customer.

Common Dependencies

SLA policies often reference:

• Custom fields - Filter conditions check field values (e.g., account tier, product type)
• Tags - Conditions filter by tags (e.g., "vip", "enterprise")
• Brands - Different SLA targets per brand
• Organizations - Different SLA targets by customer organization
• Business hours schedules - Business hours vs 24/7 calendar hours
• Ticket priority - Time targets vary by priority level

Learn more about dependency tracking →

Tips for Admins

Designing SLA Policies

• Start with defaults - Have a catch-all policy for all tickets
• Layer specific policies - Add more restrictive policies with lower position values for VIP customers, urgent issues, etc.
• Business hours matter - Choose business hours vs calendar hours based on your support model

Time Targets

Be realistic about time targets:

• First Reply Time - Often minutes to hours (e.g., 1 hour for Urgent, 8 hours for Normal)
• Next Reply Time - Usually shorter than First Reply Time
• Resolution Time - Hours to days (e.g., 4 hours for Urgent, 48 hours for Normal)

Before Making Changes

• Check impact - SLA changes affect customer commitments
• Verify dependencies - Ensure referenced fields and values still exist
• Test in staging - Preview SLA changes before applying to production
• Communicate changes - Let agents and customers know about new SLA targets

Common Patterns

• VIP customer SLAs - Faster response times for high-value customers
• Severity-based SLAs - Tighter SLAs for critical/high-priority issues
• Product-specific SLAs - Different targets for different products/brands
• Escalation workflows - Triggers that fire when SLA breach is imminent

Maintenance

• Monitor SLA performance - Use Zendesk Explore to track SLA compliance
• Adjust targets - Update time targets based on actual team performance
• Review filters - Ensure policy conditions still match your workflow
• Position order - Audit position to ensure correct policy precedence

Using Configly

• Diff SLA policies - Compare policies between sandbox and production
• Track changes - See what changed in SLA definitions over time
• Identify dependencies - Before removing a custom field, check which SLA policies use it
• Audit policy coverage - Ensure all ticket types have appropriate SLA coverage

Example Use Cases

Enterprise Customer SLA

A policy with aggressive time targets for enterprise customers.

Filter Conditions:

• Organization tags contain "enterprise"

Metric: First Reply Time (Business Hours)

Targets:

• Urgent: 30 minutes
• High: 2 hours
• Normal: 4 hours
• Low: 8 hours

Dependencies to watch: Organization tags, business hours schedule

Default SLA Policy

A catch-all policy for all tickets that don't match more specific policies.

Filter Conditions:

• (none - applies to all tickets)

Metric: First Reply Time (Business Hours)

Targets:

• Urgent: 2 hours
• High: 4 hours
• Normal: 8 hours
• Low: 24 hours

Position: Set high (e.g., 100) so it evaluates last

Dependencies to watch: Business hours schedule

Critical Bug SLA

A policy for critical bug reports requiring fast resolution.

Filter Conditions:

• Ticket tags contain "critical_bug"
• Ticket priority is Urgent or High

Metric: Resolution Time (Calendar Hours - 24/7)

Targets:

• Urgent: 4 hours
• High: 12 hours

Dependencies to watch: Tags, priority values

SLA Breach Notifications

SLA policies work well with triggers for breach notifications:

• Warning trigger - Fires when SLA breach is 1 hour away, notifies manager
• Breach trigger - Fires when SLA is breached, escalates ticket
• Missed SLA trigger - Fires after breach, updates reporting fields

Use Configly to track triggers that reference SLA fields.

Business Hours

SLA policies can use:

• Business hours - Only count time during business hours (e.g., 9am-5pm Mon-Fri)
• Calendar hours - Count all hours, 24/7

Choose based on your support model:

• Business hours - For teams that only work standard hours
• Calendar hours - For 24/7 support or customer-facing commitments

Configure business hours schedules in Zendesk Admin.

SLA Fields in Tickets

When an SLA policy applies to a ticket, Zendesk creates SLA fields you can reference:

• SLA status - Active, Achieved, Breached
• SLA next breach - Timestamp when next SLA will breach
• SLA time remaining - Minutes/hours until breach

These fields can be used in:

• Views - Show tickets about to breach SLA
• Triggers - Send notifications before breach
• Reporting - Analyze SLA performance

Related Objects

• Triggers - Automated rules that can check SLA fields
• Automations - Time-based rules for SLA escalation
• Custom Fields - Fields used in SLA filter conditions
• Views - Views that display SLA status and filter by breach risk