Incident Management Process For A Small IT Team

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.

What Is The Incident Management Process?

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".

Why Incident Management Matters On A Small Team

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:

• Your incident priority levels.
• A default owner and a backup for every shift.
• A text group and vendor support numbers.
• An update interval per priority.

The Incident Management Process, Step By Step

1. Log one incident ticket and set its priority

   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.

2. Name one incident owner

   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.

3. Link every duplicate report to the incident ticket

   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.

4. Tell users, then update on a clock

   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.

5. Restore first, fix the cause later

   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.

6. Confirm with users, then close

   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.

7. Hand off to the review

   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.

The Incident Owner's Checklist

Use this incident management checklist from first call to close.

Example: An MSP Loses A Client's Internet

Say you run a three-technician MSP; a dental office loses internet and phones. Maya owns the incident; Sam fixes it.

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.

How To Prevent Repeat Outages

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."

• Link repeats to a problem ticket for the cause, so your incident management processes don't end at closure. Ontario engages problem management for recurring incidents raised by monitoring.
• Write the workaround down as a known-issue article.
• Test the backup line on a schedule.

How To Measure Incident Management

Start every incident management clock at the first report: the first call, email, or alert. Review monthly with your SLA management numbers.

• Time to first update: first report to the first user notice.
• Time to restore: first report to a user confirming work runs, workaround included.
• Updates on time: updates sent by their promised time, divided by updates promised.
• Repeats: incidents whose cause was logged before.

Run The Incident From One Ticket

About the author

Patrick Clements Co-founder & CEO, SherpaDesk

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.

All Articles