Most MSPs already have SOPs. They sit in IT Glue or Hudu, they were written during a slow quarter, and the tech on a live call with a locked-out CFO doesn't open them. The call ends, the ticket says "reset pw, user good," no time entry gets logged until Friday, and nobody can tell whether the identity check happened at all.
That's the real SOP problem at most MSPs: not missing documents, but procedures that leave no trace in the ticket. So here's the short answer to "what MSP SOPs do I need?": write the procedures whose output is a ticket record first (call handling, ticket notes, time entries, identity checks, after-hours escalation), put them inside the PSA where the work happens, and judge each one by what the finished ticket should contain. Templates for each are below.
What an MSP SOP is (and how it differs from a runbook or a checklist)
An SOP (standard operating procedure) is the agreed way your team does a recurring task, written down so the result doesn't depend on who picked up the phone. At an MSP, SOPs cover service desk behavior: how calls are answered, what goes in a ticket, when time is logged, who gets paged after hours.
People use three terms loosely, so it helps to split them:
- SOP: the rule for a recurring process that's the same for every client. "Every call gets a ticket and a time entry before the tech takes the next call."
- Runbook: how to fix a specific technical problem, often client- or system-specific. "Rebuilding the Outlook profile on Acme's terminal server."
- Checklist: the SOP or runbook turned into tickable steps attached to a ticket, so completion can be checked.
Most "SOP repositories" mix all three, which is one reason they're hard to keep current. Runbooks change whenever a client's environment changes. SOPs should barely change at all.
The SOPs to write first: the ones that end in the ticket
Here's the test I'd use to prioritize: if a manager reads the closed ticket, can they tell whether the SOP was followed? If yes, the SOP is auditable and worth writing now. If no, it's either a runbook or a wish.
Five SOPs pass that test for nearly every MSP service desk:
- Inbound call handling: every support call becomes a ticket, attached to the right client and contact.
- Ticket notes: every note follows the same structure, so the next tech can pick it up cold.
- Time entry: time is logged against the ticket when the work happens, not reconstructed at the end of the week.
- Identity verification before sensitive changes: password resets, MFA resets and mailbox access changes only happen after a verified check.
- After-hours escalation: who decides what's urgent, who gets paged, and what the morning team sees.
They have something in common: each one either protects revenue (unlogged time is unbilled time, which we covered in MSP profit margins) or protects the client (a sloppy identity check is a breach path). They're also the ones that break down at the phone, because a call is the one channel that leaves no written record unless someone creates it.
Notice what's not on the list: "how to onboard a new client," "how to set up a laptop." Those matter, but they're project checklists and runbooks. Write them second.
Template 1: Inbound call handling SOP
Purpose: every support call results in a ticket a different tech could pick up without calling the client back.
Applies to: all inbound and outbound support calls on the help desk line.
Steps:
- Confirm the caller's name, company and a callback number. Match them to the contact in the PSA. If they're not in the PSA, flag it on the ticket instead of guessing.
- Ask whether this is about an existing ticket. If yes, open it before troubleshooting so the call is linked to it.
- If it's new, create the ticket during the call (or immediately after) on the correct board, with a title that says who and what: "Jane Doe – Outlook won't open after update," not "Email issue."
- If the request involves a password, MFA, access or payment change, follow the identity verification SOP before acting.
- Before ending the call, tell the caller the ticket number and the next step.
- Write the ticket note and time entry before taking the next call (see Templates 2 and 3).
Done means: the ticket exists, is on the right client and contact, has a descriptive title, a structured note and a time entry, all timestamped within minutes of the call.
Owner: service manager. Review: quarterly, or after any incident where a call left no ticket.
Template 2: Ticket note SOP
Purpose: any tech can understand the state of a ticket in under a minute without reading the whole history.
Every note has four parts:
- Issue: what the user reported, in their terms, plus what you confirmed.
- Troubleshooting: what you checked and changed, including error codes, machine names and anything you ruled out.
- Resolution: what fixed it, or "unresolved" with the reason.
- Follow-up: what happens next, who owns it and by when. "None" is a valid answer.
Rules:
- No passwords, MFA codes or secrets in notes, ever.
- Write for the next tech, not for yourself. "Fixed it" is not a resolution.
- Customer-visible notes are written for the customer. Internal notes can be terse but still follow the four parts.
Done means: a manager can read the latest note and say whether the ticket is resolved, waiting on someone, or stuck.
The four-part structure isn't arbitrary. It maps to the questions a service manager asks in a ticket review, and a fixed structure is what makes notes automatable later (more on that below). We covered what separates a usable note from a useless one in call logging software for MSP ticket workflows.
Template 3: Time entry SOP
Purpose: billable and agreement time is captured accurately and on the day it happens.
Steps:
- Log time against the ticket as soon as the work block ends: a call, a remote session, an on-site visit.
- Use the work type your PSA requires for that board and agreement. If unsure, pick the closest and add a note; don't leave it for later.
- Log actual minutes worked. Rounding to your billing increment is your PSA's and finance's job, not the tech's (see MSP billing increments).
- A short call still gets a time entry. Short calls are exactly the ones that disappear.
Done means: every ticket with a call or session on it has a time entry dated the same day.
Audit: weekly, compare calls on the phone system against time entries in the PSA for a sample of techs. Calls with no matching entry are the leak. Our MSP time tracking post goes deeper on where that leak usually starts.
Template 4: Identity verification SOP
Help desk social engineering isn't hypothetical. The joint CISA and FBI advisory on Scattered Spider describes attackers calling IT help desks while posing as employees to get passwords reset and MFA moved to a device they control. An MSP help desk resets passwords for dozens of companies, which makes this SOP the one you most need to be non-negotiable.
Purpose: no sensitive change is made for a caller whose identity hasn't been verified through a channel the attacker can't control.
Applies to: password resets, MFA resets or new MFA devices, mailbox delegation, admin rights, payment or banking detail changes.
Steps:
- Don't verify with information the caller gives you (a callback number they provide, their manager's name, their employee ID). Attackers research all of it.
- Challenge the user through a contact point already on file: a call back to the number in the PSA or directory, a push to their registered authenticator, or a code to the email or phone number on their directory record.
- If the check fails or the caller pushes back, stop. A failed check is not something to retry on a different method in the same call. Note it on the ticket and notify the client's primary contact.
- Record on the ticket which method was used and the result.
Done means: every ticket with a sensitive change has a recorded verification method and result before the change.
Template 5: After-hours escalation SOP
Purpose: urgent after-hours issues reach the on-call tech fast; everything else waits for the morning without being lost.
Define in writing:
- What counts as urgent: for example, a whole site or critical system down, a suspected security incident, or a client-specific definition from their agreement. Keep it short enough that whoever answers the phone can apply it.
- Who is on call and in what order: primary, backup, and when to escalate to the service manager.
- How long before escalating if the on-call tech doesn't acknowledge.
- What's left for the morning: a ticket with the caller's details, the issue in their words, and whether anyone was paged.
Done means: every after-hours call is a ticket by morning, and every urgent one shows who was paged and when they acknowledged.
Where SOPs should live so techs actually follow them
A procedure in a documentation tool is reference material. A procedure attached to the ticket is a workflow. Keep the full SOP in IT Glue, Hudu or SharePoint, but put the steps where the work happens:
- Autotask has ticket checklists that can be added from a checklist library or a ticket form template, and workflow rules can fire on tickets with incomplete checklist items, including ones marked important.
- HaloPSA has to-do lists that a ticket template can apply automatically, with workflow conditions such as "All To-Do List items completed."
- In any PSA, ticket templates and required fields do some SOP enforcement for free: a board that won't close a ticket without a resolution note enforces part of Template 2.
The tradeoff: every enforced step adds clicks. Enforce the steps where a skipped step costs money or risks a breach (time entries, identity checks) and leave the rest as guidance.
How to tell whether an SOP is being followed
Most MSP SOP advice ends at "review your SOPs quarterly." Reviewing the document tells you whether it's current, not whether anyone follows it. Review the tickets instead:
- Pick ten closed tickets per tech per month that started with a phone call.
- Score each against the "done means" line of the relevant SOP: ticket exists, right contact, structured note, same-day time entry, verification recorded where needed.
- Track the pass rate, not individual misses. A low pass rate on one SOP across the whole team means the SOP is wrong or too hard, not that everyone is lazy.
This works because each SOP above was written so its result is visible in the ticket. It's also why we suggest reviewing documentation completeness alongside the numbers in MSP KPIs: utilization and time-to-resolution figures are only as good as the tickets and time entries under them.
Where AI fits in MSP SOPs (and where it doesn't)
AI is useful for SOPs in a narrower way than "AI writes your SOPs." The value is in carrying out the steps people skip, and in producing the same structure every time:
- Ticket notes and time entries from calls: Vight transcribes recorded support calls from the phone system, matches them to the client and ticket, writes an IT support summary (issue, troubleshooting steps, resolution) and posts it to the ticket with a time entry in ConnectWise, Autotask, HaloPSA or Syncro. That turns Templates 2 and 3 from habits you audit into output you spot-check.
- Intake questions: a ticket triage agent can hold your intake SOP as scenarios: for each kind of request, the details a tech needs before starting. In Vight, it emails the requester for what's missing and posts an internal note with what's answered (ConnectWise and HaloPSA).
- Identity checks: Vight's end-user verification lets a tech challenge the caller with a Microsoft Authenticator push, a text code or an email code sent to the contact point in the directory record, and a denied check flags the ticket. That's Template 4, step 2, built into the ticket.
- Runbooks from resolved tickets: Vight's team memory (in beta) distills client notes and runbooks from resolved tickets, which helps with the runbook layer most MSPs never finish writing.
What AI shouldn't do: decide your SOPs for you. What counts as urgent after hours, which changes need identity verification, and what "done" looks like are business decisions that belong to the owner and service manager. An AI tool can apply them consistently; it can't set them. For a wider look at what to hand off first, see MSP automation and help desk automation.
FAQ
How many SOPs does an MSP need?
Fewer than most templates suggest. Start with the five above for the service desk, then add SOPs for client onboarding and offboarding, patching and backup checks. Everything client- or system-specific is a runbook, not an SOP.
What should an MSP SOP template include?
Purpose, scope (what it applies to), numbered steps, a "done means" line that describes what the finished ticket or record should contain, an owner and a review trigger. The "done means" line is the part most templates leave out, and it's what makes the SOP auditable.
Where should MSP SOPs be stored?
The full document in your documentation tool (IT Glue, Hudu, SharePoint), and the steps as a checklist, to-do list or template inside the PSA so they appear on the ticket.
Can AI write MSP SOPs?
AI can draft one from your notes or past tickets, but a person who owns the process should approve it. The bigger win is AI carrying out the documentation steps, such as notes and time entries, so the SOP is followed without relying on memory.
How often should SOPs be reviewed?
Review the document when the process or tooling changes, and review compliance monthly by sampling closed tickets against each SOP's "done means" line.
The bottom line
An SOP nobody follows is worse than none, because it gives you false confidence. Write the five that end in the ticket, put their steps in the PSA, and measure them from closed tickets. If your call handling, notes and time entry SOPs are the ones that keep slipping, book a Vight demo to see notes and time entries written from your own calls into your PSA.