How to Build an MSP Sales Process

Most MSPs look at sales and see black magic. 

They see a colleague who is a ‘natural’ and think, "He was born with it, and I wasn't. It's just not in my DNA." That's the number one reason MSPs fail at sales. They convince themselves it's a gift, not a skill. 

I’m here to tell you that’s wrong. Sales isn’t black magic. It's a process. And the more you treat it like one, the better you'll get and the more results you’ll see. 

The problem is, the average MSP only runs this process 10-15 times a year. Michael Jordan didn't get to be Michael Jordan by practicing basketball 15 times a year. He got better because he ran the same plays over and over, iterating and improving each time. 

If you’re just winging it, you’re learning all over again with every new prospect. There’s no muscle memory – and your ability to improve is severely limited. You just keep getting what you’ve always gotten.   

The good news? You already have the skills you need. I wrote about why you need a repeatable MSP sales process, it's about applying the same discipline you use for a workstation deployment to your sales engine. 

If you're sold on the philosophy, this is the guide to building the machine.  Here is the 5-step process I used when building my MSP. Steal it, adapt it, and make it your own. 

The Methodology: Get to No Early 

Before we dive into the steps, you need to understand this core philosophy: get to no early. 

Real, true objections are often a sign that you failed to properly qualify the prospect early enough. The goal of this process is to give a prospect many opportunities early on in the sales cycle to tell you they aren't a fit. If you run the play correctly, by the end, the customer will be the one convincing you that they are a fit. 

Step 1: The Right Fit Call 

At my MSP, we called our first prospect interaction "The Discovery Call." But once I heard Nigel Moore of The Tech Tribe call it "The Right Fit Call," I admittedly stole the name from him and never looked back. 

The name says it all. This first call is designed to determine if you even want to work with this company, and if they want to work with you. The time of a sales professional is incredibly valuable, so don't spend it with someone you wouldn't want to have as a client. 

During the Right Fit Call, you need to answer a few key questions: 

• How do they make money? 

• Is their problem severe enough for a timely buying decision? 

• Is this the kind of person I want to work with? (The "No Assholes!" rule is critical.) 

• Can this prospect afford me? 

• How do they make buying decisions? Who is involved? 

• Why are they leaving their last IT provider? And are we different? 

Here's how I would handle the budget question in that first 15-minute call:

"You told me you've got 10 computers. If I told you that you had to spend around $2,500 a month to do IT right, can we still be friends, or is that the end of this call?"

 If you’re convinced the prospect is a good fit, the call ends with you setting the "up-front contract" for the rest of your MSP sales process. You explain exactly what will happen next and get their permission to move forward. 

Step 2: The Stakeholder Interview  

This is where you move from a phone call to a real business conversation. Your primary objective is to identify the client's business pain. Pain is likely associated with risk or unmet needs, and while that is changing slowly risk remains the primary driver of IT decisions today. 

This is also the moment where a simple mistake can cost you everything. I learned this the hard way early in my MSP career when I had to tell one of my favorite clients that they needed to spend $30,000 to replace their old Windows XP machines before the end of the quarter. He looked at me and said, "Man, if you ever do that to me again, I'm going to take you out back and shoot you. I love you to death, man, but I can't run my business with you behaving like this." 

You have to eliminate surprise expenses. This is where you tackle the two biggest objections head-on: the decision-maker and the budget. 

First, you need to identify who is actually involved in the buying decision. It may not be the person you’re talking to. By asking probing questions, like who they consult with and whose input they value, you can ensure all the necessary people are involved. 

“Picking a new IT provider is a big decision and most of the people I work with typically lean on a few key colleagues for buy-in or a second opinion on things like this.  Who in your organization is likely to be involved in this decision with you?” 

Second, you need to talk about budget. My preferred method is a technique called "bracketing." I’ll sit down with a prospect and say something like: 

“In my experience, when a customer of your size comes to us with technology problems like this, it typically costs them between X and Y to solve these problems. Does that line up with what you were expecting to hear?" 

This isn’t about giving a final price; it's about qualifying them. Get your no early and move on to the next opportunity. 

Step 3: Data Collection  

This is where you connect the business pain from the stakeholder interview to the technical reality. While some prefer to merge this with the previous step, I always kept them separate.  

I'm separating myself and removing myself from the nerd conversation. This establishes you as the business expert and your engineer as the technical expert. 

The goal here is to identify technical deficiencies and risks to the business. It's important to distinguish between the two: 

• Technical deficiencies are your responsibility. An unmanaged switch is a technical problem that creates trouble tickets for your team. 

• Risks are the client’s responsibility. A lack of multi-factor authentication is a business risk that the client needs to address. 

This is how I would frame the purpose of the data collection for the client:

"When my engineer comes back with their findings, I'm looking for two things. First, are there technical deficiencies we can fix to make your life easier? That's our job. Second, and more importantly, are there business risks here that you need to be aware of? My goal isn't to sell you a new server because it's old; it's to show you the risk of that server failing during your busiest month and help you make a smart business decision."

This step involves a physical walkthrough. A network scan won't tell you about the 10-year-old unmanaged switch tucked away above the ceiling tiles. You need to put eyes on the environment to find the issues that align with the pain points you uncovered in your interviews in the previous steps. 

Like this? You'll love our newsletter.

Get our weekly emails packed with more expert insights, new courses, and community events you won't find anywhere else.

Step 4: The Confirmation Call   

Ever walk into a proposal presentation thinking you know exactly what’s going on, only to figure out ½ way through that you missed something critical? This next step is designed to defeat that disaster.  

The confirmation call is your opportunity to blend the technical findings from data collection with the emotion and risk from the stakeholder interview. The goal is simple: verify your findings and get permission to present the final proposal to all stakeholders. 

A conversation during this call might sound something like this: 

“If I remember correctly, you told me that [this process] was really painful. What my engineer found was that outdated and improperly configured equipment is likely the cause. I’m confident we can help you fix that.” 

The entire call is about reminding the customer of their pain and connecting the dots between their frustration and the technical issues you’ve found. It likely ends by asking permission to assemble all of the stakeholders for a proposal presentation where you’ll present your findings and recommendations.  

A nice finishing touch here is to remind them of the budget bracketing we outlined earlier.

“I know this sounds like a lot, but the good news is your monthly IT spend should still fall within the X and Y monthly spend we discussed earlier. I’m sure you were worried about cost, so hopefully that helps you sleep a little while I pull together the final numbers.”   

What I’m doing here is reminding my prospect that we discussed price before we ever put all of this time into their project and that if they object, they should do so now to save themselves time. If you find yourself getting a lot of objections from this stage forward, it’s likely because you weren’t communicating enough earlier in the sales process.

Step 5: The Proposal Presentation 

By the time you get to the final call, there should be no surprises. You should already know the prospect's pain, their budget, their risk tolerance, and the organization’s decision-making process. 

Your goal here is to present a comprehensive assessment of the organization’s technology and related risk along with an actionable remediation plan. Remind the customer of the pain, remind them of the budget, and then ask for their business in a way that feels authentic to you. 

Most people aren't going to say my go-to line: 

“It seems like we can solve for all the problems we discussed, and we are able to do so within the budget we’ve been discussing. Would you like to sign the contract now, or should I stand in the hallway while you talk about me behind my back?” 

But you need to find your own authentic way to ask for the business. If you don't ask, you don't get. 

The Bottom Line 

My last article was the philosophy. This is the framework. If you're ready to give your team the full playbook, I've built that for you.

My livestream series on Empath walks you through this exact 5-step sales process, with the worksheets and tools you need to build your own version. Members get access to all previously recorded sessions and are able to subscribe to get their questions answered live on future sessions. 

Want to try it out? You can access the entire series and much more right now with a 14-day free trial of Empath.