Key Takeaway: The case study that actually moves a prospect is specific, honest, and written from the client perspective. A dental practice with 12 employees and a 10-year-old server is more useful than a small healthcare client. Numbers are more credible than adjectives. One good case study is worth more than ten vague ones.
The MSP case study is the most underused sales tool in the industry. Most MSPs either do not have case studies, have case studies that are too vague to be useful, or have case studies that read like vendor marketing rather than client stories. The case study that actually moves a prospect from consideration to decision is specific, honest, and written from the client’s perspective rather than the MSP’s.
This guide covers how to build case studies that work, what to include, what to avoid, and how to use them in the sales process.
Why Most MSP Case Studies Fail
The typical MSP case study follows a predictable structure: we helped a client in [industry] improve their [metric] by [percentage]. The client is unnamed. The metric is vague. The percentage is unverifiable. The reader learns nothing specific about what the MSP actually did or why it worked.
This type of case study fails because it does not answer the question the prospect is actually asking: “Is this MSP capable of solving my specific problem?” A case study that describes a vague improvement for an unnamed client in an unspecified industry does not answer that question. A case study that describes a specific problem, a specific solution, and a specific outcome for a named client in a recognizable situation does.
The Case Study Structure That Works
The client and their situation. Who is the client, what do they do, and what was their IT situation before they engaged the MSP? The more specific this section is, the more useful the case study is for prospects in similar situations. A dental practice with 12 employees and a 10-year-old server infrastructure is a more useful description than “a small healthcare client.”
The problem. What specific problem was the client experiencing? Not “they had IT challenges” but “their server was running Windows Server 2012 R2, which reached end of support in October 2023, and they had not had a backup tested in 18 months.” The specific problem is what allows a prospect to recognize their own situation in the case study.
What the MSP did. The specific actions taken, in enough detail that the reader understands what the engagement actually involved. Not “we implemented a comprehensive security solution” but “we migrated the server to a cloud-hosted environment, deployed EDR on all 12 endpoints, implemented MFA on all accounts, and established a quarterly backup restore testing schedule.”
The outcome. Specific, measurable results. Not “the client is more secure” but “the client passed their cyber insurance renewal with no coverage gaps, reduced their monthly IT support costs by 23%, and has not experienced an unplanned outage in 14 months.” Numbers are more credible than adjectives.
The client’s voice. A direct quote from the client that describes their experience in their own words. The quote should be specific enough to be credible and personal enough to be human. “Our IT is better now” is not a useful quote. “We had a ransomware attempt six months after the migration, and it was stopped before it reached any of our systems. That would not have happened with our old setup” is a useful quote.
Getting Client Permission
The most common reason MSPs do not have case studies is that they have not asked clients for permission to use their story. Most clients will say yes if asked correctly. The ask should be specific: “We would like to write a brief case study about the work we did on your server migration. It would describe the problem you were facing, what we did, and the outcome. We would share it with you for review before publishing anything. Would you be comfortable with that?”
Clients who decline to be named can still be featured in anonymized case studies. “A 12-person dental practice in the Pacific Northwest” is specific enough to be useful without identifying the client. The outcome data and the specific actions taken are still credible even without the client’s name.
How to Use Case Studies in the Sales Process
The case study is most effective when it is matched to the prospect’s situation. The prospect who is a dental practice should see the dental practice case study. The prospect who is worried about cyber insurance should see the case study where the client passed their renewal. The prospect who is considering switching from a previous MSP should see the case study where the client made that transition.
The case study is not a brochure to be handed out at the beginning of a sales conversation. It is a proof point to be introduced when the prospect has described their situation and the case study is directly relevant. “That sounds similar to a situation we handled for a dental practice in [city]. Would it be useful to see how we approached that?”
Frequently Asked Questions
What if my clients will not let me use their names?
Anonymized case studies are still useful. The specific details of the problem, the solution, and the outcome are what make a case study credible, not the client’s name. “A 25-person construction company” is specific enough to be useful. Ask for permission to use the story anonymously if the client is not comfortable being named.
How long should an MSP case study be?
Long enough to be specific, short enough to be read. Five hundred to eight hundred words is a reasonable target for a written case study. The case study should be specific enough that a prospect in a similar situation recognizes their own problem, but concise enough that a busy business owner will read it.
How many case studies do I need?
One good case study is worth more than ten vague ones. Start with your best client story, the one where the problem was clear, the solution was specific, and the outcome was measurable. Build from there. Three to five strong case studies covering different client types and different problem categories is a useful library.
About Brent Lacy: Brent Lacy is a technology advisor and the voice behind Rewired MSP. He is the author of Rewired MSP: Mastery, Scalability & Performance, vCIO Rewired: Virtually Conquering IT Obstacles, and Near Miss: Preventable IT Failures Threatening Your Business Security.
Related Reading
- The MSP Differentiation Problem: How to Stand Out When Everyone Offers the Same Stack
- How to Get Your First MSP Client: What Actually Works
- The Power of the Table: Why Your Next Big Growth Move Is a Coffee Date
- MSP Growth and Sales Hub
This article is part of the MSP Growth and Sales Hub. See also: The MSP Differentiation Problem and How to Get Your First MSP Client.
