Systems Run on Numbers. If You Don't Have the Numbers, You Don't Have a System.

For years I ran my MSP and would have told you with confidence that we had systems.

Documented dispatch process. Written onboarding checklist. QBR template. Escalation procedures. Hiring rubric. Every operational function in the business had something written down somewhere. We had binders. We had shared drives full of SOPs. We had documents new hires were supposed to read on day one. If a client asked how we managed something, we could pull out a process diagram and walk them through it.

I thought that was operational maturity.

It wasn't.

Here is what I figured out the hard way. We had documentation. We didn't have systems. The two aren't the same thing and the difference is the entire reason most MSPs plateau without understanding why.

A system runs on numbers. The numbers tell you whether it is working, when it is drifting, and what needs to be adjusted. Without numbers attached, what you have is a description of how the work is supposed to happen with no way to know whether it actually is. That description has a name. It's called documentation. It isn't a system.

And the day I realized that gap was the day everything started to change.

WHAT I THOUGHT I HAD VERSUS WHAT I ACTUALLY HAD

Let me walk you through what I mean specifically because this is the moment most MSP owners discover something uncomfortable about their own business.

We had a documented dispatch process. Tickets came in, got categorized, got assigned. The process was written down. It existed in our PSA. Every dispatcher had been trained on it.

Did I know what percentage of our tickets were being acknowledged within 15 minutes? No.

Did I know our first-contact triage accuracy rate? No.

Did I know what percentage of tickets were being reassigned because the initial routing was wrong? No.

I knew tickets were coming in. I knew they were getting handled. I had no number that told me whether the dispatch process was actually producing the response time and accuracy we promised our clients.

We had a 30-day onboarding checklist for new hires. It was detailed. It had been refined over years. Every new tech was supposed to complete it.

Did I know what percentage of new hires were operating independently by day 30? No.

Did I know the success rate of their first solo tickets? No.

Did I know how my managers rated their readiness at day 60? No.

I knew people were going through the checklist. I had no number that told me whether onboarding was producing techs who could actually work without constant support.

We had a QBR template. We ran QBRs quarterly with our top clients. The template was polished. The deck was professional.

Did I know what percentage of QBRs produced three documented action items? No.

Did I know our QBR-to-referral rate? No.

Did I know what our action item completion rate was between meetings? No.

I knew the QBRs were happening. I had no number that told me whether they were producing the strategic outcomes I described to prospects when we were closing them.

This was my MSP. Run by someone who would have told you with full confidence that we had operational systems.

What we had was a story everyone in the building told themselves about how the work happened. The story was useful. The story wasn't a system.

THE THREE THINGS EVERY REAL SYSTEM NEEDS

Once I figured this out, I built a framework I have used with every MSP I have coached since. Every system in your field guide has to have three things. If any one is missing, you don't have a system. You have a document pretending to be one.

A defined outcome. What is this system supposed to produce, stated in one sentence, in concrete terms a junior tech could understand. "Every ticket acknowledged within 15 minutes, triaged accurately on first contact, routed to the right tech with the context they need to start work without asking a question." That is an outcome. "Provide great client service" isn't an outcome. It's a value. Values are important. They aren't what makes a system measurable.

A specific number that measures the outcome. The number tells you whether the system is producing the outcome. Percentage of tickets acknowledged within target. First-contact triage accuracy. Percentage of tickets routed without reassignment. These are numbers. They have targets. They can be checked. They produce signal that something is working or something is drifting.

A defined cadence and owner for reviewing the number. Who looks at the number, how often, and what they do when it shows the system is failing. Daily for high-volume systems like dispatch and escalation. Weekly for medium-velocity systems. Monthly for lower-frequency systems like onboarding effectiveness and QBR outcomes. The cadence matters less than the commitment. The number gets checked on a schedule by a specific person who is empowered to act on what it shows.

When all three exist, you have a system. When any one is missing, you have a document. And documents don't produce outcomes. People produce outcomes when they have the right system around them.

THE SYSTEMS YOU CLAIM TO HAVE AND THE NUMBERS THAT WOULD MAKE THEM REAL

Let's get specific. Here are the systems every MSP claims to have. Run your own business against this list and be honest about which ones pass the three-part test.

Dispatch. The process exists in every MSP. The numbers that make it a real system: percentage of tickets acknowledged within target, first-contact triage accuracy, percentage of tickets routed without reassignment, percentage of tickets meeting SLA on the first attempt. Without these numbers reviewed daily, your dispatch process is a description of work, not a managed system. Your client experience is a coin flip on every ticket.

Onboarding new hires. The 30-day checklist exists. The numbers that make it real: checklist completion rate at day 15 and day 30, first solo ticket success rate, time to independent operation, manager satisfaction with new hire readiness at day 60. Without these numbers, your onboarding process is a list of activities, not a measured pathway to a productive employee. You find out your onboarding is broken when a new tech still can't work independently at day 90 and you have to start over.

Escalation. The procedure exists. The numbers that make it real: percentage of tickets aging beyond defined threshold without a status update, average time to escalation owner assignment, percentage of escalations resolved within committed timeline, percentage of escalations that reach the owner. Without these numbers reviewed daily, your escalation procedure is a flowchart. Tickets age silently until a client calls. The procedure exists. The accountability doesn't.

Sales and pipeline. The pipeline review exists. The numbers that make it real: lead-to-MQL conversion rate, MQL-to-opportunity conversion rate, opportunity-to-close rate, average sales cycle length, ratio of new business to existing-client expansion, percentage of QBRs producing referrals. Without these numbers, your sales process is a sequence of stages, not a measured revenue motion. You find out you are missing your number at the end of the quarter when there is nothing left to do about it.

QBRs. The template exists. The numbers that make it real: QBR completion rate by client, percentage of QBRs producing three documented action items, percentage of QBRs producing referral requests, client satisfaction with the QBR experience, action item completion rate at the next QBR. Without these numbers, your QBR is a meeting that happens, not a system that produces measurable client experience outcomes. The meeting feels productive. The retention data eventually tells a different story.

Client retention. The relationship strategy exists. The numbers that make it real: net revenue retention, gross logo retention, churn rate by segment, expansion revenue by client, NPS by client, executive sponsor coverage rate. Without these numbers, retention is something you hope for, not something you actively manage. The clients who are about to leave never tell you. The numbers would have.

Every one of these systems shows up in MSP proposals as evidence of operational maturity. Most of them have no numbers attached. They are descriptions of work, not managed systems. The MSPs that win on operational excellence are the ones who attach numbers to every system in the field guide and review them on a documented cadence.

The ones who skip the numbers operate on the documentation and hope it produces the outcomes the documentation describes. It rarely does, and they find out about the drift from clients instead of from their own data. That is an expensive way to find out.

WHY OWNERS RESIST THE NUMBERS

Here is the part owners don't say out loud.

Attaching numbers to every system means finding out the truth about how the business is performing. Most owners are afraid of what they'll find. They suspect their dispatch system isn't hitting target. They suspect their onboarding isn't producing independent techs as fast as they tell prospects. They suspect their QBRs aren't producing the strategic outcomes they describe in sales conversations.

As long as the numbers don't exist, the suspicion stays a suspicion. The owner can keep telling themselves and their clients that the system works. As soon as the numbers exist, the truth becomes undeniable. The system either hits the target or it doesn't. The owner either invests in fixing it or accepts the gap.

That fear is the single biggest reason most MSPs operate on documentation instead of measured systems. It is also the reason the MSPs that get past the fear pull ahead of their competition fast. The numbers are uncomfortable for about 90 days. After that, they become the most useful thing in the business because they tell you exactly where to invest, what to fix, and what's working well enough to leave alone.

The owners who avoid the numbers never know what their business is actually doing. They manage by feeling. They make investment decisions based on which problem feels loudest that week. They have no idea whether the team they hired last year is actually producing better outcomes than the team they had before. They hope. They guess. They lead with confidence in front of clients while privately wondering whether what they're saying is true.

The owners who embrace the numbers manage by signal. They invest based on data. They know exactly which systems are producing the outcomes they were designed for and which ones need work. The confidence they project in front of clients is real because the data supports it.

The difference between those two operating modes shows up in every metric that matters within 12 months. Retention. Profitability. Team performance. Owner stress levels. Growth rate. The owner running on signal compounds. The owner running on feeling burns out and plateaus.

I was the second kind for years. The shift to the first kind was the most important operational change I ever made in my business.

WHERE THIS LIVES IN YOUR FIELD GUIDE

Every system in your field guide gets documented in the same format. Six components, every time.

Outcome. The one-sentence statement of what the system is supposed to produce.

Process. The steps the team follows to produce the outcome.

Measurement. The specific number that tells you whether the system is producing the outcome.

Cadence. When and how often the measurement gets reviewed.

Owner. Who is responsible for reviewing the measurement and acting on it when it drifts.

Feedback loop. The defined process for what happens when the measurement shows the system is failing.

When that format is applied to every system in your business, three changes happen.

First, you find out which of your "systems" were actually documents. Most owners discover that half of what they called systems didn't have numbers attached. The exercise of building the field guide surfaces this immediately. The number either exists and the system is real, or the number doesn't exist and the documentation was a story.

Second, you start managing the business by signal instead of by feeling. The numbers get reviewed on their defined cadence. Drift gets caught early. Investment decisions get made on data instead of hunches. The business becomes legible to you in ways it never was when you were managing by gut.

Third, your team starts operating differently. When the standard is documented with a number attached, the team knows what good looks like. They can measure themselves against the standard. They take ownership of the number because the standard exists independent of you sitting in the room reviewing it. The accountability shifts from depending on you to being built into the system itself.

This is what produces a business that runs without you in every decision. Not by accident. By documented systems that run on numbers and feedback loops your team is trained to read and act on.

Every system in your business either runs on numbers or it doesn't run at all.

The documentation makes you feel organized. The numbers make you operational.

You can have the most polished SOPs in the industry. You can have a binder full of process documents your competitors would envy. You can have a hiring rubric, an onboarding checklist, a QBR template, and an escalation procedure all written and stored where the team can find them.

Without numbers attached, none of that produces predictable outcomes. It produces variation. Some weeks the dispatch process works. Some weeks it doesn't. Some new hires get to independence in 30 days. Some take 90. Some QBRs produce referrals. Most don't.

And you never know which is which until a client tells you. That isn't a business. That is a series of accidents you are trying to manage with your gut.

Pick three systems in your business this week. Define the outcome each one is supposed to produce. Define the number that would tell you whether it's producing it. Define the cadence and the owner for reviewing the number. Start checking it.

Document the format in your field guide. Apply the same format to every other system over the next 60 days. Then sit back and watch the difference between an MSP that runs on numbers and the one you used to run.

The numbers are uncomfortable for the first 90 days. After that they become the most valuable thing in your business.

Start at builttorunmsp.com

FREQUENTLY ASKED QUESTIONS

What is the difference between a documented process and a system in an MSP?

A documented process describes how work is supposed to happen. A system produces a measurable outcome that can be tracked, reviewed, and improved over time. The difference is the numbers. A system has a defined outcome, a specific number that measures whether the outcome is being produced, a cadence for reviewing the number, and an owner responsible for acting on what the number shows. A documented process has none of those things. It tells your team what to do without telling them what they're trying to produce, how to know if they produced it, or what happens when the work drifts from the standard. Most MSPs have documented processes and call them systems. The distinction matters because documented processes produce variation while real systems produce predictable outcomes.

What metrics should an MSP track for dispatch and ticket management?

The core dispatch metrics every MSP should track on a daily cadence: percentage of tickets acknowledged within the target response time, first-contact triage accuracy rate, percentage of tickets routed without reassignment, percentage of tickets meeting SLA on the first attempt. These numbers tell you whether the dispatch system is producing the client experience you designed it to produce. Without them, dispatch becomes whatever the team makes of it on any given day, and client experience varies with whichever dispatcher happens to be working. With them, dispatch becomes a managed system that catches drift before clients feel it.

How do you measure the effectiveness of new hire onboarding in an MSP?

Effective onboarding measurement requires four numbers reviewed at defined checkpoints. Checklist completion rate at day 15 and day 30 tells you whether the new hire is moving through the documented standard. First solo ticket success rate tells you whether they're actually ready to work independently. Time to independent operation tells you whether your onboarding cycle is producing productive techs on the timeline you committed to. Manager satisfaction with new hire readiness at day 60 tells you whether your senior team views the new hire as a contributor or as a burden. Without these numbers, onboarding feels like it works until you discover at day 90 that the new hire still can't operate without constant support.

Why do most MSP owners avoid measuring their operational systems?

Most owners avoid measurement because they suspect what the numbers will show. They suspect their dispatch system isn't hitting target. They suspect their onboarding isn't producing independent techs as fast as they tell prospects. They suspect their QBRs aren't producing the strategic outcomes they describe in sales conversations. As long as the numbers don't exist, the suspicion stays a suspicion and the story stays comfortable. As soon as the numbers exist, the truth becomes undeniable. The system either hits the target or it doesn't. That discomfort is the single biggest reason most MSPs operate on documentation instead of measured systems. The owners who get past the discomfort pull ahead of their competition quickly because they manage by signal instead of by feeling.

How does a field guide turn documented processes into managed systems?

The field guide applies a consistent format to every system in the business. Outcome, process, measurement, cadence, owner, feedback loop. When every system gets documented in that format, three changes happen. First, the exercise surfaces which of the existing "systems" were actually just documents because they have no measurement attached. Second, the business shifts from being managed by feeling to being managed by signal because the numbers get reviewed on a defined cadence and drift gets caught early. Third, the team starts operating differently because the standard is documented with a number attached, which means they can measure themselves against the standard instead of waiting for the owner to evaluate them. The field guide is what turns documentation into a managed operating system.