An incident management process is the order of work from the first report of a broken service to its confirmed return. Log one ticket, name one owner, link duplicate reports, update users on a clock, restore service, confirm it with users, close, and hand off to a review.
This process comes from the team behind SherpaDesk, a helpdesk and PSA (professional services automation) tool a small IT team can run alone.
Key takeaways
The incident management process is the fixed order of work for every incident, from first report to confirmed service restoration and review. An incident is "an unplanned interruption to an IT service or reduction in the quality of an IT service," per Ontario's government IT standard, quoting ITIL. Its purpose is "to restore normal service operation as quickly as possible".
Without written incident management, an outage can put three technicians on one router, nobody on the phone. Keep an update channel that doesn't run on what breaks: in one r/sysadmin thread, leadership "asked me to send an all company email that email is down". Before the next outage, write down:
Ontario's incident management process opens with report, log and classify, then prioritize. Log what, who, and since when, through your normal ticket triage.
Example: "Main office: no internet, phones down, since 8:52."
Common mistake: fixing first, logging later.
In the Cabinet Office model, the incident lead "manages the incident and coordinates the team." With two people, one fixes and one owns. Alone, you're both; a timer reminds you to update.
Example: Maya owns the ticket and the updates; Sam works the firewall.
Common mistake: "the team owns it," so nobody sends the update.
Link each call and email to the incident, so the timeline lives in one place. Ontario makes the service desk the "single point of contact" for customers.
Example: five emailed reports, one incident ticket.
Common mistake: six tickets, six different answers.
Ontario's default: first notice within an hour of a declared major incident, then every 3 hours. We'd send a P1 update every 30 to 60 minutes. Each says what's broken, what you're doing, and when you'll update next.
Example: "No change. Next update 10:00."
Common mistake: going quiet when there's no news. "No change" is an update.
Confirm which services are down and check known fixes and recent changes. Log each attempt with its time. Out of access, knowledge, or time? Escalate by your escalation matrix. We count a working workaround as restored; the root cause is problem management's job.
Example: fail over to backup, then chase the ISP.
Common mistake: waiting on the vendor before trying a workaround.
Under Ontario's standard, whoever restores service confirms it with the user, and closure depends on that check. Book the review, then send the final update and close the linked tickets.
Example: "Internet is back."
Common mistake: closing when the router lights turn green.
The Cabinet Office requires a post incident review for every P1 and P2. Hand over the timeline and logged attempts; our post incident review template covers the follow-up.
Example: Maya attaches the timeline to the review invite.
Common mistake: treating the closed ticket as the end.
Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.
Loading form…
The form couldn’t load. Please try again.
Or start your free trial →SHERPADESK · FREE TRIAL
Resolve tickets.
Turn time into revenue.
Bring support tickets, billable time, and invoicing into one place. Built for small IT teams and MSPs.
After your trial, keep your first agent free forever.
SHERPADESK · LIVE DEMO
See tickets, time,
and billing work together.
Walk through ticketing, time tracking, and billing with a product specialist. See how SherpaDesk fits the way your team works.
A live walkthrough tailored to your team.
Use this incident management checklist from first call to close.
Say you run a three-technician MSP; a dental office loses internet and phones. Maya owns the incident; Sam fixes it.
| Time | What happened |
|---|---|
| 8:52 | Office manager calls: no internet, phones dead |
| 8:55 | Maya logs a P1 incident ticket |
| 8:58–9:25 | Maya links five emailed reports as they arrive |
| 9:02 | Sam confirms. Maya texts: "Internet is down. Next update 9:30." |
| 9:05 | Sam opens an ISP case |
| 9:30 | Maya: "Moving you to the backup line. Next update 10:00." |
| 9:35 | Sam fails over to the LTE backup |
| 9:38 | Client confirms phones, payments, scheduling work. Maya: "On backup. Next update 10:30." |
| 10:30, 11:30 | Maya: "No change. Next update in an hour." |
| 11:40 | ISP fixes the line; Sam moves traffic back |
| 12:00 | Client confirms the main line; Maya books the review, sends the final reply, closes the tickets |
Every promised update went out on time. We call service restored when the client confirms work runs: 9:38, 46 minutes after the call. Report the main line's return, 11:40, separately.
As one r/sysadmin member put it: "It's never the fault of the person implementing it's the fault of the process that let it happen."
Start every incident management clock at the first report: the first call, email, or alert. Review monthly with your SLA management numbers.
How this works in SherpaDesk
You can link each user's report to the incident ticket and close them together. Related tickets can be updated and replied to in bulk.
Log your hours on the incident ticket. Create KB turns the ticket into a known-issue article. You can run it for your own staff or for the clients you support.
A helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin.
Base Camp is $45 per agent per month ($40 billed annually). The first agent is free, forever, so a team of three pays $90 a month ($80 billed annually). The trial is 14 days free with no card.
Who this isn't for
Running 24/7 on-call for production software? Add paging incident management tools. A suspected breach follows your security incident response plan.
Our five-step adaptation of Ontario's order is report, log and classify, prioritize, resolve, and close. TechTarget's ITIL workflow splits the same path into more stages, from identification to closure. Small teams should add one named owner and updates on a clock.
This guide uses seven stages, in order. Log one incident ticket and set its priority, then name one owner. Link duplicate reports and update users on a clock. Restore service, confirm with users, book the review and close, then hand off to the review.
TechTarget calls ITIL a widely used IT service management framework and describes incident management as a key ITIL process "aimed at restoring normal service operations as quickly as possible". Its workflow runs from identification through diagnosis and escalation to closure.
The incident management lifecycle is one incident's path from report to closure. Ontario's standard runs report, log and classify, prioritize, diagnose, escalate, resolve, monitor, and close. Its major incident management adds a review for every major incident. Feed its action items to problem management.
The incident manager owns the incident from log to close. TechTarget lists acting as a communication bridge between users and technical specialists and leading post-mortems on major incidents. On a small team, that's the step 2 owner, usually whoever isn't fixing.
Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.