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.
Key takeaways
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.
| Term | Definition | Example |
|---|---|---|
| Root cause | The underlying reason for the disruption to service | An unlogged move that left a printer on Wi-Fi |
| Workaround | A solution that reduces or removes the impact while a full resolution isn't available yet | Wake the printer from its panel, then reprint |
| Known error | A problem with a documented cause and, as a rule, a tested and working workaround | The workaround article, once it names the cause |
Ticket types are covered in what an IT ticket is.
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.
Gets users working again.
Removes the cause.
Our incident management process covers the restore. A post incident review of one major outage can open a problem too.
Documented solutions speed up incident handling and reduce incidents, Oldenburg's IT services note. Count what one repeat cost you last month.
Technician hours one repeat problem costs
related tickets × minutes per ticket ÷ 60. Your numbers stay in the browser.
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.
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:
A monthly 30-minute ticket review, sorted by client and symptom, feeds both lists.
Problem management needs four things, none of them new software.
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.
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.
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.
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.
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."
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.
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.
Copy it into every problem ticket.
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.
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.
| Field | What the team wrote |
|---|---|
| Symptom and incidents | Offline on the first job of the day. 3 linked at opening (Oct 6, 13, 16), 2 more before the fix: 5 tickets, about 100 minutes. |
| Owner | Ana. Next date: Thu Oct 22. |
| Workaround | Fri Oct 16, technicians-only article KB-2041, linked to PRB-112: wake the printer from its panel, reprint. |
| Five whys | Why offline? It's off the Wi-Fi. Why? It drops the network in deep sleep and doesn't rejoin. Why on Wi-Fi? It moved to the front desk in September, away from its network jack. Why unplanned? Moves aren't logged as changes. |
| Known error | Tue Oct 20: cause added to the article. |
| Change | Sat Oct 24, 9:00: run a cable to the front desk, switch to wired. Test: idle two hours until the printer confirms deep sleep, then print from two PCs. Way back: Wi-Fi stays configured. Moves now get a change ticket. |
| Result | Test passed Oct 24. Mon Nov 23: no related incident in 30 days of daily printing. Fix held; closed with cause, actions, and lesson; article marked fixed. |
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.
Four problem management numbers are enough. Review them monthly with your other helpdesk metrics.
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."
How this works in SherpaDesk
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.
Who this isn't for
Large service desks running formal ITIL problem management with problem boards and a dedicated problem manager.
Problem management means diagnosing the causes behind incidents, or potential incidents, and getting a fix in place through change management. On a small team, three related incidents in 30 days, or one major incident that needs investigation, opens a problem ticket. So does a confirmed risk.
The five whys is a root cause technique: ask "Why?" until you reach a cause you can fix. IHI notes there may be multiple root causes, and different people may answer differently, so run it with whoever worked the tickets.
We group problem management into three phases. Identify is steps 1 and 2: spot the trigger and open one ticket. Control is steps 3 and 4: publish the workaround, find the cause, record the known error. Fix is steps 5 and 6: change, test, wait out the quiet period, then record the outcome: fix held, risk accepted, or administrative closure.
It's one named technician, not a full-time job. That person owns every open problem ticket and its next date, and keeps problem management from stalling. Whoever approves changes, often the owner, approves the fix. That person checks the test result before closing.
The difference is how far diagnosis has gone. A problem is the cause of incidents or potential incidents, often not yet understood. A known error has been diagnosed: Oldenburg describes a documented cause and, as a rule, a tested workaround. The record adds what technicians need next time: symptom, cause, and workaround, until a fix lands.
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.