Introduction
Teams rely on clear service‑level agreements (SLAs) to ensure customers receive timely answers. Zendesk’s native SLA policies measure first reply time, next reply time and resolution time, but they cannot handle every workflow nuance. The Timers app bridges this gap by letting you create unlimited, independent timers that start, stop, pause and resume based on the ticket conditions you define. This article outlines what Timers can do and shows three common SLA patterns you can implement in minutes.
How the Timers App Works
- Timers live on tickets. You can add any number of timers to a ticket via triggers or automations.
- Four core actions drive each timer lifecycle:
| Action | What it does | Typical trigger condition | Notes |
|---|---|---|---|
| Start | Begins counting seconds/minutes/hours | Ticket created, status = Open, priority set, etc. | A timer can start once or many times. |
| Stop | Locks the elapsed time and prevents future accumulation | Status = Pending/Solved, agent replied, etc. | Once stopped, a timer cannot run again unless you explicitly restart it. |
| Pause | Suspends counting without losing the already‑logged time | Waiting on customer, On‑hold, etc. | Great for “customer pending” stages. |
| Resume | Continues counting from the paused value | Customer responds, status = Open, etc. | Keeps the same timer record; no need to create a new one. |
Three Proven SLA Timers
| # | SLA Goal | When to Start | When to Stop | Why use this pattern? |
|---|---|---|---|---|
| 1. First Response | Measure how long new tickets wait for an initial agent reply. | Ticket created. | Agent sends first public reply. | Classic SLA; simple, deterministic. |
| 2. Next Reply Time | Track agent responsiveness after each customer reply. | Ticket status moves to Open (i.e., customer updated). | Ticket status changes to Pending (agent replied). | Guarantees a clean loop between customer updates and agent follow‑ups. |
| 3. Final Resolution | Ensure tickets reach a solved state within the contracted time. | Ticket created. | Ticket status changes to Solved. | Provides an end‑to‑end service commitment while accommodating customer re‑opens. |
Implementation Steps
- Design your SLA matrix. Identify which of the three patterns (or variants) map to each of your support tiers.
- Create separate timers for each SLA. Keep the logic clear; don’t try to merge first‑response and next‑reply in a single timer.
-
Build Zendesk triggers to fire the start/stop/pause/resume actions.
- Example: "If status equals Pending then Stop ‘Next Reply’ timer."
- Set breach thresholds in the Timers app and decide whether you want hard stops (breach at X minutes) or warnings (e.g., 80 % of target).
- Test your workflow with dummy tickets to confirm timers behave as expected.
- Report & iterate. Use the Timers reporting tab or export events to Explore/BI to see breach trends and refine timing.
Best Practices & Tips
- One timer, one purpose. Clarity wins; overlapping logic leads to false breaches.
- Lean on ‘Pause’ for customer wait states. This avoids penalising your team when the ball is in the customer’s court.
- Use trigger ordering to ensure the correct sequence (start before pause, etc.).
- Combine with Zendesk SLA policies – Timers doesn’t replace native SLAs; it augments them where native logic is insufficient.
- Consider implementation services. Complex multi‑brand or multi‑tier setups may benefit from a partner’s deep dive.
Need Help?
If you’d like expert assistance designing or auditing your SLA workflow, we have certified partners who can help implement and optimise Timers for your unique processes.