Here's how to write an SOP your MSP technicians can use during a ticket: choose a repeated task and write its approved steps in the order the work happens. Test the draft with someone unfamiliar with the task, then correct any gaps before wider use.
Start With the Tickets You Fix Ten Times a Week
I'd start with the repeated tickets your technicians already know how to resolve. Those are the tickets costing you time in repetition, and they're work a new hire may face on day one. If password resets are among your repeated tasks, document the approved process first. The task is familiar enough for the team to check the steps before someone else relies on them.
You're not documenting your whole operation. You're documenting the repeated tasks that eat your week. Use the ticket history to identify them.
How to Find the Tickets That Repeat Most
If your ticketing system can export or filter by subject or category, choose a history period that captures representative recurring work and count. Group by the verified task rather than by the words in the subject. Don't assume that a reported sign-in problem is a password reset before the request has been checked.
If you don't have reporting, ask each tech to list the top three tickets they see in a week, and pick the ones that show up on more than one list. Say your techs name "password reset" and "mobile setup" as their top two. Those become your first candidates.
Once you have the list, write the steps for someone using the SOP mid-shift. They need to follow the work without reconstructing the process from scattered notes.
Write Each SOP to Fit in a Shift, Not a Binder
Start with a short “when to use” statement, numbered steps and a final verification step. Keep the standard path easy to scan, with links to supporting detail where needed.
For a password reset, the standard path is to verify identity, reset through the approved admin process and confirm that the user can sign in. Document when that path does not apply and where the technician should escalate.
Test Each SOP on a New Hire Before You Trust It
Hand the SOP to a new hire, or a tech who hasn't handled that ticket type recently, and watch them follow it from start to finish. Where they stumble is where the SOP needs clarity. Say the new hire asks "where's the reset link?" That's your cue to add the portal URL to the SOP.
Run the test in a lab, sandbox, or on a non-critical ticket, so a client's service isn't at risk while you're still learning whether the steps work. And test it on someone who isn't already fluent in the process. Testing on a senior tech who knows the answer by heart tells you nothing.
If you don't have a new hire around, ask another technician to follow the SOP and note where they have to deviate. Choose someone unfamiliar with the task where possible, so their own experience doesn't hide missing steps.
When SOPs Won't Save You
This approach has limits, and you should know them before you clear your Monday morning for it. It fails if your most repeated tickets are complex and unpredictable, if you have no way to identify what repeats, or if the team is too small to test and maintain what you write.
If one technician handles everything by intuition and the tickets never repeat the same way, an SOP goes stale before anyone uses it, because the tickets that repeat are too varied and the person who'd maintain it is the same person who's too busy to write it. That's a real constraint, and it's worth naming.
If your most repeated tickets are judgment-heavy, like a network outage that could have a dozen causes, don't force them into a one-pager. Split it into an intake and triage SOP and an escalation SOP, or don't write it at all. The point is to document what's routine, not what's rare.
Start Monday With One SOP
I'd start Monday with one SOP rather than spreading the work across several unfinished drafts. Who owns the draft, the test and the corrections before the desk uses it? Put names against this checklist:
- Desk lead: pull representative ticket history and choose a repeated task with a verified resolution.
- Technician who knows the task: draft the approved steps and the final verification check.
- New hire or another technician unfamiliar with the task: test the draft in a safe environment and record every missing detail.
- Named SOP owner: correct the gaps, confirm the approved version and maintain it when the process changes.
mspoutpost.com/articles/how-to-write-an-sop-your-msp-techs-can-use-mid-ticket
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
