Should MSP SOPs live in our PSA or documentation platform?

Client-specific technical documentation (credentials, network diagrams, configurations) belongs in your IT documentation platform. Business procedures that describe how your team works, such as how you onboard a client or run a QBR, fit better in an SOP tool everyone can read.

What is the most important SOP for an MSP to write first?

Ticket handling and escalation, because it runs every day, touches every client and is where inconsistency is most visible. Client onboarding is a close second.

How detailed should a patching SOP be?

Detailed enough that a technician new to your stack could run a patch cycle correctly: the schedule, the tools, the order of rings or groups, the checks after patching and what to do when something fails.

Do we need a separate SOP for offboarding a client?

Yes. Offboarding involves access removal, data handover and billing changes, and it happens rarely enough that nobody remembers the steps. It is exactly the kind of process that needs writing down.

MSP SOPs: The 9 Core SOPs Every MSP Needs

MSP SOPs are the written procedures a managed service provider follows at every stage of the client lifecycle. The core set is nine: prospecting and outreach, discovery and assessment, quoting and proposals, client onboarding and deployment, ticket handling and escalation, patching, change management, quarterly business reviews and client offboarding. Write ticket handling and escalation first.

They describe how your team works, not how a particular client’s environment is built, and they are what let service quality stay the same as you add technicians.

Most MSPs are good at technical documentation. Network diagrams, credentials and client configurations have a home in the IT documentation platform, and they get updated because tickets depend on them. What tends to be missing is the business side: how a prospect becomes a client, how a ticket gets escalated, how a QBR is run, and how a client is offboarded without leaving access behind.

This guide covers the full stack of MSP and IT services SOPs, what goes in each, the order to write them and where they tend to fail.

Map MSP SOPs to the business pillars

An IT services firm maps cleanly onto the path a client takes. SOPCompass organizes every workspace as Company plus five pillars:

Company: handbook, tool stack and logins, technician onboarding, security policies for your own staff.
Lead Acquisition: prospecting, outbound scripts, referral and partner channels.
Lead Nurture: follow-up, assessments, educational content.
Sales Execution: discovery, technical assessment, quoting and proposals.
Fulfillment & Delivery: onboarding and deployment, ticket handling, escalation, patching, change management.
Retention: QBRs, renewals, account reviews and client offboarding.

SOP	Pillar	Owner	When it runs
Prospecting and outreach	Lead Acquisition	Sales or business development	Weekly cadence
Discovery and assessment	Sales Execution	Sales engineer or vCIO	Each qualified prospect
Quoting and proposals	Sales Execution	Sales lead	After discovery
Client onboarding and deployment	Fulfillment & Delivery	Project or onboarding lead	Each new client
Ticket handling and escalation	Fulfillment & Delivery	Service desk manager	Every ticket
Patching	Fulfillment & Delivery	NOC or senior technician	On the patch schedule
Change management	Fulfillment & Delivery	Service manager	Every non-standard change
Quarterly business review	Retention	Account manager or vCIO	Quarterly per client
Client offboarding	Retention	Service manager	When a client leaves

The order to write them

Ticket handling and escalation. It runs all day, every day, and inconsistency here is what clients feel most.
Client onboarding and deployment. The first 30 to 90 days set the tone for the whole relationship.
Patching. Routine, high-risk and easy to do slightly differently each time.
Change management. So the change that caused an outage can be found and rolled back.
Client offboarding. Rare, which is why it goes wrong.
QBRs. Your main retention tool; worth making repeatable.
Discovery, quoting and prospecting. Important, but usually handled by fewer, more senior people.

Prospecting and discovery

Prospecting SOPs cover your ideal client profile, where lists come from, the outreach sequence, call scripts and what counts as a qualified lead. Write down the questions that disqualify a prospect early (too small, wrong industry, unrealistic expectations) so reps stop spending time on poor fits.

Discovery is where you learn what you are really taking on. Document the questions you ask about users, devices, locations, line-of-business applications, current provider, backups, security tooling and compliance concerns. Include a technical assessment checklist if you run one.

Common failure point: discovery notes live in one sales engineer’s head, and the onboarding team starts from scratch. Make the discovery output a required input to the onboarding SOP.

Quoting

The quoting SOP should explain how you build a proposal: per-user or per-device pricing, which services are in each tier, how project work for onboarding is scoped, which third-party licensing is resold and at what margin, and who approves exceptions. Include a checklist for what every proposal must contain before it goes out.

If you are working toward compliance frameworks or specific client regulations, note where to check requirements rather than asserting them in the SOP. Those rules change and depend on the client.

Client onboarding and deployment

Onboarding is the largest SOP most MSPs write, so break it into a sequence of smaller ones:

Kickoff call and contact list: who approves, who reports issues, who is the escalation contact.
Access and credentials handover, stored in your documentation platform, never in the SOP.
Discovery of the environment: inventory, network, accounts, backups.
Agent deployment, monitoring and alerting setup.
Security baseline for your standard stack.
Handover from the previous provider, if any.
User communication: how to reach the help desk, what to expect in the first week.
A 30-day check-in.

Take Trailhead IT, an invented IT services firm in our IT services example. It treats post-close deployment as its own SOP in Fulfillment & Delivery, directly after the product knowledge reps rely on to close, so everyone can see what happens before and after their part.

Ticket handling and escalation

This SOP defines how every ticket moves through your service desk:

Intake channels and how each one becomes a ticket.
Triage: priority definitions with concrete examples (“one user cannot print” versus “the whole office is down”).
Response and resolution targets for each priority, matching your client agreements.
When and how to escalate: tier 1 to tier 2, to a senior engineer, to the vendor, to the account manager.
Communication standards: first response, updates while open, closing notes the client can understand.
After-hours handling and on-call rotation.

Escalation is where most service desks leak. Write down the specific triggers (“no progress in X minutes on a P1”, “same issue reopened twice”) rather than “escalate when needed.” A customer support escalation SOP template is a useful starting point.

Patching and change management

Patching should cover the schedule, the tools, the groups or rings you deploy to and in what order, how you handle reboots and maintenance windows, the checks after patching, and what to do when a patch fails or breaks something. Include how exceptions are recorded for machines that cannot be patched on schedule.

Change management covers anything outside routine work: firewall changes, server migrations, new line-of-business software. Define what counts as a standard change, what needs approval and from whom, how the change and rollback plan are recorded, and how the client is told.

Common failure point: an emergency fix made at 11pm, never recorded. Include a step for recording emergency changes after the fact.

These are procedures a technician follows while working in several consoles at once. For the screen-heavy steps, capturing the task once with the SOPCompass Capture Chrome extension (for web consoles) or recording yourself doing it (for anything on screen, with the video kept) produces a guide with screenshots faster than writing it out.

Quarterly business reviews

A QBR SOP makes reviews consistent across account managers:

Prep: pull ticket trends, uptime and backup reports, security findings, hardware approaching end of life, license counts.
The agenda: what went well, what went wrong, what is coming (renewals, projects, budget).
Recommendations: a short roadmap with priced options.
Follow-up: send notes and next steps within a set number of days, and create the projects that were agreed.

QBRs work best when they surface the client’s plans, not just your metrics. Put the questions you ask about hiring, office moves and new software into the SOP.

Client offboarding

Offboarding happens rarely, which is why it needs an SOP most. Cover:

Confirming the end date and what the agreement requires of you.
Handing over documentation and credentials to the client or the new provider.
Removing your agents, monitoring and remote access.
Removing your own accounts and admin access from their systems, and confirming removal.
Final billing and license transfers or cancellations.
A closing conversation, and a record of why they left.

Contract terms and any data retention obligations vary by agreement and location; check your contract and legal advice rather than writing rules into the SOP.

Where MSP SOPs go wrong

Mixing client documentation with procedures. Keep credentials and configurations in your IT documentation platform. SOPs describe the method.
Writing for yourself. An SOP written by a senior engineer often skips the steps that feel obvious. Have a newer technician test it.
Not updating when tools change. When you switch RMM, backup or security tools, update every SOP that mentions them. The roll out new tools use case covers how to do this without missing any.
No named owner. Each SOP should list the role that keeps it current.

To be clear about scope: SOPCompass is an SOP tool, not a PSA or RMM. It holds the written procedures your team follows and tracks who has read them, while tickets, monitoring and billing stay in the systems built for them. When a new technician starts, assigning the service desk SOPs with due dates gives them a defined reading list for their first week.

Start from a template

Our IT services and MSP SOP templates give you a starting structure for onboarding, ticket escalation and QBRs. Adapt them to your stack and your client agreements, and write the ticket handling SOP first.

MSP and IT Services SOPs: The Complete Stack