Problem Management For A Small IT Team

Problem management is the work of finding and removing the causes of incidents, including incidents that haven't happened yet. On a small team, the main case is the repeat: three related incidents in 30 days. Link the repeats, find the cause, publish a workaround, and fix it through a change.

This guide is from the team behind SherpaDesk, a helpdesk and PSA (professional services automation) a small IT team can run alone.

What Is Problem Management?

Texas A&M's IT division defines a problem as "the cause of one or more incidents or potential incidents." Oldenburg University's IT services define problem management as "all the activities required to diagnose the underlying causes of incidents and to find a solution to these problems." Fixes go live through change management.

This guide focuses on the weekly case: the same incident, again.

Ticket types are covered in what an IT ticket is.

Incident And Problem Management: What Changes

Incident and problem management share a queue, not a goal. Cornell's IT glossary notes that once an acceptable workaround is in place, associated incidents can be resolved. The cause can still be there.

Our incident management process covers the restore. A post incident review of one major outage can open a problem too.

Why Problem Management Matters On A Small Team

Documented solutions speed up incident handling and reduce incidents, Oldenburg's IT services note. Count what one repeat cost you last month.

Not every glitch deserves problem management. Make the quick fix first, and open a problem only when the issue comes back. Our reactive trigger puts a number on it: three related incidents in 30 days.

Reactive Vs Proactive Problem Management

Oldenburg splits problem management into two processes. Reactive problem management starts from incidents that already happened and runs through diagnosis, workarounds, known errors, and the solution. Most small-team problem management is reactive.

Proactive problem management aims to find and address potential problems before they affect services. Framingham's version includes analyzing incident data. Example: after a fix, check the client's other devices for the same setting.

To pick between problems, weigh:

• Service impact: how many people stop working.
• Frequency: related incidents in the last 30 days.
• Time lost: the calculator above, per month.

A monthly 30-minute ticket review, sorted by client and symptom, feeds both lists.

Before You Start

Problem management needs four things, none of them new software.

• A marker: a ticket class, category, or "PRB:" prefix.
• One problem manager: on a team of one to five, a hat, not a job.
• A home for workarounds and known errors: a knowledge base category; see our knowledge base guide.
• Two written triggers: reactive, three related incidents in 30 days or one major incident needing investigation; proactive, a confirmed risk, like a bad setting on another device.

The Problem Management Process, Step By Step

The problem management process below is this guide's six-step adaptation for a small team. The workaround comes before the diagnosis, so users get relief first. PRB-112, further down, is the running example for every step.

1. Spot the trigger

   Search closed tickets for the symptom before closing a new one, so the repeat gets counted instead of closed again. Framingham's problem management starts with patterns in incident data.

   Common mistake: each technician closes their own copy.

2. Open one problem ticket and link the incidents

   Write the symptom, client, and first date. Link every incident, so the count lives in one place.

   Common mistake: keeping the investigation in a chat thread.

3. Publish the workaround right away

   Write the symptom and workaround as a short article the day you find it. Texas A&M documents workarounds as knowledge articles.

   Common mistake: keeping it in one head.

4. Find the root cause, then mark the known error

   Use the five whys from the Institute for Healthcare Improvement (IHI): ask "Why?" until you reach the root cause. IHI warns there may be multiple root causes. Time-box root cause analysis and log the hours. Once the cause is diagnosed, add it: the problem is now a known error.

   Common mistake: stopping at a symptom, such as "the printer is flaky."

5. Make the permanent fix through a change

   At Framingham, changes are typically managed through change management for testing, approval, and implementation. A fix can break something else, so write the change with a time, a test, and a way back.

   Common mistake: fixing mid-morning, unannounced.

6. Verify, then close

   Three outcomes end the work. Fix held: the test passed and no related incident arrived in normal use over a set period; we use 30 days. If it recurs, reopen and restart the count. Risk accepted: the ticket keeps an owner and a next review date. Administrative closure: a written reason, never counted as a success. At closure, Framingham's problem management documents the root cause, actions, and lessons learned.

   Common mistake: closing on the day of the change.

A Problem Management Checklist

Copy it into every problem ticket.

Example: A Printer That Goes Offline Every Morning

Say you run a three-technician MSP. A 14-person architecture office logs "printer offline" tickets on October 6, 13 and 16, each before 9:00 and about 20 minutes.

Ana logged two hours of investigation. In the monthly review, she found the upstairs printer on Wi-Fi with the same sleep setting: a confirmed risk. She opened PRB-113 before its first ticket.

How To Measure Problem Management

Four problem management numbers are enough. Review them monthly with your other helpdesk metrics.

• Related incidents: tickets linked to problem tickets each month.
• Age of open problems: days since each was opened. Past 60 days, pick an outcome.
• Workaround coverage: share of open problems with a published article.
• Outcomes: fixes held, risks accepted, and administrative closures, counted apart. A reopened fix leaves "held".

Problem Management Best Practices And Mistakes

Restore service first, name one owner, and count a fix as held only after a passed test plus a quiet period. The common mistake is the reverse order: in a 2026 r/sysadmin thread, one member objected to "demanding an RCA up front, before a fix can be done." When you can't find the cause, keep the ticket open anyway. As another member put it: "I'd keep the record though so you can see how many times the 'mystery' keeps happening."

Run Problem Management In SherpaDesk

How this works in SherpaDesk

Linked tickets, a workaround article, a booked check

For problem management, admins can add Problem as its own ticket class, so problem tickets stay apart from incidents in the queue. The rest of problem management runs on tickets too: link each related ticket to the problem ticket and close them together. Log your investigation hours on the problem ticket.

Create KB turns the ticket into an article. Private – Tech/Admin Only keeps it for technicians; only public articles, visible on the portal without login, can be attached to replies. A To Do with a due date and reminder books the 30-day check. A scheduled ticket can run the monthly review.

A helpdesk and PSA a small IT team can run alone, for staff or clients. 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.

See Ticket Management →

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