TodaysBruHow to Build an IT Helpdesk SLA: Priority Levels, Response Times, and a Practical Template
Build a practical IT helpdesk SLA with a copyable template, illustrative priority targets, support calendars, pause rules, escalation, and clear reporting.
· 6 min read · The TodaysBru team“We’ll get to it as soon as possible” leaves employees guessing and technicians deciding what matters under pressure. A useful service-level agreement explains which problems take priority, when someone will respond, what outcome to expect, and what happens when progress stalls.
Start with commitments your team can deliver. Agree them with the people responsible for the business services you support, then configure your helpdesk to measure them. A timer setting alone is not an SLA.
Start with this one-page template
| Item | What to agree |
|---|---|
| Scope | Services, employees, locations, and request types covered |
| Ownership | Service owner, support owner, and business representative |
| Support calendar | Working days, hours, timezone, holidays, and emergency coverage |
| Priority rules | How business impact, urgency, and available workarounds determine priority |
| Targets | First response, restoration, resolution, or request fulfillment—as applicable |
| Measurement | Required attainment percentage, reporting period, eligible tickets, and exclusions |
| Clock rules | When each timer starts, pauses, resumes, and stops |
| Escalation | Who acts when work is at risk, what they do, and when employees receive updates |
| Review | Review date, agreement version, and approving parties |
Complete this together before promising deadlines to employees.
Is there a standard set of SLA times?
There is no universal timing table every helpdesk should copy. ITIL service-level management emphasizes clear, business-based targets. Your commitments should reflect the importance of the service, available staffing, support hours, and dependencies. See PeopleCert’s ITIL guidance.
A small weekday team and a staffed 24/7 operation should not make identical promises.
Set priority from impact and urgency
Ask three questions: What work is blocked? Who is affected? Is there an acceptable workaround?
A company-wide login outage usually needs faster action than a malfunctioning secondary monitor. However, a problem affecting one person can still be critical if it blocks an essential, time-sensitive business activity.
Document examples for each priority so employees and technicians can apply the same rules.
Separate response, restoration, and resolution
- First meaningful response: someone takes ownership and provides a useful next step. For this template, an automated receipt does not qualify.
- Restoration: the affected service becomes usable again, potentially through a workaround.
- Resolution: the incident meets your agreed resolution criteria.
An incident may be resolved after service is restored through an accepted workaround. The underlying cause can still require a permanent fix. Define when employees confirm recovery and when the ticket closes. Restoring service is a central goal of incident management. See Atlassian’s incident-management guidance.
Use example targets as a starting point
The following are illustrative incident targets for a team with staffed critical-incident coverage and an eight-hour weekday support calendar. They are neither ITIL requirements nor TodaysBru defaults. Validate them against workload and capacity before agreeing them.
| Priority | Example | First meaningful response | Restoration target |
|---|---|---|---|
| P1 — Critical | Essential service unavailable with severe business impact | 15 elapsed minutes, 24/7 | 4 elapsed hours, 24/7 |
| P2 — High | Important work blocked with no acceptable workaround | 1 support hour | 8 support hours |
| P3 — Normal | Limited disruption with a workaround | 4 support hours | 24 support hours—three eight-hour days |
| P4 — Low | Minor disruption with little immediate business impact | 8 support hours | 40 support hours—five eight-hour days |
If you cannot staff a 15-minute emergency response, agree a different commitment or establish suitable coverage.
Routine requests need their own fulfillment expectations. A new laptop, software approval, or onboarding request depends on authorization, availability, and the required delivery date.
Make the clock predictable
For every target, define the start event, permitted pauses, completion event, and treatment of reopened tickets or priority changes. Support calendars and start/pause/stop conditions are established SLA configuration concepts. See Atlassian’s SLA guidance.
For example, with Monday–Friday coverage from 9 a.m. to 5 p.m., a four-support-hour target starting Friday at 4 p.m. expires Monday at noon, assuming no holiday or pause.
For each permitted pause, record:
- What information or decision is needed.
- Who owns the next action.
- When someone will follow up.
Waiting in an internal queue should not automatically pause the clock. Report the employee’s total elapsed wait alongside measured SLA time.
Escalate before a deadline is missed
Give every ticket an owner. Set an advance warning that names the person responsible for intervening and the action expected: reassigning work, involving a specialist, or communicating a revised plan.
Escalate immediately when business impact warrants it. Do not wait for a timer threshold during a serious incident. Agree an update frequency so employees know when they will hear from IT again.
Measure the agreement clearly
For each target, agree the percentage that must meet it and the reporting period. There is no single attainment percentage appropriate for every service.
For a resolved-ticket measure:
Compliance = eligible tickets resolved within target ÷ eligible tickets resolved during the reporting period × 100
Document exclusions. Report overdue open tickets alongside this percentage so unfinished work remains visible. Review results by priority, together with paused time, reopened issues, and employee feedback.
Pilot proposed targets against actual workload before adopting them, then review recurring misses with the relevant service owners.
Apply the agreement in TodaysBru
TodaysBru tracks a resolution target for each ticket priority, using business hours or a 24/7 clock. Administrators can configure working hours, timezone, holidays, and priority targets.
Pending pauses the clock—including for critical tickets—and resolving a ticket records its SLA outcome. Use Pending consistently with your agreed waiting rules.
First response and restoration are useful commitments, but TodaysBru does not currently measure them as separate SLA clocks. Decide what “Resolved” means in your workflow before configuring the resolution target.
TodaysBru’s resolved-ticket SLA reports exclude tickets without a recorded resolution snapshot. Review open breaches alongside those reports to understand the outstanding workload.
Use the SLA settings guide to configure your agreed resolution targets, and the helpdesk metrics guide to plan the wider review.