I define impact and urgency together. I separate acknowledgement from restoration, and I publish only targets the staffed service can actually deliver.
Before I start
- A service catalogue, business owner, support hours, time zone, and an escalation rota.
- Ticket timestamps for acknowledgement, assignment, updates, restoration, and resolution.
- Approval from the people who fund coverage and accept the service targets.
Step by step
Choose coverage before targets
I choose business-hours support or a funded 24/7 rota. For business hours I document weekdays, time zone, opening times, holiday calendar, and the out-of-hours emergency route. I never imply a 24/7 promise just because the ticket portal is always open.
Define business impact
High impact means a critical service or many users are affected; medium impact means a team or important function; low impact means one user or a limited noncritical function. I capture affected service, number of users, workaround, and business consequence in the ticket.
Define urgency and calculate priority
High urgency means work is stopped without a reasonable workaround; medium means a material degradation with a temporary workaround; low means work can continue or be scheduled. Use the local matrix builder below to make the decision visible and consistent.
Agree realistic example targets
My starting example is P1: 15-minute response and 4-hour restoration; P2: 1-hour response and 8 support-hour restoration; P3: 4 support-hour response and 24 support-hour restoration; P4: 8 support-hour response and 40 support-hour fulfilment. These are proposals, not universal ITIL requirements. Adjust them to staffing and service contracts.
Define what each clock means
Response is human acknowledgement and an initial plan. Restoration is usable service or an accepted workaround; it is not necessarily permanent repair. Resolution records the completed fix. I start clocks at recorded receipt within the agreed coverage and explicitly define out-of-hours handling, holidays, and any approved pause conditions.
Name the escalation and update owners
For P1, I assign an incident lead, technical owner, communications owner, and a 30-minute update cadence while actively handled. My example P2 cadence is 2 support hours. At 50% of target I flag risk; at 75% I escalate; at breach I notify the service owner and record the reason.
Try the matrix on real examples
I classify a company-wide sign-in outage, one user’s printing problem, and a planned account request. I compare decisions across agents, adjust ambiguous definitions, and have the service owner approve the final version.
Report the service, not just a percentage
I report volume by priority, response/restoration attainment, reopens, oldest backlog, and satisfaction. I inspect the reasons for breaches and agree a small improvement each month. I distinguish incidents from requests and route security incidents through the separate security process.
How I check the result
0 of 4 checks completed
Checklist progress stays in this browser. I use it to track checks, not to certify a deployment or compliance.
If something does not work
Everything becomes P1
Require a recorded impact/urgency justification and review priority changes.
Targets look good but users still wait
Inspect restoration, transfers, reopens, and backlog in addition to first response.
Out-of-hours clock is disputed
Define coverage and the emergency route in the agreement before signing it.
Build the working matrix
I keep the interactive builder on its own page.
Open SLA Builder ↗My working templates
I use these as starting proposals, then agree coverage and targets with the service owner.
Download CSV ↓I capture the incident clock, ownership, impact, communications, and regulatory decisions.
Download MD ↓About this playbook
These are my practical operating recommendations and example targets. I adapt them to business requirements, staffing, contracts, and risk decisions.