Copy-paste starting points for the documents every support and IT team ends up writing: postmortems, incident comms, severity definitions, SLA policies, runbooks, and the on/offboarding checklists. Fill the brackets, delete what you do not need. No gate, no email.
Incidents
Incident communication messages
Initial, update, and resolution messages for a P1/P2. Fill the brackets, keep the promised cadence.
INITIAL (send within 10 minutes of declaring)
--------------------------------------------
⚠ [P1|P2] incident — [service/feature] is [down | degraded]
Impact: [who is affected and how]
Status: investigating. Incident commander: [@name]
Next update: [time, e.g. :30] in this channel.
UPDATE (every 30 min for P1, hourly for P2 — even if nothing changed)
--------------------------------------------
Update [n] — [time]
What we know: [current hypothesis / confirmed cause]
What we're doing: [current action]
Workaround: [if any, else "none yet"]
Next update: [time].
RESOLVED
--------------------------------------------
✅ Resolved — [time]. Duration: [start–end, total].
Cause (short): [one sentence, no blame]
Follow-up: postmortem by [date]; action items will be tracked in [queue].
Thanks for your patience — questions in thread.
Blameless postmortem
Six sections, one page. Write it within a week of any P1/P2 while the timeline is fresh.
# Postmortem: [incident title]
Date of incident: [date] · Duration: [total] · Severity: [P1/P2]
Author: [name] · Review meeting: [date]
## Impact
[Who was affected, for how long, what it cost. One paragraph, numbers where known.]
## Timeline (from the incident channel, not memory)
- [HH:MM] [event — detection, actions tried, escalations, resolution]
- ...
## Contributing causes
[Ask "why" past the first answer until you reach process or system.
"Human error" is where analysis starts, never where it ends.]
1. ...
2. ...
## What went well
- [detection that worked, runbook that helped]
## What went poorly
- [where minutes were lost: unseen alert, missing runbook, stalled escalation]
## Action items (into the normal queue — visible aging)
| Item | Owner | Due |
|------|-------|-----|
| ... | [one name] | [date] |
Severity matrix (P1–P4)
Impact-based severity definitions to pin next to the queue. Edit the examples to your services.
P1 — CRITICAL: service down or unusable for most users, or data at risk.
Examples: [prod outage, data loss risk, security incident]
Response: page immediately, incident channel + commander, updates every 30 min.
P2 — MAJOR: core function degraded or down for a subset; no workaround.
Examples: [login failing for one region, critical integration down]
Response: page on-call, updates hourly.
P3 — MINOR: non-core function impaired, or a workaround exists.
Examples: [report export slow, UI glitch with workaround]
Response: business hours, tracked in queue, no incident machinery.
P4 — LOW: cosmetic or single-user.
Examples: [typo, layout nit]
Response: normal queue priority.
Rule: severity is set by observable impact, not by who escalates.
If two people can argue about the same outage's severity, tighten these definitions.
SLAs & escalation
Escalation path
Who gets paged when, and after how long. One per service or queue; keep it to one screen.
Service/queue: [name] Owner team: [team]
LEVEL 1: on-call ([rotation name])
Paged: immediately on P1/P2.
If unacknowledged after [15] min → LEVEL 2.
LEVEL 2: secondary on-call / team lead ([name/rotation])
If unacknowledged after [15] min, or incident exceeds [1h] unresolved → LEVEL 3.
LEVEL 3: engineering manager [name] + [head of infra/CTO]
Also notify: [customer comms owner] if customer-visible.
NON-INCIDENT ESCALATION (ticket aging, not severity):
Ticket in queue > [SLA target] → auto-escalate to [team lead].
Ticket reopened twice → route to [senior/specialist], not back to original assignee.
Keep this in the tool (escalation policy), not just in this doc —
an escalation that depends on someone remembering this page will not fire at 3 a.m.
SLA policy (per priority)
Response and update commitments by priority, with the internal SLOs that back them. Promise response firmly, resolution cautiously.
# Support SLA — [team/product]
Effective: [date] · Hours: [24/7 | business hours, timezone]
| Priority | First response (SLA) | Internal target (SLO) | Updates | Resolution target |
|----------|---------------------|----------------------|---------|-------------------|
| P1 | [30 min] | [15 min] | every 30 min | [restore < 4h]* |
| P2 | [2 h] | [1 h] | hourly | [1 business day]* |
| P3 | [1 business day] | [4 h] | on change | [5 business days]* |
| P4 | [2 business days] | [1 business day] | on change | best effort |
* Resolution targets apply to known/routine categories only. Novel issues get
a diagnosis-or-update commitment, not a fix-time promise — hard resolution
SLAs on unknowns incentivize premature closes that return as reopens.
Backing OLAs (internal — the SLA fails without these):
- Engineering picks up P1/P2 escalations within [30 min / 2 h].
- [Security] reviews flagged tickets within [4 h].
Measurement: clocks start at ticket creation; priority set at triage;
SLO breaches alert [owner] before the SLA is at risk.
On-call handoff
Five minutes at rotation change. The outgoing person writes it; the incoming person acknowledges it.
On-call handoff — [rotation] — [date]
Outgoing: [name] → Incoming: [name]
OPEN THREADS (anything that might page you)
- [ongoing incident/degradation, current state, where the notes live]
- [flaky alert currently firing — known cause? safe to ack?]
WATCH FOR
- [deploy/change scheduled this week and what it might break]
- [customer/team expecting a follow-up]
QUEUE STATE
- P1/P2 open: [n] — [links]
- Aging past SLA: [n] — [links]
TUNING DEBT (noise you hit — file, don't inherit silently)
- [alert that fired without action → ticket to retune/delete]
Incoming: reply ✅ with questions. No ✅ = handoff didn't happen.
Knowledge
Knowledge base article
One question per article, titled as the requester asks it, self-contained, with verification. Structured for AI retrieval as much as for humans.
# [The question, in the requester's words]
e.g. "VPN shows connected but internal sites won't load"
Applies to: [platform / plan / office — state the boundary IN the text;
this is what stops an AI applying a Mac fix to a Windows machine]
Owner: [name] · Last reviewed: [date] · Review by: [date +6mo]
## Problem
[One paragraph: what the user sees, in their vocabulary.]
## Fix
1. [step — name systems explicitly, no "as before"]
2. ...
## Verify it worked
[What the user should now see. This line is what lets an AI agent
confirm a fix rather than just recite one.]
## If this didn't fix it
[Next step or escalation path — where the ticket goes and what to include.]
Runbook
For a recurring operational task or known failure. Write it from the resolved incident while the fix is fresh.
# Runbook: [task or failure mode]
Trigger: [the alert / symptom / request that means "use this runbook"]
Owner: [team] · Last used: [date] · Source incident: [link]
## Preconditions & access
[What you need before starting: permissions, VPN, dashboards. Links.]
## Steps
1. [imperative step — one action each]
Expected result: [what you should see before continuing]
2. ...
## Verification
[How you know the system is healthy again — the check, not a feeling.]
## Rollback
[If a step made things worse: how to get back to the starting state.]
## Escalate instead if
[Conditions under which this runbook does NOT apply — hand to [who] with [what info].]
People ops
IT onboarding checklist
One parent ticket per hire, tasks keyed to the start date. Goal: zero tickets filed by the new hire in week one.
# Onboarding: [name] — [role] — starts [date]
Parent ticket: one per hire. Every task has an owner and a deadline.
DAY −10
[ ] Hardware ordered per role standard ([laptop model]) — owner: [IT]
[ ] Access matrix row confirmed for role [role] — owner: [IT + manager]
DAY −3
[ ] Identity account created; groups per matrix — owner: [IT]
[ ] Email, chat, HR portal, password manager — owner: [IT]
[ ] Role licenses assigned ([list from matrix]) — owner: [IT]
[ ] Laptop imaged, MDM enrolled — owner: [IT]
DAY −1
[ ] Access grants activated (not before) — owner: [IT]
[ ] Manager: first-week buddy + intro meetings booked — owner: [manager]
DAY 1
[ ] Hardware handoff, login verified WITH the person — owner: [IT]
[ ] Day-one test: everything on the matrix opens; zero tickets filed.
DAY 7
[ ] Check-in: anything missing → fix AND update the matrix — owner: [IT]
IT offboarding checklist
Triggered by the HR event, never by memory. Security order: SSO first, stragglers second, transfers last.
# Offboarding: [name] — last day [date]
Trigger: HR event (auto), NOT a filed ticket. Every day between departure
and deprovisioning is a day former credentials still work.
LAST DAY (in this order)
[ ] Identity/SSO account disabled — cascades through everything behind SSO — owner: [IT]
[ ] Non-SSO stragglers from access matrix row: [list] — owner: [IT]
(Tools signed up for with email + card live here. If it's not in the
matrix, it won't be found — that's why procurement goes through the matrix.)
[ ] Shared credentials they held: rotate [list] — owner: [IT/security]
[ ] MDM: remote lock/wipe scheduled; device return arranged — owner: [IT]
WITHIN 3 DAYS
[ ] File/doc ownership transferred to [manager] — owner: [IT]
[ ] Calendar events, recurring meetings reassigned — owner: [manager]
[ ] On-call rotation slot replaced — owner: [team lead]
[ ] Mailing lists, group ownerships cleaned — owner: [IT]
RECORD
[ ] All actions logged on this ticket (who revoked what, when) —
this timeline is what the auditor asks for.
Queue operations
Ticket categorisation taxonomy
A starting category scheme derived from what people ask, not from your org chart. Shallow, mutually exclusive, and automation-ready.
# Ticket taxonomy — [team]
Rules that keep a taxonomy usable:
1. Shallow. Two levels maximum. A third level is where consistency dies.
2. Mutually exclusive. If two categories can both be right, merge or sharpen them.
3. Derived from demand. Build it from a month of real tickets, not from a template.
4. Owned. Every category has a fulfilling team, or it does not exist.
ACCESS & IDENTITY
- Account access (locked out, password, MFA)
- Application access request → allow-listable if the role matrix covers it
- Permission change / elevation → exception path, human decision
- Offboarding / deprovisioning → HR-triggered, never request-driven
HARDWARE & DEVICE
- New equipment request
- Broken / replacement
- Device configuration & software install
- Return / recovery
CONNECTIVITY & INFRASTRUCTURE
- Network / VPN
- Email & calendar
- Printing / peripherals
- Service degradation → check severity, may be an incident
APPLICATION & PRODUCT
- Defect / bug report → severity + priority, may escalate
- Expected behaviour question → knowledge gap, not a defect
- Data correction request
- Integration failure
REQUESTS & ADMIN
- Information / how-do-I → highest deflection potential
- Purchase / licence request
- Environment or test data request
MAPPING NOTES (fill in per category)
Fulfilling team: ...
Standard or exception: ...
Auto-resolvable (reversible, verifiable, well-trodden, low blast radius)? Y/N
Target first response: ...
Review quarterly: any category under ~2% of volume is noise (merge it);
any over ~25% is hiding distinct work (split it).
Canned response library
Starter replies for the most common queue moments — plus the rule that every macro used more than twice is a missing knowledge-base article.
Rule before the templates: a canned response is a speed aid, not knowledge.
An AI cannot ground answers in your macro library, and a requester cannot
search one. Every macro you use more than twice a week is a knowledge-base
article you have not written yet — write it, then link to it from the macro.
ACKNOWLEDGEMENT (only when a real reply will be slower than your SLA)
--------------------------------------------
Thanks [name] — this is with [team] now. Current status: [what is happening].
I will update you by [time] even if there is nothing new to report.
NEED MORE INFORMATION
--------------------------------------------
To get this to the right person quickly, could you send:
- What you expected to happen, and what happened instead
- When it started, and whether it is every time or intermittent
- [screenshot / error message / order or account ref]
Once I have that I can [next step].
KNOWN ISSUE
--------------------------------------------
This is a known issue — you are not the first, and nothing is wrong on your side.
[One-sentence plain description of the cause.]
Workaround for now: [steps, or "none available"].
Tracking: [ticket ref]. I will message you here when it is fixed.
RESOLVED BY THE REQUESTER'S OWN ACTION (no blame)
--------------------------------------------
Glad that worked. For future reference, [the check that fixes it] resolves this
in most cases — documented here: [KB link].
CLOSING AS DUPLICATE
--------------------------------------------
Merging this into [ticket ref], which is the same issue reported earlier —
you will get updates there, and your report is linked so the impact count is right.
ESCALATING
--------------------------------------------
I have escalated this to [team] as [ticket ref] with the details you sent.
What happens next: [step]. Expected update: [time]. I will keep this ticket open
so you have one place to follow it.
DECLINING / OUT OF SCOPE (no apology spiral)
--------------------------------------------
This one sits with [team / outside what we can change], and here is why: [reason].
The route that will work: [alternative]. Happy to help you file it.
Support team scorecard
A monthly scorecard with the numbers worth reviewing, the trap beside each one, and space for the decisions that came out of it.
# Support scorecard — [team] — [month]
VOLUME & SHAPE
Tickets received: ____ Resolved: ____ Net backlog change: ____
Top 3 categories by volume: ____ / ____ / ____
Share that repeat an already-answered question: ____%
→ Your deflection ceiling input. Track the trend, not the number.
SPEED
First response time — median ____ p90 ____
Time to resolution — median ____ p90 ____
→ Read p90 first. Means hide the tail, and the tail is what people remember.
QUALITY
Reopen rate: ____%
→ The honesty check. A fast close that reopens was not a resolution.
CSAT (if collected): ____% Response rate: ____%
→ Low response rates skew positive. Report both or neither.
QUEUE HEALTH
Backlog age — median ____ oldest ____
→ Rises before volume charts show a problem.
Tickets breaching SLA: ____
Escalations to engineering: ____ (of which identification-only: ____)
→ Only the identification bucket should be falling.
AUTOMATION (if AI triage is running)
Auto-resolved share: ____% Reopen rate on auto-resolved: ____%
Categories promoted this month: ____
Categories demoted this month: ____ Why: ____
→ A month with zero demotions usually means nobody is checking.
WHAT WE DECIDED
1. [decision, owner, date]
2. ...
Documentation written this month (from the handoff clusters): ____
A scorecard with no decisions section is a report. The decisions are the point.