Process Is What Sets Your MSP Free
After more than 30 years building and scaling MSPs, Nick and I know that process is where many good businesses become stuck. Owners work harder, hire more people, add more tools and still find that every important decision funnels back through them. Tickets bounce around, projects take longer than they should, and capable people wait for answers they should already have. That is not a people problem. It is not necessarily a tooling problem either. It is a process problem. In this episode of MSP Mastery: Ctrl Alt Deliver, we explore the second pillar in our three part series on the foundations of a successful MSP. The first pillar was people. This episode is about process. The final instalment will focus on the mindset of a leader. Process is not about turning people into robots or documenting every tiny action in the business. It is about creating clear, reliable ways of working so your team can make good decisions, serve clients consistently and operate without needing the owner to step in every few minutes. When it is done well, process gives people freedom, confidence and accountability.
MSP Mastery
7/20/20267 min read
After more than 30 years building and scaling MSPs, Nick and I know that process is where many good businesses become stuck. Owners work harder, hire more people, add more tools and still find that every important decision funnels back through them. Tickets bounce around, projects take longer than they should, and capable people wait for answers they should already have.
That is not a people problem. It is not necessarily a tooling problem either. It is a process problem.
In this episode of MSP Mastery: Ctrl Alt Deliver, we explore the second pillar in our three part series on the foundations of a successful MSP. The first pillar was people. This episode is about process. The final instalment will focus on the mindset of a leader.
Process is not about turning people into robots or documenting every tiny action in the business. It is about creating clear, reliable ways of working so your team can make good decisions, serve clients consistently and operate without needing the owner to step in every few minutes. When it is done well, process gives people freedom, confidence and accountability.
Stop Outsourcing Your Mess
One of the clearest lessons we learned in our own MSP journey was that offshoring does not fail because the team is located overseas. It fails when an MSP tries to outsource confusion.
Early on, we attempted to use offshore resources to complete tickets overnight. On paper, it sounded sensible. We could queue up work at the end of the day and return the next morning with a list of completed tickets. In reality, we came back to partially completed jobs and more questions than answers.
The issue was not the capability of the offshore team. The issue was that our own internal processes were not properly documented. Key client knowledge sat in the heads of owners and senior technicians. Steps were assumed rather than explained. Every ticket required context that had never been captured.
This is just as relevant for an onshore team member joining your MSP. A skilled technician from another business may know the technology, but they do not automatically know your client standards, ticket workflows, tools, escalation paths or commercial rules. If you do not teach them the way your business works, you are setting them up to fail.
The lesson for MSP owners is simple. Before you add people, whether they are local, offshore, junior or senior, make sure you can clearly explain how work moves through your business. If the answer is trapped in somebody’s head, you do not have a scalable process.
Build Process in Three Clear Layers
The most useful process framework we developed was deliberately simple. A good process needs three layers.
At the top is a high level flowchart. This shows the journey from beginning to end. It might cover client onboarding, employee onboarding, project delivery, sales quoting or ticket management. The flowchart helps a team member understand where the process begins, what happens next and what a successful outcome looks like.
The second layer is a checklist. Each major stage of the flow contains the key actions that must be completed. Checklists help people avoid missing important steps, especially when work is handed between roles or teams.
The third layer contains the detailed standard operating procedures, technical documentation and vendor resources. This is where a team member can find the exact instructions for completing a task.
When someone is new, they may need all three layers. They look at the flowchart to understand the overall journey, follow the checklist and refer to the detailed documentation to learn the work. Once they become competent, they may only need the checklist as a prompt. Eventually, for routine work, the process becomes second nature.
This structure matters because documentation must be useful, not overwhelming. A massive folder full of disconnected documents is not a process. It is a library that people will avoid using. Your team needs to know what they are trying to achieve, what they must do next and where to find support when they need it.
Documentation Is a Shared Responsibility
One of the biggest mistakes MSPs make is assigning documentation to one person or one department. They expect the project engineer, service manager or operations coordinator to keep everything current. That never works for long.
Documentation belongs to everyone.
Processes change when a vendor updates a product, when a client environment changes, when a new security standard is introduced or when your team finds a better way to complete routine work. If nobody feels responsible for updating the knowledge base, people quickly lose trust in it. Once a technician believes the documentation is outdated, they stop checking it. They go back to asking the same senior people for help, and the business falls back into dependency.
Trust is the real asset. Your documentation must be accurate enough that people rely on it when they need to act.
That requires a culture where every team member contributes. If someone discovers an outdated instruction, they should fix it or flag it. If they solve a recurring issue, the solution should be captured. If a process is unclear, the team should improve it. This is not extra administrative work. It is how an MSP turns individual knowledge into a business asset.
The business owner needs to set the expectation. Documentation is not optional because it is what enables consistency, delegation and growth.
Triage Is Where Service Efficiency Begins
In this episode, we spent time unpacking the difference between answering a phone call, dispatching a ticket and genuinely triaging the work. These are not the same thing.
A receptionist or concierge can take a call and capture basic information. A dispatcher can allocate work. But effective triage requires someone with enough knowledge to understand the issue, categorise it correctly, link relevant documentation and assign it to the right person.
Without this step, technicians receive vague tickets from unfamiliar clients with little context. They have to investigate what the issue means, search for information, determine the correct contract, locate the right tools and work out who else may have dealt with the problem before. That is slow, frustrating and expensive.
A properly triaged ticket should give the technician what they need to solve the issue efficiently. The ticket should have the correct category, client information, priority, work type and instructions. Where possible, it should include links to relevant documentation and known solutions.
This is particularly important if you want to use junior technicians or offshore resources effectively. They are usually very good at following a clear workflow. They should not be expected to make commercial or technical decisions without the information and authority to do so.
We proved in our own MSP that routine tickets could be completed at a far higher volume when triage was done properly. The technician could focus on completing the work rather than guessing what the work was meant to be.
Your most experienced people should not be spending their days closing routine tickets while junior team members sit underutilised. Senior people should be coaching, triaging, escalating complex issues and improving the system. When the numbers are the other way around, it is usually a sign that the workflow needs attention.
Consolidate Tools Around One Source of Truth
Tool sprawl creates process sprawl. Many MSPs have a PSA, RMM, documentation platform, project platform, quoting system and several specialist tools that all hold slightly different versions of the truth.
That creates uncertainty. Where should a technician look for client information? Which system holds the current configuration? Where does billing information live? Which record should the team trust?
Our view has always been that you need one clear source of truth, usually the PSA. That is where contracts, tickets, client history and billing come together. Other tools should support that system rather than compete with it.
This does not mean every tool must come from one vendor. It means the tools you choose need a defined role in your operating model. Your team should not have to jump between multiple screens to complete basic work if the systems can be integrated or simplified.
Every mouse click costs time. Every extra system creates another opportunity for errors, duplicate data and missed information. If you have alerts that nobody reads, remove them. If you have mandatory fields that add no value, reconsider them. If a process depends on a technician remembering to search three different platforms, redesign the process.
The goal is not to collect tools. The goal is to create an operating environment where the right information appears at the right time.
Give People Guardrails, Not Bottlenecks
Good process does not remove autonomy. It creates it.
One practical example from our own business was giving field technicians authority to purchase urgent items up to a set value without calling for permission. If they needed a cable, modem or small replacement part to get a client operational, they could make the decision and get the work done.
The guardrail was clear. The financial limit was defined. The process for recording the purchase and invoicing the client was established. If the cost exceeded the limit, the technician knew exactly who to contact and what approval was required.
Without those guardrails, people delay decisions. A technician may drive hours back to the office because they did not know they could spend a few dollars locally to fix the problem. The client waits longer, the technician loses productive time and the business absorbs unnecessary cost.
This is the broader lesson. Your people need clarity around where their authority begins and ends. They need to know which decisions they can make independently, what needs escalation and how to escalate it. When those rules are clearly articulated, people become more confident and owners receive fewer unnecessary interruptions.
Process Turns Knowledge Into Scale
The purpose of process is not perfection. You do not need a detailed procedure for a task completed once each year. Focus on the work that happens repeatedly and has the greatest impact on your client experience, profitability and team capacity.
Think about the 20 per cent of processes that cover 80 per cent of your work. Your common ticket types, client onboarding, project handovers, escalation pathways, quoting, invoicing and employee onboarding deserve attention first.
When you document those core activities, configure your tools to support them and teach your people how to use them, your MSP becomes easier to manage and easier to scale. You create space for your best people to solve bigger problems rather than repeat the same fixes every day.
That is the real promise of process. It turns the knowledge of a few individuals into a reliable operating system for the whole business.
If this episode has made you question whether your processes are helping or hindering your team, take a look at where work is slowing down, where people are repeatedly asking for help and where senior staff are being pulled into routine decisions. Those are usually the first places to improve.
Connect with Nick, me and the MSP Mastery team through MSP Mastery to continue the conversation. The right process will not just make your MSP more efficient. It will give you and your team the freedom to build a business that genuinely works for you.
