# MSP Notes — Full Content ## AI priorities MSPs should turn into revenue before the end of the year **Author:** Gaidar Magdanurov | **Published:** 2026-09-09 **URL:** https://mspnotes.com/ai-priorities-msps-should-turn-into-revenue-before-the-end-of-the-year **Tags:** Business   AI is easy to activate and much harder to operate. Customers switch on copilots, build agents inside business applications and buy AI features from vendors they already use. The operational problems arrive quickly: excessive data access, unmanaged applications, unpredictable costs, inconsistent outputs, weak audit trails and unclear accountability. For an MSP, that gap is both the opportunity and the product roadmap: manage the AI systems customers are already adopting and charge for it on top of the managed services you already deliver. ## 1. AI enablement before deployment Do not just resell the licenses. Sell readiness and enablement packaged with licenses. Microsoft Copilot is an example. Copilot respects the permissions already configured in Microsoft 365, which is necessary, yet it also means overshared or poorly governed information may become easier for authorized users to discover. Microsoft's [deployment guidance](https://learn.microsoft.com/en-us/microsoft-365/copilot/configure-secure-governed-data-foundation-microsoft-365-copilot) tells organizations to identify and remediate oversharing, establish access guardrails and monitor Copilot activity. That remediation can be a conversation starter with a customer. An AI readiness assessment covers: - Approved and unapproved AI applications and shadow AI discovery - SharePoint, OneDrive and other data-sources - Identity and permissions - Data classification and retention - AI license allocation and utilization, assignment policies for inactive users - Existing policies, contractual requirements and regulatory exposure - A prioritized remediation and deployment plan The deliverable states what must be fixed, who owns it, what comes next and what it costs, and it scopes the remediation and managed-operations work that follows. Tools like [Acronis GenAI Protection](https://www.acronis.com/en/products/cloud/cyber-protect/genai-protection/) help with shadow AI discovery and add protection while the analysis and proper deployment are ongoing. The tools are available; the goal is to package and sell them. ## 2. AI agents as managed workloads Traditional monitoring detects infrastructure failures: a server is unavailable, an application returns an error or an endpoint stops reporting. AI fails differently. An agent may complete a transaction but choose the wrong action. It may loop, use the wrong data source, produce an unsupported answer or need repeated human correction while every availability indicator stays green. MSPs should therefore manage agents as a distinct workload class. An agent is model + context + operating harness. The model produces the output. The harness decides what the agent can access, what it can spend, when a person must approve an action and how it is stopped or rolled back. The harness is the MSP's job. At minimum, monitoring should answer five questions: - What did the agent do? - Which data and systems did it access? - Where did it fail or require human intervention? - What did each task cost? - What changed as a result of the review? The tooling does not have to be perfect at launch. Microsoft provides [Copilot readiness and usage reports](https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-reports-for-admins), agent-usage information and Purview audit logs covering AI activity. Some of that reporting may depend on the customer's license tier, so confirm what you can evidence before pricing the service. Add an AI section to every quarterly business review. One sentence works there: "Here is what AI did in your business this quarter, here is what it cost and here is what we changed." ## 3. AI cost control AI costs do not behave like software seats. A seat has a predictable monthly price. An agent's cost varies with requests, model, tools called, data retrieved and iterations needed to finish a task. That variability is already an enterprise concern. In the FinOps Foundation's [State of FinOps 2026 survey](https://data.finops.org/), 98% of 1,192 practitioners now manage AI spend, up from 31% two years earlier. Enterprises hired for this. Small businesses will rely on their MSPs. Three services fit here: - **License optimization.** Compare assigned licenses with actual usage and remove or reallocate idle seats. The savings show on the next invoice. - **Budget controls.** Set spending limits, alerts and escalation rules for usage-billed services, and define who can raise a limit and when a workload is paused. - **Cost-per-outcome reporting.** Do not stop at tokens or monthly software cost. Connect the expense to an operating result: cost per ticket processed, per document reviewed, per proposal generated. Let me make this concrete. A 60-user customer holds 40 Microsoft 365 Copilot Business seats at the $21 per user per month list price: - 40 seats × $21 = $840 per month, $10,080 per year - Usage reports show 12 seats with no activity in 30 days, 30% of the total - 12 seats × $21 = $252 per month, $3,024 per year back to the customer That is $3,024 on the next invoice, which makes the assessment fee easy to justify. Of course, the example oversimplifies the matter. Some idle seats belong to people who need training, not removal, and that work is where the MSP earns. ## 4. AI governance and compliance [Research commissioned by AvePoint](https://www.avepoint.com/news/research-from-avepoint-and-omdia-reveals-governance-and-compliance-as-the-leading-ai-adoption-barrier-among-ms-ps-260409) from Omdia surveyed 333 MSPs globally. Of those, 51% named data governance and compliance as the main obstacle to customer AI adoption. 94% said they were committed to automating AI data readiness and compliance work, yet only 43% rated themselves highly mature at delivering it. Omdia projects 21% growth in MSP compliance services in 2026. Governance may become the strongest recurring component of an MSP AI offering. This is a familiar managed-services opportunity: customers need the capability, cannot justify building it internally and require continuous evidence that the work is being done. The service is the readiness assessment run continuously: acceptable-use policy, AI inventory including shadow AI, identity and data-access controls, activity logging, human approval for sensitive actions, employee training, exception procedures and a quarterly compliance report. Regulation helps sell the service, and the EU just supplied a deadline. The [EU AI Act's Article 50](https://commission.europa.eu/news-and-media/news/safer-and-more-transparent-ai-2026-08-02_en) transparency obligations took effect on August 2, 2026. Businesses must tell people when they are interacting with certain AI systems and label specified categories of AI-generated content. Fines run up to €15 million or 3% of global turnover, with proportionality for SMEs. > A word of caution. An MSP should not present itself as the customer's legal adviser. The MSP's role is operational partner: translate the customer's legal and contractual requirements into controls, records, training, monitoring and evidence. ## What to do next Most MSPs do not need a broad AI portfolio on day one and could not staff one. Start with three tiers: Potential Offer Customer receives Commercial model Expansion trigger **Assess** AI inventory, shadow AI discovery, permission and license review, roadmap Fixed fee Findings scope the next two tiers **Deploy** Data-access remediation, AI or agent rollout, policies, user training Project fee plus licensing margin New users, use cases, integrations **Manage** Monitoring, reporting, cost control, policy enforcement, compliance evidence Per-user, per-agent or per-tenant MRR Growth in AI usage and regulatory scope None of this is free to deliver. An assessment consumes technician days before the first invoice, and the governance tier needs someone who can read a customer contract. Price the tiers with that labor in them. Build the offer on needs your current customers already have: - **Select ten existing customers for an initial AI review.** Start with those already using Microsoft 365 Copilot, public AI tools or AI-enabled business applications. - **Create one fixed-scope readiness assessment.** Define inputs, deliverables, exclusions, price and turnaround time. - **Run the assessment internally.** Build your own AI inventory, acceptable-use policy, permission review and cost baseline before selling governance. - **Add AI to every QBR.** Cover active tools, cost, risk, utilization and the next action. - **Automate one internal workflow end to end.** Documentation from resolved tickets is a practical start. Measure the result. Serve the customers who need it now. What works becomes the package for the rest of the base and for new customers. It is time to put AI on your price list. --- ## AI is Infrastructure, Manage it as One **Author:** Gaidar Magdanurov | **Published:** 2026-06-22 **URL:** https://mspnotes.com/ai-is-infrastructure-manage-it-as-one **Tags:** Technology   You already design the IT infrastructure for failure. You put a UPS and a generator behind the power. You run a second circuit so a dead WAN link does not take a client offline. You keep backups and a DR plan because you assume, correctly, that storage and cloud services go down. AI deserves the same treatment, because it has become load-bearing in how you deliver services and critical for customer workflow. Alert triage in the SOC, ticket summarization and routing in the PSA, remediation scripts in the RMM, client reporting, first-line chat. And the same applies for the customer applications - most of them depend on AI in almost every business process now. And when the model behind those features is unreachable, or produces unexpected results, the workflow degrades or stops. The difference from a power cut is that most teams have not yet built a single contingency for it. And you are routing real work through a service you do not control and have no fallback for. ## How AI infrastructure fails There is a whole list of scenarios for AI failure: - Provider or regional outage. Every major cloud has had multi-hour outages. - Rate limiting under load. The moment your volume spikes, a shared API can throttle you. - Deprecation. A model version you tuned your prompts and workflows around gets retired. - Price changes. A per-token increase that looks small can quietly break the unit economics of an AI-assisted service you priced months ago. - Regulatory cut-off. On June 12, 2026, the US government ordered Anthropic to suspend its two newest models for any foreign national, and the company switched them off for all customers within hours. No deprecation window. That is now a documented failure mode, not a hypothetical one. Any one of these takes your AI layer offline or makes it economically unsustainable for you or your customers. However, all of those scenarios are survivable if you planned for them. ## The two contingencies that matter Reliability is your product. So build for AI the way you build for everything else in the delivery path: redundancy you can fail over to, and a copy you control. This applies to your infrastructure and projects you deploy for your customers. **Run more than one provider with smart routing**. Do not single-source the model. Put a thin routing layer in front of your AI-dependent workflows so that when one provider is down, throttled, restricted, or repriced, traffic shifts to another automatically. This is multi-WAN logic applied to AI. The point is that failover happens by design, not as a 2 a.m. scramble while tickets pile up. Having more than one provider also gives you somewhere to go when one of them changes its pricing. **Keep a local model you control**. For the workflows that must not fail, run an open-weight model on your own hardware or customer infrastructure. Mid-sized models that can be suitable for certain workflows run on a single workstation-class GPU. It will not match the best cloud model on raw capability. That is fine. This is the same logic as keeping a local backup: the cloud copy is better day to day, but the local copy is the one that saves you when the cloud is unreachable. Size the local model for "good enough to keep the SLA alive," not "best in class." Solutions like [Acronis Cyber Frame Local](https://www.acronis.com/en/products/cloud/cyber-protect/cyber-frame/) help you provision the virtual machines, storage, and networking needed to host private AI applications, local model runtimes, RAG systems, vector databases, and agentic workflow automation stacks in your data center or on customer premises. ## What to do now - Map where AI sits in your delivery and customer services: which workflows, which tools, which providers. - Separate the AI that touches an SLA-bound service and critical processes for your customers from the AI that is merely convenience. - For the critical paths, stand up one real fallback: a second provider behind a routing layer, or a local open-weight model, depending on the workflow. - Test the failover. An untested fallback is not a fallback; the same rule you already apply to backups and DR. Kill the primary on purpose and confirm the work keeps moving. - Make sure you communicate the value of this to your customers - this is a good point to show your expertise and leadership to your customers. --- ## The MSP Business is Changing Faster than Most MSPs are **Author:** Gaidar Magdanurov | **Published:** 2026-06-12 **URL:** https://mspnotes.com/the-msp-business-is-changing-faster-than-most-msps-are **Tags:** Business Recent reports from Omdia and Jay McBain's presentations, highlight two issues: future growth for MSPs is not going to be easy, and there is a huge opportunity many MSPs are not leveraging yet. ## The market is tough Managed services revenue will grow 10% in 2026, reaching $650 billion globally. That sounds healthy. Yes, based on Omdia reports, there are over 330,000 companies fighting for managed service contracts. The market is crowded, churn in customer bases is high, and channel growth expectations for the year dropped in Omdia's latest polling. RMM and PSA software growth is slowing too, which is a reliable leading indicator: when MSPs stop adding seats to their tooling, they have stopped adding clients. > The problem is not demand. The problem is differentiation. Undifferentiated MSPs shrink. ## Shift from products to services For every $1 of infrastructure sold, the partner opportunity around it is $7.13. It breaks down as advice (16%), design (18%), build (27%), procure (5%), adopt (16%), and manage (18%). The resale transaction many MSPs relied on historically is 5% of the value. The other 95% sits in services before and after the sale. Software and services already account for 84% of partner revenue. Hardware resale margin is not coming back. This is very clear for MSPs relying on infrastructure resell. If they sell a client $50,000 of infrastructure and stop there, they captured the worst slice of a $350,000 opportunity. The MSP that wraps assessment, design, deployment, adoption, and ongoing management around that same deal earns seven times more – at better margins, on recurring contracts. ## AI is the biggest open opportunity, and clients cannot do it alone The AI services market for partners grows from $59 billion in 2025 to $267 billion by 2030 – a 35% annual growth rate. Three data points explain why this lands on MSP desks: - 47% of customers say they will rely on specialized partners for agentic AI – the largest single answer, ahead of building in-house or buying off the shelf. - 70% of customers report that fewer than 20% of AI proofs of concept reach production. The main blocker is integration and architectural complexity – exactly the work MSPs do. - 59% of customers now have dedicated AI budgets, and 40% of those budgets exceed $500k. There is a catch. 82% of partners say they need more vendor support to sell AI, and lack of vendor enablement is the top adoption barrier at 32%. The practical move: pick one or two vendors who invest in AI training, certifications, and co-selling, and go deep. Do not spread across ten vendor programs that each give you a webinar and a logo. The service lines that pay: AI readiness assessments, data preparation and governance, integration into existing workflows, and ongoing management of AI security and compliance. None of this requires building models. All of it requires knowing the client's environment – which is the asset MSPs already own. ## Cybersecurity remains the strongest engine Global cybersecurity spending hits $311 billion in 2026, up 12.1%. Two-thirds of that is services, not technology. And 91.7% of all cybersecurity spend is sold through or with partners. Within services, the growth is in exactly the categories MSPs can deliver: MDR up 15.2%, deployment and integration up 16.4%, remediation up 66.4%. Managed security services overall grow 14.4% to $106 billion. In Omdia's channel survey, 73% of partners are investing in managed security services, 70% plan to co-deliver with other partners, and 63% will use AI agents for specific security tasks. Notably, 65% also plan to reduce internal headcount – the direction is leaner delivery, with AI and automation carrying more of the operational load. Margin in security services will increasingly come from delivery efficiency, not just price. ## The buyer changed, sales motions probably did not Three findings about how clients buy now: - 75% of B2B buyers do not want to talk to a salesperson. They research digitally, compare on marketplaces, and arrive with an opinion. - Buying decisions form across roughly 28 touchpoints: peer groups, review sites, communities, podcasts, AI assistants like ChatGPT, and events. Cold outreach reaches buyers after they have already decided. The implication for a 20-person MSP is not "hire a marketing team." It is: be visible where your buyers already gather. Local peer groups, one or two review platforms with real client reviews, a steady presence in the communities your vertical trusts. Visibility compounds; campaigns do not. ## What to do next The model that resells products and bills for tickets is being replaced by one that sells outcomes across the full client lifecycle. The market will keep growing 10% a year. Whether your business does depends on four moves: - Map your revenue against the services multiplier. If most of it sits in procure and basic manage, you are exposed. - Build one packaged AI service this year – readiness assessment is the natural entry point – with a vendor who funds your enablement. - Push security mix toward MDR and managed services, and use automation to protect margin as you grow. - Shift sales effort from outbound to visibility: reviews, peer groups, community presence. Do not try all four at once. Pick the one that fixes your weakest number – growth, margin, or retention – and start this quarter. --- ## The Internet is Being Rebuilt for Agents and it is an Opportunity for MSPs **Author:** Gaidar Magdanurov | **Published:** 2026-03-26 **URL:** https://mspnotes.com/the-internet-is-being-rebuilt-for-agents-and-it-is-an-opportunity-for-msps **Tags:** Business, Technology   The internet was built for people clicking through pages, filling out forms, and deciding in real time. It is no longer the case. The next wave of "users" arriving on the internet are AI agents that act on behalf of humans. Gartner projects that 40% of enterprise applications will embed task-specific AI agents by the end of 2026. Akamai reports AI bot traffic surged over 300% across its network in 2025. And Gartner predicts that by 2028, 90% of B2B buying will be agent-intermediated, pushing over $15 trillion through agents. Yet, most businesses are not ready for this. Their websites are designed for humans. Their checkout processes require form-filling that is hard for agents to navigate. Their data is locked inside visual layouts that look beautiful to people but are hard for agents to consume. For MSPs, this gap between where the internet is going and where most businesses are today is exactly the gap that creates advisory revenue opportunities. ## Websites for agents It may seem that an AI agent can simply use the internet the way a human does: open a browser, read the text. Yet, it is not the best way for agents to consume the content. The modern web relies on visual hierarchy. Headings communicate the importance of size. Navigation uses spatial positioning. Product pages rely on images and layout. Agents do not care about it. They care about data relationships, not pixels. Most websites could not provide the structured information agents prefer. Sites without machine-readable data see agents disengage. "Why are all the AI agents going to our competitors?" is going to become a common refrain for your customers soon. A business whose website is optimized only for human visitors is becoming invisible to an increasingly large share of how research and purchasing decisions are conducted. ## Changes needed The immediate needs fall into three areas: - **Structured data and schema markup**: Every product page and service description needs markup that communicates what the content means, not just how it looks. This is the single highest-impact change most businesses can make today. - **Machine-readable content layers**: New standards like llms.txt — a Markdown file at a site's root that gives AI systems a concise overview of key content — are emerging as the agent equivalent of sitemaps. - **API-first design**: Agents do not fill out forms. They want direct, programmatic access to information and transactions. Businesses that expose clean APIs for products, pricing, and availability will be the ones agents can interact with. ## Tools for agents To illustrate the transformation, let's talk about the tools available to agents. As AI agents are becoming operational entities that need the same infrastructure human workers have always had. A growing ecosystem now provides agents with the capabilities they need to work on behalf of people. - **AgentMail**: Email infrastructure for agents — their own inboxes with threaded conversations, semantic search, and structured data extraction. - **AgentPhone** and **Kapso**: Phone numbers and WhatsApp access for agents, covering the two communication channels that dominate business interaction globally. - **ElevenLabs** and **Vapi**: Natural voice synthesis and real-time phone conversation capabilities. An agent powered by these tools can handle front-line phone inquiries around the clock. - **Browserbase, Browser Use, Hyperbrowser**: Full browser automation — navigating sites, clicking elements, filling forms. - **Firecrawl**: Web crawling without a browser, turning messy websites into clean Markdown or JSON. - **Exa**: Semantic search built for agents. Traditional search engines rank by backlinks and ad spend — signals designed for humans. Exa uses neural embeddings to understand query meaning. - **Kite** and **Sponge**: Payment infrastructure for agents. - **Sixtyfour**: Agent-optimized search for discovering people and companies — the prospecting and research work that sales teams have done manually for decades. For your customers who sell products or services online, the practical question is direct: can an AI agent purchase from your business today? And for everybody, the practical question is even more straightforward: Can the agent use the tools available to it interact with your product and services? ## The opportunity You, as an MSP, can provide guidance to your customers. Focus on the foundational web optimization work that pays off regardless of how fast agent adoption speeds up. The structured data work is good practice even in a world where agents arrive slower than predicted. The internet is being rebuilt. The question is not whether this affects your customers — it is whether you are the one guiding them through it. --- ## What the LiteLLM Attack Means for the MSPs **Author:** Gaidar Magdanurov | **Published:** 2026-03-25 **URL:** https://mspnotes.com/what-the-litellm-attack-means-for-the-msps **Tags:** Business, Technology   The [recent supply chain attack on litellm](https://gaidar.net/supply-chain-attack-via-litellm-a97d1cf95df3) highlighted the problem - every software vendor and every customer using any software with third-party libraries is exposed to vulnerabilities in the dependencies of those libraries. A poisoned version of a popular Python library with over 90 million monthly downloads could harvest SSH keys, cloud credentials, database passwords, and every API key stored on the affected machine. The attack was caught by accident — a bug in the malicious code crashed a developer's machine, triggering an investigation. Without that bug, it could have run undetected for weeks. For MSPs specifically, the question is not just "how does this work." The question is: what do you do about it for your customers, starting right now? ### MSP challenge Most MSPs have built their managed security offerings around a well-understood perimeter: endpoints, email, network, identity, and patching. These are necessary yet insufficient. The litellm payload arrived through a legitimate package manager, executed during a routine dependency install, and targeted credentials stored on an endpoint. No malware signatures to detect. No phishing email to filter. No unpatched vulnerabilities to close. ### Things to do now If you have customers who develop applications, consider: **1. Treat all endpoints as high-value targets.** Most MSPs apply their strongest monitoring and access controls to servers and cloud infrastructure. Workstations often go unprotected. Yet, the litellm attack showed that every endpoint can be an entry-point. A developer's laptop often has long-lived cloud credentials, database connection strings, CI/CD tokens, and SSH keys sitting in plaintext files. One compromised `pip install` and all of it is gone. Elevate workstations, especially developer workstations, to the same security tier as your customer's production servers. Apply the same monitoring, the same alerting, the same access controls. **2. Push customers to eliminate long-lived credentials on local machines.** This is the single highest-impact change. If an attacker exfiltrates an AWS access key that expires in 60 minutes, the damage window is narrow and containable. If they exfiltrate a static access key that has been sitting in a `.env` file for 18 months, they have persistent access to your customer's entire cloud environment. Work with your customers to move credentials into a secrets manager and enforce short-lived, scoped tokens issued through their identity provider. This does not prevent the attacks from executing. It makes the stolen credentials worthless before the attacker can use them. **3. Monitor outbound traffic from workstations.** The litellm payload had to send the harvested credentials somewhere. That means outbound network traffic to an unfamiliar endpoint, likely with an unusual payload size. Most MSPs already have the tooling to detect this — DNS filtering, outbound traffic analysis, anomaly detection. The gap is that these tools are typically pointed at servers and general endpoints, not specifically at developer workstations. Extend coverage. Create alerting rules for unusual outbound connections from machines where development tools are installed. This is a detection layer that you can deploy within your existing stack. **4. Offer dependency auditing as a managed service.** Most engineering teams don't pay attention to what their projects install. A single top-level package can pull in 40 or 50 dependencies, each one maintained by a different person or team, each one a potential attack vector. Tools like `pip-audit` or `npm audit` provide automated scanning that flags known vulnerabilities and suspicious packages. Package it as a recurring service: weekly or monthly dependency audits with a report that goes to the CTO. **5. Implement a process to manage the dependencies of your and customer applications.** Advise your customers to enforce a policy where no new dependency - and no version upgrade of an existing dependency - goes into production-bound code without review and explicit approval. Pin exact versions. Verify checksums. Do not allow automatic upgrades. A developer who pinned `litellm==1.82.7` with a hash check would not have pulled the poisoned `1.82.8`. ### Conversation starter Most business owners and many CTOs do not understand that their development teams implicitly trust thousands of strangers every time they build software. The concept of a transitive dependency - code you did not choose to install, written by someone you have never heard of, running with full access to your machine - is foreign to anyone who has not worked in software development. Frame it simply. Every package developers install comes with a tree of other packages, sometimes dozens of layers deep. Any of those packages can be compromised by a single attacker gaining access to a single maintainer's account. When that happens, every machine that installs the update hands over its credentials. No phishing required. No user error. Just a routine installation. Then tell them about the litellm case. Ninety million downloads per month. The poisoned version lived for less than an hour. Caught only because the attacker's code had a performance bug. **Ask them: would your team have noticed?** ### The opportunity The type of conversation you can have with your customers about attacks like litellm is a way for you to serve as a trusted advisor and build stronger relationships with your customers. Not to mention, an additional revenue stream from protecting workstations that are usually not protected. --- ## Doubling MSP Productivity Leads to 5x Margins **Author:** Gaidar Magdanurov | **Published:** 2026-03-04 **URL:** https://mspnotes.com/doubling-msp-productivity-leads-to-5x-margins **Tags:** Business Most MSP owners track revenue, cost, and margin and clearly understand how discounts and variable costs affect their margins, yet quite a few don't appreciate how much improvement in the productivity of their tech team and ability to serve more customers influence their margins. Today, with the widespread of AI tools to automate MSP productivity, and availability of [natively integrated platform for MSPs](https://www.acronis.com/en/products/cloud/cyber-protect/), significant increase of productivity is possible, and the margin impact for MSPs is substantial. The math behind MSP profitability is surprisingly simple. And it reveals something most business owners overlook: a modest improvement in productivity can produce an outsized improvement in profit margins. ## The Labor Cost Problem An MSP is a service business. MSP technicians are the product. Everything else — the software licenses, the office space, the back-office overhead — is secondary. Labor accounts for up to 80% of a typical MSP's total costs. An average MSP operates with profit margins of 8% to 12%, far below other professional services like legal and financial firms that average 30% to 35%. Even best-in-class MSPs — roughly the top 25% — rarely push the margin past 15% to 17%. When 80 cents of every dollar goes to labor, there is almost no room to squeeze an additional profit from existing operations. They can raise prices — but commoditization pressure makes that harder every year. They can cut costs — but they are already lean on non-labor costs, and good technicians don't come cheap. Adding customers typically means hiring more technicians, which resets the equation back to the same thin margins. This is the trap most MSPs are stuck in. Revenue grows. Headcount grows. Margins mostly stay flat, if not decrease. ## The Productivity Solution There is a way out of this trap, and it does not require raising prices or cutting staff. If the existing team can oboard and handle more customers without a proportional increase in labor cost, the entire economic model of the MSP business shifts. Let us walk through a specific example. Consider an MSP with $1 million in annual revenue and operating at a 10% profit margin. Here is their current cost structure: - Revenue: $1,000,000 - Labor cost: $720,000 (72% of revenue) - Variable cost: $180,000 (software, admin, vendor fees — 18% of revenue) - Profit: $100,000 (10% margin) Now, suppose the MSP doubles their productivity. Their existing team takes on twice the customer base, revenue grows to $2 million. What happens to costs? Assume labor stays at $720,000 — same team, same salaries. Variable costs double proportionally to $360,000 — more licenses, more admin overhead for the additional customers. - Revenue: $2,000,000 - Labor cost: $720,000 (unchanged) - Variable cost: $360,000 (doubled) - Profit: $920,000 The profit margin j**umps from 10% to 46%**. The profit goes from $100,000 to $920,000 — nearly a 10x increase. > Doubling productivity does not double margins. It multiplies them roughly five times over. Of course, the example oversimplifies the matter, as the labor cost may increase, the may be scenarios that the existing team can't cover, but the direction stays. ## Why This Matters Now? This is not an abstract thought experiment. The technology to achieve meaningful productivity gains already exists, and MSPs are already using it. Acronis partners report that they use to manage 200-250 endpoints per technician and are now hitting 350, with best in-class covering over 500. AI-driven automation is producing measurable results across the industry. [Leading MSPs report](https://www.acronis.com/en/blog/posts/msp-trends-2026-creating-opportunities-in-a-difficult-market/) 15% to 25% technician productivity gains and 40% to 70% reductions in ticket resolution times. AI-powered tools can handle 70% to 80% of Level 1 issues automatically, freeing technicians for higher-complexity work. The productivity gains are not limited to ticket automation. Consider the full scope of repetitive work that consumes technician time: user onboarding, patch management, monitoring alerts, password resets, device provisioning, and compliance reporting. [Tech Rage IT](https://rewst.io/success-stories/how-tech-rage-it-saved-60k-a-year-automating-new-user-onboarding-with-rewst/) found that their technicians spent nearly 20% of their time on monotonous onboarding tasks. Automating that process alone reduced time spent by 80% and saved $60,000 annually. ## The Strategic Choices of Productivity When the MSP team becomes twice as productive, they face three strategic options — and each one transforms the competitive position: - **Grow revenue at constant cost.** Take on more customers with the existing team. - **Lower prices to win market share.** If the cost drop, they can undercut competitors while maintaining the same absolute margin. In a commoditizing market where traditional helpdesk services are under pricing pressure, this is a powerful tool. - **Reinvest in higher-value services.** Use the freed technician time to move into cybersecurity, compliance advisory, and cloud migration — services with higher margins and lower commoditization risk. Most successful MSPs will pursue a blend of all three. The point is that productivity improvements give them options. Thin margins give none. What is clear - MSPs that invest in driving productivity will have the advantage, and those not investing in productivity will risk going out of business. Sounds harsh, yet it is the reality of today. ## What Can You Do? Measure revenue per technician, endpoints per technician, and tickets resolved per technician. These are the productivity numbers. And productivity drives your margins. Audit where your technicians spend their time. The repetitive, rule-based tasks — onboarding, patching, alert triage, password resets, basic troubleshooting — are the targets for automation. Consolidate your vendor stack. Twenty-five tools mean twenty-five integrations, twenty-five vendor relationships, and twenty-five training requirements. Fewer tools that work well together will produce more capacity than a sprawl of best-of-breed point solutions. The MSPs that will increase their productivity this year will define the competitive landscape for the decade that follows. The rest will be working harder for the same thin margins, and eventually will go out of business. --- ## Guide for MSPs on Leading AI Adoption for Their Customers **Author:** Gaidar Magdanurov | **Published:** 2026-01-28 **URL:** https://mspnotes.com/guide-for-msps-on-leading-ai-adoption-for-their-customers **Tags:** Business, Technology AI adoption is rapidly accelerating across companies of all sizes, yet in most cases it is happening without strategy and governance, diminishing effectiveness and creating security risks. “Shadow AI” is the modern plague. This creates a major opportunity for MSPs to step up as trusted AI adoption advisors, increase customer satisfaction, and establish one more revenue stream. Reviewing recent research by a variety of analyst firms, we identified the top three AI implementation risks for SMBs that MSPs can reduce: lack of visibility on AI usage, AI usage policy, and operational control. ## 1. Transition from “Shadow AI” to managed AI The number one challenge for most businesses is unsanctioned AI usage by employees. They use a variety of services and produce results of unknown quality, as well as expose confidential business information to AI tools that do not provide privacy and confidentiality. Guide for MSPs: - Audit AI usage across all endpoints. If you use [Acronis](https://www.acronis.com/en/products/cloud/cyber-protect/security-edr/), then enabling GenAI security on endpoints will enable AI usage tracking. - Define a list of approved tools. - Document a clear AI usage policy for the company. - Offer AI usage monitoring as an ongoing managed service - Offer automation of business processes using AI tools–deploying and configuring agents, implementing processes and workflows for customers. Those projects can be part of the ongoing managed services offering or one-off projects. The key selling message for the customers is helping them to gain productivity in a managed environment. ## 2. AI literacy as a service A lack of AI literacy among employees and management is one of the biggest blockers to gain productivity. Many organizations do not systematically train their employees on AI tools and prompt engineering, not to mention workflow automation. MSPs can lead here and add another training service in addition to security awareness training, making AI literacy a billable service. Guide for MSPs: - Build or license AI literacy training. - Design an onboarding and continuous training process on AI tools for the employees. - Offer coaching on AI automation for business processes specific to a customer. Key selling points here are that employees training on AI are more productive, delivering more value to the business, as well as reduced risk of a security breach or confidential data disclosure because of human errors. ## 3. Secure data and workflows Data leakage via AI prompts is already causing incidents, including exposure of source code and confidential business data. The risk increases as employees upload files or reuse sensitive information in AI interactions. Guide for MSPs: - Classify sensitive data and define policies for data usage with AI. - Enforce prompt restrictions and data loss prevention controls. If you use Acronis, the tools will be available as a security plan in the next three months. - Integrate AI usage into existing data security and compliance frameworks. The key selling point here is that AI workloads should be treated the same as other types of workloads, like endpoints, servers, virtual machine or Microsoft 365 accounts. All workloads require cyber protection, management, and automation. ## Call to action AI is here. However, for many customers, safe AI adoption is still optional. Eventually, AI protection will be a default option like backup and endpoint protection. While few MSPs are providing those services, you can be one of the first and gain a competitive advantage. Consider taking the following three steps now: - Educate your team on AI – for their own productivity and for the scenarios they could implement for your customers. - Design managed AI service offerings, and offer them on top of your traditional packages or include them into higher tier packages and use them to upsell customers to the next tier. - Upgrade your tools to enable AI workload protection, management and automation. The opportunity is here to take, yet you have to act fast. --- ## Practical Marketing for MSP. Part 4 - Referrals, Local SEO **Author:** Gaidar Magdanurov | **Published:** 2025-10-18 **URL:** https://mspnotes.com/practical-marketing-for-msp-part-4-referrals-local-seo **Tags:** Marketing In [the previous article of the series](../../../practical-marketing-for-managed-service-providers-part-3-marketing-tactics), we discussed an approach to selecting marketing tactics based on the resources available. Advanced marketing tactics will likely be ineffective without sufficient resources for implementation and maintenance, as well as dedicated time to collaborate with teams on securing contracts. However, there are tactics that can provide a stable flow of incoming prospects with minimal time investment. Based on feedback from participants in my marketing workshops, they report getting 1-3 customers per quarter by using these simple tactics. ## Referral marketing A basic tactic for getting referrals is to ask your existing customers, partners, vendors, friends, and family for referrals to customers who need IT services. The best practice here is to make the referral process as easy as possible. Start by crafting a concise email and a 1-2 page document that clearly outlines your services for potential customers. Ideally, include a quote or a few from the existing customers praising the positive experience of working with you. Ensure the email is easy to forward and that its formatting is intact after multiple forwards. Simple paint text with neat text formatting works well. Here are some ideas for a [referral email content](../../../files/8/Referral_email_template_ideas.pdf). The document should be easy to read and include the most essential information, suggesting that the reader call, email, or visit your website as an action item. Here are some ideas for the content in an [editable Word document](../../../files/7/MSP_One_Pager_Simplified.docx). You can create emails and documents tailored to the profiles of your customers and the services you provide. For instance, those you helped with Microsoft 365 onboarding may recommend you to their friends who are struggling with the same issues. Those who got a complete infrastructure refresh from you may recommend you for that. Being more specific helps - you get higher quality recommendations and, usually, faster conversions of prospects to customers. You can send the email templates to your customers, provide them with the file or printouts, or ask them to display printouts at their business locations. Local stores can be an effective way to distribute your marketing materials. Simply asking your customers goes a long way... Just don't forget to say "thank you" and send a small gift with a handwritten "thank you" card—simple tokens of appreciation that help drive your business work really well with SMB owners. ### Referral program A more advanced tactic is creating a referral program, offering incentives to customers, partners and employees for referring customers. If asking your customers to promote you for free does not work, a referral program can be a logical next step. The referral program defines incentives for referrals for clients, partners or employees, and the program design depends on your clients' [lifetime value and cost of acquisition](../../../practical-marketing-for-msp-part-2-marketing-funnel-and-metrics). Clients can be rewarded with gift cards or special client appreciation events, such as dinners, sports events, shows, and trips. However, it is becoming more popular to provide direct account credits. The value of the credit is easy to determine if you estimate your customer acquisition cost at $9,000; then, giving $5,000 credit for a referral that led to a successful annual contract sign-up looks like a bargain. Similarly, it may work for referral partners - various SMB associations and groups, business owner clubs, and insurance agents. However, with partner referral, it is more common to have a commission on the first year's revenue from the clients. Typical commissions are in the 15-30% range, with the potential for additional commission as the volume of successful referrals grows. Thus, commissions may be offered on a sliding scale - the higher the number of referrals, the higher the commission for the next successful deal. Finally, don't forget about your employees. They have family, friends, former colleagues and contacts in various social settings. Offering generous bonuses for signed contracts based on employee referrals can help to build the initial client base while the business is small.  ## Local SEO The most underutilized marketing tactic for MSPs is leveraging Google search and Google Maps to promote your business to those already searching for IT services in your location. Restaurants and shops are using this tactic aggressively, and this tactic works for MSPs, yet very few really utilize it. Here is an example. A doctor starting his own practice in Sydney is looking for IT support. When he types "it support for doctors," he will see a recommendation of a local business offering IT services for Medical IT.![](https://web.archive.org/web/20251113122702im_/https://mspnotes.com/static/img/local_seo_medical_it.png) The reason this happens is that Medical IT has a business profile set up with Google. And this is [something you should do immediately](https://support.google.com/business/answer/2911778) if you haven't already. Make sure you provide all the necessary information and add photo and video content. This will increase your chances of getting clicks and attracting "free" incoming leads for your services. ### Local SEO best practices When designing and optimizing your business profile for local SEO, consider the landmarks and specific businesses in the area and how your profile aligns with local searches. Consider how your [differentiation and strategy](../../../practical-marketing-for-managed-service-providers-part-1) may play out here, like focusing on medical professionals in the example we used. Consider the types of searches your target audience is making while looking for your services. If you are based in a specific area, use local landmarks. For instance, a law firm in Barangaroo in Sydney may be looking for "it support near me", or "it services for law firms in Barangaroo". Being more specific with descriptions in your business profile may help with targeting, or may limit the people seeing your ads, looking for the right balance and optimizing your content. And, lastly, don't forget to collect reviews—the content of the reviews and ratings matters. Higher ratings and more reviews increase your business's visibility and improve the chances of being contacted. If you have multiple physical locations, consider experimenting with targeted advertising. Some businesses rent small offices or co-working spaces to increase their visibility in targeted locations. ## Conclusions The marketing tactics we discussed in this article are simple, require minimal time to prepare and execute, yet provide real value to MSP businesses. Effectiveness of the tactics depends on the location and competition in the area, quality of services, and how active your customers, partners and employees are in referrals. Yet, as of today, there is no reason not to invest a little time in implementing those tactics. --- ## Practical Marketing for MSP. Part 3 - Tactics **Author:** Gaidar Magdanurov | **Published:** 2025-09-16 **URL:** https://mspnotes.com/practical-marketing-for-managed-service-providers-part-3-marketing-tactics **Tags:** Marketing Now that we have [a strategy for our MSP](../../practical-marketing-for-managed-service-providers-part-1) in place and a good grasp of [marketing metrics](../../practical-marketing-for-msp-part-2-marketing-funnel-and-metrics), it is time to review marketing tactics and proceed with planning. Before kicking off the planning, we should take a critical look at the resources we have available and investments we can afford to direct towards sales and marketing. It seems logical that generating a large number of leads would be pointless if there is no capacity to follow up on them and close the deals. Yet, many MSPs start by investing a significant amount of money to generate incoming leads, only to end up disappointed, as they fail to see the conversions and business growth they had hoped for. ## Selecting marketing tactics Here is a simple table that could be used as a tool to choose marketing tactics based on the resources available for sales and marketing. On the left side, in the criteria column, every next row assumes that it is added on top of what is covered in the previous rows. **Criteria** **Tactics** Core service offering Referrals, “local SEO” (inbound), website + Marketing strategy/differentiation + Content, useful tools, educational materials (inbound) + Dedicated/allocated sales resource + Cold calling, LinkedIn outreach, events/networking + Dedicated/allocated marketing resource + Community marketing, Campaigns and email nurtures + Substantial marketing budget + Digital marketing (paid ads, paid social) + Marketing is a priority + Account-based marketing (ABM) Now, let’s discuss this table in detail. If the MSP only delivers **basic managed services** and does not provide a differentiated marketing strategy, marketing investments most likely won’t have positive returns, and the best tactics are those that come “for free”. Asking existing customers and partners to refer potential clients, and ensuring the MSP is discoverable in search, and has a solid description of the services on the website. The moment there is a **differentiated marketing strategy** – focusing on a specific vertical, unique expertise, and services an MSP can offer - it is a good time to add content marketing and create content that is useful for prospects and clients. This approach should focus on sharing educational materials and expertise. It comes at a low cost and brings reasonable-quality leads. The approach is to showcase differentiation and expertise, and collect leads from potential clients interested in the offering and expertise. When **dedicated sales resources** are available, even if only part-time, activities can expand to include cold calling local businesses, finding local businesses on LinkedIn, initiating conversations with them, and attending local events. The approach is to use direct outreach to deliver the story of the MSPs to potential prospects, researching them, and trying to sign them up as customers. Only when **dedicated marketing resources are available**, even if they are part-time, will it make sense to have scalable campaigns and invest money in marketing. Employing digital marketing and account-based marketing makes sense when there is a sufficient budget to make an impact and marketing is a priority for the company, as these tactics require a significant investment of time and resources. ## Marketing tactics used by most MSPs Based on our experience working with thousands of MSPs, most MSPs primarily use referrals as their primary tactic. Some visit networking events or host their own events, and follow up with emails. That makes sense, as marketing is not really a priority for MSPs. Most claim that they want to grow their business, yet in reality, they acquire only 4-8 new customers a year, to replace the churn of their existing customers. ![](../../../static/img/marketing_tactics_graph.png) There is a common misconception that marketing does not make sense without using multiple tactics. In reality, having a solid strategy and executing a few key tactics well may be enough to reach business goals. In future articles of the series, we will discuss tactics and best practices. Here, we only list the top five: - **Referrals** – various ways of getting existing customers to bring new business, and leveraging the network of connections to get direct referrals. Hint: It works best if there is a simple story that is easy to tell and share, highlighting the key differentiator. - **Events** – going to industry events, participating in local business meetups, organizing lecture and webinars on IT. - **Email** – sending relevant technical news, tips and tricks for business owners, and building image of an expert in the field among the contacts that an MSP was able to collect. - **Social media** – posting relevant news and comments, joining relevant discussions and providing useful advice for the people in need. Hint: focusing on local businesses and joining the right group is the key to success. - **Content** – producing various useful materials and recommendations, posting articles and videos with tips and tricks. Distributing value for free, in exchange of building awareness of the MSP services. However, regardless of the tactics employed, three key success factors for marketing should be considered when planning and executing activities: consistency, commitment, and persistence. ### Consistency Having a well-defined and well-documented story is a must. At any given moment, potential clients should receive the same consistent message. If you target doctors and offer IT services specific to doctors, stick to the story of being an expert in the field. If you jump around and discuss your expertise in cybersecurity, cryptocurrency, or AI-based coffee machines, it may be a good story for a conversation; yet, a focused and repeatable message will stick better and, in the long run, will yield better results. ### Commitment Most marketing activities fail because MSPs start them and stop them before they see results. Running a small ad campaign, visiting a few events – it is, most likely, not enough to see the impact. Marketing is effective only when it is planned for long-term execution. Thus, a marketing plan is a commitment to execute it. ### Persistence We live in a world overloaded with information. It is amusing to say that, but your offer of IT services competes with everything else in the head of the SMB business owner – casual games, new cars, and solar panels. New information and marketing messages are coming from everywhere. Therefore, it is essential to consistently deliver the same message to the same person multiple times until they react to it. Based on personal experience running digital marketing campaigns, 10 years ago, people would react to ads and visit a landing page after eight impressions, and now they require over 16. [Attention span has been reduced dramatically](https://www.universityofcalifornia.edu/news/cant-pay-attention-youre-not-alone) in recent years. You only have [15 seconds](https://blog.youtube/creator-and-artist-stories/youtube-creator-playbook-tips-first-15/) to grab the attention of a YouTube video viewer. And it's only getting worse. ## Conclusions Effective marketing requires a consistent, repeatable message and continuous execution. Carefully estimate the resources available for marketing, and design a marketing plan that takes into account your ability to execute it in the long run. Based on experience, marketing can take a long time to yield results, and those who are willing to play the long game are winning business from those who don’t. --- ## Practical Marketing for MSP. Part 2 - Funnel and Metrics **Author:** Gaidar Magdanurov | **Published:** 2025-09-10 **URL:** https://mspnotes.com/practical-marketing-for-msp-part-2-marketing-funnel-and-metrics **Tags:** Marketing In the [first article](../../../practical-marketing-for-managed-service-providers-part-1) of the series, we took a practical approach to designing an MSP strategy. Let’s take the same approach to discuss the marketing funnel, metrics and plan. ## Marketing funnel The marketing funnel is a key concept for evaluating marketing performance. The funnel provides a clear view of the process of generating interest among prospects and converting them into customers. Traditionally, the funnel is split into six stages (awareness, interest, consideration, conversion, signup and advocacy), and those stages are grouped into four blocks (Top of the Funnel, Middle of the Funnel, Bottom of the Funnel). ![](../../../static/img/marketing_funnel_plan.png) Let's looks at three most important stages: **Funnel stage** **Description** **Example** **Top of the Funnel (ToFu): **Awareness Prospects are aware of the problem and interested in a solution; they discover your services. An SMB business owner attends a webinar about cyber insurance hosted by an MSP and learns that they need the insurance; to obtain it, they must ensure their infrastructure complies with a specific checklist. **Middle of the Funnel (MoFu): **Interest and Consideration Prospects are exploring your offering and determining how it aligns with the problem they have. The SMB business owner is interested in using managed services from the MSP that made a presentation, because the MSP is offering to implement all the requirements for obtaining cyber insurance at a favorable rate. **Bottom of the Funnel (BoFu): **Conversion Prospects are reviewing your offering with the intention of becoming a customer if it meets their needs. The business owner receives a proposal and negotiates a service-level agreement. **Sold or Converted: **Retention & Advocacy Prospects buy the service, and start talking about the service they are getting to other prospects. The business owner signs a contract and becomes a customer. The MSP onboards the customer and starts active management. The business owner discusses the high quality of services they are receiving from the MSP with their friends, and the MSP receives new referral leads as a result of those conversations. MSP provides additional services to customers.   The funnel is a solid tool for thinking about the marketing process – how many potential customers understand the problem and seek a solution, how many of them are considering your services, and how many are actively evaluating the services. **Marketing metrics** One thing that comes as a surprise to most people starting learning marketing is that marketing is all about numbers. Marketing has stories and requires creativity, yet it all comes down to numbers – choosing metrics, setting up goals, and achieving those goals. Here are the most common metrics used by MSPs to measure their marketing efforts: **Awareness** # website visits, # content downloads, # social media engagements **Interest** % Email engagement (open, click), # webinar attendance, # content consumption **Consideration** # assessment requests, # proposal downloads, # reference calls **Conversion** $ contract value, # sales cycle length (in days), % win rates **Retention** $ MRR growth, $ service upsell/expansion, % churn rates **Advocacy** # referrals, # testimonials, % referral win rate, $ MRR from referrals   The metrics help to evaluate marketing performance at every stage of the funnel. The best practice is to measure the metrics and set targets for improving those that will have the most significant impact. Let’s look at a few significantly simplified examples: > Let’s imagine you have 100 new users visiting the website every month, and 50 submit an assessment request, and then only 1 signs up every month. Given that the conversion rate from the assessment requests to sign-ups is 2%, it would make more sense to look into ways to improve the conversion from assessments to sign-ups, rather than invest more money into getting more traffic to the website. > > > Or, imagine you get 1,000 new users coming to the website every month, but only 10 submit assessment request. With 1% conversion from visitors to the next stage of the funnel, it makes sense to look into what prevents the visitors from submitting the request. Is the form working well? Is the form easy to fill in? Is the content good enough and leading the visitor to make a decision? > > > And, if you have 100 new visitors a month, 10 submit requests and 5 convert, you have 10% conversion to assessment requests, and then 50% conversion to customers. Why not invest more in getting more quality traffic to the website? You will need to take a baseline for the metrics and then examine them to identify areas for improvement, focusing on those that you can directly impact. We will be looking into the tactics you can execute in future articles of the series. ## Key business metrics The metrics we discussed earlier help assess and optimize marketing performance; however, the ultimate goal of marketing is to directly impact key business metrics, including customer acquisition cost (CAC), monthly recurring revenue (MRR), and lifetime value (LTV). ### Customer acquisition cost (CAC) The formula to calculate CAC is simple – divide the total expenses of customer acquisition by the number of new customers. Total expenses include salaries of sales and marketing team, marketing expenses for online and offline activities, and expenses for tools used for sales and marketing. Let’s make a simplified calculation: > An MSP has a part-time sales person and part-time marketing person, and pays $6,000 per month for them and their business expenses. Monthly marketing budget is  $2,500. Website and content management system, SEO tools, CRM tools, LinkedIn Sales Navigator cost another $500. Therefore, total sales and marketing expenses are $9,000. On average, MSP acquires one new customer per month. Therefore, CAC =  $9,000/1 = $9,000. ### Monthly recurrent revenue (MRR) MRR is the total amount of money clients pay to an MSP every month. MRR includes all collections under long-term contracts, as well as recurrent service fees such as charges for backup and storage, but does not include one-off projects. Another simplified calculation: > An MSP has 50 customers with average contract value of $12,000. Thus, on average each customer pays $1,000 per month, and MRR = 50 x $1,000 = $50,000. ### Lifetime Value (LTV) LTV is the total expected revenue per customer that an MSP anticipates collecting. The formula is simple – multiply average contract value by the average number of years clients stay with an MSP. One more simplified calculation: > Our MSP with 50 customers for the last many years in business retains most customers for 2.5 years. Therefore, LTV = $12,000 x 2.5 = $30,000. ### Putting the metrics together CAC, MRR, and LTV enable MSPs to evaluate their business performance and forecast their financials, and marketing has a direct impact on all of them. Choosing the right messaging and right channels, and optimizing marketing campaigns, lowers CAC. Targeting specific customer profiles, signing up larger customers, and continuously upselling existing customers on new services increase MRR. LTV mostly depends on the quality of service and stability of the client’s business; however, upselling clients on additional services reduces the risk of the client changing service providers, as the cost of transition becomes higher. One frequent mistake owners of new MSPs make is pushing for recruitment of customers, significantly raising the CAC, before they can justify it by the LTV. If an MSP is spending more money on recruiting customers than they pay over their lifetime with the MSP, you will eventually run out of money. It is imperative to monitor marketing performance from a cost perspective and evaluate the quality of incoming clients based on the value they bring each month and over their lifetime. Spending more on sales and marketing eventually leads to diminishing returns – CAC is growing faster than LTVs, and this can be illustrated by the simple graph below. ![Marketing spend efficiency](../../../static/img/marketing_spend_effeciency.png) An effective marketing manager strives to optimize marketing investments to maximize value while monitoring long-term financial performance. It is easy to generate a high volume of new leads at a higher cost. Still, the MSP should have the capacity to sign them up and maintain the quality of service, thereby extending the value of contracts by adding more services (growing MRR) or keeping customers for longer (growing LTV). ## Return on Marketing Investment Another common pitfall for MSP business owners is not investing enough in marketing. The moment they are trying to scale your business and start making marketing investments to expand customer acquisition beyond referrals, it is essential to recognize that, up to a certain level of activities and expenses, marketing may not be producing results at all, or may produce only bare minimum results. Thus, it is crucial to conduct experiments and scale investment and activity to determine the optimal amount of investment that yields the maximum return. ![Marekting ROI](../../../static/img/marketing_roi.png) Most MSPs I have worked with have a 5x return on marketing activity, excluding the fixed costs of personnel and tools, which means that for every $1 spent on marketing activity, they expect to receive $5 in return over time. MSP spends $2,500 per month on digital marketing costs, expecting to make at least $12,500. If the expense brings one customer, it would mean that the LTV of the customer should be over $12,500. Having returns below 5x for most MSPs indicates that the sales and marketing efforts may not be profitable, after factoring in the costs of personnel, client support, licenses, and other miscellaneous client-related expenses. ![Marketing spend](../../../static/img/marketing_spend.png) Based on the experience with MSPs in 2024, most MSPs that are investing in marketing are spending around $2,000 on marketing per month, and we can anticipate that the amount will grow in 2025 as the cost of digital marketing and the cost of events are rising and expected to grow, while competition for clients becomes more aggressive.   **Conclusions** Marketing is all about the data and metrics. Marketing is much more than lead generation. Marketing encompasses everything from bringing in the client to retaining the client and expanding the portfolio of services provided to them. Marketing must consider the business's ability to sign up and retain clients, as well as its capacity to do so profitably. One of the best ways for MSP owners to evaluate marketing professionals they plan to hire is to ask them about the metrics they use and how they analyze them. If they can discuss volume of leads, conversion rates, and deal sizes, they are educated marketers. If they can discuss CAC, MRR and LTV and put it into the perspective of an MSP business, they are experienced marketers.   In future articles, we will discuss marketing tactics. --- ## Practical Marketing for MSP. Part 1 - Strategy **Author:** Gaidar Magdanurov | **Published:** 2025-06-30 **URL:** https://mspnotes.com/practical-marketing-for-managed-service-providers-part-1 **Tags:** Marketing There are numerous excellent books on marketing. There are countless excellent online courses and video series available on marketing. Yes, MSPs often lack the time and desire to invest significant time in marketing. Most MSP business owners, being technicians at heart, want to focus on the technology and the quality of service they deliver to their customers, instead of driving business. Yet, marketing is often considered the “necessary evil” – without doing it effectively, there is little to no business growth. Therefore, in this short series of articles on marketing, we will examine a specific and practical approach to marketing that has been successfully used by MSPs worldwide. ## Marketing strategy Effective marketing begins with defining the strategy, making decisions on the target audience, and the offering that will be promoted through marketing. The goal of the strategy is to describe **the best product for a specific market segment**. To design an effective strategy, it is essential to conduct thorough market research and understand the type of customers available in the market, their spending behavior and willingness to pay, as well as the services they require. Then, knowing the market, make decisions to focus on specific segments and validate that you have the capability and resources to target that segment effectively, offering the best product for it. A simple example would be offering services to customers who require a quick on-site presence within a one-hour driving radius of your office and marketing your availability to be on-site within an hour. Customers need a fast on-site presence, and the MSP has the geographical advantage of being physically close to them. ### An example Let’s expand on a more sophisticated example of a startup MSP in Australia. They had substantial experience working with law firms in the past; they understand the requirements and speak the "legal" language; thus, it seemed like a good idea for them to target law firms specifically. They conducted research and decided to target only smaller law firms in the Sydney area, as these firms are primarily based in the Sydney region. They defined their market segment as companies with 15–75 employees and annual revenues of $3–35 million, who either have some basic internal IT support or use break-fix MSP services, and spend at least $35,000 per year on IT infrastructure support services. They estimated that approximately 2,000 companies in the area fit the profile. Their current target is to reach $3.5 million in revenue, and, assuming a $35,000 annual contract value, they need 100 customers, which is approximately 5 % of the target and seems reasonable. They have 10 people on their team, most of whom have some background in law or IT for legal firms. Based on their capacity model, they can serve 100 customers; thus, they have the necessary resources and expertise to deliver the services. Now, designing the best product for the market, they decided to focus on compliance, which is becoming increasingly important for law firms. They also offer quick on-site support in the Sydney area, as well as a deep understanding of the needs of law firms. Their team has legal expertise and compliance expertise. They have a local presence with a four-hour guaranteed response. They designed product packages (basic, advanced, and premium) tailored to the law firm’s needs, with fixed pricing and predictable monthly billing. ## Marketing mix: the 4 Ps of marketing Since the 1960s, when E. Jerome McCarthy conceptualized the 4 Ps (product, price, place, and promotion), the concept has been widely used to explain the essence of marketing. The whole idea of marketing is to make the right product available at the right price in the right place with the right promotion. Simply put—coming back to the discussion of the marketing strategy—design the best product for the audience and then offer it to them at the right moment when they need it, or when they can recognise that they need it and that the product is the best option for their needs. The concept is simple, yet many MSPs, having a technical background, dismiss it. It seems obvious that businesses need data backup and cybersecurity. It is evident that, in case they have time-sensitive systems, they need disaster recovery. Yet… It is obvious to the technical experts, not the business owners. Customers may be convinced that they will never experience a ransomware attack, or that hardware failure is so rare that they are not willing to pay for extra protection. Therefore, it is essential to target customers during “marketable moments,” when they may be seeking a new service provider and are open to a conversation. For a typical MSP, those moments may be: - Downtime – hardware or software failure, cyber-incident. The business is struggling and seeking immediate assistance. - New regulations and compliance requirements. Although there may not be an immediate need, the business believes there is an upcoming issue that needs to be resolved. - A new person in charge of IT or of the business, or an acquisition/structural change, may be an opportunity to switch to another MSP. - IT budget reduction – the business is looking to identify savings and wants the minimum viable solution (may not be the best customer now, yet the budget may grow over time). - New business or a business looking for an IT service provider for the first time. The promotional part of the marketing mix is about identifying the right marketing channels and activities to engage customers at the right moment, initiating a conversation. The “place” part of the mix refers to the location where you sell your products and the distribution channels you use to sell them. Putting it all together, let’s describe a typical MSP’s marketing mix: 4 P Key question Typical answers for an MSP Product What do you sell? - Core services: helpdesk, cybersecurity, backup - Differentiation: vertical or technology focus - Packaging: à la carte, bundles - Value-add services: v-CIO, compliance audit Price What is the pricing model? - Per user - Per device - Per hour for projects - Packages/tiers (Silver, Gold, Platinum or Basic, Advanced, Premium) Place Where do you sell? - Offline: networking events, business-association meetings, industry events, local meet-ups - Online: consultation form, digital events, organic and paid search Promotion How do you promote? - Inbound: referrals, content marketing (articles, case studies, reviews) - Outbound: presentations and booths at events, digital marketing, cold calling, email marketing ### An example – IT services for doctors During the marketing workshops for MSPs, we searched Google for “IT support for doctors” – a phrase a healthcare professional or administrator might use to find a service provider in the area – and one company’s website showed up first that was a good illustration of strategy and marketing mix: [Medical iT](https://medit.com.au/). ![Medical iT search result](../../../static/img/practical_marketing_it_support_for_doctors.png) We can clearly see the strategic positioning – they are offering the best managed IT services for doctors. From the search, it is clear that they are targeting the local market (we will discuss local SEO later in this series of articles). ![Medical iT website header](../../../static/img/practical_marketing_medical_it.png) When we visit the website, we can clearly see that they offer specialized services for doctors and confirm their expertise by mentioning well-known software used in medical practices. ![Medical iT services list](../../../static/img/practical_marketing_medical_it_2.png) This example illustrates a highly effective tactic – getting in front of people seeking a specific service in a particular area and validating expertise through industry knowledge and relevant case studies. In future articles, we will discuss selecting marketing tactics and estimating marketing expenses as part of the business model. --- ## AI and Prompt Engineering for MSPs **Author:** Gaidar Magdanurov | **Published:** 2025-04-29 **URL:** https://mspnotes.com/ai-and-prompt-engineering-for-msps **Tags:** Business, Technology You're missing out on productivity if you're not using AI now. Soon, if you don’t use AI and don’t scale your operations using AI, you will start losing customers to competitors that will be able to serve more customers at a lower cost. Cost-conscious SMB owners will gladly switch to MSPs that offer services at a lower price, especially if they are not delivering value beyond traditional infrastructure management and helpdesk services. Many MSPs have implemented AI in their daily operations. This article will examine easy-to-implement scenarios and best practices for AI prompt engineering that do not require development and can be achieved using public large language models (LLMs) like ChatGPT. ## Scenarios for automation Number of scenario MSPs outsource to AI – creating content for marketing purposes. Typically, MSPs lack dedicated personnel for marketing, and they must rely on part-time marketers and agencies to produce the content themselves. AI helps to significantly reduce the time required to create marketing assets, and, most importantly, review and update them as assets tend to age. Sales and marketing scenarios: - Website pages – maintaining product catalog, service descriptions, blog content and SEO optimization. - News and social media – writing announcements, responding to market news (for instance, guiding customers to defend against a new cyberattack). - Case studies and customer stories – writing case studies for the website and using them in the sales process based on projects with customers. - Adjusting proposals – modifying standard proposals based on a specific customer’s needs. The second most popular scenario is automation for customer communications. Preparing responses and creating various reports consumes a significant amount of the technicians' productive time. AI can simplify and accelerate the development of documents, especially when templates are developed and a straightforward process is in place to adjust them to a specific case. Customer communication scenarios: - Email templates – responses to popular requests, generic guides for step-by-step issue resolution, explanations of various problems and situations, notifications, and announcements. AI is especially useful for preparing security advisory notes in a language the customers will understand, as technical people tend to overcomplicate the explanation of the issues. - User guides and onboarding materials – documentation for customers to enable them to use self-service to resolve the most frequent issues. A good guide allows for offloading a significant volume of simple problems to the customer. - Customer-specific FAQ documents – a solid addition to the user guide, answering frequent questions for customers on how to enable specific capabilities, use tools, request new software and hardware, how to prepare and file a ticket with HelpDesk, and so on. Customer infrastructure, needs, and tools vary; AI helps to adjust the content and simplify the language to make the FAQs more useful. - Knowledge base articles, standard operating procedure (SOP), and implementation guide documents – documenting cases and standard procedures for internal and external use and sharing with customers, vendors and contractors. - Reports – weekly, monthly, quarterly reports, presentations for business reviews, summaries of the work done, and improvement proposals. Last but not least, automation for internal operations is needed. Usually, it is the hardest part to automate due to a lack of trust in AI to perform a good job, as it is an essential part of MSP operations. However, AI is useful for expanding on the documents and scripts prepared by the technical expert, validating them, and identifying gaps. Internal operations scenarios: - Infrastructure documentation – internal MSP infrastructure and customer infrastructure. - Process documentation – internal procedures and best practices, essential for the onboarding of new technicians. - Troubleshooting and automation scripts – writing, debugging and validating scripts for automation in test and production environments. ## Prompt engineering technique Now that we have defined scenarios, it is time to examine the effective prompting technique that has proven useful in achieving consistently high-quality results for the scenarios listed above. ### 1. Create a prompt: provide context and examples Begin building the prompt by providing as much context as possible to ensure a successful execution of the task. For example, if you need to create an instruction for end customers about the upcoming operating system update that you will roll out to all machines, provide the AI with details about the customer's infrastructure, the version of the operating system, and any other relevant information. Don’t forget to instruct the AI on the style to use for writing the text, the actions to document, and the steps to execute. If you have an example of a communication, attach it to the chat and tell AI to review it and use it as an example. Example: > You are an MSP technician writing instructions for non-technical users about the upcoming operating system upgrade. Please provide clear, straightforward instructions, and answer questions you anticipate users may have. > > > 1. Begin with a brief, non-technical explanation of why this update is important (security improvements, performance enhancements) > > > 2. Include clear pre-update preparation steps, including: not shutting down systems at the end of the day, not interrupting the update. > > > 3. Explain the approximate duration and what users can expect from the systems in the process. > > > 4. Explain what users can do to verify that all of their applications works and they can access all systems and data they use. > > > 5. Provide a troubleshooting guide for the common issues with details on how to escalate the issue to the helpdesk if they can’t fix the issue using the guide. > > > If I attached a file with an example of a communication, please review it and use it as an example to create the new communication. ### 2. Improve the prompt: evaluate and refine Before executing the prompt, try asking AI to review and improve it. In the process, you may find out if you are missing anything. There is a simple prompt you can use to achieve that. Example: > You are an AI prompt engineer. Please review the prompt I provide below that I want to use to create a communication to my customers, non-technical users, about the upcoming system upgrade. Please suggest improvements, and let me know if the prompt effectively achieves the result. AI will provide recommendations on improving the prompt and the revised prompt. Example of the AI output: > Add specificity about the update details > > > > > - Include a parameter for the specific OS being upgraded (Windows 10 to 11, macOS version, etc.) > > - Add a placeholder for the actual scheduled date/time of the update > > > > Enhance the communication style guidance > > > > > - Specify that instructions should use numbered steps with screenshots where helpful > > - Request bullet points for key warnings or cautions > > - Suggest using bold text for critical information > > > > Add personalization elements > > > > > - Request a friendly, reassuring tone to reduce user anxiety > > - Include a closing section with company contact information > > - Add a clear subject line recommendation for email communications > > > > Incorporate user preparation specifics > > > > > - Request specific instructions about backing up critical files > > - Include guidance on applications to close before leaving for the day > > - Mention what users should do with open documents > > > > Add post-update verification details > > > > > - Specify common applications users should test > > - Include guidance on what "normal" looks like post-update Example of the improved prompt: > You are an MSP technician writing instructions for non-technical users about the upcoming [SPECIFIC OS] upgrade scheduled for [DATE/TIME]. Create a clear, friendly communication that reduces anxiety while ensuring users know exactly what to do. Please provide straightforward instructions and answer questions you anticipate users may have. > > > 1. Begin with a brief, non-technical explanation of why this update is important (security improvements, performance enhancements) and reassure users about the process. > > > 2. Include clear pre-update preparation steps, with numbered instructions and screenshots where helpful: > > >    - Specific steps for backing up critical files > > >    - Instructions to save and close all documents before leaving > > >    - Direction to leave computers powered on at the end of the day > > >    - Bold warnings about not interrupting the update process > > >    - A clear timeline of when users should stop working on their systems > > > 3. Explain the approximate duration and what users can expect: > > >    - How long the update will take > > >    - What they might see on their screens when they return > > >    - Any potential temporary performance impacts after the update > > > 4. Provide specific post-update verification steps: > > >    - How to confirm the update completed successfully > > >    - A checklist of common applications to test > > >    - How to verify access to critical systems and data > > >    - What "normal" operation looks like after the update > > > 5. Include a troubleshooting guide for common post-update issues: > > >    - Solutions for 3-5 frequently encountered problems > > >    - Clear indicators of when to stop trying to fix it themselves > > >    - Specific instructions for contacting the helpdesk (phone, email, ticket system) > > >    - Information to provide when reporting an issue > > > 6. End with a friendly closing that includes: > > >    - Your MSP company name and contact information > > >    - Helpdesk hours and response times > > >    - A thank you for their cooperation > > > If I've attached a file with an example communication, please review it and use its style, formatting, and tone while enhancing it with the above requirements. > > > Suggested email subject line: "Important: Your Computer Update on [DATE] - Action Required" ### 3. Simplify Run the prompt and review the result. Continue to refine the prompt to enhance it and achieve the desired outcome. Focus on simplifying the prompt, as it will allow you to maintain it more easily. Producing results takes less time, and, most likely, the output quality will be much better if the prompt has only the necessary context and instructions. Before editing the final communication, invest time in enhancing the prompt. You can create a library of prompts and use them with slight modifications. Your prompt library will be your knowledge base for future use. You can reuse elements of prompts for other documents and adjust them as needed for future use. Treat the process of creating the prompt as training a new employee. You invest time in building high-quality prompts, and then it will pay off with a dramatic increase in productivity. ## Conclusions Prompt engineering is becoming a natural part of life. Simple prompts lead to simple results. Complex prompts with context, tailored for the task, can produce outstanding results and can be reused in the future. Invest in an AI prompt library, train your team to use AI effectively, establish a knowledge exchange, and you will gain a competitive edge now and stay relevant in the future. --- ## The Rise of Ultra-Specialized Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2025-03-05 **URL:** https://mspnotes.com/the-rise-of-ultraspecialized-managed-service-providers **Tags:** Business Following up on the [article about MSP strategy](../../strategy-for-managed-service-providers), I received many questions regarding vertical market strategy and targeting specific industries. I must admit that I have recently noticed more MSPs moving towards ultra-specialization. Instead of serving multiple verticals, they are focusing on a specific niche and managing to outgrow their less selective competitors. Lately, I have been talking to an MSP in New York that solely focuses on hedge funds, a New Jersey-based company focused on insurance brokers, and a Massachusetts-based company that serves dental clinics. Those companies have a few things in common: they have a very small team of only a few technicians, yet they have a sizable number of customers and significant revenue. They also have a standardized technology stack and very deep knowledge of specific applications and processes relevant to their customers. Those three companies were living proof that “less is more.” By focusing on very specific segments, they were able to simplify their operations, increase their productivity and virtually avoid sales and marketing costs, acquiring customers through referrals. ## The ultra-specialized advantage While “traditional” MSPs are trying to serve everyone, ultra-specialized MSPs define a strategy to go after a specific niche. This gives them a few advantages over “generic” competition: - Deeper expertise in specific industry and technologies used there, continuously accumulating more knowledge, and being a trusted adviser to their customers - Ability to offer more value besides managing IT infrastructure – offering ways to improve employee productivity, improve efficiency of the business processes, implement compliance requirements - Image of an expert in the vertical – inspiring word-of-mouth and customer references, reducing the need for marketing to acquire new customers - More predictable service delivery – having standard operating procedures and automation, freeing up time for technicians to serve more customers, or spend the time learning new technology to stay relevant to the market - Much stronger client relationships – being not “yet another IT guy”, instead being a trusted technology adviser and long-term business partner ## Finding a niche The opportunity may come from experience or deliberate action, such as deciding on the opportunity and recruiting the team to go after the opportunity. There are two common ways to define the niche for MSPs: ### 1. Industry and compliance expertise - Healthcare, and regulations like HIPAA - Finance, and regulations like SOX, PCI/DSS - Legal and data privacy laws - Manufacturing and the ISO standards - Government and certifications like CMMC ### 2. Technology specialization - Cloud and cloud security - Data analytics platforms - AI tools and services - IoT and operational technology - Legacy system upgrades ## Building the niche expertise Building an ultra-specialized practice requires market knowledge, technology expertise and network building. Starting with market knowledge, you need to know industry-specific regulations, top vendors, and solutions for software, hardware, and specialized machinery. Getting industry-specific training and certification and continuously participating in industry-specific events makes sense. Technology expertise includes industry-specific software, typical infrastructure patterns, common issues, cybersecurity threats, and case studies of challenges and cyber-attacks on industry companies. Networking is necessary to establish a name in the industry. Attending events and participating in trade associations, participating in online groups and providing valuable comments, and hosting your own online and offline events to share best practices all require dedicated effort, yet they pay off in the long run. Speaking at events, publishing thought-leadership content, and sharing stories based on experience on the website and social media also help build an expert image and attract customers without additional marketing. Of course, building strong relationships with your customers and using them for referrals is an absolute must. In addition to referrals, customers can participate in your events, provide quotes, or even represent you at industry events. Treat your customers as your evangelists—if they are happy about your services and the value you bring to them, they may sell your services to prospects for you. ## Partnerships To be an ultra-specialized MSP, you don’t have to provide all types of services to your customers. You may not have and may not need staff to provide certain expertise on a daily basis, and partnering with other service providers for some of the services is a way to focus on your unique area of expertise. Ultra-specialized MSPs tend to outsource one-off and infrequent projects, like setting up physical network infrastructure. They may also outsource basic helpdesk for generic IT support and to provide quick on-site presence in case a ticket requires physical presence, such as plugging in a disconnected server or rebooting a frozen printer. The ultra-specialized MSP focuses on unique industry expertise and maintaining customer relationships. To avoid distractions, subcontractors can cover some of the workload. Partners may be a valuable source of referrals and projects specific to the subject matter expertise. ## Pricing strategy Being a well-known expert in a specific industry also offers the advantage of value-based pricing. Instead of competing with other MSPs for the lowest bid per endpoint or per user, you compete on the value offering for that industry. Ultra-specialized MSPs focus on offering packaged solutions instead of per-endpoint or per-user pricing. They may offer an industry-specific package with pricing based on the size of the infrastructure. The package includes a complete set of services (management, monitoring, backup, cybersecurity, disaster recovery, incident remediation, investigation, and so on) and compliance with industry-specific regulations. In addition to the service packages, they may offer custom consulting services for IT strategy, infrastructure modernization, Cloud migration, and integration after mergers and acquisitions. These can be long-term, high-value projects that generate significant revenue for the MSPs. ## Staying relevant Ultra-specialized MSP strategies are gradually becoming increasingly popular. While some MSPs focus on standardizing and scaling their technology stack and improving the productivity of their technicians to serve more customers and compete on price, others choose to avoid head-to-head competition and select the niches to serve. Given that the MSP market worldwide has over 200,000 companies offering or selling managed services and is expected to almost double in the next 5-6 years, the competition will only get tougher. Therefore, for those choosing an ultra-specialized strategy it is essential to stay relevant and follow a simple checklist: - Conduct regular market assessment, and continuously monitor news about the market – stay up-to-date with the trends and regulations - Monitor technology trends affecting the industry, and come up with relevant proposals to modernize and improve the infrastructure of your customers - Regularly execute skill analysis of your team, identify gaps and implement development plans - Develop partnerships with vendors, distributors, industry associations, and collaborate with industry experts - Frequently review your service portfolio and refresh it as needed It is relatively easy to become an ultra-specialized MSP now and gain a customer base; however, in the next few years, it will become increasingly difficult. Earlier entry is not a long-term advantage if you don’t keep your expertise up to date. ## Conclusions Looking at what is going on right now, it is easy to envision that in the near future the competition between MSPs will become even more fierce. While the IT infrastructure is growing and the market size for the MSPs is growing rapidly, there are more and more large MSPs that are winning on efficiency, productivity, and, therefore, able to offer lower prices. In the pricing wars smaller MSPs rarely stand a chance against larger MSPs, and the ultra-specialized strategy may be a way to establish a strong position and defend your business. Implementing the ultra-specialized MSP strategy requires significant market research and critically evaluating your strengths and capabilities. Building a brand in the industry will also take time and effort. However, in the long term, this strategy has proven to pay off for those who are able to build and maintain the required expertise. --- ## Strategy for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2025-02-18 **URL:** https://mspnotes.com/strategy-for-managed-service-providers **Tags:** Business One of the toughest challenges in business is defining a strategy. For a new MSP, the typical approach is to acquire a few customers through existing contacts, friends, and family, bringing revenue to cover expenses. However, it is essential to develop a strategy for expanding a business or remaining competitive while rivals pursue their customer base. After speaking with thousands of MSPs over the years, I've noticed that successful MSPs share one key characteristic—they have a strategy documented in one form or another. So, let’s explore a simple framework for defining and documenting that strategy. ## The strategy framework We will define a strategy framework as five components: - **Opportunity** – well-defined, well-understood opportunity based on the understanding of the market. - **Differentiation** – unique (and better than the competition) business qualities regarding the opportunity. - **Capabilities** – the existing capabilities that can be developed to support differentiation and work for the opportunity. - **Focus** – things you choose to do and things you decide not to do. - **Execution** – the plan to make it work, the team, the motivation, the financial plan, the operational plan, and continuous learning required to develop the capabilities, maintain differentiation, and go after the well-defined opportunity. Let’s discuss each component and devise a simplified example of defining a strategy based on my observations of the success of mid-size MSPs over the years. ### 1. The opportunity The world is still going through digital transformation. It may seem that most businesses already use technology, and it is impossible to run any business without technology. Yet, it is far from reality. A vast number of companies are still in the pre-digital era, and most are only scratching the surface of what is possible with modern technology. If you think about AI-based tools, most companies barely scratch the surface of what is possible. Multiple analysts project that digital transformation will accelerate by the end of 2030, with small and medium businesses heavily demanding MSP services. Many predict that the MSP market will double by 2030, while ongoing digitalization is expected to increase the server market by 75%, the endpoint market by 119%, and the data center market by 48%. Simultaneously, by 2023, analysts foresee a shortage of over 85 million IT professionals worldwide. This means there will be significantly more IT infrastructure and insufficient IT personnel to manage it, creating a massive opportunity for MSPs. However, simply knowing that the market will grow doesn’t help develop a strategy. Creating a strategy involves defining the opportunity for your business. To identify that opportunity, the MSP needs to understand how many businesses it can serve, what types of services those businesses require, and whether they can afford the level of service they need. > *Let’s consider an imaginary example of an MSP named Gilgamesh IT. They are launching a business in a small town. They know about 1,000 SMB customers in the finance industry within a four-hour drive from their office. They understand the types of companies and the infrastructure those prospects require, along with the challenges these businesses face in obtaining cyber insurance, ensuring compliance, and enhancing cybersecurity. This represents the identified opportunity – a specific type of business, in a certain location, with particular needs.* Defining the targets will help shape the rest of the strategy. While providing any service to anyone may seem like a good idea (it, indeed, does not), it will quickly deplete resources, lead to a [break-fix model](../../converting-a-business-from-break-fix-to-managed-service-provider-learnings-from-a-real-life-story), and fail to support a competitive advantage. Therefore, begin by identifying the target market and constructing your strategy from there. ### 2. The differentiation There are many IT professionals providing services to your target market, and they do a good job if they have customers. How will you stand out to win over customers, and what is that “better” you can provide that others can’t? The differentiation should be clear for the customer. The story can’t be too complicated; otherwise, it will be hard to market and won't “stick” with customers. Therefore, consider the differentiation you can easily explain that resonates with the customer. They should be able to understand and agree that differentiation is essential. Imagine choosing to differentiate your business through your own [integrated technology stack](../../boosting-msp-productivity-by-reducing-tool-overload). While other companies deploy various tools to different customers or support whatever tools customers had used before signing a contract, you provide a standardized technology stack. You have chosen a remote management and monitoring tool that integrates with security, backup, and reporting tools. Consequently, your technician can quickly assist any customer, spend less time resolving issues, and deliver much faster resolutions. You offer your customers a significantly better SLA, increased reliability for their infrastructure, and a slightly lower cost for your services. What do customers care about? They care about how much money they will pay you, how quickly you resolve their issues, and how much downtime they may experience. Let’s say you are the MSP offering your customers a standard package with disaster recovery and guaranteed downtime of no longer than an hour. You can calculate the “usual” downtime for their business and the cost of that downtime and estimate how much you will save them by offering quick recovery. You may be the MSP that can quickly dispatch a technician to the customer's location. This means the customers will receive service quickly because you have a wide network of technicians to drive to them. Or, you can offer unique security expertise that no one else can, guarantee compliance with regulations and cyber insurance checklists, and lower the cost of cyber insurance. Whatever your differentiation is, it should be clear to the prospects and customers. They should know they can choose anybody to support their infrastructure, yet your company offers them a distinct differentiation they care about. > *Gilgamesh IT chose an integrated technology stack, which is standard for all customers. When customers sign an agreement, they must agree to get a standard image for their workstations and servers deployed during the onboarding period. Therefore, Gilgamesh IT can offer a much better SLA and slightly lower cost than the competition, as its technicians can serve significantly more endpoints than other MSPs in the area.* A good test for differentiation is a conversation with customers and prospects. If they understand the value of differentiation, you can pass it on to other prospects as you grow, and it works to recruit and retain customers for you. Another good test is to replace your company's name with another company while you are discussing your differentiation and see if it works. If it does, it seems like the others can claim the same, and it is not a real differentiation. ### 3. The capabilities It is easy to imagine anything, yet when it comes to reality, we are limited to what we have available. For example, you may envision being a leading provider of cybersecurity services to your customers, but you may not have any cybersecurity expertise in your team, rendering the vision nearly impossible to implement without recruiting new people or partnering with a cybersecurity services provider. Your capabilities may include your team or people you know and can recruit quickly, experience and skills, technology and know-how, contact database, partners and customers. These capabilities support your unique differentiation, and you should either possess them or have a clear path to develop them. For instance, if you have technicians spread all over the area, you can offer your customers on-site presence within a very short time. Having people with software development skills will allow you to develop scripts for automation and increase your team's productivity. Having relevant expertise in specific verticals and knowing specialized infrastructure and business applications may allow you to establish a leading position for those verticals. The key to leveraging these capabilities is figuring out your available resources and planning how to leverage them for your business. > Let’s say our Gilgamesh IT team has a bunch of IT professionals with software engineering backgrounds and automation experience, and they can build tools that would automate deployment, testing, maintenance, and roll-back of the software and patches. The capabilities play along nicely with differentiating better SLAs than the competition. Better SLAs on issue resolution are critical for their chosen industry vertical. When defining capabilities, one must be true to oneself. Being willing to offer services to a specific vertical, like healthcare or finance, yet lacking relevant experience, reference customers, and experts in the field willing to help means one lacks capability. ### 4. The focus Opportunities and projects are flying around all the time. Some of them may seem interesting. Quite often, many seem interesting and easy to get. Yet, if you don’t clearly define which opportunities you take and which you say “no” to, you may end up chasing too many targets and getting stuck with the projects that will undermine your strategy. From my almost twenty years of experience in IT, focus is the hardest part for nearly every organization. Customers seem similar, products look easy to build, large contracts with new types of customers look attractive. Yet, chasing multiple targets rarely leads to success, and deciding what to do and what not to do is crucial. With time, you may reconsider, as the strategy may have to change, addressing the market situation and changing economic conditions. Yet, from the beginning, defining your targets and clearly documenting what is outside your scope is crucial. The focus may be on customer sizes, types of businesses, industry verticals, geographies, and IT infrastructure requirements. You choose targets that align with your opportunity, differentiation and capabilities and stick to them. > Let’s continue with the example of Gilgamesh IT. They have people with experience working with hedge funds and investment family offices; therefore, they decided to target only those customers. They have blueprints for the infrastructure, recommendations for the business processes, case studies and reference customers in the defined verticals, and their website clearly states that they offer services to those types of customers. From time to time, they get requests from customers from other industries and are tempted to consider. Yet, they know they have a sizable opportunity in the niche they selected; they have experience and standard operating procedures to serve those businesses.  Saying “no” is hard. It does go against human nature. We want to be nice, and we want to grab whatever goes our way. Yet, saying “yes” to an opportunity at some point automatically means saying “no” to something else. You may pick up a few unusual and not strategic opportunities for you, and it will bring you some extra revenue in the short term. Yet, it will hinder your growth in the long term, as your resources will be distracted by supporting something new and solving new types of problems, leading to a reduction in the quality of service to your existing customer base. ### 5. The execution Now, to the most down-to-earth part of the strategy – the execution. When you define your opportunity and differentiation, map out your capabilities, and define your focus, it is time to plan how you will execute your strategy. Below is a short list of questions that give you direction toward building and documenting your plan. - Who is your team? - What is the management structure and management cadence? - What are the metrics you are going to track? - How are you going to motivate your team to execute the strategy? - How will you develop your team, technology, and business processes? - What is your financial model? - What are your standard operating procedures – help desk, incident resolution, escalation process? - How are you doing sales and marketing? - How are you providing customer support? - Who is managing customer relationships? - What is the cadence of working with customers? - What is the schedule for software and infrastructure refresh? - How often and what kind of reports do you provide to them? - How will you ensure continuous learning in your team? - How will you keep your market knowledge up-to-date and your strategy relevant? - How do you educate your customers? - What are [the metrics](../../metrics-for-managed-service-providers) you will track and [the goals](../../smart-goal-setting-for-managed-service-providers) you will set? The execution part of the strategy explains “what” you will do to achieve your goals. The parts of the strategy before that document “how” you are going to do it (differentiation, capabilities, focus) and “why” you are doing it (the opportunity on the market). Think about the specifics of what you need to do to execute the previously defined strategic directions, and make sure you document it and make everyone on your team aware of what they need to do to implement the company’s strategy. ## Putting it all together in a financial model Now, let’s continue with our Gilgamesh IT imaginary friends. Knowing what we know about their strategy, let’s try to put some numbers behind it. Let’s assume they were right in their estimates of having 1,000 businesses matching the profile of a customer they want to serve. An average customer would be worth a $30,000 annual contract based on the competitive pricing in the location. Thus far, the market opportunity for Gilgamesh IT is $30,000,000 if they assume they have all of the companies in the region signed up as customers. However, Gilgamesh IT’s founder is realistic and believes they can get only 10% of the market; therefore, realistically, they are targeting only $3,000,000 in business. This sounds good, but do they have the capacity to serve those customers? Based on their estimates, their customers have, on average, 26 endpoints. Thus, 10% of the market, or 100 customers, would have 2,600 endpoints to manage. Gilgamesh IT has only 8 technicians, meaning each technician should be capable of supporting 325 endpoints. Based on their current experience and given that Gilgamesh uses a standardized integrated tech stack, the technicians can manage over 500 endpoints per person. Thus, the target of 10% of the market is within their capacity. In addition, they may have time for additional customers if they can acquire more customers and time for one-off projects for those customers. Not to mention that by continuing to automate their tools, they expect to decrease the average time per ticket and free up more time for technicians to learn new technology or serve more customers, generating more revenue and receiving higher bonus payments. Putting a financial model, even a simple one, behind the strategy is a way to validate thinking, make assumptions, and reconsider capabilities and capacity. ## Wrapping up Having a well-defined and well-documented strategy and aligning the whole team around it brings many benefits. It creates clarity regarding the business goals and the approach the business takes to achieve them, and it helps focus resources on what matters. In the MSP business, it is very easy to get distracted, start picking up business from all over the place, and get swamped by one-off break-fix projects. While it may work for a business that just wants to maintain a particular lifestyle of the owner and the employees, it does not work for a company with aspirations to grow and successfully compete in the long term. Building a strategy may be a frustrating exercise, and that is why many MSPs involve mentors and consultants to help them with that. Yet, by merely applying the effort and doing the exercise of documenting the strategy, you may identify the opportunities and gaps you have not seen before and turn your business from being a stagnating, not growing lifestyle business into a growing, competitive, profitable MSP. --- ## Protecting Your Team Against Your Customers: Quick Guide for MSP Owners **Author:** Gaidar Magdanurov | **Published:** 2025-01-10 **URL:** https://mspnotes.com/protecting-your-team-against-your-customers-quick-guide-for-msp-owners **Tags:** Business The previous article about [dealing with technician burnout](../../dealing-with-msp-technician-burnout) generated a few fascinating private discussions with MSP owners who suggested that, in many cases, the reasons for burnout are not related to internal operations but rather to the need to deal with abusive customers. In the last month, I heard numerous stories of customers screaming at MSP technicians and doing something completely unexplainable, like unplugging a server from the power outlet and forcing a technician to drive for a few hours to plug it in. Another surreal story was about a customer who regularly put wet paper into a printer, causing jamming that would result in a technician visiting the customer site and listening to various complaints about internet speed and slow coffee machines. People do behave strangely sometimes… Handling complicated customers is a serious issue, especially for technicians who are uncomfortable with customer communications. When they get into arguments, they close down, suffer and burn out. Therefore, business leaders need to address the issue as early as possible. Here is a short guide based on best practices for handling complicated customers I recently collected from MSP owners. ## A policy on handling customer behavior Start by creating an internal document describing acceptable and unacceptable customer behavior and how technicians deal with it. Using the document as a guide would help technicians understand the recommended course of action. > Most owners recommend politely ignoring complaints and screams while onsite or during a phone call and informing them about the behavior so they can have a conversation with the customer. Technicians appreciate if their managers or MSP owners handle all complicated “human” situations, and many consider getting somebody else involved in non-technical issues a benefit. ## Train your team Help your technicians learn conflict resolution skills. Accepting negative feedback and apologizing for whatever disturbs the customer can end unpleasant communication. The manager can address the actual issue later. The goal for the employees is to de-escalate conflict on the spot, not get emotionally involved. > In most cases, when another person screams at you, it has nothing to do with you—they are just dealing with their internal discomfort. Knowing this and approaching unpleasant situations helps you emotionally detach from the altercation.  ## Show support to your staff After handling a situation with the customer, communicate it to your technicians. They want to know that you have their backs and that your policy is not just a piece of paper. Also, feel free to congratulate people on solving technical issues despite the complications in communication. > One amazing MSP had a policy that at the end of the year, all technicians would vote for the worst customer to handle, and they would “fire” the customer if there was a clear leader by the number of technician votes. Even though they rarely do that, technicians know their opinion is important, and the owner supports them. ## Discuss customers in employee meetings Most MSPs have one-to-one conversations with their employees, focusing on the tasks and hand, compensation, and time off planning, yet they do not discuss customer relationships. And engineers may not share their concerns and complaints without being asked directly. Thus, asking questions about how they interact with customers is a good practice. However, ensuring that employees feel safe sharing the information and don’t feel like you are evaluating their performance under stress is vital. > One MSP founder told me he always asks how well customers treat his engineers. If he hears about gracious customers, he sends them gift cards with a small handwritten thank you note expressing gratitude for their good treatment of their employees. Building trust with the team is extremely important. They should feel they can discuss any issues with you, and raising concerns about customers won't damage their reputation. Protecting your employees builds stronger relationships, learns about problematic customers early, and retains your best talent. Even more, having a strong work ethic and reputation helps attract talent looking for a better work environment. --- ## Dealing with MSP Technician Burnout **Author:** Gaidar Magdanurov | **Published:** 2024-11-23 **URL:** https://mspnotes.com/dealing-with-msp-technician-burnout **Tags:** Business One of the recent challenges MSP leaders and founders face is preventing burnout among their technicians. The growing complexity of IT infrastructure, remote work and the increasing diversity of tools and services used by customers lead to continuous workload growth for technicians, and overload frequently leads to burnout and deteriorating performance. In this article, we will explore the signs of burnout and strategies for helping technicians avoid it based on the experience of MSP managers who have successfully overcome it. ## Signs of burnout The usual sign managers notice is deteriorating performance. If there is a system to track [operational metrics](../../metrics-for-managed-service-providers), like resolution time or SLA violations, it quickly becomes visible that technicians are taking more time to respond to and resolve tickets. However, it can be a sign of temporary overload, a temporary spike in workload due to market situation (some vendors love to push updates that create a workload for the MSPs), the time of year, or the onboarding of new customers. Or it can be an indicator of burnout. The declining performance warrants a review and a conversation, and that conversation is a good time for the manager to look for signs of burnout. A few signs can become obvious in the conversation. ### Excessive complaints The office, hardware, software vendors, customers, management, and kitchen coffee quality. Some people naturally like to complain, yet if all they do is complain, it is a bad sign. They only complain without offering ideas on how to improve the situation; it may indicate that they gave up on improvements and see everything around them in a negative light. ### Negative attitude Negative or “hopeless” comments towards the job, customers or tickets. If technicians make cynical comments about their work and highlight that their efforts are wasted, issues will recur, and customers will continue to do dumb things, it may be a sign of a change in outlook on life, especially if the employee had a positive attitude in the past. ### Physical fatigue They move slower, work on tasks slower, and speak as if they are not interested in conversations—these may indicate that they have lost interest and motivation. ### Forgetfulness They forget the tasks they took on, do not follow up with peers and customers after they promised to and forget to log information in the systems. This can signify that they no longer care about work and dismiss the tasks until their peers or managers remind them. ### Lack of interest outside of work It is also a solid indicator of burnout if they were talking about what they do outside of work frequently and then stopped and were not excited about their hobbies anymore. > Sometimes, it takes only a single conversation with a technician to realize that their behavior and attitude have changed adversely. This requires active listening, withholding judgment and a desire to provide advice. The manager's goal in the conversation is to listen and understand. ## **Strategies to deal with burnout** The most effective approach is to reduce the workload and optimize the efficiency of day-to-day operations. [Consolidating the tech stack](../../boosting-msp-productivity-by-reducing-tool-overload), implementing new tools that reduce the time required for processing tickets, implementing customer self-service, and designing an internal documentation system to share information more easily are techniques that free up time. These are prerequisites for implementing other strategies. Then, consider the following strategies that work for successful MSPs. ### Show technicians the impact of their work One reason work does not feel fulfilling anymore is that it does not seem necessary to anybody or it seems unnecessary. When people are unsure why they do what they do, they tend to question why they must put effort into a fruitless job. There are many ways to show the impact. One way is to show dashboards of the tickets handled and customers served. Explain how their performance allows them to grow the MSP business and how their assistance will enable them to maintain or grow their customers' business. Another way is to tell stories about customers, which makes it more relatable. For example, a story about a business owner who was able to send her kids to college because IT allowed her to grow her margins sounds better than just cold numbers on the response time. ### Help them define and defend their borders Understand what a reasonable workload is and what shall be done when the workload is unreasonable. Train people to say “no” to the tasks they can’t complete. Offer your help in routing and processing the tasks. Consider hiring more people or contractors for overflow work and reducing the scope of the provided services or reducing SLAs if there is no way to extend the team's capacity. It may be worth reducing the services offered and having tough conversations with the customers instead of losing the team or failing to deliver on promises. ### Implement fun activities at work Build a schedule of breaks and team activities. These can include a team coffee break or technical or soft skills training—anything that takes people out of their daily routine and brings them together to do something else, connect with each other, or gain new skills. Some people tend to push their limits, trying to handle more and more work, and forget about breaks—skipping breakfasts, lunches, and dinners—and, as a result, burn out. Those people may need help to realize that breaks are useful, and sometimes, a bit of a management push is required to implement them. ### Reduce after-hours workload Customers may work 24/7, and something may happen at any time. Sometimes, it is required to get people to respond to tickets outside of regular working hours. Relying on people taking on work during weekends, holidays and vacations can quickly become a norm, and eventually, it leads to frustration among those agreeing to do it. Until it is too late and employees start to resent their jobs, implement a policy on handling the workload after working hours, making it an exception instead of the norm, and consider splitting the workload between people when it is essential. ## Conclusions Burnout has become a serious issue for MSP technicians after the COVID-19 pandemic. The amount of work grew due to the growing complexity of IT in the remote environment. Many started working remotely themselves, losing the connection to other people, forgetting to take breaks, and not separating their work and free time – as they would spend all the time in the same place doing the same things repeatedly. As a result, burnout has become a severe risk to MSP businesses, and the owners and managers must pay attention to the issue. Luckily, personal attention from managers and simple strategies have proven effective for many MSPs who have managed to help their employees deal with burnout. --- ## Top 5 Ways Cybercriminals Breach Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2024-10-02 **URL:** https://mspnotes.com/top-5-ways-cybercriminals-breach-managed-service-providers **Tags:** Technology, Security Nobody likes to talk about breaches. Public information is minimal, and issues are usually swept under the rug. No CISO or MSP wants to be featured in the news about the following cybersecurity incident. And yet, breaches happen, and it is crucial to be prepared. Below is a list based on multiple conversations with MSPs over the years and recommendations to prevent the incidents. ## **1. Phishing and social engineering** Attackers send sophisticated emails or trick employees and customers into visiting fake websites, tricking readers and visitors into downloading malicious software or providing their credentials to the attackers. Modern attacks may include AI-generated images, audio and video, and employees can be invited into video conference calls, like in the story of an employee who sent [$25 million based on a deep fake call with the  CFO](https://siliconangle.com/2024/02/04/scammers-used-deepfake-cfo-trick-company-employee-sending-25m/). The most important protection method against attacks is mandatory security awareness training for employees and customers. Humans are, and will be, the weakest link in cybersecurity, and that link should be reinforced with knowledge. Additional measures should include email security and anti-phishing/URL filtering solutions to limit exposure to malicious emails and websites, as well as the ability to report suspicious emails and block them for the rest of the organization. ## **2. Weak and re-used credentials** Brute-force password guessing may be a thing of the past, as most applications limit the attempts to enter passwords and introduce significant delays, rendering direct password guessing impractical. However, stolen hashes of passwords are a completely different story. Attackers steal hashed passwords from vulnerable services and applications and then run brute-force attacks, trying to guess the passwords. ![](../../static/img/time-to-brute-force-a-password.jpg) The solution here is to enforce strong password policies – requiring a certain length and complexity and regular password updates. A good practice is to educate people to use memorable passwords with multiple words like “MyFavoriteAddressIsVanDeGraaffDr#1”. Passwords don’t have to be impossible to remember. Otherwise, people will save them in notes or write them down – potentially exposing them to attackers. Another good idea is to have multi-factor authentication enabled and mandatory, with an authenticator app on the phone serving as a second factor. Enabling single sign-on is also a good practice. That way, there is only one entry point, one strong password and one-second factor authentication for an employee to use. Convenience helps avoid insecure workarounds employees can choose to use. ## **3. Unpatched vulnerabilities** Cybercriminals exploit known vulnerabilities in software – operating systems, applications, IoT devices – to penetrate the network, gather information or obtain remote control over the infrastructure. The most dangerous attacks are on remote monitoring and management tools (RMMs) – if there are vulnerabilities in RMM, it means attackers get access to all customer devices. The solution is to establish and enforce [vulnerability scanning and patch management policy](https://www.forbes.com/councils/forbesbusinesscouncil/2024/08/26/update-with-confidence-a-guide-to-safeguarding-your-it-infrastructure/). Run system scans for vulnerable software regularly and apply patches. To avoid issues with updates, test patches in sandboxes or on a limited number of devices before rolling them out to all devices. ## **4. Supply chain attacks** Attackers compromise customers’ infrastructure to penetrate MSPs’ infrastructure and gain access to other customers. Getting administrative access to one customer, accessing tools used to communicate with the MSP, or accessing network shares and applications in the MSP networks can be leveraged to collect information for future attacks on an MSP or its customers. A subset of those attacks is a “man-in-the-middle” attack when the attacker intercepts communications between MSPs and customers and uses them to gather information, influence decisions, or extract money by redirecting payments to the wrong bank accounts. Those types of attacks are becoming more widespread due to the automation of attacks, ease of replacing bank payment information, relatively small payments and delays in recognizing the payments. The solution is to verify the sender and recipient and pay attention to verify any suspicious messages. If something does not seem right, any employee's first reaction should be to call the customer. Any third-party access and privileges should be limited to the minimum necessary to conduct the business, and all activities should be monitored and audited. Not to mention, a VPN or Zero-Trust network policy should be in place for remote access. ## **5. Insider threats** Malicious insiders or former employees who still have access, or employees tricked or forced to act on behalf of cybercriminals, are becoming a real issue for the MSPs. Who do you trust if you don’t trust your team? There is no silver bullet, yet a few things could help to protect the infrastructure. Starting with using the least privilege principle or “need to know” basis for all access and a detailed audit log of all activities and implementing tools for monitoring user activity and flagging suspicious and unusual behavior. It is crucial to have regular security reviews, verify who has access, and be highly swift with revoking access from people who do not need it to do their jobs anymore. A Data Loss Prevention (DLP) solution could also be useful. ## **Conclusions** It is tough enough to be an MSP and responsible for the operations of multiple businesses. Cybersecurity concerns add more to the plate of MSP owners, putting them under much additional pressure. Therefore, it is essential to build security policies and implement the tools to enforce them as soon as possible and then conduct regular reviews and policy updates. With proper tools and processes, making an MSP secure becomes second nature—like pushing pedals and steering the wheel in a car, the necessary activity to get from one place to the other. --- ## Acquiring a Managed Service Provider Business. Part III: Integration **Author:** Gaidar Magdanurov | **Published:** 2024-09-23 **URL:** https://mspnotes.com/acquiring-a-managed-service-provider-business-part-iii-integration **Tags:** Business In [Part II of the series of articles about MSP acquisitions](../../acquiring-a-managed-service-provider-business-part-ii), we discussed valuation, negotiations and deal structure. This article will wrap up the series and discuss the integration process after the acquisition. ## **Planning the integration** Effective integration requires building a detailed integration plan and roadmap that covers all integration aspects—business, technical, and marketing. ### **Integration roadmap** The roadmap shall include enough details to provide the complete picture to everyone participating in the integration project. It should cover the roles and responsibilities of participants, and everyone involved should know what is expected of them at every point. It is crucial to assign success metrics for each milestone and track against those metrics. If the project does not go as planned, metrics will help to understand what should be improved. The metrics may include revenue growth, customer retention, contract renewal, and various [technology and operational metrics](../../metrics-for-managed-service-providers). Look at the processes, workflows, and internal tools and decide on integration, upgrade or discontinuation. The earlier the decisions are made after a detailed analysis, the better. Switching the new team to the same tools and procedures the old team uses usually seems easier. Yet, the integration could be an opportunity to review the tools and procedures and gain additional efficiencies from the improvements and upgrades. The usual integration project for a small to medium MSP can take 6-12 months, depending on the scope of integration. If it implies technology standardization and refresh, it may depend on the customer agreements that may limit the ability to replace and refresh software and hardware on the customer’s side. ### **Team integration** Interview all the team members, conduct skills and qualification assessments and build a team integration plan. It is crucial to assess cultural fit and skill level. Merging teams of experienced technicians often leads to a clash of egos, reporting line issues, and tensions between the teams. Therefore, invest in team-building activities and set up constructive relationships between teams. The number one reason integrations are not going as planned is neglect of the human factor and mistakes in integrating human resources. One often overlooked aspect is the company culture. Say one team is run like a family business, and one team has strict corporate rules and subordination. It will take time to align the culture of the new, larger organization, and proper time should be given to plan the approach to merging the culture of the organizations. > *Tip: Assigning mentors to the new team members to introduce them to the new company and onboard them on the technology stack has proven to be much more effective than providing documentation and suggesting that newcomers do self-paced learning.* The acquiring company's managers should focus on retaining key employees, and retention plans should be well-thought-out. Retention bonuses and options or shares in the company are becoming increasingly common. However, transparent communication and ensuring everybody understands plans, roles, and responsibilities may be enough if the employees share the vision and believe their work lives will improve. ### **Technology integration** Suppose you are one of the MSPs working towards technology consolidation and integration. In that case, the integration will require mapping the technologies used by different teams to your technology stack roadmap, working on migration scripts and educating the team. If you are not standardizing technology and supporting what you have, it is surprising that you could get to the stage of acquiring other companies. It may be a time to consider standardization at this point. Talking to MSPs struggling to grow their business after integration, the author learned that the significant challenges are the team's inability to manage multiple different tools or not having scalable infrastructure to onboard new customers. *Tip: The best practice for integration is to have a staged rollout, including sandbox testing, before deploying the new tech stack to production.* ### **Communication strategy** Develop a comprehensive internal and external communication plan for the integration roadmap. Changes like mergers of MSPs usually worry customers, and it is crucial to keep them up to date with the plans and the vision, build trusting relationships with them, and show them how their managed services will improve. > *Tip: You can assume that when customers hear about the acquisition, they will start considering switching to another service provider if they are left in the dark about the transition. For smaller businesses, acquisition indicates the company's failure, as they naturally assume financial challenges. They may have deep personal relationships with previous management and may be looking to change partners now, but they expect not to have those people in place. Therefore, think about communicating with the customers and what you will tell them.* Communicating a high-level integration roadmap, the vision for the future technology stack managed service offering, and the improvements you plan for the combined company internally and externally should be a priority for management. Otherwise, it is easily forgotten. The best communication practice is to have regular All-Hands meetings with the team about the integration process and send bi-weekly status updates to key stakeholders and the customers of the company you acquired to reduce anxiety from the changes they are going through. > *Tip: A customer survey is a good idea, yet it rarely provides enough information, so having calls with customers is a better option and a chance to build relationships. Be prepared for customers trying to re-negotiate their agreements during those conversations.* ## **Learnings from successful acquisitions** MSPs who went through multiple acquisitions and shared their stories named a few things that helped them get the most out of the integration. ### **Setting strategic objectives** Thoroughly [review metrics](../../metrics-for-managed-service-providers) of your business and the newly acquired company, and define long-term goals, like revenue growth over the next 2-3 years, increase in customer lifetime value, and improvements in SLA – whatever you decide to be the most impactful and inspiring for your business. ### **Communicate early** Get employees involved as early as possible in the planning. Instead of offering the roadmap designed by the management, get your team to participate in building it. This will make your team feel they have made their own decisions and will be motivated to implement the plan. It may also be a good idea to involve the customers in the process, collecting their requirements and looking into improvements they would expect – in the process, being able to upsell additional services and increase average contract value. ### **Identify customers at risk** While building the integration plan and interviewing customers, look for signs of dissatisfied customers looking to switch to another provider. Address their concerns before proceeding with the changes to retain their contracts. However, if the assessment shows that retaining those customers is not profitable, be ready to walk away. ### **Create a dedicated integration team** Consider creating a dedicated team for migration and integration rather than allocating responsibilities among multiple team members. The integration should be a priority; otherwise, it may take longer than initially planned. ## **Conclusions** This article concludes the series dedicated to MSP acquisition. Of course, it is impossible to cover all aspects in a few short areas, and the advice of legal and financial professionals assisting with the transaction. Yet, I hope it gives some food for thought to people looking into acquiring an MSP business for the first time. *If you have gone through the acquisition process yourself, please contact me and share your acquisition experience. I would be happy to write a follow-up article with additional tips.*   --- ## Acquiring a Managed Service Provider Business. Part II: Valuation, Negotiation and Deal Structure **Author:** Gaidar Magdanurov | **Published:** 2024-09-20 **URL:** https://mspnotes.com/acquiring-a-managed-service-provider-business-part-ii **Tags:** Business [In Part I of this series](../../acquiring-a-managed-service-provider-business-part-i) of articles about MSP acquisitions, we discussed the reasons for the acquisition, target selection and due diligence process. In this article, we will discuss valuation, deal structuring and negotiation strategy for acquiring an MSP business. ## **Valuation of an MSP business** There are multiple ways to value an MSP business; choosing the valuation is a negotiation process, and the final results depend on the reasons for the acquisition. If it is purely a financial reason, the valuation tends to be based on the financial metrics. At the same time, if it is a customer base, technology or team acquisition, the valuation may be bound to the customer retention metrics rather than pure financials. ### **EBITDA multiple method** EBITDA stands for Earnings Before Interest, Taxes, Depreciation, and Amortization and is a common metric used to evaluate a company's financial performance. [This CFI article](https://corporatefinanceinstitute.com/resources/valuation/what-is-ebitda/) provides more details about EBITDA. The formula for EBITDA: EBITDA = Net Income + Interest + Taxes + Depreciation + Amortization, or EBITDA = Operating Profit + Depreciation + Amortization To put it into the perspective of the MSP business, EBITDA is primarily influenced by the scalability of the business (growing revenue while decreasing cost at scale), customer retention, and the ability to upsell additional services and increase revenue from existing customers. The valuation is estimated by applying a multiple to EBITDA. The multiple depends on the size of the business and actual EBITDA values. Small MSPs with 1-2 employees and under $200k in EBITDA may be valued at 1-2x, while large stable MPSs can be valued at 4-8x. There is no scientific method to assign a multiple, and it will be a part of the negotiation. Knowledge of recent deals in the area and consultation with legal and financial advisors and private equity firms may help develop a competitive proposal applicable to the specific location. The rule of thumb for MSPs is that the higher the EBITDA, the higher the multiple they can expect. ### **Recurrent revenue multiple method** Another popular method to discuss valuation is applying multiples to the annual recurrent revenue (ARR) calculated as the value of all long-term contracts on an annualized basis. For example, a $12,000 yearly contract gives $12,000 to the ARR, yet a $36,000 three-year contract gives the same $12,000 to the ARR (1/3 of the total contract value). The usual multiples for MSPs on ARR are in the range of 1-2x and open to negotiation. Higher multiples are applied to MSPs with a proprietary technology stack, allowing them to scale their business at lower costs and have a higher share of “sticky” services in their portfolio, like backup, disaster recovery, and security. Having significant ARR from reselling software and cloud-based services is also an opportunity for an MSP to negotiate a higher multiple. It is important to note that non-recurrent revenue from one-off projects, time-based jobs, and reselling of non-subscription software is usually excluded from the calculation. If there is a substantial amount of income in that bucket coming in regularly, the revenue many be included in the valuation with a discount, usually less than 1x multiple. ### **Discounted Cash Flow (DCF) method** This method suggests estimating the business's free cash flow (FCF) in the long term, usually over a five-year period. It is more frequently used by private equity and purely financial buyers and rarely by MSP owners acquiring MSPs. The DCF calculations include multiple steps and formulas, and there is [a good article in Investopedia](https://www.investopedia.com/terms/d/dcf.asp#:~:text=Discounted%20cash%20flow%20(DCF)%20is,will%20generate%20in%20the%20future.) explaining the process. For this article, we can simplify it by building a financial model covering the next five years based on revenue retention and growth and then estimating the business's present value based on the future value provided by the model. For instance, a company that generates $300k of FCF now will have a $3.75M value in 5 years, with a present value of $2.3M. A company that generates $10M of FCF now will have a present value of $99.2M. ## **Factors affecting valuation** Independently of the method used to estimate the value of the business, there are common factors affecting the valuation. ### **Financial performance** Revenue growth, retention (revenue from the existing customers), profit margins, share of the recurrent revenue vs. one-off revenue. General directions for the MSPs trying to grow the value of their business are to transition as much business as possible to the subscription model, sign multi-year contracts, introduce price increases in their contracts upon renewal, and upsell additional services to the existing customers. ### **Customers** Critical parameters impacting valuation are average contract length (the number of years customers renew), average contract value (indicating the size of the customers), and customer churn rate. Red flags would be that most of the revenue comes from only a few large customers rather than multiple customers and that significant revenue comes from the most recent contract. The MSP owner might have inflated the revenue by signing large and not-so-profitable agreements to boost the valuation before selling the business. ### **Services portfolio** The breadth of services allows for the upselling of additional services to existing customers and reducing customer churn. The rule of thumb for many MSPs is that every additional service a customer consumes reduces churn risk by 50% because switching to another MSP becomes more costly and takes significantly more time. ### **Team** MSP business is all about people. Key employees, their contracts, and time with the company are critical to keeping the business afloat after acquisition. The team's operational efficiency is a significant contributor to the valuation—SLA compliance (resolving tickets within the contractual SLA), the volume of tickets resolved per day, the time to resolution, and the number of endpoints managed by the technicians. Perfect financial metrics, but red flags in the team may significantly lower the valuation of the business. ###  **Negotiating a deal** The final valuation of the business and the transaction structure depends solely on negotiation. There is no single source of truth for valuation, and what can be more valuable for one buyer may be less valuable for another. Below is a simple process for preparing for the negotiation. - Conduct a marketing analysis. Look at the information about recent deals in the area. Find comparable companies in the news and analyst reports. Build a case for the valuation based on similar deals. - Identify the synergy from the acquisition – can you grow your customer base or upsell services to your existing customer base after the acquisitions, or can you sell new services to the customer base of the company being acquired? The synergy will help to justify a higher valuation, as well as to help you focus on the goals of the transaction, not solely focusing on the price. - Consider different options to structure the transaction – cash, stock, earn-out structure – we will discuss it later in the article. - List all the red flags and reasons to decrease the business's valuation. Look at the abovementioned factors and document all reasons the valuation may be decreased. - Come to the negotiations with a realistic proposal and arguments to support it and be ready for multiple rounds of talks. For some MSP owners, their business is their “baby,” and negotiations can quickly become emotional. After the price agreement is reached, it is important to discuss the timeline, integration process, and communications with the employees and customers. A single position and vision should be communicated internally and externally. ## **Structuring the deal** The deal structure can be a trading card in the negotiations. Cash today is more valuable than cash in the future, so a higher valuation with a smaller payout today may be preferable to a lower valuation with an all-cash transaction. ### **All-cash** Sellers get their money; buyers assume control. The transaction is clean and fast. It may require a loan for a buyer to pay the cash or a payment schedule consisting of installments taken from the company’s cash flow. Based on the experience of many MSPs, this type of transaction is easier to agree on yet brings the highest risk of overpaying and struggling with the performance of the newly acquired business. ### **Stock transaction** Sellers get shares in the new business and become stakeholders in its success, as their future earnings depend on the combined company's future performance. Pure stock transactions are rare, as most sellers seek a cash-out. Stock transactions may come with tax benefits in some jurisdictions and getting advice from a tax professional makes sense when considering the attractiveness of the stock transaction. ### **Earn-out structure** This structure suggests the earn-out period based on the company’s performance. Usually, it is structured with a portion of the value paid upfront and then the rest of the value paid during a two- to three-year period based on company performance. The usual metrics used for earn-out plans include revenue, EBITDA and customer retention, and an opportunity to receive higher amounts if the company outperforms its targets. This structure is usually employed when there is a need to retain the initial business owners and managers and motivate them to help grow the company.   More and more MSPs are acquiring other MSPs after a hybrid deal structure combining a portion of cash, stock and performance-based earn-outs. The flexibility in structuring the deal is a good card to play in negotiating the value that sellers will receive.   [In the next article of the series](../../../acquiring-a-managed-service-provider-business-part-iii-integration), we will discuss integrating the newly acquired MSP. --- ## Acquiring a Managed Service Provider Business. Part I: Reasons, Targets and Due Diligence **Author:** Gaidar Magdanurov | **Published:** 2024-09-19 **URL:** https://mspnotes.com/acquiring-a-managed-service-provider-business-part-i **Tags:** Business Even though analysts report that the MSP acquisition market [has slowed down](https://www.crn.com/news/channel-news/2024/msp-m-a-market-slowing-but-still-more-deals-than-before-covid-expert), the topic is still hot, and many MSPs start considering acquisitions once they reach a certain size. In this series of articles, we will examine the aspects of acquisition that may be useful for MSPs considering their first acquisition and IT professionals considering starting an MSP by acquiring an existing business. ## **Why acquire an MSP?** There may be multiple reasons for acquiring an existing operational MSP business besides growing the customer base. While getting more customers and more technicians to serve those customers is often named as a primary reason, there are other benefits to consider while working on the acquisition. ### **New services and expertise in the portfolio** Bringing people with new expertise to offer additional services allows MSPs to upsell additional services to their customer base. Diversifying the portfolio also provides for acquiring new customers who demand new services. The most popular services added via acquisitions are security, disaster recovery and virtual CIO services. ### **New location** Most MSPs serve customers within a reasonable driving range, limiting the business's growth to the technician's ability to be on-site within a day. Additional locations expand the geographical presence and potential customer base. ### **Cost savings at scale** More business enables MSPs to negotiate better deals with hardware and software vendors, get additional incentives through distributors, and save on operational costs like finance and legal fees. ### **Reduction of marketing costs by eliminating competition in the local market** Not having a competitor nearby going after your customer base reduces marketing costs and acquiring a smaller but more aggressive competitor can be a way to eliminate the competitive pressure. ## **Identifying acquisition targets** Once the acquisition objectives are defined, it becomes straightforward to look for a match. The best practice is to build a table with the search criteria and conduct market research, populating the table with the information needed to make the decisions. The usual parameters to consider:  - Size of the company – employees and customers, revenue and margin (if available) - Service offering – complimentary offerings, unique expertise - Technology stack – complementary or completely different, consolidated or diverse - Industry focus – critical in case of solid focus on [vertical marketing](../../vertical-marketing-strategy-for-managed-service-providers) - Contract terms – monthly, annual, multi-year - Pricing structure – lower or higher, flexible or fixed - Reputation – social media, reviews, customer interviews can be helpful - Management team and team culture – is it the founder-led company or the company led by the professional management - Partnerships – vendors and distributors used by the company After collecting the information, it is time to contact the owners and discuss the opportunity. Given that many MSPs are “lifestyle businesses” and rarely valued highly, rejection of communication about the acquisition opportunity is usual and should not discourage you from looking at other targets. > Tip: Many MSPs value their relationships with their employees—as they become a family over the years—and at the beginning of the conversations, it is important to have a solid vision for what is going to happen with the team and look for a cultural fit with the existing team. ## **Due diligence process** The acquisition process requires legal and financial support, and the best practice is to retain people with experience driving acquisitions. However, the future owner should delve very deeply into the details of due diligence before making the final decision on whether to finalize the deal, what price to offer or whether to walk away from the deal and look somewhere else. There are multiple areas for due diligence for any sizable business. ### **Financial** Review current and past financial statements and dynamics. Look for discrepancies in the reporting and revenue recognition practices. A change of ownership may force some customers who are on the verge of moving to another MSP to decide to proceed now. Review debts and leases and terms for them. ### **Legal** Review contracts with existing customers and terms of termination. Look for liabilities and protections in place, especially in downtime and cyber incidents. Review insurance agreements and coverage. Investigate any opportunities for litigation and check for the status and impact of any past litigation. If there is proprietary technology in place—acquired or developed in-hours—investigate the intellectual property rights. Be diligent in reviewing compliance with regulations, depending on the industries served. ### **Technical** Assess the technology stack and IT infrastructure in place. Look at the cost of operating and upgrading the infrastructure. Review documentation, especially the documentation for customer onboarding, offboarding and daily maintenance. Weak documentation and relying on employee knowledge are red flags. Be diligent about software licenses and compliance with vendor licensing policies. Quite often, you may discover unlicensed software, and in some cases, even counterfeit software, that will become your problem after the acquisition. Put particular emphasis on evaluating cybersecurity, including the technology used, procedures to maintain cybersecurity, level of knowledge, and presence of incident response policies. ### **Team** Besides reviewing contracts and HR policies, it is crucial to interview employees and understand team dynamics well. There is a chance that the relationships with the management retain employees, and after the acquisition, you may face resignations or have to incur significant expenses for the retention bonuses. Look for the key employees and informal leaders on the team and evaluate if they are a cultural match for you and your team and if you can work with them. The business of MSP is purely people; thus, evaluating the team is the top priority for the leader, and external consultants are rarely able to do it for the leaders.   In [the next article](../../../acquiring-a-managed-service-provider-business-part-ii), we will look at the approach to the valuation and execution of the transaction. --- ## Why Do Managed Service Provider Businesses Fail? **Author:** Gaidar Magdanurov | **Published:** 2024-09-12 **URL:** https://mspnotes.com/why-do-managed-service-provider-businesses-fail **Tags:** Business A reader asked me: “Gaidar, you spoke to thousands of MSPs, and you share best practices and tips, but what about those who fail? Why do they fail?” It is a fascinating question. When I was working on market intelligence at Acronis for a few years, we found out that there are around 300,000 companies that offer or resell managed services worldwide. About 10% of them shut down or are acquired every year, yet new MSP businesses appear every year, quite often to be shut down in the same year or the year after. The question about the reasons for failure inspired me to do deep research in my notes from the last ten years to find comments about previous business failures. The topic became so engaging that I contacted a few former MSPs who joined vendors and channel companies to get their perspectives on reasons for failure. The list started to grow, and completing this article took over four months. This article can be helpful for MSPs suffering through the same issues, knowing that others experience the same issues and that thousands of companies were able to pull through. We will discuss this at the end of the article. So, why do MSP businesses fail? ## **Don’t believe in success anymore** The business is not growing and is hitting a rough patch. Customers are leaving, tickets are piling up, and there are not enough people to manage the workload. The future does not look bright; there is no business stability, and returning to a corporate job does not seem like a good idea. In another situation, business is going okay, yet there are no new customers, the margin is small, and the lifestyle could have been better in the corporate days. Earning money is tough, and getting up for work daily gets less exciting. ## **Fail on expectations of fast results** IT professionals start an MSP business expecting to get a scalable business yet getting themselves just yet another job. Instead of working a 40-hour workweek for a corporation, they get themselves a 120-hour workweek with the same or sometimes lesser pay. Savings are running out; bank account looks grim as they don’t change their spending pattern, expecting the business to grow fast and pay them back. One US-based MSP noted that they were working long hours, paying themselves about $80,000 a year salary, establishing processes, and after they were ready to onboard an employee to do the work, they found out nobody wanted to work such long hours for $80,000, and paying more would reduce the margin the owner takes. They expected to acquire new customers quickly but could land 1-2 contracts a quarter merely to balance the churn of customers that were going out of the business. ## **Focus on mistakes and failures, getting stuck in the past** Bad things happen. Customers have downtime, tickets get incorrectly handled, and customers get upset and leave. This is the nature of business; there is almost always a churn of customers. Proposals are always rejected. There are times when you must let the customer go when the cost of maintaining their contract is too high, and there is no potential to get more value from the account. The ability to move on and keep driving the business despite the failures is essential. Yet, some MSP business owners focus on their mistakes and waste time and effort on retaining customers who are about to leave and stop selling after being rejected many times. Instead of thinking about the future and creating opportunities, owners get stuck with their past mistakes, repeatedly reliving them and being afraid of the future. ## **Fear of changes** Changes are scary. An ancient Chinese proverb goes, “When the winds of change blow, some people build walls, and others build windmills.” This really applies here. Working against the change leads to failure. Technology changes, customer needs evolve, employee performance changes. Trying to work against the change takes away tons of energy and prevents us from investing in the future. MSP service offerings should constantly evolve. Today, you offer anti-virus, tomorrow, you offer EDR, the day after XDR. Now, you have your customers using backup and tomorrow, you will offer disaster recovery. Yesterday, your customers were using on-prem servers, and they moved to the Cloud today. The situation in the lives of employees changes, and top performers can become toxic and destructive, and there is time to let them go. ## **Give up easily** Good things are rarely easy. If you start marketing and fail with a few first campaigns, it is not the time to give up—you must push it consistently. If customers reject your proposal, you must adjust it and go after others. Giving in to the feeling of hopelessness and resignation leads to the end of the business. A UK-based MSP told me they were chasing a large customer for over three years until they had a chance to land a deal. They also failed miserably during onboarding because they underestimated the complexity of the infrastructure and the lack of resources to fulfill the SLA. And they gave up to learn that even smaller MSP was able to take over after them, and those guys kept pushing, provided discounts, worked extra hours for free but managed to retain the account. ## **Believe that relationships will retain customers** The MSP world is highly competitive. Your customer of many years may be approached by somebody offering new services at a lower price or, even better, painting the picture of a much more efficient and effective IT infrastructure driving their business. Business leaders value relationships, yet when the value of a new proposal is too attractive, they tend to move on. If the MSP business doesn’t evolve, doesn’t address technology trends, and does not become a partner for the business leaders – good relationships won’t retain the account. No amount of excellent work in the past overcomes savings and higher earnings in the future. The goal of any business, including MSPs, is to make money for its stakeholders. Thus, you have to perform on a daily basis and show a bright future to keep the customers. ## **Focus on loss, not on gain** Instead of growing a customer base, MSPs that focus purely on retention eventually fail. Customers leave—sometimes they go out of business, sometimes priorities change, or they are acquired, and the services of an MSP become unnecessary. Customers leave, and it is just a fact of life. Thus, focusing on retention will ultimately cause MSPs to lose in the long run. ## **Overwork and burnout** Working hard is good; it gives excellent results. Yet, working hard all the time and running yourself into the ground has negative consequences. You burn out as a leader, lose interest and drive, and influence your team in the same way. You start from rejecting new projects –to avoid more work. You stop investing in developing your team and try to maintain the status quo. Then you become toxic – saying “no” to every employee initiative, forgetting to take care of your team. And then, you, as a leader, make the whole team appear to burn out to the outside world. Customers and prospects start talking about your company as slow and not innovative and look for another partner. ## **Thinking their challenges are unique** The customer was down for a few days due to a faulty update by a cybersecurity vendor and a failure to recover from a backup due to storage misconfiguration. Another one could not fail over to the Cloud due to complicated network configuration. One more had significant losses due to a malfunctioning VPN preventing them from working during the active trading session. And so on, you name it. Every issue or problem may have happened somewhere else, and somebody might have found a way to deal with it. Without looking for best practices from others or solutions applied in similar situations, it is easy to reinvent the wheel every single time and waste enormous resources. ## **The antidote** This list looks scary and relatable for any business owner, not just the MSP. Bad things happen, energy may be low, and things are not going well. It occurs in business, in life, and relationships. Yet, many successful companies managed to survive despite facing the same challenge. So, what solution helped those successful business owners? They believed in their strength and skills, believed in the positive outcome, and believed in success. Believing gives hope in the future, making changes less scary, and it helps to keep working to get the results. Play the game of belief. Here is the same thought delivered with passion by [Sir Philip Anthony Hopkins](https://www.youtube.com/watch?v=RoKcHWSr4r8). --- ## New Revenue Streams for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2024-08-26 **URL:** https://mspnotes.com/new-revenue-streams-for-managed-service-providers **Tags:** Business, Ideas A recurrent topic raised during the meetings with MSPs is finding ways to collect more revenue from the existing customer base due to [declining profits](../../profit-challenges-for-managed-service-providers). Most MSPs could be better at [acquiring new customers at scale](../../game-on-the-cutthroat-world-of-managed-service-providers), so they rely on the existing customer base and upsell additional services to their customers. MSPs commonly object to adding additional services unrelated to infrastructure management, like managing websites, because “it is not our business.” Last week, a Florida-based MSP told me, “Offering something else is like Walmart making money on something but selling stuff.” It's funny they mentioned it because Walmart now makes [significant revenue from advertising](https://www.ft.com/content/1e2a5338-f1ae-41ee-bc08-4c86f2eb5a58). The ad business is more profitable than selling goods at the stores, and its advertising business has grown 30% year-over-year, faster than any other business line of Walmart. It is a good illustration that having access to customers is an opportunity to make money on additional services. ## **How do MSPs make money now?** Let’s look at the “traditional” services MSPs offer and charge for. The most common services include device and network monitoring and management, help desk services, backup and recovery, and basic security services. Usually, MSPs offer various packages with different combinations of services and various service level agreements (SLAs), offering customers a choice to get better and faster service at a higher cost. The usual candidates for additional revenue are software and hardware reselling. MSPs frequently resell Microsoft 365 licenses and help procure hardware, collecting small yet stable margins. Additional services may include managing software and hardware renewals, hardware warranties, and maintaining licenses across all software assets. Another usual source of additional revenue is reselling and managing cloud services—a variety of specialized cloud applications may require monitoring and management, which is charged to the end customers. One-time or project-based sources of revenue may include migration to different software or cloud services, virtualization of infrastructure, one-time renewal of hardware and standardization of software. ## **What can be new revenue streams for MSPs?** MSPs looking into new revenue sources and open to being creative with their services have a great choice of services they can add to their current offering. End customers now demand cybersecurity and compliance services. Given that human mistakes are the most prominent attack vectors, an MSP can offer education for employees in addition to installing cybersecurity software. On top of essential security, MSPs can offer Endpoint Detection and Response (EDR) and managed security operation centers (SOC). The services can be outsourced to a partner or a vendor if MSPs don’t have the resources to do it themselves, and the margin will be shared with them. - Therefore, for cybersecurity, MSPs can add to their portfolio: - Vulnerability assessments - Penetration testing - Security awareness training - Incident response - Forensics As for compliance, more and more customers, including small businesses (SMBs), have requirements to comply with specific government regulations or requirements of the large enterprises they serve. An SMB, a vendor for an enterprise, may have to comply with the regulations applicable to the enterprise to continue business with them. This creates an opportunity for MSPs to offer compliance services: - Compliance audits - Policy development and implementation - Consulting on compliance requirements (for example, GDPR, PCI DSS, HIPAA) Cybersecurity and compliance are highly demanded services and seem like solid next steps for MSPs, yet there are many more opportunities to expand the services portfolio and generate additional revenue. - Cloud service consulting – helping customers to find more effective ways to do business by employing cloud services. There are opportunities in the management of services and supporting cost optimization. Many customers struggle with multiple services and using various clouds, and consulting on consolidation and management may be a desirable offer if it is correctly [positioned toward generating additional revenue or cost savings for the customer](../../positioning-the-value-of-managed-services-to-prospects-and-customers). - AI consulting – multiple services are available for automating day-to-day operations, yet general knowledge of the services and best practices of their application is scarce. Consulting on AI implementation and ongoing maintenance of processes involving AI tools is in demand, and the market is growing as AI tools become a de facto requirement to stay competitive in many industries. - IoT management— offices are now filled with devices that can create multiple issues if left unmanaged, starting from being a potential entry point for cyberattacks. A few MSPs offer IoT management now, and those services can be a potential competitive differentiation for those who do. There are also opportunities to offer services in addition to infrastructure management, including web hosting and web presence, CRM management and support with marketing automation, virtual CIO services, and the design of a complete IT strategy aligned with the business plan. ## **Conclusions** Having trusted relationships with customers opens up various opportunities to offer additional services, and in most cases, [a partner can provide the services on behalf of an MSP](../../msps-reselling-managed-services). Looking for ways to grow their business, MSPs may explore services their customers want and consider options for offering those services. Besides serving as an additional revenue stream, offering additional services deepens relationships and reduces the risk of customer churn, as customers tend to look for lower-priced offerings from other MSPs if they consume only the essential infrastructure management services. --- ## Smart Goal Setting for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2024-08-07 **URL:** https://mspnotes.com/smart-goal-setting-for-managed-service-providers **Tags:** Business MSP owners and managers, often being technical people, struggle with setting business goals for their MSPs. Quite frequently, the goal sounds like “grew revenue by X% next year,” which is fine, yet without a detailed model behind it, the goal is just a statement. ## Designing business goals Let’s build a simple model to explain the goal design process. Let’s assume we have an MSP with 50 customers; each customer, on average, pays $15,000 per year, resulting in $750,000 in revenue for the MSP. If the business manager wants to grow revenue by 20%, they will need to collect $900,000, which is $150,000 more than in the previous year. There are two ways to do this at a high level: increase collection from existing customers or add new customers. A new customer brings $15,000 per year, and the MSP, from experience, is confident it can acquire two new customers per quarter. To simplify the model, let’s assume the customers start paying from the beginning of the quarter. Therefore, the revenue from the 8 new customers in the next year will be $75,000 (the first 2 will bring 15,000 each, the second 2 only ¾ of that and so on…). So, we assume we will make $75,000 from those new customers and have $75,000 to make on the existing customer base. There are a few ways to grow revenue from the existing customer base: renegotiate the prices (as MSP agreements are most likely to have a clause allowing for price increase), upsell additional services, or offer higher-tier packages of services. Getting $75,000 from the existing customer base would be a 10% price increase, leading to $16,500 per customer per year. From the price increase, adding additional services, and increasing SLAs. We assume that all customers will stay with the MSP in this example. Therefore, the business goals for the MSP business will look like: - 20% revenue growth in the next year - 2 new customers at an average contract value of $15,000 acquired per quarter - 10% average increase in revenue per existing customer ## Cascading the business goals to the organization For the MSP technician, the goal of growing revenue by 20% makes very little sense. They don’t operate in terms of revenues. Their influence on business results comes from their day-to-day jobs, and their goals should be focused on supporting growth. Let’s create a simplified model to estimate the team of technicians needed to support the business's growth. Say we have 5 technicians who spend 20 hours a week each handling tickets from the existing customers, spending an average of  2 hours per customer. Assuming a similar workload, an additional 8 customers will require 16 hours per week. One way to handle the extra time is to recruit one more technician or reduce the time per customer to 1.7 hours a week. The time spent on customers is determined by the number of incoming tickets and the time spent per ticket. For this simple example, let's say that a ticket takes 0.2 hours on average, and each customer generates 10 tickets per week. Ticket volume may be reduced by increasing the reliability of the infrastructure, introducing new software packages, and implementing self-service capabilities like the ability to recover files and folders from the back to avoid contacting the MSP. The time required to handle a ticket may be reduced by implementing an integrated tech stack, reducing the number of consoles to use. Thus, the goals for the technicians can be to reduce the volume of tickets to 8 per customer per week or reduce the time of processing a ticket to 0.17 hours. Quite often, MSP managers choose to use the combination. Moreover, a reduction in ticket processing time can be connected to the price increase for the existing customers, given that they are receiving better SLAs, or it can be connected to the upselling of more expensive packages with additional tools to reduce ticket volume. Therefore, the goals for the technical team can be: - 20% reduction in the number of incoming tickets - 15% reduction in the time spent per ticket ## Discussion The example above is simplified yet describes a fundamental principle. Setting the goals around improving the work that the team is doing focuses the team on finding solutions to improve while providing them guidance in terms they understand. There is no guarantee that all targets will be achieved; therefore, a combination of targets should allow the final goal to be achieved—like reducing ticket volume and processing time per ticket. Using the sports analogy, winning teams behave like winning teams. They don’t have goals defined for winning every competition; they have goals to show their top performance. They may lose certain games, yet they will ultimately achieve top results while working on their performance. The same applies to MSPs. They may not be able to acquire as many customers as they planned or upsell to as many customers as they want, yet due to their higher operational efficiency, they will have the capacity to do so, and over time, that capacity can be used to achieve faster growth. --- ## Pricing and Costs for Managed Service Providers: Defining Per User and Per Device Rates **Author:** Gaidar Magdanurov | **Published:** 2024-08-02 **URL:** https://mspnotes.com/pricing-and-costs-for-msp-defining-per-user-and-per-device-rates **Tags:** Business The most common question from MSPs is how to define and adjust their prices. There is a trap to go down the rabbit hole of following the competition, as customers shopping for rates most likely will do a comparison. However, this is a risky approach, as MSPs have different cost structures, different services and different value they provide. Last year, it posted about [pricing for MSPs](../../pricing-for-managed-service-providers), advocating to target profit margins, and since I received multiple questions about specific examples, his post will expand on the topic. ## The rates In the US, depending on the level of service and technology stack deployed, expected per-device or per-user rates range from $50 to $300. The range is rather broad, as it really depends on what is included in the price. Some MSPs include all necessary productivity, management, and cyber protection tools in the cost and end up at the higher side of the range, while others charge separately for software licenses with little to no markup. And there is a wide range of options there. Some MSPs include only necessary tools like RMM, backup and security, while overs include everything that the customer needs. The all-inclusive approach has its pros and cons. It is usually easier in the initial negotiation, showing customers that there is no additional cost and that the cost of the managed contract is fixed for at least a year. At the same time, it is much harder to upsell by adding additional tools and services even if the customer desperately needs them. ## The margin The usual range of margins in the US is between 30% and 70%. Most of MSPs design their offering target at the last 50% margin and end up at a 30-40% margin during the contract negotiations. To calculate the rates based on the target margin, consider the cost of software, the cost of running the business with the customer, and the cost of the employee's time.  Margin is calculated using a simple formula: *Margin = 1 – (Cost / Price)* Therefore, to calculate the Price, use the following: *Price = Cost/(1 – Margin)* Let’s say your cost per hour is $50 and your target margin is 50%, then your price shall be $100 per hour. To estimate the time required per customer, make assumptions, and then adjust them based on reality. In most cases, you already have some experience with the ticket volumes and time required to handle the tickets.  Also, it is a practice to look at your margins regularly, assess the profitability of customers, and make hard decisions about parting ways with customers if they become unprofitable. ## The reality The sad truth about meeting pricing is that customers will negotiate, and you will make concessions. A good rule of thumb is never to give up discounts without adjusting the level of service. If a customer demands a discount, estimate what you must adjust to maintain your profit margins. For instance, at a lower rate per device or user, you can offer longer response time for the support tickets – saving time for your technicians to serve over customers. Another sad reality is that you will always have customers with incidents that will require a lot of attention and time, and those are hard to predict, as you never know if somebody will force a faulty update for the systems or if a customer will have administrator access, makes some funny changes you will have to fix. If the incidents become a norm, you must re-negotiate the agreement or drop the customer. Many MSPs continue to support customers that become unprofitable and, over time, destroy their own business. ## Charging by an hour With more and more MSPs switching to per-user or per-device pricing, the model for charging per hour of work is still alive, especially in complicated customer cases requiring a lot of extra effort. One option to consider with customers who use a lot of hours is to offer them much lower per-user and per-device prices while establishing an hourly rate for handling incidents. In this case, having the customer's history allows you to estimate the price using the same target margin approach. … In any case, remember to [sell on value](../../positioning-the-value-of-managed-services-to-prospects-and-customers), not only on price. At the end of the day, the customer cares about what you do for their business as long as your services save them money or allow them to make more money. --- ## Positioning the Value of Managed Services to Prospects and Customers **Author:** Gaidar Magdanurov | **Published:** 2024-06-15 **URL:** https://mspnotes.com/positioning-the-value-of-managed-services-to-prospects-and-customers **Tags:** Business, Ideas An active reader, “How can my MSP compete on value when I don’t know what prospects want?” He elaborated that endless conversations about the customers’ needs lead him nowhere. Customers and prospects share ideas on what they would like to receive as services from their IT-managed service provider and then… don’t pay for them or choose another provider offering a lower price. True, it is easier to know what people want once they pay for it and prove they want it. Until they pay for it, they just share ideas on something they would like to have (read “good to have, maybe”). Not until they take money out of their pockets and have other priorities. > Here is another way of thinking about the services to provide. Start not from what people want but what they don’t want to do. It is usually easier to identify and easier to sell to customers. ## **What do business owners want to avoid doing?** Most MSPs would quickly respond to the question. Business owners don’t want to spend time on something that is not their core business. They don’t want to spend time dealing with their IT; they want everything to work so they don’t even have to know what their MSPs are doing. It is so. That is why they are hiring MSPs to manage their IT. Yet, to understand what and how to offer them, we need to go deeper into their needs and business needs to identify their pain points with their MSPs. Below is the list of everyday things I heard from the business owners when I asked them about their pains while working with IT providers. Addressing their pains is the way to pitch value to them. - **They don’t want to pay for services they don’t need**. Often, it is not that they don’t need the services; they don’t understand the benefits. If they have EDR deployed to improve their security, yet they think Windows Defender is more than enough, it would require explaining to them that having the additional layer of protection helps them avoid the risk of dealing with infrastructure that does not work or a security breach that could kill their business. - **They don’t want to learn about the issues when it is too late**. Lack of timely or clear communication leads to wasted time and frustration. Owners don’t want to worry about something that may happen, and lack of communication makes them wonder if something terrible may happen. Regular reports, scheduled reviews or email updates give business owners some predictability. - **They don’t want to call MSPs for support**. Nobody wants to see things break, but even more to that — spending time explaining what has happened, waiting for the fix, and losing productivity is a pain for business owners. Having proactive monitoring and prevention of issues in place helps to alleviate the pain. - **They don’t want to waste time because IT doesn’t work or their computers’ performance is slow. Remote fixes, updates and upgrades outside of working hours minimize the impact on people’s productivity**. Scheduling backups and complete security scans outside working hours is also a good practice. - **They don’t want to waste time working with inefficient applications**. For instance, having multiple productivity applications that are not integrated may be frustrating, and switching to a platform like Microsoft 365, Google Workspace, or Slack with integration of the business applications can alleviate their pain. - **They don’t want unpredictable service levels. **Suppose a response to a critical issue takes minutes one day and hours another, and there is no way to get support outside of working hours. In that case, business owners tend to be unhappy about the inconsistency, even more than the issues. Looking at the list of the pains, you can build the offering and the pitch to sell that offering to the customers — addressing things they don’t want to do by offering them ways to avoid them. ## **One single main point** The list above is long; many business owners can detail their grievances with MSPs for hours. Yet, when I ask them bluntly what is the one single pain they have from working with MSPs, not all of the small details — many say, “We don’t want to spend time teaching MSPs about my business.” > MSPs understanding their customers’ business can be the most critical value they can bring to their customers. An MSP that understands the business can offer solutions and address the pains. Knowing, for example, what a typical dental office needs and offering them the services, software, expertise, and SLAs they need can be the best value that MSPs can provide to their customers. With an understanding of the business of your customers and prospects, you can build your portfolio of services and products and pitch it most effectively. Therefore, defining who your customers are and focusing on them is essential; being everything for everybody is never a sustainable strategy. --- ## Importance of Good Ol’ Backups for MSPs **Author:** Gaidar Magdanurov | **Published:** 2024-05-15 **URL:** https://mspnotes.com/importance-of-good-ol-backups-for-msps **Tags:** Technology, Security Discussing the topic may seem funny. Backup is necessary, and every MSP knows that — and it is almost always part of the managed services offering. However, MSPs often see backup only as a way to recover the system in case of a failure, data loss or cyber attack. Backups are much more than that. ## **Useful data** The secondary copy of data can be used in a variety of ways. Starting from building reports and analytics on the type of data present in production systems without putting additional load on the production system, and continuing with using the secondary copy of data for training AI, looking for data modification patterns, and discovering unexpected and suspicious behavior of data modification. Comparing the data on a production system to a backup can help uncover hidden cyber threats — like ransomware gradually encrypting files on the production system and being unnoticed by security solutions. ## **Archive for investigation and litigation** Having a snapshot of data from the past can be helpful in multiple scenarios. After mitigating a cyber attack, the backup can be a valuable source of information for forensic investigation — to discover how the attack progressed and what happened in the process. MSPs frequently overlook the importance of an investigation after an attack as they focus on getting their customers back to productivity. However, not knowing how the attack happened may lead to repetitive attacks, and not knowing the full extent of the impact may lead to unpleasant surprises in the future. Another application of backup in this context is archiving data for future litigation. Recovering documents and communications may be crucial for litigation and directly requested by courts. ## **Sandbox** Another valuable application for a backup copy is using the data for tests — recovering the data and systems to spare hardware or a virtual environment and testing updates and new software on a system that is an exact replica of a production system. ## **Migration** Another application of backup is the migration between hypervisors, physical servers, including those with dissimilar hardware, and on-premises to Cloud and backup. The backup and recovery process can be used instead of specialized migration tools, saving the IT budget, as no additional software is needed to accomplish the migration. The beauty of it is that migration and recovery are the same process. Thus, migration can also be used as a fire drill to check procedures for handling recovery in case of disasters. … As you can see, a backup is more than just a copy to recover if things go south. As data storage becomes cheaper, keeping copies for future use and covering additional scenarios of using backup to deliver more value for the customers makes sense. --- ## Converting A Business from Break-Fix to Managed Service Provider **Author:** Gaidar Magdanurov | **Published:** 2024-04-30 **URL:** https://mspnotes.com/converting-a-business-from-break-fix-to-managed-service-provider-learnings-from-a-real-life-story **Tags:** Business In this post, I share a story from an MSP about their journey of converting their break-fix shop into a managed service provider I collected over multiple message exchanges last month. In no way is it a guide to starting your own MSP; for that, I would suggest checking out [a great collection of training courses on specific aspects of running an MSP business](https://www.acronis.com/en-us/academy/msp/), yet the stories here can be a source of inspiration for entrepreneurs in the managed services business. > The story’s hero asked not to disclose any information about them besides being a proud American MSP. The story covers over three years as of today, and it started during the Covid pandemic. ## **The mentor** After struggling to maintain sustainable income from one-off jobs at hourly rates for years and getting to the stage of life when predictable income was necessary for the family’s well-being, the break-fix business owner was considering taking a corporate job. Managing a break-fix shop with four employees and a few part-time contractors was an exciting experience, and the freedom to run their own business was the reason they started the shop in the first place, yet struggling with getting enough contracts to pay salaries and not being able to set aside money for the rainy day was too much. Reading Reddit posts about people starting their MSP businesses and attending courses of MSP gurus like Chris Wiser and Eric Simpson convinced the hero of our story that [a long-term contract model](../../../understanding-the-managed-service-provider-model-contracts-billing-and-services-78fedcf1f909) is the only way to continue running their IT business. Yet, they were lacking confidence in their ability to start it. It was a many months-long struggle, and the owner was close to shutting down their shop until they met another MSP owner in the local community at one of the events. The MSP owner suggested serving as a mentor to help with the transition. The mentor gave the owner confidence and reassured them that failure to do so would not take away an opportunity to join a corporate IT department. The mentor also suggested that the break-fix owner try the transition before letting their employees go. As they became family, forcing them to look for jobs will have a detrimental impact on the mental health of our hero. > Having a person with the experience of the transition from break-fix to managed services to advise you and instill confidence in your abilities helps you make the first step. ## **The plan** Our hero sat down with his mentor and made a transition plan. Firstly, they planned the capacity to continue the engagements with an hourly rate for their existing customers and estimated the capacity for one-off jobs that were coming their way based on their experience of the previous years. Secondly, they agreed on a cutoff date for accepting new break-fix customers. They have decided not to accept any work from new customers without a six-month long-term contract. And then, if they get enough customers on the managed agreements to maintain their operations, they will get back to their existing customers and ask them to switch to annual contracts. They prepared a plan, documenting everything they needed to prepare, from contracts to marketing to recruit new customers, and planned the budget for the transition. In the process, they realized how little structure they had in their business and how little attention they paid to driving the business growth, acquisition, and retention of customers. In the process, they also spent time reviewing their technology stack and realized that they never had preferred solutions documented, and they were supporting whatever infrastructure customers had. As a result of the planning exercises, they selected RMM and PSA solutions to manage customers remotely and automate their business operations and decided to standardize their backup, agreeing that they would accept customers “as is” and then, over time, standardize their infrastructure-based on the preferred technology stack. > Building [a checklist](../../../a-checklist-for-a-new-managed-service-provider-6cae01a42a7b) of activities and assets needed for an MSP business and then building a specific plan with dates, resources and dependencies is the key for the successful transition. ## **The transition** Our hero was offering managed contracts for any new customers reaching out for IT support through word-of-mouth. Yet, he admitted that he still readily accepted one-off projects until the first three customers signed annual agreements, as he had struggled with cash flow. After getting the first three customers with long-term contracts, he took a firm position not to accept break-fix jobs anymore and had to refer a few customers to his competitors, with a few exceptions. In the first few months, our hero learned that the choice of RMM and PSA solution was not the best and switched to another vendor. After a review of the contracts by attorneys per customer requests, many changes were implemented. Service level agreements (SLAs) were defined for the work customers expected from the MSP. They also had a few major security incidents with compromised infrastructure and some of their customers’ data being encrypted for ransom. Since then, they added additional security services and partnered with an MSSP to offer incident investigation, as they acquired customers that needed this for compliance with cyber insurance requirements. They also introduced a policy to mandate offsite backups for customers and run recommended security on all computers on customers’ networks. They switched to another distributor due to regular billing issues and the distributor’s lack of support. The transition period barely looked like they had planned. Yet, in about a year and a half, they had built a working MSP model delivering over 50% of their revenues. Transitioning break-fix customers took longer than expected, and they had to retain some older accounts on the break-fix model due to personal commitments and relationships that were chosen not to strain. Surprisingly to them, the difficulty came from the employees, who were not used to working with customers on long-term contracts. Shifting their mindset from a one-time project to continuous maintenance of customers’ infrastructure took a while, and one person left the company unwilling to handle the incoming volume of support tickets. Initially, the team had to increase the hours they worked per week, yet after the transition was completed, they saw a significant reduction and “in general are much happier people to be around.” > Being flexible and open to making changes to their plans during the transition was something that allowed them to see it through. ## **The learnings** Most customers were reluctant to transition to annual agreements and required special discounted offers to agree to sign the managed services agreements. Most received a 30–50% discount from the initially published rates for the first year, with some having discount reductions for a few years after the initial contract. The owner thinks that they would retain 50–60% of their existing customers without the deeply discounted offers if they were not afraid to push harder and would be open to losing some customers. Yet, they were constrained with cash flow. Therefore, they retained almost 80% of their break-fix customers after the transition, and then about 80% of the overall customer base renewed contracts after the first year and nearly everyone after the second year. Most customers left for MSPs offering lower prices, yet a few returned after a year of getting a lesser quality of service. Looking back, our hero claims that making discounted offers instead of [selling value](../../../positioning-the-value-of-managed-services-to-prospects-and-customers-f77258ab17f1) was their biggest mistake, and they would be better off with fewer, higher-paying customers. Yet, they don’t have precise calculations, and they only speculate. > “Exit interviews” with leaving customers were the most important ways to learn how to improve the services and offers and taught how to sell value rather than price. The hardest part was learning to pitch the services to prospects. The old pitch of “we will fix issues when you have them” was easy, and selling on the value of a long-term agreement was hard. Luckily, most of the new customers were coming through word-of-mouth referrals and did not require convincing regarding the quality of the service. The key asset for the transition was the loyal customer base. What started as a break-fix shop for friends and family evolved into a sizable MSP business, thanks to loyal customers helping recruit other customers and actively advocating for the MSP in the local community. > Fostering relationships with customers helped generate a constant flow of referrals and references, leading to prospects signing up. A quick conversation with an existing customer is an effective sales tool. Still, the hardest thing to do is to say “no” to prospects unwilling to sign up for long-term agreements. Some projects look like easy money and are hard to refuse. Our hero sees that they are improving at that while still accepting projects if those are small, simple, or “come at an outrageously good rate.” ## **The road ahead** Their immediate plans include investing in marketing to acquire more customers, adding additional services to make their offering more valuable, and increasing the amounts they charge their customers based on the different packages of services they offer. They started by charging $75 per workstation and $150 per server per month for a limited scope of service, with additional service coming at an hourly rate of $200 per hour, and over time, introduced additional options that would include everything at $120 per workstations and $300 per server, with some of the customers paying $150 per workstation and over $300 per server, plus $75 per printer or specialized endpoint like POS terminal. They still maintain hourly rates for some agreements, yet they are trying to transition customers to the all-inclusive model with defined service SLAs. They aspire to transition most of the on-premises infrastructure to Azure and all file servers to Microsoft 365 OneDrive and SharePoint. Yet, they are not pushing it hard due to existing contractual agreements. Their other aspiration is to include the annual price increase in their agreements at a 3–5% rate. They missed that at the beginning of the transition. Many customers agree that it has become a standard practice and allows both parties to plan their financials. They have doubled their revenue in the last two years and look forward to expanding and hiring more people as they grow. The next hires they plan to have soon are an operations manager and a marketing manager. For technology, they want to build their own stack to make a standard for all customers at onboarding to grow their [operational maturity](../../../msp-maturity-and-scalability/) and increase productivity. They are cautious of signing large customers, even though they have a few strong prospects, as they are afraid of the workload with those customers and are scared of growing dependency on a few large accounts. Our hero considers going “upmarket” as the next step after he builds efficient operations. ## **The conclusion** The transition from a working break-fix model to an MSP may seem scary. Yet, it is not only doable but also necessary to maintain a sustainable, predictable income. Building a detailed plan, finding a mentor or adviser to help with the plan and to answer questions on the go, and finding the courage to start making changes open up the opportunity to succeed. The market for managed services is large and growing. Canalys, in July 2023, estimated the global market for managed services at $488 billion in 2023, with over 300,000 companies offering managed services, yet less than 50,000 generate more than 50% from the managed services. Given the model’s predictability, we can expect more and more companies to transition to the “pure” MSP model. I hope the story inspires the break-fix shop owners to plan the transition today. --- ## Replacing Another Managed Service Provider **Author:** Gaidar Magdanurov | **Published:** 2024-04-15 **URL:** https://mspnotes.com/replacing-another-managed-service-provider **Tags:** Business Sometimes, customers are unhappy with their current MSP partners and start looking around for another partner. They might have received a recommendation from somebody they trust or just got fed up with issues and poor SLAs with the current MSP, or they don’t believe they get the value for the money anymore. Whatever the reason they started the conversation with a new potential partner, it does not mean they will be ready to switch right away. There is a cost associated with it, and the customer should be confident in the new partner to go through the hassle of switching. Even if the customer had a major disaster and doesn’t want to avoid staying with the existing partner, winning the account is not easy — as they will be shopping around and talking to other MSPs in the area. In this article, I offer helpful tips on how to pitch to customers in a competitive situation. ## **Start with the improvements** Instead of discussing all the excellent services you can offer, investigate the prospect’s infrastructure, understand their frustrations, and discuss the improvements you would implement. It may sound counterintuitive; however, instead of telling customers how good you are, tell them what poor quality of service they are getting now. Be specific when discussing the issues customers are experiencing to make the conversation about them. The generic pitch of everything you can do or how you are better than other MSPs rarely works — everybody tells the customer the same thing. ## **Gain credibility by being specific** Based on the information about the customer issues and your knowledge of the competitor serving the customer, explain to the customer the weaknesses of the competitor (for example, lack of cybersecurity knowledge, using only basic antivirus and not an EDR solution) and your strengths (for example, number of security experts on your team, their experience, certificates, customer references). Again, be specific; discuss the weaknesses and strengths of the customer’s situation. They may be excited to know you have experience putting network cables in the deep sea. Still, if it is irrelevant to the customer’s environment, it rarely gives you additional points for consideration. ## **Praise the competitor a bit** A neat trick is to highlight the strength of the customer’s current partner while focusing on their experience that is irrelevant to the customer’s environment. The customer did not choose a bad MSP; they chose a good MSP, but not the one with the relevant experience for the particular customer infrastructure. In summary, the winning pitch requires understanding the customer’s needs and being very specific about the customer. They always hear generic pitches and want to trust that your expertise is relevant to them. --- ## Simple Sales Tip: Talk About Money They Make, Instead of Money They Pay **Author:** Gaidar Magdanurov | **Published:** 2024-03-30 **URL:** https://mspnotes.com/simple-sales-tip-talk-about-money-they-make-instead-of-money-they-pay **Tags:** Business, Ideas In many sales conversations between MSPs and business owners, the communication revolves around the service cost. MSPs tell the business owners how much they have to pay for the services, and the business owners assess the cost, not the value of the service. In this post, let’s look at how to transition the conversation from the cost to the value. The tip is simple — start by talking about how much customers can save or make if they deploy the managed services first instead of talking about the cost of the managed services. Customers can save or make money by stopping doing certain things they used to do. For instance, automating the preparation of quotes and delivering digital documents instead of paper documents may save time and expenses. Therefore, discussing the cost of the services before discussing the cost forces customers to adopt the mindset, “We are making money, not spending money.” --- ## Niche for Managed Service Providers: Remote-First Businesses **Author:** Gaidar Magdanurov | **Published:** 2024-03-15 **URL:** https://mspnotes.com/niche-for-managed-service-providers-remote-first-businesses **Tags:** Business, Ideas COVID-19 forced many businesses to implement options to work remotely — online meetings, collaboration platforms, and file cloud storage. Since then, many companies have supported fully remote or hybrid work — allowing employees to work remotely with occasional visits to the office or team meetings. MSPs were crucial in supporting remote work, taking the workload of managing remote offices and supporting the rapid adoption of cloud-based collaboration services, and the expertise of supporting remote workers became crucial for many MSPs. Now, many MSPs are focused on helping companies transition back to “office live,” with many businesses requiring employees to be on-site. However, at the same time, there is a new niche for MSPs — remote-first businesses. Businesses built around the concept of remote work hire employees worldwide without the expectation of getting them to work from a single location. Those businesses start by implementing cloud-based collaboration tools, building the workflows from remote collaboration, and not trying to move existing workflows to the Cloud. The emergence of those businesses creates an opportunity for MSPs to manage their delocalized infrastructure and collaboration tools. ## **8 Mandatory Competencies for Remote-first MSP** MSPs willing to position themselves as experts for remote-first businesses and become leaders in the market require a specific set of skills and expertise. 1. **Strategic planning**. It starts with planning the infrastructure architecture to satisfy the customer’s needs while providing high-cost efficiency. Hyperscalers offer much flexibility, yet unwise planning may lead to remarkably high costs. All customers want to get guidance from their MSPs on the most efficient and economical way to implement IT for their business. Remote-first businesses tend to be even more frugal and have higher expectations for cost efficiency. 2. **Cloud infrastructure and services**. Expertise in Azure, Amazon, and Google Cloud and collaboration suits like Microsoft 365 and Google Workspace are essential, as they are the backbone of remote-first businesses. 3. **Cybersecurity**. Containing cyber threats inside a corporate network is easier than with cloud-based services available 24/7 worldwide. Cloud security expertise may be used as an advantage when pitching potential remote-first customers. **4.** **Data protection and disaster recovery. **Cloud-based infrastructure is also prone to disasters — data center outages and malicious or accidental data deletion. 5. **Endpoint management**. While almost everything is in the Cloud, users still have their devices and local network infrastructure that requires management and security. 6. **Compliance**.** **Distributed** **businesses operate in multiple jurisdictions and require specialized knowledge of privacy, data storage, and retention from the MSP. 7. **Automated Helpdesk and self-service. **Remote-first businesses usually demand 24/7 availability and fast reaction, and the usual helpdesk system should be augmented by automation to be able to handle ticket volume spikes within SLAs. Offering self-service tools, like the ability to recover accidentally deleted emails or files, and AI-based chat-bots for quick diagnostic and triage of the issues in a language preferred by the user, may significantly improve the experience and reduce the support cost. 8. **User training. **Systems are as good as the people that use them. As a Microsoft Teams user with previous Slack experience, I can testify that the approach proposed by the vendor and the way users got used to their tools may be very different and require continuous training. Having the expertise differentiates an MSP targeting remote-first businesses and [makes it easier to win the business](../../../vertical-marketing-strategy-for-managed-service-providers-ad59147bf6c0). Maybe it is a niche for you to consider if you already have the required talent and the expertise. --- ## Who do I sell to? A Quick Tip for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2024-02-29 **URL:** https://mspnotes.com/who-do-i-sell-to-a-quick-tip-for-managed-service-providers **Tags:** Business, Ideas A managed service provider is looking at a mid-size business in their area and considering offering their services. The service provider sees a good match — as the business works in the same vertical where the service provider has vast experience. The service provider has a lot to offer and can reduce costs and increase the productivity of the business’s employees, yet… all conversations with people from the business lead nowhere. It looks like the business is just not interested in any savings, any productivity increase or making more money… sounds surprising, yet it is a common situation because the service provider is not talking to the right person. ## **Finding your champion** To sell into a somewhat sizable business, it is important to find the person who will be the champion for you, and that champion will directly benefit from the partnership with the managed service provider. To find the champion, consider who will benefit from the services the MSP provides earlier than others. It takes time to see the impact of increased reliability and accelerated issue resolution. Yet, the impact of new business systems is visible immediately. > I can share a story here. An MSP replacing the old, slow file server with OneDrive and Microsoft 365 helps the team collaborate on proposals. Since COVID, they work from home and have to edit the same document together during a call or take turns editing the files. It leads to multiple files named something like Customer_Proposal_v123 piling up on the file server, and sometimes people publish versions simultaneously and need to merge the changes manually. Implementation of Microsoft 365 leads to real-time collaboration on documents. No more “version hell” and a lot of time saved. After hearing what MSPs offered them, the team working on proposals immediately started to pressure the CEO to employ the MSP. It is important to note here that the most active champion is the person or the team that is getting the benefits now. Promises to deliver something over a long time do not have the same effect, as people think they may not be in the roles they are in over that time or don’t feel it is important enough to invest their energy. ## **How do we discover the scenarios to sell?** Start by talking to your existing customers. Ask them what they use daily and when they save the most time and effort. Find those who love the service and understand what they did not like before or why they love the service. Then, look for similar scenarios in new accounts. Almost nobody will provide useful information if you ask them, “What is your pain?” or something like that. However, if you start with something specific like “I guess you are spending a lot of time collaborating on documents,” you will frame the thinking of the person you are interviewing. Also, making a statement drives them to argue with you and share more information in the process. They may not have a collaboration issue, but sending large files over the network is an issue. Or the issue may be restricting access to confidential documents. Whatever it is, start by showing that you know their scenarios. Be very specific, talking about their business process and the tools they use. --- ## Metrics for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2024-02-15 **URL:** https://mspnotes.com/metrics-for-managed-service-providers **Tags:** Business, Technology In a famous experiment, people are asked to slow down or speed up their heart rate using breathing techniques, and those who are provided with real-time data on their heart rate can do it much easier than those who have to rely only on their feelings. To understand, control and improve anything, we need to be able to measure it first. We can effectively influence what we can measure. Yet, many smaller MSP businesses have very few metrics defined and measured. In this post, I will list metrics many successful MSPs find useful, grouping them into three categories — operational, technology, and financial. ## **Operational metrics** This group of metrics is helpful in understanding the capacity and performance of an MSP business and forecasting the ability of the team to handle more workload as the business grows, with reasonable degradation of the quality of the services. - **Ticket volume**. Data measured and reported per time and per client. It is important to monitor trends in the volume as those can indicate degradation of the IT infrastructure or the impact of mismanaged updates and patches. Volume per client and trends per client allow MSPs to understand if there are specific customers experiencing a high volume of issues. Client ticket volume can also help identify non-profitable customers that may have to be discontinued. - **Response time**.** **Average time to respond to a ticket and comments from the customers. In practice, quite frequently, this is the most impactful metric for the customer’s perception of the service quality. For larger MSPs with a variety of customers and types of tickets, it may be sensible to measure ticket response time based on the severity of the issue or priority of the customer, frequently defined by the contractual SLA on the response and resolution. - **Resolution time.** Average time to resolve the issue since it was reported. Issues should be grouped in similar types and severity to make sense of the metric. - **Service Level Agreement violations**. The** **measure of how many times SLAs on response time and resolution time were violated. It is important to measure the metric by customer and technician to understand the risks for customer churn and technician performance degradation. - **Customer Satisfaction**.** **Few MSPs focus on measuring satisfaction now; however, surveys started to be implemented more often in recent years after the ticket is closed, and technicians are offered bonuses based on the trends of improving customer satisfaction. ## **Technology metrics** This group of metrics is useful to evaluate the performance of the technology stack and infrastructure, spot degradation before it becomes an issue, and analyze the impact of the implementation of new tools on the overall performance. - **Uptime**. Uptime of servers and applications critical for MSP and the customers. Incidents, patches and maintenance impact the uptime. The decline in uptime metrics may indicate that technicians have to spend more time on maintenance, and it is time to upgrade the infrastructure and consider implementing new tools or automation. - **Update success rate.** This metric serves as an early indication of the potential volume of tickets related to updates of operating systems, applications and MSP tools. Failed updates lead to security vulnerabilities, ticket volume, and additional maintenance time. - **Backup success rate**. Monitoring the frequency and success rates of backups is extremely important, as there is nothing more disappointing than discovering an unusable backup after a major incident at a client’s site. - **Security incidents frequency**. It is important to track all types of incidents, including false positives. A growing number of security incidents may indicate the need to review the security architecture and implement additional measures. Growing false positives that usually annoy customers and technicians indicate that it may be time to consider switching to another security vendor. - **Automation coverage**. Share the scenarios covered with scripts and automation. More sophisticated MSPs measure the number of steps required and time required per technician for routine tasks; however, even simply assessing how many of the usual scenarios are automated and making automation a priority leads to significant long-term improvements in the MSP efficiency and capacity. ## **Financial metrics** Operational and technology metrics are directly connected to efficiency and influence most of the financial metrics. Yet, it is important for a successful business to monitor and optimize the metrics related to customer acquisition and retention besides looking only at the revenue and expenses. - **Revenue**. It is important to measure revenue per client and trends over time and understand the structure of both revenue and expenses. Revenue from long-term and short-term contracts, revenue from on-time jobs, revenue from direct customers and from sub-contracts. Knowing the structure allows MSPs to understand and forecast their income. - **Expenses**.** **Expenses per employee, expenses per client, technology expenses per vendor, one-time payments, short-term and long-term agreements, and lease payments. All of it is important to understand the cash flow and avoid getting into a situation when an MSP has to pay expenses now while revenues from the customers are coming in the future, leading to business loans and paying interest on the loans. - **Recurrent revenue **(monthly — MRR or annual — ARR). Recurrent revenue is so important that I put it as a separate line here. Recurrent revenue comes from long-term contracts and is committed by the customers. Recurrent one-time jobs for customers, even if those are coming in steadily, are not recurrent revenue and can be tricky for long-term planning. - **Customer lifetime value (LTV)**. For MSPs that have been in business for multiple years, it makes sense to track the average time customers spend with the MSP and the average value they bring per year to understand the value of each new client MSP acquires. - **Customer acquisition cost (CAC). **Understanding the** **sales and marketing costs required to acquire a new customer is crucial to drive business growth. Knowing the LTV and cash flow of the business, MSPs can estimate the amount of money they can invest in sales and marketing. Calculating CAC per the activity MSPs do to acquire customers — offline and online events, digital ads, marketing agencies, offline ads — helps guide marketing efforts and focus on the channels that deliver profitable customer acquisition. - **Sales cycle length**. The time it takes to sign up a new customer since the beginning of the negotiations allows MSPs to predict how quickly the business can generate revenue from sales and marketing activities. It is extremely important for MSPs with low margins to know how quickly they can replace a customer after losing one. - **Customer churn**.** **How frequently and quickly customers churn is important for predicting revenues and planning sales and marketing activities. - **Employee churn cost**. The metric is sensible for larger MSPs, yet many don’t pay enough attention to it. Knowing the cost of recruiting and replacing an employee allows one to make business decisions when the competition or corporations are pouching employees. For smaller businesses, some owners try to retain everybody, while others look only at the average cost of the employees. Yet, the cynical view of comparing the employees’ compensation to the market and the costs of recruitment and onboarding to the expense of retaining employees makes business decisions easier. Of course, this is not a comprehensive list of metrics for MSPs, yet it may be a good start for an MSP owner just starting up the business or for MSPs who are looking into optimizing operational efficiency. Many MSP businesses have owners who want to exit by selling their MSP to a larger competitor or private equity. The acquirers will be interested in metrics, and having current numbers and historical data may be extremely helpful in increasing the business’s value. --- ## Managed Service Providers Selling Drills, While Business Owners Buy Holes **Author:** Gaidar Magdanurov | **Published:** 2024-01-30 **URL:** https://mspnotes.com/managed-service-providers-selling-drills-while-business-owners-buy-holes **Tags:** Marketing Many articles about sales and marketing share the famous quote from Harvard professor Theodore Levitt: “People don’t want to buy a quarter-inch drill; they want a quarter-inch hole.” The quote illustrates that people are looking for solutions to their problems, not products. Yet, marketers keep selling drills. Going deep into the details of the way the drill operates. While details may appeal to the professionals, they can quickly imagine how long it will take for them to drill holes knowing the power of the drill; many regular consumers would prefer to see the time it would take to drill a hole in the wall of their house. That is why the iPod had a “thousand songs in your pocket” message for the consumers, while professionals would understand the capacity in GBs at the time. MSPs are notorious for selling their services. Talking about the servers and networks, backup and security agents they will install to make the IT infrastructure reliable. It makes sense for a professional, and it is comfortable for an MSP to discuss it. Yet, for a business owner, it does not make much sense. They care about making sure everything works, and if something does not work — it is being quickly fixed. Only some business owners want to hear the details of the tools MSPs use or the network architecture they will implement. Most will want to know how much it will take to fix broken things, and they want to be assured that things won’t get broken often. Some MSPs tend to oversell their expertise, talking in abbreviations of their certifications, technologies they know, and scripting languages they use. Most of it sounds like gibberish for most of the business owners. “We do the IT so that you can do your business, and we are capable of doing it” — this is what they want to hear. Therefore, an effective pitch starts by talking about the problems that the business owner is facing and explaining the solutions in terms that they understand. The technical details may follow as needed, yet it needs to make more sense to lecture business owners on technology. --- ## Inside SMB Owner’s Mind: Negotiating Managed Services Agreements **Author:** Gaidar Magdanurov | **Published:** 2024-01-15 **URL:** https://mspnotes.com/inside-smb-owners-mind-negotiating-managed-services-agreements **Tags:** Business We discussed negotiating a managed services agreement with an SMB that is looking to switch to another service provider. The MSP was surprised that whatever they were offering was not accepted, while they were offering all the good stuff — improve reliability and security, implement a robust business continuity plan, and refresh the software the business runs. ![](../../../static/img/smb-owner-graph.png) The proposal was an obvious “yes” for the MSP and an obvious “no” for the SMB because they had different views on the proposal. What seems to be a reasonable thing to do for the MSP to deploy more software was just the increase in the technology cost and decrease of margin for the business owner. The business owner wants to increase margin, getting more efficiency from the technology and the new MSP partner for their business — reducing the cost of doing business and the cost of the headcount. Therefore, the negotiation hits the wall. One party suggests decreasing the margin, while the other wants to increase it. The way to unblock it is to go beyond the current state of the business and discuss what can be done on the technology side and which tools relevant to the company can be deployed to increase employee productivity, resulting in business growth. For instance, it is deploying Microsoft 365, improving collaboration and processes, enabling businesses to provide services to more customers and increasing revenue. Or reducing time and administrative overhead and freeing up the time of employees and contractors on hourly rates by deploying applications that automate accounting and billing. It is essential to start by discussing what is important for the business owner — increasing their profits. --- ## Understanding the Managed Service Provider Model: Contracts, Billing, and Services **Author:** Gaidar Magdanurov | **Published:** 2023-12-30 **URL:** https://mspnotes.com/understanding-the-managed-service-provider-model-contracts-billing-and-services **Tags:** Business In summary, the managed services model is a subscription model for IT services. To put it simply, long-term contracts are preferred over one-time jobs. A company that provides IT services on request usually has a price list, including services with fixed fees, like setting up a new machine or reinstalling an operating system on a broken device. For more complicated cases, they charge per hour of work needed to complete the job. This type of service is usually called the “break/fix” model. Any time there are one-time service contracts only, it is a “break/fix” model. Managed services imply a long-term contract. Customers pay a fixed fee for a certain level of service and additional fees on top of their contract. In exchange, they get proactive support for their infrastructure and higher quality of service, as the MSP knows and manages their infrastructure. > The primary differences between management services and break/fix models are proactive management and long-term contracts. ## **Break/fix model** The break/fix model is easy to implement, and many MSPs start with that model. One or a few IT professionals get fed up with corporate jobs and start their own business. They publish ads in the local newspapers and social media groups, promote their services via friends and family, and start helping people on a one-time basis. They only need basic IT skills and prices that local business owners and residential customers will pay. The model is highly unpredictable. Sometimes, the demand for IT services spikes (thinking migration from Windows 10 to Windows 11), and sometimes, it dies down with economic fluctuations, changes in the demand from the local business, or competitive pressure with a rival computer shop offering break/fix services at a lower price. There are no long-term customer relationships, and switching service providers is easy for them. ## **Managed services model** The managed services model is predictable if adequately implemented. Long-term contracts guarantee a certain income level, and MSPs can estimate their margins, given that they know their costs. It also allows them to scale their business with a limited number of IT technicians. As they manage their customers’ infrastructure, they can set up the tools they need to manage it remotely and set up backup and security solutions to prevent incidents and decrease the workload for handling the issues. Given the long-term relationships, the MSPs can become trusted advisors for business owners and help them increase efficiency using modern IT solutions, increasing the value of their services, charging higher prices and getting higher margins. The managed services model is more challenging to establish, requiring capacity planning. There are multiple questions to answer: - Given the existing resources, how many customers and incidents can the MSP handle? - What service level agreements (SLAs) can they provide when responding and resolving issues? - How can they maximize their margins by lowering the cost of people or technology and increasing the value of contracts? - What is the plan to increase capacity in case of a peak workload? - Do they use subcontractors for services outside of the area of their primary expertise? For instance, many MSPs outsource security and physical network installation. However, even given the more complicated planning required, the MSP model allows for a stable business that can scale. The break/fix model is unpredictable and hard to scale, and scaling break/fix almost always requires hiring more technicians, who have been in high demand and low availability for the last few decades at least. ## **Contracts in the managed services model** Most MSPs support multiple contract options based on customer requirements: monthly, annual, and multi-annual (usually two or three years). Longer-term agreements are more predictable, but many customers prefer not to commit to long-term agreements. Thus, MSPs have to maintain a mix of different contract types. Higher maturity MSPs usually don’t offer contracts under one year. Multi-year contracts are a good negotiation tool when customers try to lower the monthly payment; an option is to offer a monthly payment with a longer-term agreement. Many MSPs prefer to trade margins for predictability, planning to increase margins with growing efficiency. Frequently, contracts also include onboarding and offboarding fees that cover the expenses of MSPs to take over the customer infrastructure or transition the customer to the new MSPs. Onboarding fees are usually waived for long-term agreements and serve as a tool to negotiate an annual contract instead of a monthly contract. Offboarding fees are often replaced with a 30-day notice for termination requirements, allowing MSPs to execute the transition while still being paid by the customer they are offboarding. ## **Pricing in the managed services model** There is a great variety of pricing options used by MSPs. In general, most MSPs estimate their costs and add a margin on top of it; however, the way the price is calculated for the end customer may differ, and it may depend on the customer, on local practice, or on the way MSPs sell their services to the customers. The most popular models are per device and per-user payment, and less popular models are per hour and per incident. In the per-device model, a price is assigned per device under management. It may vary between types of devices (workstation, laptop, server, printer) or maybe a flat fee per device under management. In the per-user model, it is either the total number of users — employees of the company or the number of users using the IT infrastructure daily. For instance, in a store with three shifts per day, it would be tough to charge per employee while only about a third of the staff is on duty at the same time. Per-incident and per-hour models usually include a minimum monthly fee under the contract, including a certain number of incidents or hours, and everything on top of that is charged according to the price. Models can be mixed. Monthly payment is calculated based on the number of devices or users; however, the pricing is calculated hourly for non-standard situations not covered by the monthly fee. ## **Pricing tiers** Some MSPs include everything in their per-user or per-device pricing, and some add additional charges for software, consumption of services and cloud storage as separate lines on the monthly invoice. Those that include everything into one monthly payment usually offer options for the customers for the level of service they receive — tiers. It allows them to offer additional tools and higher quality of service while maintaining their target margin. The tiers may differ by the SLAs on response and resolution time or by the services included and usually follow the “Good — Better — Best” pattern. One example could be the Silver, Gold and Platinum tiers of one friendly MSP I know. Silver includes basic security software, remote management and incident response within 24 hours. Gold includes backup and additional endpoint security software with a 12-hour response SLA. Platinum includes email security, backup for M365 and a 6-hour response SLA. Some MSPs may offer local backup only in the lower tiers and cloud backup in addition to the local backup in the higher tiers. Another example is a lower tier including antivirus only and a higher tier including EDR solution. ## **Services** The core services that most MSPs provide are remote infrastructure management (computers, servers, network), data backup and security. At a fundamental level, MSPs can use free tools to provide services, such as remote desktops for remote access, built-in backup, and antivirus software for backup and security. However, as MSPs scale operations, the basic tools are not enough, and they transition to professional solutions for MSPs, jointly with the expansion of the portfolio of their services. As MSPs grow their portfolio of services, they offer proactive infrastructure management, driving hardware and software upgrades and advising customers on how to increase their IT productivity. Successful MSPs grow from the “break/fix” shop to the “trusted advisor” when they deliver measurable value to their customers’ businesses. ## **Business Automation** At any reasonable scale, MSPs need automation for their operations, starting with the basic need to receive and track customer requests in a **ticketing system**. Tracking requests and the time spent on them allows MSPs to better plan capacity, identify problematic customers and implement solutions that decrease ticket volume. Without a ticketing system, it is next to impossible to understand the performance of employees and the cost of maintenance of each customer. The other important parts of automation are **contract management and billings**. While smaller MSPs use Excel spreadsheets or accounting software to calculate monthly bills at any reasonable scale, it becomes hardly manageable and time-consuming. Not to mention that time spent on back-office operations takes away time that could be spent managing customers or selling services to new customers. A good billing solution would track contracts and expiration, time and incidents, and calculate and issue invoices with minimum time spent by the MSP. The third piece of automation is a **Customer Relationship Management** (CRM) system to track customer interactions. Having solid customer data helps successful MSPs to upsell additional services or upgrade customers to higher offering tiers, as well as to prevent churn of customers by building stronger relationships and acting as trusted advisors to the business. CRM is also extremely important for recruiting new customers — collecting information on prospects in one place and acting on it promptly is necessary to sign up new customers continuously. An MSP business that cannot recruit customers risks getting shut down, as the existing customers can churn for various reasons. ## **Conclusions** The managed services model benefits both the customer and MSP. The customer gets reliable and cost-effective IT services. The MSP gets predictable revenue and the opportunity to provide proactive maintenance to increase the reliability of the infrastructure while decreasing their maintenance cost — resulting in a growth in their margin. --- ## Boosting MSP Productivity by Reducing Tool Overload **Author:** Gaidar Magdanurov | **Published:** 2023-12-15 **URL:** https://mspnotes.com/boosting-msp-productivity-by-reducing-tool-overload **Tags:** Technology A typical MSP technician works with dozens of different tools every day. Most technicians create routines and checklists and automate their work as much as possible, yet if they take a quick break to think about the amount of time they spend dealing with various tools, they may be dismayed. Instead of productive time doing something useful for the company or just having some free time to have fun, they are spending cycles on updating, configuring, verifying, diagnosing, and fixing a wide variety of software. ## **Understanding Tool Overload** To name a few tools in the MSP toolbox, remote monitoring and management tools, antivirus, firewall, backup, help desk system, service automation system, and a variety of productivity and collaboration tools like Microsoft 365 or Slack. There are multiple studies of [context switching](https://www.techsmith.com/blog/context-switching/) being a productivity killer. A technician has to change context multiple times daily, depending on their task. Switching between tools is not only a risk to productivity, but it can also lead to numerous mistakes, ranging from misconfiguration, which can lead to performance issues for customers, like running all backups of all systems at the same time, to critical configuration failures, which can lead to customers going offline and forcing technicians to go on-site to fix the problem. We are all human; we all make mistakes. I still remember when I was supporting a bunch of small companies as an MSP back in my university days. I had to come to fix a server that went down because somebody with root privileges ran “rm -r” in the wrong folder. By the way, the memory is painful, as the company used a tape device to back up, and neither their IT guy nor I could get the backups working. Multiple tools with different UI, policies, and design philosophies increase the “surface of the possibility of a mistake.” Not to mention, a significant tool update requires going through training or reading the documentation. Therefore, comes “tool overload.” This is a state that is not realized by many. They are getting used to dealing with multiple tools and don’t see how much time they spend and how many avoidable mistakes they make. ## **Reducing Tool Overload** There are many ways to do it, and most MSPs start with automation and standardization. Whatever is possible to automate with scripts is automated. What is impossible or too complicated to automate is put into checklists and standard operating procedures (SOP) documents and forced on technicians to follow. > Automation is excellent and extremely important to stay competitive in the MSP market as customers’ infrastructure grows fast. MSPs need to catch up by being able to manage more workloads. However, automation has one serious risk — the wrong script run on multiple workloads quickly creates a lot of damage. Therefore, automation should be tested in sandboxes and monitored in a production environment. Having various tools to automate leads… You guessed it right: more chances to fail and more complicated scripting. Yet again, tool overload plays a nasty role in making automation cumbersome and less reliable. Thus, the solution that goes hand in hand with automation — reducing the number of separate tools, choosing integrated tools or using integrations. The most effective integrated solution would offer the same UI for various devices, the same policies, the same configuration, preferably one agent, and a standardized interface for scripting and automation. Getting on the path of reducing tools and simplifying business processes for most of the MSPs I was talking to led to building their own technology stack and getting to a higher [operational maturity level](../../../msp-maturity-and-scalability/). ## **Evaluating the benefits** Before taking on the endeavor of replacing the familiar tool with something else that would allow for the reduction of tool overload, it is important to define the metrics of success and set reasonable goals for the project. Here are a few metrics that MSPs use to evaluate the success of the project: 1. **Time waste reduction**. Measuring the time technicians spend before and after implementing new tools and integrations. Some MSPs prefer to measure time per ticket; some measure the total time spent between different tasks — handling customer tickets, onboarding new customers, and performing regular maintenance. Some MSPs go even deeper and classify the types of tickets and look at the time reduction for different kinds of tickets — like backup and recovery, security incidents, network issues, and performance incidents. 2. **Reduction of mistakes**.** **Measuring** **the** **number of issues or time spent resolving problems caused by human error may be challenging, and many MSPs do it based on the expert evaluation or tracking activities of technicians for a few days before and after the implementation of new tools. 3. **Reduction of training time**. This one is huge for growing MSPs and MSPs with a high churn of employees. Reduction in training time due to consolidation of tools allows to scale faster by hiring new employees and hiring junior technicians right out of college (who are we kidding, there are not enough IT pros anymore, and MSPs higher right of high school…). Another hidden benefit of standardization, integration and reducing the number of tools used is having more “generalists”—technicians capable of executing various tasks. Instead of having “a backup guy” and “a security guy,” MSPs can have people able to handle a more extensive scope of functions, reducing the wait time to get an expert allocated in case of a customer issue. ## **Executing tool overload reduction** I hope you are convinced now that reducing the number of tools is good; let’s look at how many MSPs execute it. Based on numerous conversations, the process that works for the most looks like this: - **Audit the tools you use**. Start by listing everything a technician does and when they use the tools. Then, estimate the time it takes for them. - **Identify redundancies**. Look for the tools that could be integrated or managed together. Review the vendors with the integrated tools available, and check if their integrated solutions can replace your technicians’ tools. - **Prioritize**. Based on the time spent and issues raised because of various tools, prioritize which devices should be replaced on integrated first. Often, replacing everything at once makes little sense, as the overhead and cost are prohibitive. Based on the experience of others, the first candidates are backup and security. - **Test**.** **Implement the tools in a subset of the infrastructure and test how it works with your customers before rolling it out to everybody. - **Educate**.** **After the choice is made, educate the team. Get vendor certifications. Build a checklist to verify the technicians’ competence to handle new tools. - **Deploy**.** **Roll is out to all customers. The faster customers access standardized infrastructure, the faster you realize the benefits and see the improvements. If you have been in the managed service business for a while, chances are high that you suffer from tool overload without even suspecting it. It is easy to overlook, as you see your technicians busy, customers happy, and everything seems fine. However, if you look into it, you will realize there is an opportunity to reduce mistakes, reduce overhead, and increase capacity to onboard and maintain more customers if you lessen the tool overload. --- ## Vertical Marketing Strategy for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2023-11-30 **URL:** https://mspnotes.com/vertical-marketing-strategy-for-managed-service-providers **Tags:** Business, Ideas In the post about [bringing value to the customers](../../../positioning-the-value-of-managed-services-to-prospects-and-customers/), I mentioned the need to define the customers and focus on them. This is important for designing the best services that fit the customer needs, and it is crucial to stand out from the crowd of competitors as experts in the areas essential for your target group of customers. The target groups are most likely specific industries, also known as [vertical markets](https://www.techtarget.com/searchitchannel/definition/vertical-market); therefore, we are discussing vertical marketing strategy. Let’s start with a simple example. If you want to fix your iPhone, would you rather go to a company specializing in “electronics repair” or an “expert in iPhone repairs”? If your eye hurts, would you go to the general practitioner, or would you instead go to an eye doctor? I hope the analogy is clear. Being a specialist in a particular problem or offering specialized service helps to differentiate your offering from the competition. **Marketing to a vertical** Let’s examine what is needed to market to a specific segment of customers and then review an example. - **Solutions tailored for the vertical**. The offering should be built based on the needs of the companies working in a specific industry — support for specialized applications, packaging of the services and service level agreements (SLAs). - **Pitch tailored for the vertical**. It is essential to use the language that the people working in the industry use. Know the major vendors. Know the scenarios. Know their pain points with their IT systems and how to solve them. To be convincing, it is crucial to sound like somebody who works in the industry. - **Credentials**. You need more than just claiming you are an expert and speaking like one. You can watch an excellent[ movie about Frank](https://www.imdb.com/title/tt0264464/), a skilled forger who has passed as a doctor, lawyer and pilot. Customers want to be reassured they are making the right choice of partner for their business. Therefore, certifications and customer stories are essential. General IT and specialized IT training and certification for the technicians and required compliance certifications for the company (like HIPAA, for example) can be a start. As the practice grows, the success stories of other customers in the industry are adding additional credibility. - **Marketing and branding**. The website, the social media, and the ads you post should not be controversial, with the image of an expert in one or a few industries you are trying to build. The vertical defines where and how to advertise what images and texts are appropriate and well-accepted. Look at every asset you produce or request from a marketing agency to be aligned with your target audience. - **Content interesting for your vertical**. The best marketing tools are the articles, videos, recorded and live webinars discussing the IT challenges in your chosen vertical and how they can be resolved. Paradoxically, the more educational the assets are, and the less they talk about your expertise and services, the better they are accepted and build the trust of your potential customers towards you. - **Participation in the relevant events and communities**. Joining industry communities and attending industry events is necessary to continuously learn about the vertical and showcase your story to potential customers. The vertical marketing strategy requires a lot of research — interviewing prospects and customers, reading specialized resources, and following relevant influencers and industry news. **Dental practice — an example of a vertical** An MSP willing to support dental practices needs to know what those dental practices use and what they expect from MSPs. Let’s look at a few examples. - **Specialized software for dental practice**. Management system for the practice like Dentrix. Software to manage instruments used in the practice, like imaging solutions by Dexis. - **Specialized software for healthcare providers**. Electronic medical records solution and patient portal, like Epic. Telemedicine software like Spruce. - **Generic business software**. Accounting, like QuickBooks. Productivity and communication software, like Microsoft 365. CRM, if not covered by the practice management system. And other systems, like inventory management, compliance management, backup and recovery, and security. - **Compliance**. Industry requirements, like HIPAA. Data retention and clean-up are generally a headache for every business, and healthcare practices are even more complicated. Those are a few examples of what could be a differentiator for the dental practice vertical, which should give a general idea of the direction for developing the vertical strategy. Implementation of a vertical strategy takes time and requires continuous reviews and adjustments to be a strong differentiator against competition. And one of the best sources of information is the existing customers from the vertical. A strong feedback loop is essential to stay up-to-date with what is going on in the industry. --- ## Game On: The Cutthroat World of Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2023-10-30 **URL:** https://mspnotes.com/game-on-the-cutthroat-world-of-managed-service-providers **Tags:** Business, Ideas Let’s admit a hard truth: MSPs are not good at getting new customers. Many only do prospecting once they have to replace a churned customer in their portfolio. Many are not keeping up with maintaining their CRM, not doing events, not investing in advertising — doing nothing, just waiting for good referrals. Sometimes referrals come, sometimes don’t… Yet, new MSPs are constantly appearing, and they need to get customers. They start by offering lower prices or better service portfolios and, eventually, win over customers from older MSPs. The competition is pressuring older MSPs, and they must [compete on their services’ value.](../../../pricing-for-managed-service-providers/) However, I am hearing more and more often from MSPs that whatever services they offer, their competition quickly copies what they offer. Thus, they are reluctant to advertise what they offer, slowly updating their websites, preferring to “sell” value in direct conversations with the prospects. Yet, prospects are not running to the MSPs’ doors to listen to the pitch, as they don’t see a reason to do it — as everyone in the area offers the same. At least, it looks like from whatever one can find online… So, what if whatever you offer will be copied by the competition? There is only one sensible solution — don’t worry about it and keep changing, keep improving your service, and be better at what you do. Accept that those services you launch and the SLAs you offer will be copied. So, it is not your current portfolio of services that allows you to compete — it is the continuous change and improvement. Looking after the trends and future needs and offering what the customers in your area will need is the solution. Even if the competitors copy it, they will play a catch-up game with you. Therefore, successful competition is about competing on “future value” rather than the value everybody can deliver today. Being an innovative MSP in your area will set you apart from the competitors. Of course, it is not easy and requires time for research, updating your strategy, and delivering services to your customers. Yet, it is time well spent if it allows you to offer new services to your customers and prospects. --- ## Rebranding for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2023-10-15 **URL:** https://mspnotes.com/rebranding-for-managed-service-providers **Tags:** Business, Marketing Why would somebody even care about the brand of a managed service provider? Do customers remember “the IT guy that comes, then things don’t work”? It may not make much sense when the “IT guy” is the brand. People know the person, rely on what they can do, and sign up for their services. Yet, it may be necessary if a company is established, has a name and reputation, and tries to change its direction. Various market studies from IT Glue and Acronis show that over 70% of MSP businesses are over six years old. This means the companies have some history, established reputation and customer base. And for many, customer referral is the most effective way of acquiring new business. However, for the established customers, there is a clear connection between what the MSP does and what services they receive, and they talk about their experience with their peers. When an MSP tries to offer new services — for example, [managed security practice](https://www.forbes.com/sites/forbesbusinesscouncil/2023/08/22/crafting-a-winning-cybersecurity-practice-for-your-msp/), it may be brushed aside by the existing customers, who may not be willing to increase their bills or don’t believe they need the service, and MSPs have to revert to marketing to promote their services to new customers. And here, it may be the time to consider rebranding, to disassociate the old knowledge about their business from the new things they are trying to build. There is usually a negligible risk, as existing customers won’t go away just because of the name change. Referral is still the primary channel, yet there is an opportunity to get those who knew the old brand and associated it with a set of services to consider new services — just because they will hear a different name. Not to mention, buying security services from “Your Neighborhood Backup Guy” may not look like a great idea. At the same time, “The Security Expert in Your Town” may sound more appropriate to potential customers. Another example is if an MSP changes focus from dental clinics to retail, the name “Dentists’ Favorite IT Guy” may not be the best anymore. Rebranding may be a good idea if there is a strategy change or an opportunity to expand the services offered to another market segment or provide new types of services. If the answer to the question “Will it bring value to the business?” is a definite “yes,” it makes sense. However, for many business owners, even considering rebranding is a daunting task — not clear what to do, how to do it, and the old brand is so dear to their heart, and they still have that first t-shirt they made with the company name somewhere around the house. ## **Checklist for rebranding** It is easier than it seems, and only some things should be addressed immediately. Below is the checklist of the simple steps to plan and execute a rebranding: - Come us with a **new name**. ChatGPT can be of help here to brainstorm and research with you. - Register a domain for the new name. One of the criteria for the name is the availability of a **domain name**. Searching for domain zones may be an option to get the domain name you like. - Hire a designer or use an online service to design the **new logo, business card and website template** (or color guide). With this minimum set of material, the next steps can be executed. - **Brief employees** about the rebranding and that they should look for all mentions of the old brand and implement the new one every time they see the old logo. It is hard for some internal systems, external services, and social media to cover everything at once, so updates will be gradual. TSA’s “See something, say something” phrase works well here. When employees see the old logo or name, they replace it. - Build a **website** and host it with the new domain. A website builder is a simple and cost-efficient solution. Picking a template and adjusting the color scheme to match the brand may be enough for the initial launch. - Create **new content **for the website. ChatGPT is again helpful in creating and editing drafts of the pages. - Configure **email** and **helpdesk** for both old and new domains or set up forwarding. - Update **email signatures**. It is a step easy to overlook, yet it is something that many customers will see. - Optionally, print **t-shirts, caps**, **and cups** with the new logo. The easiest way to get the new logo out there is to brand the team — giving them wearables. - Update the **logo on the vehicles** used. If you don’t have a logo on the cars you use, consider adding it, especially if you have long drives to customers. - Create new **social media accounts** or rename existing ones, referencing the old name in the brackets, so old users won’t be surprised when they see the new name in their social media feed. - Send an **email** and a nice **postcard** to your customers and partners, informing them about the name change and sharing a few words about what you did with your strategy or product portfolio. Rebranding may seem scary, yet it is a simple procedure. A bit of patience and a bit of time spent on replacing the old logo and name, and it is done. --- ## Pricing for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2023-09-30 **URL:** https://mspnotes.com/pricing-for-managed-service-providers **Tags:** Business New MSPs are frequently obsessed with learning of the prices other MSPs on the market charge. Quite often, they try to compete on price — offering the same package of services to the same customer segments at lower prices than others. This path leads to nowhere. Margins are getting smaller (and there is already [a lot of pressure on margins](../../../profit-challenges-for-managed-service-providers/)), competition responds with matching prices, and everybody loses in the end. While working at Microsoft with hosting providers, I have seen the same situation unfold in the web hosting market, helping them sell more services on the Windows platform. Initially, pricing competition caused hosters to lose money on lower tiers of shared hosting plans and small virtual private server (VPS) instances, making money only on larger VPS and physical server hosting. After some time, most of the smaller players were pushed out of business, acquired by larger players, or introduced additional services, making web hosting a way to acquire customers while making money by offering a variety of add-ons. Knowing the market and competitive pricing is useful. However, fixation on pricing only eventually leads to huge issues with the business. Effective price is based on the value that MSP delivers to their customers. There is a massive opportunity for differentiation based on the variety of services, technology stack, and service level agreements (SLAs). At the end of the day, the best MSP customers are looking for a reliable IT partner, not for the lowest price. The pricing strategy I suggest to MSPs is to calculate backward from their target profit. They target the profit, estimate the profit margin, and then estimate the pricing and number of customers needed to achieve the target profit. They evaluate how realistic the goal is regarding the number of customers and estimate the service offering that would allow them to provide the level of service they need. When competition attacks you on price, you can respond by comparing the value of services and the cost of transitioning from a trusted partner to a partner offering a lower price. ## **Key takeaways** - Price is based on value, not competition. - Design prices based on profit margin target. - Compete on the services’ value, not the price. --- ## Practical Market Research Trick for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2023-09-15 **URL:** https://mspnotes.com/practical-market-research-trick-for-managed-service-providers **Tags:** Business, Marketing The primary struggle for smaller MSPs is acquiring new customers. Sales and marketing activities are outside the “technology” scope, and hiring an agency or dedicated salespeople is expensive. Therefore, the owners of MSPs serve as sales and marketing leaders for their firms. MSPs are facing the question of what to offer to whom and how, which requires researching the local market where they offer their services. It can be time-consuming and complicated to understand the local needs and who the buyers of managed services in the area are. Common issues with market research are related to various cognitive biases and the desire to see things that may not be like they seem. Coming to the market with the idea that types of businesses should have a higher demand for managed services — for example, healthcare — may lead to focusing on the healthcare professionals in the area who are not even looking for managed services. There is one nasty trick that can be done for the market research that many software startups employ. Instead of researching the market, research the successful competitors in the market. What do they sell? To whom? How? Analyzing websites and advertisements of successful local MSPs, attending the same events, and joining the same business associations could help understand the offerings already working in the market. And then offer a better service, extended service, or recruit those customers who are not yet using those services. ## Step-by-Step Competitor Analysis You do not need an MBA or a marketing budget. You need a browser, a spreadsheet, and a few hours of honest work. ### Step 1: Build Your Competitor List Start by identifying every MSP operating in your geographic market. This is easier than it sounds: - **Google it.** Search for "managed service provider [your city]," "IT support [your city]," "cybersecurity services [your city]," and similar variations. Go at least five pages deep --- most people stop at the first page, which means they only see the competitors who are already winning at SEO. - **Check Google Maps.** The local pack results often surface smaller players that do not rank organically. - **Search industry directories.** Look at listings on sites like Clutch, UpCity, and the Better Business Bureau. Channel partner directories from vendors like Microsoft, Datto, or ConnectWise often list local partners. - **Ask around.** Talk to vendors, distributors, and colleagues at peer groups. They know who is operating in your area, including the ones with no web presence at all. Aim for at least 10 to 15 competitors. If you are in a smaller market, you may find fewer. If you are in a major metro, you could easily find 50 or more - in that case, focus on the ones targeting a similar customer size and vertical to your own. ### Step 2: Analyze Their Websites Systematically This is where the real intelligence comes from. For each competitor, work through the following checklist: - **Services offered.** What is on their services page? Do they lead with cybersecurity, cloud migration, co-managed IT, or traditional break-fix? The services they promote most prominently are likely their best sellers. Pay attention to what is conspicuously absent, too - gaps in their offerings are your opportunities. - **Target customer.** Who are they talking to? Look at their case studies, testimonials, and industry-specific landing pages. If three of your competitors have dedicated pages for dental offices, that tells you something about local demand. If none of them mention manufacturing, that might be an underserved niche or a dead end - you will need to investigate further. - **Pricing signals.** Most MSPs do not publish pricing, but many give clues. "Starting at $X per user per month," package tier names, or even the absence of pricing (which often signals enterprise-level or premium positioning) all tell you something. Look at whether they sell per-device, per-user, or all-inclusive bundles. - **Social proof.** Read their testimonials and case studies carefully. What types of businesses are quoted? What problems did those businesses have before switching? What outcomes do they highlight? This is market research handed to you on a silver platter - these are real customers describing real needs in their own words. - **Team size and capabilities.** Their "About Us" and "Team" pages reveal headcount, certifications, and partnerships. A competitor with 50 employees and a SOC is playing a different game than a three-person shop. - **Content and thought leadership.** What do they blog about? What webinars do they run? The topics they invest content in are the topics generating leads for them. If every competitor is producing content about compliance, your market cares about compliance. ### Step 3: Use Digital Intelligence Tools You do not have to stop at what is visible on their website. Several tools, many with free tiers, let you peek behind the curtain: - **SpyFu** (from $39/month) is built specifically for competitor analysis. Enter a competitor's domain and you can see which keywords they are bidding on in Google Ads, which organic keywords they rank for, and how their strategy has evolved over time. SpyFu maintains over 15 years of historical keyword data, so you can spot trends. If a competitor recently started bidding on "HIPAA compliance managed services," they are probably seeing demand there. - **SEMrush** (from $139.95/month) is the broader platform. Beyond keyword data, it provides backlink analysis, traffic estimates, and AI-powered competitive gap analysis that highlights opportunities your competitors are missing. The free tier gives you limited but still useful access. - **SimilarWeb** (free tier available) estimates total website visits, traffic sources, and audience demographics. Useful for quickly sizing up which competitors are actually generating web traffic versus those with nice-looking sites that nobody visits. - **Google Alerts** (free) lets you set up email notifications whenever a competitor is mentioned online. Set alerts for each competitor's company name, their key employees, and relevant industry terms. This runs on autopilot and surfaces news, press releases, and blog mentions you would otherwise miss. - **Ubersuggest** (free tier available) offers site audits and keyword tracking that can help you understand what content strategies are working for your competitors. - Step 4: Go Beyond the Website The internet only tells part of the story. The rest comes from showing up: - **Attend the same events.** If your competitors are sponsoring the local chamber of commerce luncheon or presenting at a business association meeting, show up. You will learn who they are targeting, what message resonates, and who their prospects are. More importantly, you will meet the same prospects. - **Join the same associations.** Professional and industry groups --- local chapters of CompTIA, ISACA, or your state's technology council --- put you in the same rooms. But also look at where your competitors show up outside the IT world: construction industry associations, medical practice management groups, financial advisor networks. That reveals their vertical focus. - **Monitor their hiring.** Job postings reveal strategy. If a competitor is hiring a vCISO, they are building out security services. If they are hiring salespeople focused on a specific vertical, they are expanding into that market. LinkedIn and Indeed make this easy to track. - **Talk to their former customers.** This requires tact, but prospects who switched away from a competitor will often tell you exactly what went wrong --- if you ask the right way. Frame it as understanding their needs, not as trashing the competition. ## Research Techniques Beyond Competitor Analysis Competitor analysis is your fastest path to actionable intelligence, but it should not be your only path. Here are additional sources that fill in the gaps: ### Industry Reports and Market Data The managed services market is projected to grow from roughly $424 billion in 2026 to over $1.27 trillion by 2035, with a compound annual growth rate above 12%. More usefully for a local MSP, you can find vertical-specific data showing where spending is concentrated. Reports from sources like Kaseya's MSP Benchmark Survey, Datto's State of the MSP Report, and ConnectWise's IT Nation research provide data on average revenue per endpoint, common service bundles, and pricing benchmarks. Many of these are free in exchange for an email address. ### Census Data for Market Sizing Here is a trick most MSPs have never heard of: the U.S. Census Bureau's **County Business Patterns** dataset provides establishment counts, employment figures, and payroll data broken down by county and 6-digit NAICS code. Want to know how many businesses with 10 to 49 employees exist in your county? How many medical offices, law firms, or manufacturing plants? The data is there, it is free, and it is updated annually. Look for NAICS codes like: - **5415** Computer Systems Design and Related Services (your competitors) - **6211** Offices of Physicians (a common MSP vertical) - **5411** Legal Services (another common vertical) - **2382** Building Equipment Contractors (if you target trades) Pair this with your competitor analysis and you start to see the real picture: how many potential customers exist in your market versus how many competitors are serving them. ### Local Business Associations Your local chamber of commerce, economic development authority, and small business development center are gold mines of market intelligence. They publish reports on local business growth, new business registrations, and industry composition. Many offer free counseling for small businesses, and the counselors often have deep knowledge of the local business landscape. ### Your Own Customer Base Do not overlook the research asset you already have. Interview your current customers: - Why did they choose you? - What other providers did they evaluate? - What services do they wish you offered? - What business challenges keep them up at night? Five honest conversations with existing customers will teach you more about your market than a week of Googling. ## Competitive Intelligence Worksheet To make this practical, here is a template you can adapt into a spreadsheet. Create one row per competitor and fill in these columns: Field What to Record **Company Name** Legal name and DBA **Website URL** Primary site **Estimated Team Size** From About/Team page or LinkedIn **Primary Services** Top 3-5 services promoted **Target Verticals** Industries mentioned in case studies, testimonials, or landing pages **Target Company Size** SMB, mid-market, enterprise - inferred from messaging and pricing **Pricing Signals** Per-user, per-device, bundled; any published rates **Key Differentiator** Their main positioning claim **Certifications/Partnerships** Microsoft, Cisco, SOC 2, etc. **Content Focus** Blog topics, webinar subjects **Ad Keywords** From SpyFu/SEMrush **Web Traffic Estimate** From SimilarWeb **Strengths** What they do well **Weaknesses/Gaps** Missing services, bad reviews, outdated site **Recent Moves** Hiring, acquisitions, new service launches After filling this in for 10 to 15 competitors, patterns will jump out. You will see which verticals are crowded, which are underserved, what the standard service bundle looks like, and where pricing is anchored. ## A Warning About Survivorship Bias Here is the most important caveat in this entire article, and the one most people skip: **you are only studying the survivors.** When you analyze your competitors, you are looking at the MSPs that are still in business. You are not seeing the ones that tried the same services, targeted the same verticals, and failed. This is survivorship bias, and it can lead you badly astray. If five of your competitors focus on healthcare IT and all five appear to be thriving, you might conclude that healthcare is a great market. But what if ten other MSPs tried healthcare in your area over the past five years and went under? You would never know from competitor analysis alone. To guard against this: - **Look for the "dead".** Search for MSPs in your area that have closed, been acquired, or pivoted. The Wayback Machine (web.archive.org) lets you see defunct competitor websites. Old business registrations and dissolved LLC filings are public record in most states. - **Talk to vendors and distributors.** They know which MSPs churned out of their programs and often know why. - **Weight your conclusions by base rates.** If you find that 8 out of 10 surviving competitors target healthcare, but your census data shows only 30 medical offices in your county, the math may not work for another entrant. - **Consider the failures you cannot see.** For every successful service offering you observe, ask yourself: is this working because it is a great market, or because that particular competitor executes well? A service that works for a mature MSP with 20 technicians and deep vendor relationships may not work for you at your current size. Survivorship bias does not mean competitor analysis is useless. It means competitor analysis is the *starting point*, not the final answer. Combine it with census data, industry reports, customer interviews, and your own judgment before making big bets. --- ## MEDDIC Sales Framework for Managed Service Providers **Author:** Gaidar Magdanurov | **Published:** 2023-08-30 **URL:** https://mspnotes.com/meddic-sales-framework-for-managed-service-providers **Tags:** Business Technical people love frameworks. Frameworks make things easier — instead of sitting in front of a blank page and trying to put ideas on paper to develop a format, you follow the guidelines, fill in the blanks and get an actionable result. While MSPs quickly adopt cybersecurity frameworks like NIST, MITRE ATT&CK, and CKC, they are usually not as well-versed in sales frameworks, partially because of the natural tendency of technical people to stay away from sales and marketing and partially because there are multiple frameworks. It is unclear which one to apply to the sales of management services. In this post, I would like to explore a [simplified MEDDIC framework](https://meddicc.com/meddic-sales-qualification-and-frameworks) for lead qualification for MSPs. The framework is designed to simplify the decision to allocate efforts to recruit a customer. Focusing on the “wrong” customer is the number one sales productivity killer. Instead of spending time with those who can become customers, MSPs tend to spend much time trying to convince those who will not be good customers. Given limited time and marketing resources, the wrong focus is an easy way to lose money on sales and marketing and get disappointed. Let’s avoid that by using MEDDIC. The MEDDIC acronym stands for: - Metrics - Economic buyer - Decision criteria - Decision process - Identify pain - Champion Let’s discuss each section and come up with relevant examples from different businesses that can be MSP customers. ## **Metrics** Most MSPs’ customers are driven by the goals they set for their businesses: revenue, cost, and profit margin. Thus, defining the impact of the services provided by MSPs in terms of the metrics valued by the customers makes much more sense than pitching vague benefits like “everything will work fine” or “you will be happy with our service.” Let’s consider a business that requires salespeople to pitch a product and process orders. The company’s profitability directly depends on the productivity of salespeople — the number of orders they can pitch and place during the working day. Their productivity depends on the skills of the salespeople, their training, and the availability of the IT systems they use. Suppose they are on a call with a customer, and the system goes down or performs slowly. In that case, it may result in losing a customer or spending significantly more time with the customer, taking away the time from another customer. Therefore, an MSP can help with Uptime and Performance metrics that directly influence the business. Imagine a salesperson being able to place 10% more orders by making the IT system work faster and with less downtime — that would lead to 10% more revenue for the business using the same resources. An MSP offering to increase sales productivity by 10% would be a much better suitor for a technology partner than an MSP offering to “keep things running.” Therefore, it is crucial to define the types of customers, which metrics an MSP can influence, and what the sales pitch to the customers can be regarding business-specific metrics. ## **Economic buyer** The economic buyer is the person making the decision. For most SMB customers, it is the owner of the business. It is essential to understand which metrics and criteria the buyer uses to decide and appeal to that information, even if the conversation is with a person working for the buyer. Understanding the buyers requires research, and the most valuable resource can be the existing customer base if an MSP already has it. Talking to existing customers allows us to understand the perspective of similar customers and improve the sales pitch. For example, MSP serving dental practices can learn that one way to increase profits for their customers is to offer additional services like producing dental aligners, which may be a priority. From the IT perspective, they need a quick and easy way to place orders with labs making aligners. This requires IT infrastructure to be set up to allow data exchange while maintaining the healthcare industry’s necessary security and privacy standards. Conversing with the prospects while knowing their specific needs and offering them particular solutions goes a long way. If an MSP is expanding to a new market segment or just starting the business, online research, a few visits to SMB meetups and asking prospects out for a coffee may be practical ways to collect the intelligence needed to better understand their needs. ## **Decision criteria** Knowing the metrics and the buyer is crucial to understand the decision criteria. Do they value lower cost, faster implementation speed or higher reliability? Understanding the factors implementing the decision-making process would help to build the most effective pitch. For instance, a law firm partners when choosing an MSP looking for a quick onboarding with minimum downtime and a guarantee of protecting against a critical failure — like a ransomware attack or hackers accessing sensitive information. For that firm, specific details of the implementation and security measures in place are the best pitch from an MSP. For most SMB customers, there are standard decision criteria: - Cost - Time for the implementation - Time for employee training - Risk mitigation - Return on investment As cost is quite often the primary factor, MSPs frequently have to assume the existing infrastructure and licenses already purchased by the customer. That leads to the need to maintain a non-standard technology stack. Yet, pitching to other factors may shift customers’ decision-making to agree to higher costs for additional benefits. If adequately connected to the business metrics, it is possible to convince customers to change their technology stack while moving to a new MSP. ## **Decision process** A typical SMB owner makes decisions after consulting his trusted advisors (like a “classmate that became an IT guru”), looking at his peers in the local community, and relying on their gut feeling. It helps to understand who is impacting the decision and influence those actors as well. A dental practice is considering a new MSP, looking for references from other dental practices, and asking about the metrics the MSP was able to improve for other dental procedures. A local retail chain considers how many engineers live in the vicinity and how long it takes them to get to the store locations. Some owners look for online reviews from businesses in the same industry or exact location, and some owners rely on the advice of their customers or suppliers. ## **Identify pain** MSPs offer a solution to a problem — running IT infrastructure with external IT staff, lowering the cost of managing IT infrastructure, improving reliability and performance, implementing innovation, and improving existing processes. This all sounds good, yet generic words rarely work well. Customers trust specific propositions more than promises of making things better. The successful MSPs can look at the current situation, identify the pain and offer a measurable improvement. For instance, a small online store needs help with slow order processing and losing customers unwilling to wait for the order system to go online. The average order is $50, and the store sees ten customers not finishing daily purchases because of low system performance. Solving the issue will bring $500 a day in sales. A manufacturing company loses thousands each month in employee productivity because employees spend an enormous amount of time recovering accidentally deleted files that require creating tickets with a Helpdesk and offering self-service solutions to free up the time that can be used to produce more goods. A media production company loses hours daily on following up with their customers that have issues receiving large files because of an unreliable network and poor file sync and share solution — an MSP can solve the problem and calculate the improvements in actual costs of the hours saved. A specific pitch increases a customer’s confidence in the partner. Knowing the language and the pains and providing clear guidance and recommendations is a strong competitive advantage for an MSP. Time spent researching the pain points pays over time, yet without it, winning deals from the competition becomes increasingly difficult. ## **Champion** The champion is the person inside the organization who will help the MSP land the customer by advocating for their services. It can be any employee whose voice will be heard by others and the company’s owners. A salesperson struggling to hit their targets because of frequent network downtime can be an extremely active (and even aggressive) advocate of switching to an MSP offering a solution for that problem. An employee familiar with the quality of service the MSP delivers to another customer can be a strong reference for the MSP. One of the best champions for MSPs is the former employees of their customers. When they change jobs and land in companies with less than efficient IT infrastructure, they are happy to advocate for the partner they used to be pleased with. Therefore, keeping a good CRM and tracking the contacts of people changing jobs is a strong sales channel for MSPs. ## **Now, how do I use it?** The MEDDIC framework forces an MSP to do two things — define segments of customers they want to go after and learn more about their customers and prospects. Defining segments requires saying “no” to other types of customers, which may be hard to do. Yet it is a vast sales productivity booster. Going after “random” customers is expensive and rarely productive. The sooner an MSP defines a segment, the sooner they can work on sales productivity. Collecting information about customers and prospects is time-consuming and an investment in itself, yet with defined segments and a good CRM to keep records, it becomes easier and faster over time. The more you sell to a particular feature, the more you learn about their customers—the more effective you become in their sales process. A sales framework is an investment. You must practice, train our team, get your engineers to help you collect the information, and use every opportunity to learn more. However, if done well, it gives good ROI. --- ## MSPs reselling managed services **Author:** Gaidar Magdanurov | **Published:** 2023-08-15 **URL:** https://mspnotes.com/msps-reselling-managed-services **Tags:** Business If you are to listen to most of the MSP owners, they could be better at selling their services. They go to endless local business events, buy ads in local newspapers, put their ads on local bulletin boards, participate in online forums, buy digital ads, use social media, optimize their websites, and… nothing happens. They rarely get new leads and rarely sign up new customers. At the same time, sales and marketing activities take significant time and effort and distract from the cool stuff — deploying and managing technology. At the same time, some MSPs are good at selling. They are technical yet speak the customers’ language and can adjust their pitch on the go and sign up customers. Therefore, there is a profitable model for the MSPs struggling with customer acquisition to discover — partnering with those good at sales. The model works for any MSP; however, it becomes more profitable if the MSP can offer some unique expertise — security and incident mitigation or expertise in specialized software. However, the “reseller” part of the business is even more interesting, as any MSP with solid relationships with its customer base can become a reseller of other MSPs’ services. As long as they can offer new services for the customers and bill them more than the MSP they resell, there is an opportunity to earn additional margin from the services others provide. The most popular services added on top of the basic infrastructure management and helpdesk are: - **Security**. Ranging from deploying and managing EDR solutions to incident mitigation and investigations. - **Cloud services**.** **Offloading infrastructure to the cloud, managing specialized cloud services, and hosting line-of-business applications. - **Disaster Recovery**.** **A great addition to primary backup usually includes regular failover testing. - **Compliance**.** **Analysis of compliance requirements, implementation of regulations, and certifications. - **Training**.** **Generic IT training, specialized security training. Finding a trusted partner to provide the services can be a challenging task, as many MSP owners are protective of their customer base and need to make an effort to agree to provide access to their customers to other MSPs. Yet, if the reseller model is implemented correctly, it not only allows them to generate additional profit from somebody else’s services but also increases customer satisfaction and decreases the chances of a customer moving to another MSP. The more services customers consume through their MSP, the lower the chances they will be looking for another partner, understanding the high cost and inconvenience of the transition. --- ## MSP Profit Challenges **Author:** Gaidar Magdanurov | **Published:** 2023-07-30 **URL:** https://mspnotes.com/profit-challenges-for-managed-service-providers **Tags:** Business A few weeks ago, we talked with [Dave Sobel](https://www.davesobel.com/) (I strongly recommend his podcast to people interested in the managed services market, by the way) about the MSP market and our observations of new trends in the market. Among the topics we discussed were the present-day challenges for the smaller MSPs. Since that conversation, I have been asking MSPs I am talking to about their challenges at every suitable opportunity, and the general theme seems to be the same across the world. ## **Declining profits** For the smaller MSPs, the central issue of the last 3–6 months is the decline in profits. Their customers are going out of business, decreasing their IT budgets, and requesting to downgrade their service level or demand discounts. Some MSPs shared stories of customers not paying the bills and suggested going to court to collect the payment or offering only a partial payment. Businesses that depend heavily on foot traffic around major office buildings suffer, as fewer people go to the office and fewer people turn to them to consume their services and goods. This impacts the MSPs. Vendors serving those who depend on foot traffic also suffer losses, which affects the MSPs serving them. Many SMBs struggle with timely cash collections, which leads to cashflow gaps. As a result, they cut expenses and reduce expenses, often including IT spending in the list of expenses to cut. When everything works, MSPs are rarely visible, and business owners start to think they don’t need to pay them as much as they did. ## **Simplified illustration** Let’s examine how changes in a smaller US-based MSP’s customer base impact its profits using a simplified business model. Their “pre-pandemic” model allowed them to collect 14% profit, run a company with 10 highly skilled engineers, and spend about 10% on sales and marketing to constantly source new leads for customers to replace the churn that, sadly, happens every year. Their administrative costs are around 5%, and they spend around $10,000 monthly on the technology and tools—internal and the software they deploy with their customers. ![](../../../static/img/profit_1.png) *Pre-pandemic business model* During the pandemic, due to the increased economic pressure, they lost 10% of their customer base, and the remaining customers requested to reduce their contracts. The MSP was really good at pitching the value of their services, and the reduction on average was not extreme — as they were able to replace some of the customers that were churning and maintain the same or slightly lower contract value for those who stayed, with average annual contract value falling from $26,000 to $24,000. However, combined with the churn of customers, profits went to zero. To mitigate the impact, they reduced the technology cost, switching to free tools and reducing the services they deploy to their customers to $6,000 monthly. They reduced G&A to 3% and sales & marketing expenses to 7% (as they have tested that going below that generates not enough leads to sign up any new customers, and in their situation, they desperately need to replenish their customer base). This brought their margins to 9% and made the owner nervous; for any future redaction, she would have to reduce the number of engineers, most of whom worked for her for over 6 years and became her second family. ![](../../../static/img/profit_2.png) *Business model during the pandemic* In the last year, the churn continued. Some old customers got out of business; some switched to MSPs with much lower costs (speaking of loyalty, huh). Even though marketing activities helped recruit new customers and replenish the customer base, new customers came with significantly lower contract values, driving the average numbers down. Profit dropped, and the owner had to decide to remove two people from the company. The profit margin is just 4%. However, further reduction in staff will make it extremely difficult to maintain the customers’ infrastructure. It would increase the risk of losing them and, eventually, going out of business. ![](../../../static/img/profit_3.png) *More customers, smaller contracts* So, what is going to happen next? ## **Going after the big fish** Looking at the customer base, the MSP owner realized that a few larger customers have significantly larger contracts. They have more employees and more workloads to manage, and their business is growing. Therefore, the owner focused on upselling additional services and offering strategic IT guidance to those customers to increase their contracts. The offer includes additional security and disaster recovery services and higher SLAs for issue resolution. Refresh their network infrastructure and hardware. Introduction of new cloud-based services for employee time tracking, desk and conference room sharing, migration of the on-premises email system to the Cloud and many others. The direction is to collect more money from the bigger customers. ## **Scaling the operations** Another avenue to increase revenue is to support more smaller customers. The issue is that the contract value is small; while they may take up a significant capacity of technicians, more is needed to justify the value those customers bring. Also, customers constantly looking for cheaper service are not loyal, and onboarding and off-boarding become expensive. The only way to scale the business and include customers with smaller contracts is to implement automation and standardization where possible—standardizing the technology stack and increasing the [operational maturity](../../../msp-maturity-and-scalability/). [Consolidating tools](../../../boosting-msp-productivity-by-reducing-tool-overload/) and introducing a standard technology stack decreases technicians’ time and allows the same team to handle significantly more workloads. Automating most tasks allows for uniformly taking care of most customers, freeing up more time for technicians. A side effect is that technicians with more free time from their day-to-day jobs can participate more actively in marketing activities—going to local events, talking to prospects, and participating in online communities of business owners. ## **Light at the end of the tunnel** From the collective image example above, the MSP found a way to improve profits, and they are willing to continue bringing profits back to the pre-pandemic level. Given that they can scale, they are looking into acquiring customers lost by other MSPs who could not accommodate lower contract values or went out of business because of the shrinking profits. The story’s moral is that scalability through automation and standardization becomes necessary. For MSPs without unique services and working at scale, scalability is crucial for survival. --- ## MSP Maturity and Scalability **Author:** Gaidar Magdanurov | **Published:** 2023-07-15 **URL:** https://mspnotes.com/msp-maturity-and-scalability **Tags:** Technology, Business In the 2022 Global MSP benchmark survey, Kaseya reports that most MSPs support up to 50 clients. Multiple reports from Datto, Kaseya and Acronis indicate that most MSPs have been in business for over six years, and over a quarter have been in business for nearly 15 years. Many companies have been in business for a long time and have yet to grow beyond 50 clients. Based on numerous conversations, there are three primary reasons: the inability to support more customers, the inability to recruit more customers and the general lack of desire to scale the business when the owners are content with their profits. In this article, we will talk about the inability to scale due to a lack of technical talent to support more customers and manage more workloads. While many MSPs can’t afford to hire more people, without adding people, they cannot scale the business; others can scale and support more customers. What differentiates them is the level of operational maturity. There is a model with [five levels of maturity](https://www.auvik.com/franklyit/blog/msp-operational-maturity/) based primarily on financial performance, yet I prefer a model based on business and technical maturity. The level of maturity is not directly related to the financial performance, as many small MSPs can collect reasonable profits, and it is more of an indicator ability to scale the business using the existing resources. The maturity level is not directly connected to an MSP’s size. I met high-maturity MSPs with only two technicians, and I regularly met low-maturity MSPs with over 25 technicians. ## **Low-maturity MSPs** The primary differentiator of low-maturity MSPs is their willingness to take any customer with any infrastructure and maintain that infrastructure as it is. Therefore, technicians must support multiple software packages and services and different types of hardware. They readily accept break-fix customers without long-term contracts, show up to fix a range of issues and charge customers by the hour. Low-maturity MSPs often offer only a basic set of services—remote infrastructure management, backup and security—and different tools for each based on what a previous MSP already installed at the customer’s location. The vast scope of tools to support leads to difficulties for the technicians, who have to be experts in too many different tools. Onboarding new people is complicated, and shifting technicians between customers is also complicated, as each customer’s infrastructure is very different. ## **Medium-maturity MSPs** They are still willing to take any customer with any infrastructure; however, they have documented procedures to standardize the infrastructure over time, replacing existing hardware and software with their preferred choices. Often the standardization is presented to the customers during the onboarding process, and initial buy-in for the standardization is received. Some technicians specialize in certain tools or services. For example, dedicated people are responsible for backup, disaster recovery, and security services, and they support a set of technologies. Medium-maturity MSPs focus more on preventative maintenance and push break-fix customers; they occasionally serve to transition to long-term contracts, pitching them lower risks from preventing the issues. Automation is developed for the standard tools they prefer, usually a set of standard scripts to implement recommended policies. Switching technicians between customers is much easier in comparison to low-maturity MSPs, and standardization of infrastructure that happens over time leads to increased productivity and capacity to onboard more customers. ## **High-maturity MSPs** The primary differentiator for high-maturity MSPs is their own stack of technologies. They have pre-selected vendors and tools tested in the various environments they support. Standardization of the infrastructure is documented in a contract with the customers and begins right at the onboarding process. Standard hardware, standard software and a set of documented standard operating procedures allow transitioning technicians between accounts, faster onboarding of new customers and providing more reliable service to the customers with shorter times to resolve problems. Preventative maintenance and automation are the keys to success, and with all infrastructure needs handled, high-maturity MSPs have time to provide strategic IT advisory to their customers, not only handle their infrastructure. ## **Measuring scalability** One key metric to compare the capacity of MSPs to handle more workload is the number of endpoints per technician that the technician can maintain at a level satisfactory for the customers. Based on multiple interviews, I estimate that on average, low-maturity MSPs can manage less than 200 endpoints per front-line engineer, medium-maturity up to 300–400, and high maturity over 400 endpoints. So far, the lowest number I heard was about 60, and the highest was over 1,500 endpoints per front-line engineer. The technicians’ productivity is dramatically different based on the experience and type of customers they support; thus, the numbers mainly indicate the scale that could be achieved with a higher level of operational maturity. A higher level of operational maturity allows MSPs to scale and grow the business with the existing resources. Therefore, if you target to grow the business, it makes sense to look at the maturity of your operations and consider what can be improved to increase it. --- ## A Checklist for a Managed Service Provider **Author:** Gaidar Magdanurov | **Published:** 2023-06-30 **URL:** https://mspnotes.com/a-checklist-for-a-managed-service-provider **Tags:** Business After my previous post about [starting an MSP business](../../../from-it-professional-to-entrepreneur-starting-an-msp-business/), a few people asked for a checklist that a new service provider could use to determine whether they have all the necessary elements covered. ## **1. Business plan** - Identify your target market — location, industries, types of companies, and size. - Define the services you want to offer. - Research the competition and assess the demand for MSP services in your chosen market and the prices you can charge. - Define pricing for the managed services (for example, per user, per device, per incident, per extra time spent). - Build a model showing how many contracts and at what value you need to win to make the business sustainable. > Many service providers use multi-tier pricing options, offering different service levels like Silver, Gold and Platinum. Therefore, the model can include estimates of the number of contracts of each type. The business plan should be reasonably documented, regularly reviewed, and updated, as life will correct the assumptions. The document is also an excellent way to onboard partners and employees and explain who the customers are, what the offerings are and how they are packaged. ## **2. Service catalog** - Define your service offerings. For example, remote monitoring and management of endpoints, telephony, helpdesk, cybersecurity, data backup and recovery, cloud services, and IT infrastructure consulting. - Estimate the cost of offering the services and capacity based on the number of users or endpoints you can manage to validate the business model — as the model may imply the ability to support more customers than the actual capacity with the current team size. - Define preferred tools and vendors. - Document processes for deploying and maintaining services. - Establish service level agreements (SLAs), providing enough buffer for responses and issue resolution, given that workload can peak during certain times (for instance, significant customer sales events and the release of Windows updates). ## **3. Legal Structure and Registration** - Decide on the legal structure (for example, sole proprietorship, partnership, LLC, or corporation). - Register it with the appropriate government authorities. - Obtain necessary licenses and permits. - Ensure compliance with relevant regulations. ## **4. Insurance** - Obtain appropriate insurance coverage: - General liability insurance - Professional liability - Property insurance - Cyber insurance - Consider the option of reselling cyber insurance to your customers. - Investigate how your insurance will handle cases like ransomware attacks on the customer infrastructure or major outages of cloud-based services that lead to significant business losses for the customers. ## **5. Technical expertise** - Obtain relevant industry certifications (for example, CompTIA A+, Network+, Security+, MCSA) — the credentials are important for marketing to customers and improving your team’s skillset. - Obtain vendor training and certification (for example, Acronis and ConnectWise). ## **6. IT infrastructure and tools** - Acquire necessary hardware. - Acquire software tools to deliver your services (for example, RMM, PSA, backup, DR, antivirus, EDR). - Implement security policies — it is essential to include guidance for handling customer information and protecting the privacy of customers and employees. - Implement maintenance policies to prevent outages of your infrastructure. ## **7. Relationships with distribution** - Find preferred software and hardware distributors. You may find better deals for projects that include hardware and software packages. - Enroll in distributor communications—do not miss opportunities to save on acquiring or renewing software and hardware for yourself and your customers. - Enroll in training activities offered by distributors—quite often, distributors provide opportunities to learn products and services that can be valuable for customer recruitment or improving your team’s skills. ## **8. Customer service** - Set up email and messaging accounts. - Set up a phone system and call tree for incoming customer calls. - Set up auto-response for after-hour support. - Document procedures for customer service and building relationships. - Train your team to solicit referrals and positive reviews. - Define metrics to measure the quality of the service to be able to early detect and respond to decreasing levels of service (for example, time to first response, time to resolution, the time between responses, the share of cases resolved on the first contact) ## **9. Online presence** - Create a professional brand identity (e.g., logo, website style, marketing materials). - Build a messaging document to highlight your unique selling points and emphasize your expertise, reliability, and customer service. Use it for all of the materials produced about your MSP. - Publish a website. - Publish credentials and case studies. - Create social media accounts. - Build a regular practice of reviewing social media, searching for reviews of your business, and responding to complaints and praise. > Many MSPs prefer to outsource all or some marketing services to an external agency or a part-time consultant; however, it may be too expensive or unnecessary at the earlier stages of an MSP. In any case, the owner of the MSP needs to stay closely involved with marketing, as they know their business and customers better. Not to mention that marketing activities can be costly and, if uncontrolled, can quickly destroy margins. ## **10. Marketing** - Set up online advertising. - Consider offline marketing channels (direct mail, newspaper ads) — find opportunities for local promotions. - Join local business communities, get information about your business posted there and attend their events. - Consider hosting online webinars or offline events for small business owners on relevant topics (for example, best practices of IT infrastructure for dental clinics or how to avoid being ransomed for data). - Proactively ask customers to refer prospects. ## **11. Business development** - Build a network of partners to deliver services you are not offering. - Build a network of referral partners and businesses, exchange leads and services. - Join industry associations. - Attend professional and SMB conferences. - Participate in local business networking events to build your professional network. ## **12. Customer relationships** - Implement a CRM solution. Don’t rely on notes or Excel spreadsheets—they will quickly become obsolete. In the modern world, customer competition starts with knowing customers well and following up with them on time. - Define data needs (for example, what you need to know about your customers and prospects). - Build profiles of customers and prospects in CRM — the more relevant data you have, the easier the conversations with them will go. The data in your CRM will also help you build and offer new services and spot growing customer needs you are not addressing now. - Track the history of interactions and contracts. - If the business plan includes hiring sales, implement a reward program for new customer acquisition. This checklist may look like a handful. Do not be scared. If you sit down and write down what you do in your current job and which projects you run, you will discover many things you are doing. Also, all of it looks like it is a lot of fun! --- ## From IT Professional to Entrepreneur: Starting an MSP Business **Author:** Gaidar Magdanurov | **Published:** 2023-06-15 **URL:** https://mspnotes.com/from-it-professional-to-entrepreneur-starting-an-msp-business **Tags:** Business, Marketing In this post, I share observations on how many new MSP businesses started based on hundreds of stories I heard over the last ten years of working with MSPs. The MSP market is growing with the growing demands of business customers for quality IT services. [Grand View Research](https://www.grandviewresearch.com/industry-analysis/managed-services-market) estimated the size of the global managed services market at $276 billion in 2022 and predicted growth at 13.6% CAGR from 2023 to 2030. [Markets and Markets](https://www.marketsandmarkets.com/Market-Reports/managed-services-market-1141.html) valued the market at $242 billion in 2021 and projected growth to $354 billion by 2026. [Microsoft](https://www.channelfutures.com/business-models/microsoft-spotlights-420-billion-small-and-medium-business-smb-opportunity) calls SMBs are $420 billion untapped opportunity for SMBs. The opportunity is there, and there is room for the new MSP firms. Let’s look at the typical scenario of starting a new MSP business, its challenges, and how MSPs overcame them. ## **Getting ready to start an MSP business** It starts with an IT person entertaining the idea of running their own services business. They have the skills and experience; they know how to handle customers –even the annoying guy from the next cubicle who looks like a personality from “The Office.” They can build networks, manage physical and virtual machines, and deploy security and data protection. They have what it takes to run IT infrastructure for a small business customer. Usually, by they already have a few occasional customers. Friends and friends of friends ask for help and pay them for occasional service. Not yet a stable source of income, yet something, and clearly shows an opportunity. Many stop at the stage of entertaining the idea, as they have bills to pay and are afraid of the stability of the corporate job. Yet, some find ways to overcome the fear of failure. Below are the steps successful MSPs take to launch the business. ## 1. Write down the worst-case scenarios and plan how to overcome them Having a plan for each scenario helps to gain confidence. Worst-case scenarios are unlikely to happen; however, in the process of coming up with ideas on how to mitigate them, backup plans are made. Quite a few people start by looking at their savings accounts, estimating that they can cut down on their expenses, and planning when they will have to look for a job with a stable income in case their business fails. Remembering that there is a [shortage of tech talent](https://qubit-labs.com/it-talent-gap-still-growing-in-2022-2023/), and good IT professionals don’t stay without a job for long, helps too. ## 2. Write a plan for transitioning from a corporate job to owning an MSP business Having a plan and visualizing the next steps helps to overcome anxiety about getting the business running. Many start by listing the engagements they had in the past to understand how many customers they can sign up easily. Then look into their networks for initial conversations with potential customers to understand who else may need their services. Researching the pricing for the MSP services in their area, starting from the global reports like the [one from Kaseya](https://www.kaseya.com/resource/msp-pricing-managed-it-services-pricing/) as a general direction, future MSP owners can build a simple financial model, estimating the number of contracts they need to get the desired level of income that will allow sustaining their business and their lifestyle. ## 3. Prepare for the transition from the corporate job Not everyone has enough customers to sustain the business right away. Thus, many chose to have a gradual transition. Starting from getting more productive at their corporate job to freeing up time for customers and transitioning to remote or part-time positions to have the flexibility to build the business. The best practice here is to become effective in delivering on daily tasks. Automation plays a significant role here. Writing scripts for routine tasks takes time, yet it saves us much time in the future. Being efficient in the primary job gives time to do the side gig while also helping automate many tasks for the future MSP business. ## 4. Develop service-level agreements and standard contracts Before offering services to more customers, MSPs decide on what level of service they can realistically provide. While combining the corporate job with the business, quite often, the agreements will indicate service during the evenings and weekends, which means that customers may have to wait sometimes 24–48 to get issues resolved. Yet, getting a consultation with a lawyer, drafting the agreements and offering services at a fixed monthly fee, calculated from the number of devices or users, and then pitching it to customers converts the relationships with “break-fix” to proper managed services arrangements. The primary selling point for the customers is the reliability of the infrastructure that has preventative maintenance, as the same person maintains the infrastructure. ## 5. Transition to the MSP full-time Customers tend to tell other businesses about the quality service provided to them by their MSP, and the customer base slowly yet steadily grows. Customers demand more and more attention and get impatient to have service provided during evenings and weekends. MSP gets to the point where combining a full-time day job with an MSP business is impossible. Usually, by this time, there are established procedures for client intake and onboarding and experience with taking over unmanaged and previously (poorly) managed infrastructure. Basic tools for management, protection and automation for the business are in place, and it is possible to scale the operations by adding more people to manage clients’ infrastructure. Many new MSPs look to recruit former colleagues whom they know through past experience, as they know their qualifications. However, new MSPs often look to recruit recent graduates with little to no experience, as they can train them on their procedures and technologies while paying relatively small salaries. ## The financial reality: How much runway do you actually need? ### Startup costs Starting an MSP is not capital-intensive compared to most businesses, but it is not free either. Here is what a solo-operator budget looks like based on a feedback of a few new recently started MSPs: Category Estimated Range Business formation (LLC, insurance, legal) $3,000 - $5,000 AI assistant (Claude, Codex) $200/month RMM and PSA tools $200/month Cyber protection stack for the initial set of custoemrs (EDR, backup, email security) $300/month Hardware (laptop, networking gear for lab/testing) $3,000 - $5,000 Website, branding, business cards $500 Professional liability and E&O insurance $1,000 - $3,000/year Initial marketing (local networking, online presence) $2,000 **Initial investment** ~$13,000 **Monthly operating overhead (before salary)** ~$1,000 (inc. insurance) These numbers assume a lean solo operation. If you plan to rent office space or hire a technician immediately, add $3,000 - $6,000 per month. ### The break-even calculation This is the math that matters most. Industry benchmarks show the average MSP contract for a small business with 20-50 users runs $2,000 to $5,000 per month. Per-user pricing for SMB-focused MSPs averages around $150 to $200 per user per month, with top performers commanding $250 or more. Here is a simplified break-even model example for a solo MSP owner who needs to replace a $90,000 annual salary: - **Monthly personal income target:** $7,500 - **Monthly business overhead:** $1,000 - **Monthly revenue needed:** $8,500 - **Average contract value (small business, 15-25 users):** $2,500/month - **Minimum viable client count:** 4 clients - **Realistic target to have breathing room:** 5-6 clients Four managed services clients at $2,500 per month gets you to $10,000 in monthly recurring revenue. That covers your overhead and matches your previous salary. Five or six clients gives you a cushion for slow months and the ability to start investing in tools and growth. ### How much savings do you need? Plan for 6 to 12 months of personal expenses with zero business income. Here is why: - **Months 1-3:** You are still building your pipeline. Revenue is inconsistent or nonexistent from managed services contracts. You may pick up some break-fix or project work. - **Months 4-6:** Your first 1-2 managed services contracts are signed. Revenue is growing but does not cover your full expenses. - **Months 7-12:** You are approaching break-even with 3-5 contracts. Cash flow is stabilizing. If your monthly personal expenses (mortgage, groceries, insurance, everything) are $5,000, you need $30,000 to $60,000 in savings as your runway. That sounds like a lot, but remember -- this is the same buffer that lets you negotiate from a position of confidence rather than desperation. Desperate MSP owners undercut their pricing, and underpriced services are the fastest path to burnout and failure. ## What I have learned from watching transitions to MSPs After a decade of watching IT professionals become MSP owners, a few patterns stand out: - **The ones who succeed plan financially before they plan technically.** They know their break-even number, they have their runway calculated, and they have a shared agreement with their family about what "success" and "failure" look like at specific milestones. - **The ones who fail usually fail on sales, not on service.** They are excellent IT experts who cannot bring themselves to pick up the phone, ask for referrals, or quote a price without apologizing for it. If selling makes you uncomfortable, that is the skill to develop first - not another certification. - **The gradual transition almost always outperforms the leap of faith.** The MSP owners who spent 3-6 months building their client base while still employed had significantly better outcomes than those who quit first and figured it out later. Savings buy you time, but signed contracts buy you confidence. - **The ones who last build recurring revenue from day one.** Break-fix work is tempting because it produces immediate cash, but it is unpredictable and unscalable. Every hour spent on break-fix work is an hour not spent building the managed services contracts that will actually sustain your business. - **Technology adaption is now a business survival skill, not a differentiator.** AI and automation are changing how MSPs deliver services, create margins, and measure value. The MSPs launching now need to think about AI-assisted monitoring, automated remediation, and efficient service delivery from the start - not as future enhancements. The MSP industry has room for new entrants. The demand for managed IT services from small and medium businesses is not slowing down. But the bar is higher than it was five years ago. Customers are more sophisticated, security requirements are more demanding, and the competitive landscape is more crowded. Succeeding requires more than technical skill - it requires financial planning, legal awareness, emotional resilience, and the willingness to become a business person first and a technician second. --- ## All-You-Can-Eat Pricing ## Definition All-you-can-eat pricing is a flat monthly fee – usually per user, sometimes per site – that covers unlimited support within a defined scope: every ticket, remote or onsite, with no hourly billing for covered work. It is the unlimited-support form of the all-in seat price. ## Why it matters to an MSP The model aligns incentives correctly: under [break-fix](/wiki/glossary/break-fix) you earn when things break, under all-you-can-eat you earn by preventing tickets. It is also unforgiving. Margin depends on ticket volume per user staying low – typically 0.5–1 tickets per user per month in a well-standardized environment – and every ticket above that is labor you eat. That only works if you control the environment: [RMM](/wiki/glossary/rmm) on every device, current patching, standardized hardware, and the right to refuse unsupported systems. The real risk is scope creep. "Unlimited" is read by clients as "everything," and without a boundary you will find yourself deploying twelve new hires' laptops, migrating a line-of-business app, and running a server rebuild for the same fee. The defense is an explicit out-of-scope clause paired with a service catalog: the contract lists what unlimited covers, states that anything not listed – projects, migrations, new sites, hardware refreshes, third-party vendor escalations beyond a set time – bills at project or hourly rates, typically $125–$250 per hour as covered in [MSP pricing models](/wiki/msp-pricing-models), and defines a minimum-standards rule excluding end-of-life operating systems and unmanaged devices. Add a scope trigger: 20% seat growth or a new location re-opens pricing. Finally, watch the [PSA](/wiki/glossary/psa) for outliers. A client running three times the average tickets per user is either a root-cause problem you fix once or a repricing conversation at renewal; carrying them silently is how a book loses margin. Related terms: [Per-Seat Pricing](/wiki/glossary/per-seat-pricing), [Break/Fix](/wiki/glossary/break-fix), [SLA](/wiki/glossary/sla), [Value-Based Pricing](/wiki/glossary/value-based-pricing) --- ## Backup and Disaster Recovery Process ## The standard: 3-2-1 plus immutability The baseline design for every client is 3-2-1 – three copies of the data, on two different media, one offsite – with a modern, non-negotiable addition: at least one copy must be **immutable or air-gapped**, because [ransomware](/wiki/glossary/ransomware) operators hunt backup infrastructure first and encrypt or delete it before touching production. This is no longer just good practice: tested offline/immutable backups are on the standard 2025–26 [cyber insurance](/wiki/glossary/cyber-insurance) minimum-controls list, and some carriers now ask for documented restore tests. A [BDR](/wiki/glossary/bdr) design that can't produce evidence is, to an underwriter, no backup at all. **Roles:** one tech owns daily job review (rotate weekly so it doesn't rot), the account manager owns per-client RTO/RPO agreements and test-restore sign-off, and the owner/service manager declares disasters and runs recovery events. ## Define RTO and RPO per client tier Recovery objectives are a business negotiation you document, not a technical default. Agree an [RTO](/wiki/glossary/rto) and [RPO](/wiki/glossary/rpo) per client – ideally per system – write them into the [business continuity plan](/wiki/glossary/business-continuity-plan) and the service agreement, and price them honestly. A typical tiering: | Tier | Example workload | RTO | RPO | Typical design | |---|---|---|---|---| | 1 – Critical | Line-of-business server, EHR, ERP | ≤ 4 hrs | ≤ 1 hr | Appliance BCDR with local virtualization + immutable cloud copy | | 2 – Important | File servers, finance workstations | ≤ 24 hrs | ≤ 4–24 hrs | Direct-to-cloud image backup | | 3 – Standard | General workstations, M365 data | 1–3 days | 24 hrs | Cloud endpoint/SaaS backup | Tighter objectives cost more – local virtualization hardware versus direct-to-cloud is largely what separates the price points. Clients who refuse Tier 1 pricing for Tier 1 systems should sign that decision. ## What gets backed up - **Servers:** image-based backup, always – file-level alone can't hit any meaningful RTO. - **Endpoints:** decide per client and put it in writing. At minimum, key-person machines; "workstations aren't backed up unless contracted" stated explicitly beats an assumption discovered during a loss. - **Microsoft 365 / SaaS – the day-one must-sell.** Microsoft's shared-responsibility model is explicit: Microsoft protects the service, the customer owns the data – and Microsoft's own Services Agreement recommends third-party backup. Native tools are retention features, not backup: recycle-bin and versioning windows top out around 93 days, retention policies aren't restorable point-in-time copies, and tenant configuration (users, groups, Conditional Access) isn't backed up at all. Ransomware, malicious insiders, departed-employee license cleanup, and admin error all fall outside Microsoft's recovery obligations. For the MSP, it's the easiest attach in the catalog: agentless API deployment, typically ~$2–3/user/mo cost, clean margin, and it's the first thing a client actually uses ("restore Bob's deleted mailbox"). Every client is already in M365 – a 100% attach rate is realistic. ## Vendor options (brief, as of 2026) - **Acronis Cyber Protect Cloud** – MSP-focused backup for physical, virtual, cloud, and SaaS workloads, with optional cloud disaster recovery managed through the same console; a fit for providers that want to consolidate backup and recovery management. - **Datto (Kaseya) SIRIS/ALTO** – the appliance BCDR reference: instant local and cloud virtualization, all-in pricing. Killed High Watermark billing in Dec 2025 and cut prices roughly 10% in Jan 2026 under competitive pressure; post-acquisition frustration in the community is real (see Slide, the Datto founder's new BCDR startup explicitly courting unhappy partners). - **Axcient x360Recover** – direct-to-cloud or appliance, pooled storage, flat per-device fair-use pricing; the most common Datto alternative at MSP volumes. - **Cove Data Protection (N-able)** – cloud-first, storage included, flat per-device plus per-user M365 rates, no appliance capex; excellent for lean new MSPs. - **Veeam** – powerful and license-heavy, with price rises of 4–8% in Jan 2026 (second straight annual hike); best fit for server-heavy or VMware-centric clients. - **M365/SaaS backup:** Acronis Backup for Microsoft 365 (Exchange Online, OneDrive, SharePoint, Teams, and Entra ID), Datto SaaS Protection (3x daily, per-license, unlimited storage), Dropsuite (channel-only, now NinjaOne-owned), Afi (~$3/user/mo list, negotiable), Cove. Pick one platform and standardize – one backup product across all clients is what makes daily monitoring and restore testing operationally possible. ## Monitor jobs daily A backup silently failing for three weeks is the classic MSP negligence story – and it's preventable: 1. Every business morning, the rotation owner reviews the previous night's jobs – failures and warnings, not the wall of green. 2. Every failure becomes a PSA ticket, closed only with a root cause and a subsequent successful job. 3. Track **last-good-backup age** per protected system; anything exceeding the agreed RPO is escalated as an incident that day, not filed as a note. 4. Alert on silence too – an agent that stops reporting is more dangerous than one reporting failure. ## Tested restores on a schedule An untested backup is a hypothesis. Insurers have caught up to this – documented restore tests are increasingly requested at renewal. - **Quarterly, per client:** one file-level restore and one image/VM boot verification, rotating through systems so everything gets exercised over the year. Log evidence – ticket, screenshots, timing – in the client's documentation. - **Annually, per Tier 1 client:** a DR exercise against the runbook – a live failover or a rigorous tabletop. Measure actual recovery time against the contracted RTO and update the runbook with what broke. - Automated boot-verification screenshots are table stakes, not a substitute – they prove the VM boots, not that the application works. ## Recovery runbooks and the DR communication plan Each client gets a recovery [runbook](/wiki/glossary/runbook) in your documentation platform, maintained per your [documentation standards](/wiki/msp-documentation-standards): restore order and dependencies (domain controllers before applications), where credentials live, vendor and ISP support numbers, and the decision tree – restore in place, virtualize locally on the appliance, or fail over to cloud [DRaaS](/wiki/glossary/draas). The communication plan answers, in advance: who declares a disaster, who is the single voice to the client, what the update cadence is (a typical commitment: an update every 2–4 hours during active recovery, even if the update is "still restoring"), and what the out-of-band channel is when email is down – which it will be, since mail servers and M365 access are often part of the outage. If the cause is a security incident rather than a failure, the [incident response process](/wiki/incident-response-process) leads and this process executes the recovery step. ## Exit criteria for a recovery event A recovery event is closed only when all of the following are true: 1. Data and systems restored, and **validated by the client's owner of each system** – not just "the VM boots." 2. If the cause was ransomware or compromise: restore points verified clean and the initial-access vector closed before reconnection, under IR-process direction. 3. Backups re-established on restored systems, with the first new job completed and verified. 4. Client sign-off in writing that operations are restored. 5. Post-event review completed within two weeks: actual RTO/RPO vs contracted, what failed, runbook updated, and any remediation sold as roadmap items. ## Cadence at a glance - **Daily:** job review, failure tickets, last-good-backup age check. - **Monthly:** per-client backup status in reporting; verify coverage of newly added systems. - **Quarterly:** test restores with logged evidence; review RTO/RPO tiers for changes. - **Annually:** DR exercise for Tier 1 clients; revisit vendor pricing and immutability settings. Backup is the one service where the work is invisible until the worst day of a client's business – run the discipline daily and rehearse the bad day before it happens. --- ## BDR (Backup and Disaster Recovery) ## Definition BDR (backup and disaster recovery) is the combined service of taking regular copies of a client's systems and being able to run them again, to a stated recovery point, after hardware failure, [ransomware](/wiki/glossary/ransomware), or site loss. In MSP usage it usually means a specific architecture: a local physical or virtual appliance that takes image-based backups of servers, can boot them as virtual machines on-site, and replicates the images to the vendor's cloud for off-site recovery. ## Why it matters to an MSP Clients undervalue backup until it is the only thing that matters; BDR converts it from a checkbox into a recovery commitment with an [RTO](/wiki/glossary/rto) and [RPO](/wiki/glossary/rpo) you can sign. File-based backup is cheap – typically $5–15 per workstation per month – but a dead server still means rebuilding the operating system, applications, and configuration before restoring data, a day or more of labor you may not be able to bill. Image-based backup captures the entire system, so recovery is booting the last snapshot on the appliance or in the cloud within minutes to an hour. That is the difference between a four-hour RTO and a two-day one. The appliance-plus-cloud model costs real money – typically $150–500 per month for a server-class client as of 2026 in hardware and per-terabyte cloud fees – which you mark up inside a managed plan or bill as a separate line. It also carries the ransomware requirement – the cloud copy must be immutable and the appliance must not share credentials with the production domain – and an obligation to test: insurers and auditors now ask for quarterly boot-verification screenshots or documented restore tests. Untested BDR is the largest single liability an MSP carries. Architecture choices are in [backup and recovery design](/wiki/backup-recovery-design). Related terms: [RTO](/wiki/glossary/rto), [RPO](/wiki/glossary/rpo), [DRaaS](/wiki/glossary/draas), [Business Continuity Plan](/wiki/glossary/business-continuity-plan) --- ## BEC (Business Email Compromise) ## Definition Business Email Compromise is fraud conducted through a trusted mailbox: an attacker either takes over a real business email account – today most often via adversary-in-the-middle phishing kits like Evilginx that steal session tokens and bypass weak MFA – or convincingly spoofs one, then impersonates an executive, employee, or vendor to redirect wire transfers, change payroll deposit details, or reroute vendor payments. There is often no malware involved at all, just a plausible fraudulent email, which is why it slips past antivirus-era thinking entirely. ## Why it matters to an MSP FBI IC3 reporting consistently ranks BEC among the top cybercrime loss categories, with billions in reported losses annually, and SMBs are prime targets: a single fraudulent wire can be a six-figure, often unrecoverable loss. The countermeasures form a layered, sellable package. Technical: phishing-resistant [MFA](/wiki/glossary/mfa) with Conditional Access and legacy auth disabled; hardened email security – DMARC/DKIM/SPF enforcement plus an API-layer tool such as Acronis Email Security, Avanan, Mesh, or IRONSCALES on top of Microsoft's EOP/Defender. Human: [security awareness training](/wiki/glossary/security-awareness-training) with phishing simulations. And – critically, because no technology covers it – finance-process controls at the client: out-of-band verification of any payment or banking change, and dual approval on wires. Advising on that last layer is what separates an MSP acting as a security partner from one merely selling licenses. Related terms: [Phishing](/wiki/glossary/phishing), [MFA](/wiki/glossary/mfa), [Security Awareness Training](/wiki/glossary/security-awareness-training) --- ## Break/Fix ## Definition Break/fix is the reactive IT support model: the client calls when something is broken, you fix it, and you bill for the time and parts – hourly, per incident, or against a prepaid block of hours. There's no monitoring, no maintenance obligation, and no recurring fee; the relationship is active only while something is wrong. ## Why it matters to an MSP Break/fix is how most MSPs start, because it's how small businesses are used to buying IT, and the model to leave behind fast. The economics are inverted: you earn more when the client's systems fail more and nothing when they run well, so the incentive is to fix the symptom and wait for the next call rather than remove the cause. Clients sense that and haggle every invoice. Revenue arrives in lumps you can't forecast, so you can't hire ahead of demand, and a lender or acquirer prices the business on [MRR](/wiki/glossary/mrr) and discounts hourly revenue to almost nothing. Managed services flip the incentive. A fixed monthly fee per user or device means you profit when tickets go down, so you're paid to patch, monitor, and standardize. The numbers favor the switch: hourly rates of $125–$250 are typical in US markets, but a flat-fee agreement at $100–$250 per user with an [RMM](/wiki/glossary/rmm) handling routine work commonly runs 50–60% gross margin, against the 30–40% typical of time-and-materials. Some hourly clients will refuse a monthly fee: set a conversion deadline, hold a $500-plus monthly minimum, and let the rest go. Aim for at least 50% recurring revenue in the first year, and treat every break/fix invoice as a sales conversation about the agreement that would have prevented it. Fee structures that replace hourly billing are compared in [MSP pricing models](/wiki/msp-pricing-models). Related terms: [MRR](/wiki/glossary/mrr), [Per-Seat Pricing](/wiki/glossary/per-seat-pricing), [All-You-Can-Eat Pricing](/wiki/glossary/all-you-can-eat-pricing), [MSP](/wiki/glossary/msp) --- ## Building Your Client Security Stack ## Security is the core offer, not the upsell Verizon DBIR-derived 2025 data puts ransomware in 44% of all breaches – and in 88% of breaches at SMBs, versus 39% at large enterprises. Two-thirds of 2024–25 ransomware attacks hit organizations under 500 employees. The median ransom payment in 2025 ran around $115K, and a typical SMB incident costs anywhere from $120K to $1.24M all-in. Your clients are exactly the target profile, and their insurers and regulators are already forcing them to buy controls. If you don't sell the stack, the MSP down the road will. So stop quoting antivirus as a line item. Build one standardized stack, price it into the seat, and refuse to onboard clients without it. ## The non-negotiable baseline The channel-consensus minimum – "no client onboarded without it": - **Managed [EDR](/wiki/glossary/edr)/[MDR](/wiki/glossary/mdr)** – endpoint detection with a 24/7 SOC behind the agent, on every endpoint and server - **Hardened M365/email security** – tuned EOP and Defender for Office 365, anti-phish policies, DMARC/DKIM/SPF enforced, legacy auth disabled; add an API-layer product where risk warrants - **[MFA](/wiki/glossary/mfa) everywhere** – enforced via Conditional Access, with phishing-resistant methods (FIDO2 keys, Windows Hello) at least for admins, which underwriters increasingly expect - **DNS filtering** on every device - **[Security awareness training](/wiki/glossary/security-awareness-training)** with phishing simulations - **Password manager** deployed per client – and one for your own shop's credentials - **M365/SaaS backup** – under Microsoft's shared-responsibility model the customer owns the data; native recycle-bin and versioning windows top out around 93 days, retention policies aren't restorable point-in-time copies, and tenant configuration isn't backed up at all Don't sell this à la carte to small clients. À la carte invites them to decline the one control that later becomes the breach. ## Vendors and typical wholesale costs MSP wholesale pricing is almost always quote-based and volume-tiered; the figures below are typical community-reported ranges as of 2026. | Layer | Leading options | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Managed EDR | [Acronis EDR with Acronis MDR](https://www.acronis.com/en/products/cloud/cyber-protect/managed-detection-and-response/) – integrated EDR/XDR, 24/7/365 SOC monitoring, response, and recovery; Huntress Managed EDR – channel-first, 24/7 SOC included | | EDR without bundled SOC | [Acronis EDR](https://www.acronis.com/en/products/cloud/cyber-protect/security-edr/) – attack-chain visibility, endpoint response actions, and optional Acronis MDR; SentinelOne – operated by the MSP or paired with Vigilance MDR; Microsoft Defender for Business – standalone or included with Microsoft 365 Business Premium; Bitdefender GravityZone – commonly purchased through distribution options vary | | Email security | [Acronis Email Security](https://www.acronis.com/en/products/cloud/cyber-protect/email-security/) – API-based Microsoft 365 deployment, also supports Google Workspace and other mail systems; tuned EOP + Defender for Office 365 P1; Check Point Harmony Email/Avanan (~$3–5/mailbox); Proofpoint Essentials (~$2–5); Mesh | | MFA | Entra ID P1 Conditional Access (in Business Premium); Duo (~$3–6) where clients aren't Microsoft-centric | | DNS filtering | DNSFilter (~$0.90–2.70 list, cheaper on the MSP program, white-label); Cisco Umbrella (quote-only, generally pricier) | | SAT + phishing sims | [Acronis Security Awareness Training](https://www.acronis.com/en/products/cloud/cyber-protect/security-awareness-training/) – multitenant management, short lessons, and phishing simulations; KnowBe4; Breach Secure Now; usecure; Huntress SAT | | Password manager | Keeper MSP and Bitwarden MSP (~$4 Teams, ~$6 Enterprise tiers); 1Password (most polished multi-tenant console) | | M365 backup | [Acronis Backup for Microsoft 365](https://www.acronis.com/en/products/cloud/cyber-protect/m365-backup/) – Microsoft 365 and Entra ID backup with granular recovery; Datto SaaS Protection; Dropsuite; Afi; Cove | One option is to consolidate EDR/MDR, email security, SAT, and Microsoft 365 backup in Acronis Cyber Protect Cloud. Another is to use Microsoft 365 Business Premium as the foundation, with Huntress providing the managed SOC service. ## Resell MDR – don't build a SOC The staffing math kills the DIY [SOC](/wiki/glossary/soc) for small MSPs: continuous 24/7 coverage takes roughly 8–12 analysts minimum, typically $1M+/yr fully loaded, plus SIEM tooling – before a single alert is triaged. That doesn't pencil until you manage several thousand endpoints. Meanwhile attackers deliberately work nights, weekends, and holidays, precisely when a three-person MSP is asleep. Reselling MDR buys a 24/7 SOC at $2–15/endpoint marginal cost with no hiring. This is settled consensus in the channel. - **Acronis MDR** – 24/7/365 monitoring, investigation, response, and recovery through Acronis EDR or XDR; choose the Acronis SOC or another available SOC provider. - **Huntress** – SOC included with Managed EDR (plus ITDR and Managed SIEM add-ons); choose pre-authorized SOC response or click-to-approve. - **Blackpoint Cyber** – active-response MDR: the SOC autonomously isolates hosts, disables accounts, and contains at the network level; typically $8–15/endpoint/mo. - **Todyl** – combines SASE, SIEM, EDR/MXDR, and GRC modules in one per-user agent; attractive when you want to consolidate firewall/VPN/DNS/SIEM spend. - **RocketCyber (Kaseya Managed SOC)** – priced through Kaseya bundles; community consensus rates SOC quality below Huntress and Blackpoint. Compare Acronis MDR, Huntress, and Blackpoint against the same requirements: response authority, identity coverage, recovery capability, escalation times, reporting, minimum commitments, and total per-endpoint cost. ## Packaging: in the base seat or as a tier? Two workable models – see [MSP pricing models](/wiki/msp-pricing-models) for the broader pricing context: **Security inside the base seat.** The whole baseline is included in one all-in per-seat price, typically $100–175/user/mo as of 2026. **Pros:** no per-control negotiation, a uniform stack across clients, no "client declined EDR" liability. **Cons:** a higher sticker price in competitive bids. **Base seat + security add-on tier.** Core management in the base seat; a $25–50/user/mo "Secure" SKU carries EDR/MDR, SAT, DNS filtering, and backup. **Pros:** an easier upsell path and cleaner attach-rate reporting. **Cons:** clients can say no – so make the tier mandatory for new clients and move legacy clients onto it at renewal. Either way, write the stack requirement into your MSA, and treat any declined control as a signed risk-acceptance letter, never a quiet omission. ## The stack is your cyber insurance answer key Underwriting has become a technical audit. The standard 2025–26 minimum for insurability: MFA on email, remote access, and admin accounts; EDR – increasingly "24/7-monitored EDR/MDR" – on all endpoints and servers; tested offline/immutable backups; a patch and vulnerability-management cadence; an incident response plan (increasingly, an exercised one); email filtering; and SAT. Weak answers mean 40–100% premium hikes, ransomware sublimits and co-insurance, or outright declination. Some carriers now also expect phishing-resistant MFA and documented restore tests. Notice that this list is the baseline stack, item for item. That makes every [cyber insurance](/wiki/glossary/cyber-insurance) renewal a sales event: map each questionnaire line to a deployed control, export the evidence (EDR console reports, backup test logs, MFA enforcement reports), and close gaps before the renewal date – "your carrier requires MDR" closes deals that ROI arguments can't. One hard rule: help the client answer, but never sign the attestation yourself; see [Compliance as a Service](/wiki/compliance-as-a-service) for why. And pair the stack with a tested [backup and DR process](/wiki/backup-dr-process), because "do you test restores?" is now a standard carrier question. ## Where to start Choose one architecture and standardize it. The integrated route starts with Acronis Cyber Protect Cloud for EDR/MDR, email security, SAT, and Microsoft 365 backup, then adds separate DNS filtering and password management. The point-product route combines Business Premium, Huntress, DNSFilter, one SAT platform, Bitwarden or Keeper, and one Microsoft 365 backup product. Price both routes against the same coverage requirements before committing. Onboard every new client on the full stack from day one, migrate existing clients at contract renewal, and hold the line on "no client without the baseline." Then apply the same standard to your own shop first – see [Securing Your Own MSP](/wiki/securing-your-msp) – because none of this is credible if your own house isn't hardened. --- ## Building Your Service Catalog ## Why the catalog comes first You cannot price what you haven't defined, and you cannot sell what you can't state plainly. The service catalog – the written list of exactly what you deliver, what you don't, and what each piece costs you – precedes [pricing](/wiki/msp-pricing-models) and [sales](/wiki/msp-sales-marketing), because both collapse without it. Quote without a catalog and every proposal is bespoke; deliver without one and every "can you also just..." becomes free work. The classic new-MSP failure mode is a verbal deal with undefined scope, and the catalog is the first half of the fix (the contract is the second). The catalog is an internal discipline document first and a sales document second. Write it before your first proposal, even if you have zero clients. ## The core managed offering Your base bundle is what every managed client gets, no exceptions. As of 2026 the standard core looks like: - **Monitoring and alerting** – [RMM](/wiki/glossary/rmm) agent on every endpoint, network monitoring, actionable alerting you actually respond to. - **Patch management** – OS and third-party patching on a defined cadence, with reporting. - **Help desk** – business-hours support through defined channels (email, portal, phone), every request ticketed, response times per your SLA. - **Security baseline** – [EDR](/wiki/glossary/edr) on every endpoint, MFA enforcement, email security, DNS filtering, security awareness training. Make the baseline non-negotiable: a client who declines EDR is a breach you'll be blamed for. - **Backup oversight** – managing and verifying backup/DR jobs, alert response, periodic restore tests. (Whether backup licensing itself is included or an add-on, the *oversight* is core.) - **[vCIO](/wiki/glossary/vcio) touch and QBR** – a strategic review cadence, technology roadmap, and budget forecast, even in lightweight form. If an item is in the core, it's in *every* deal. Resist building a stripped tier that removes the security baseline to hit a price point – that's how you acquire clients whose incidents cost more than their contract. ## The exclusions list The exclusions section earns more money than the inclusions. Enumerate what is **not** covered and state that anything not listed defaults to a quote or time-and-materials at your current rates. Standard exclusions: - **Projects** – migrations, office moves, server refreshes, new deployments: quoted separately, fixed-fee or T&M. - **After-hours work** – outside business hours bills at the emergency rate unless the client buys a 24/7 tier. - **New-hire hardware** – procurement, provisioning, and the hardware itself for headcount growth is a billable event (or a defined per-onboarding fee), not free labor. - **Third-party application development and deep LOB app support** – you coordinate with the vendor; you don't write or debug their software. - **Anything not listed** – the catch-all line that makes the list enforceable. ## Add-on services Add-ons attach to the core for clients who need them, at their own price: - **Compliance program management** – HIPAA, CMMC, SOC 2 support priced as a program, not ad-hoc hours; see [compliance as a service](/wiki/compliance-as-a-service). Compliance-heavy verticals typically support 15–25% higher pricing overall. - **Co-managed IT** – a defined subset of the catalog (tools, escalation, projects) delivered alongside internal IT. Kaseya's 2025 benchmark found 61% of MSPs saw co-managed revenue rise, so it's worth a defined offering rather than one-off deals. - **Advanced security** – managed SOC/MDR, vulnerability management beyond the baseline; a serious add-on security stack typically retails at $25–$50/user/month on top of base. - **[HaaS](/wiki/glossary/haas)** – hardware bundled into the monthly seat. **Caution for new MSPs:** you front the capital, carry asset-tracking overhead and default risk, and non-payment leaves you repossessing laptops. The common advice is to skip HaaS early or use third-party financing so the balance-sheet risk isn't yours. ## Structuring tiers Two to four tiers is the norm; three is the sweet spot. Every tier includes the full security baseline – tiers differ on coverage hours, strategy depth, and advanced services, not on whether the client is protected. A typical shape: | | Essential | Professional | Complete | |---|---|---|---| | Monitoring, patching, help desk | Business hours | Business hours | Extended / 24×7 P1 | | Security baseline (EDR, MFA, email security, SAT) | Included | Included | Included | | Backup oversight | Included | Included | Included + DR testing | | Managed SOC / MDR | – | Included | Included | | vCIO / QBR cadence | Annual review | Quarterly | Quarterly + roadmap & budget | | Compliance program support | – | – | Included | Price the middle tier as your default recommendation and let the top tier anchor. Map tiers to per-user prices using your pricing model. ## Map every line to a tool and a unit cost For each catalog item, record two things: **which tool or process delivers it** and **what it costs you per unit** (per seat, per device, per client). "EDR" maps to your specific EDR product at its per-endpoint wholesale cost; "backup oversight" maps to your backup platform plus a labor estimate; "help desk" maps to PSA seat costs plus loaded tech time per ticket. This table – the catalog joined to your [tool stack](/wiki/msp-tool-stack) – is what makes your pricing floor computable instead of guessed, exposes which offerings are margin-negative, and tells you instantly what a vendor price hike does to each tier. One tool per function: stack sprawl multiplies training, documentation, and error surface, and margin leaks trace directly to it. ## Scope-creep defense The catalog's daily job is defending scope. The operating rule: **everything not listed is a quote.** When a client asks for something outside the catalog, answer, "That is outside the agreement, so I will send a quote," not with a favor. Undocumented favors compound: they train the client that scope is negotiable, they never make it into tickets or time entries, and they quietly destroy agreement margins – below roughly 45% gross margin on managed services, mispricing or scope creep is usually the culprit. A defined catalog turns every out-of-scope request from an awkward confrontation into a routine sales opportunity at your project rates (typically $125–$250/hr as of 2026). ## The catalog and your MSA The catalog is the source of truth for the service attachments in your [MSA](/wiki/msp-contracts-and-msa). The standard structure – an evergreen master agreement with services defined in attachments incorporated by reference – means the MSA body rarely changes while service attachments are generated from the current catalog. Scope, exclusions, and out-of-scope rates in the contract should be copied from the catalog, never improvised per deal. If the catalog and your contracts disagree, you have two sources of truth and, in a dispute, effectively none. ## Review it annually The catalog is a living document. Review it once a year (a fixed calendar quarter, before contract renewals): retire services nobody buys, promote add-ons that every client takes into the core, fold in new baseline expectations – the security baseline in particular has expanded every year – and refresh unit costs against current vendor pricing so your floor math stays honest. Feed the changes into renewals via the escalator and scope conversation, with evidence from your QBRs. ## Where to start Write version one this week, and keep it small: one core bundle with the six standard components, one explicit exclusions list ending in "anything not listed is quoted," and at most one add-on you can genuinely deliver. Map each line to its tool and unit cost, then use that to set prices and generate your first MSA service attachment. Add tiers when prospects force the conversation, not before. A one-page catalog you enforce beats a beautiful three-tier matrix you discount away – and it's the foundation everything else in [starting your MSP](/wiki/how-to-start-an-msp) builds on. --- ## Business Continuity Plan ## Definition A business continuity plan (BCP) is the client's documented answer to how the business keeps operating through a disruption – a cyberattack, a fire, a flood. It covers people, premises, communications, suppliers, and manual workarounds, not just systems. A disaster recovery (DR) plan is the technical subset: how the IT environment is restored, in what order, within the agreed [RTO](/wiki/glossary/rto) and [RPO](/wiki/glossary/rpo). ## Why it matters to an MSP The distinction matters because it defines what you deliver versus what the client owns. You own the DR plan: the recovery [runbook](/wiki/glossary/runbook), restore order and dependencies, where credentials live, vendor and ISP numbers, and the decision tree between restoring in place, virtualizing on the appliance, or failing over to [DRaaS](/wiki/glossary/draas). The client owns the BCP: who decides to invoke it, how staff are contacted when email is down, whether the practice can see patients on paper for two days, where people work if the office is unusable, and what customers and regulators are told. You contribute the technology sections and the recovery objectives, but refuse to be sole author of the rest – whoever writes the whole BCP owns every decision in it when it fails. Commercially, the BCP is where RTO and RPO get their business meaning. A four-hour recovery objective is a technical target until it is written next to "we lose roughly $8,000 per hour the ERP is down," at which point Tier 1 BCDR pricing sells itself. It is also a common ask: cyber-insurance applications, [HIPAA](/wiki/glossary/hipaa) risk analyses, and [SOC 2](/wiki/glossary/soc-2) and [CMMC](/wiki/glossary/cmmc) assessments all look for a documented and tested plan. Running an annual BCP review and tabletop exercise is a natural [vCIO](/wiki/glossary/vcio) deliverable, because it turns backup from a line item into a business conversation. Related terms: [RTO](/wiki/glossary/rto), [RPO](/wiki/glossary/rpo), [DRaaS](/wiki/glossary/draas), [vCIO](/wiki/glossary/vcio) --- ## Choosing and Migrating RMM and PSA Platforms ## What each platform does – and why the integration matters The [RMM](/wiki/glossary/rmm) is the agent on every managed [endpoint](/wiki/glossary/endpoint): monitoring, alerting, [patch management](/wiki/glossary/patch-management), scripting, and remote control. The [PSA](/wiki/glossary/psa) is the business system: the [ticketing system](/wiki/glossary/ticketing-system), time tracking, agreements, contract billing, and profitability reporting. The integration between them turns two tools into an operation. An RMM alert creates a PSA ticket against the right client and asset; the technician's time lands on the right agreement; the endpoint count syncs from the RMM to the invoice. When that loop breaks you bill from stale counts and lose unbilled hours. Judge the pair as a pair – a great RMM with a shallow PSA connector costs more in lost billing than it saves in features. Where both live in one platform, the integration problem disappears and another appears: you cannot replace one half without replacing both. The rest of the tooling is in the [MSP tool stack](/wiki/msp-tool-stack) guide. ## Pricing shape and what it does to your margin The number matters less than its shape. RMMs are priced per endpoint or per technician with unlimited endpoints; PSAs per user; combined platforms usually per technician. - **Per endpoint** scales with revenue, and a departing client takes its cost with it. It penalizes low-density technicians. - **Per technician, unlimited endpoints** is cheapest at 150–200 endpoints per tech and gets cheaper as density rises. It punishes the first hire – a step change in cost with no matching revenue – and "unlimited" is often capped in the fine print. - **Per PSA user** is the sleeper cost: every dispatcher, account manager, and part-time bookkeeper who touches a ticket is a license. Check the definitions of full and light users before counting seats. Model the stack at today's size, at double, and at half – cheap at 1,000 endpoints can be brutal at 400 after losing a large client, especially with a minimum. ## Contract term, minimums, and the churn trap Term and minimums do more damage than list price. Three-year terms are standard from larger vendors, one-year terms often cost materially more, and month-to-month may not exist. Minimums – commonly 50 endpoints or 5 users – survive client churn. Auto-renewal notice windows are often 60–90 days before expiry, and missing one commits you for another term. Get four things in writing: the term and notice window, the renewal price or a cap on the increase, the right to export all data at any time, and what happens to minimums if your endpoint count falls. Calendar the notice date the day you sign. The rule from [startup costs](/wiki/msp-startup-costs) holds at every size: vendor commitments should never outlast the client contracts that fund them. ## Integration coverage and automation depth Ask two questions. Is there a documented, supported API covering tickets, time entries, assets, and agreements, plus native connectors to your documentation, backup, [EDR](/wiki/glossary/edr), accounting, and quoting tools? A thin API means paying a consultant to work around it. And how deep is the automation? For an RMM: scripting in a real language, remediation that runs before a human sees the alert, patch rings and maintenance windows, a versioned script library. For a PSA: workflow rules that route, escalate, and close tickets, [SLA](/wiki/glossary/sla) timers that drive dispatch, agreement logic that handles overages without spreadsheets. Automation depth is the difference between 150 and 300 endpoints per technician – the whole margin story; see [MSP KPIs and benchmarks](/wiki/msp-kpis-and-benchmarks). ## Vendor stability, acquisition risk, and security posture Nearly every major platform is private-equity owned, and the post-acquisition pattern is predictable: price engineering at renewal, bundling pressure, stagnation, support decline. Weigh the owner's track record as heavily as the product, and favor vendors whose terms and export tooling make leaving an inconvenience rather than a hostage situation – more in [MSP vendor and channel](/wiki/msp-vendor-channel). The RMM is the most dangerous software you run: remote-execution rights on every client device at once. The 2021 supply-chain attack through a widely used RMM encrypted over a thousand downstream businesses, and remote-access vulnerabilities keep appearing in ransomware post-mortems. Before signing, ask for the vendor's [SOC 2](/wiki/glossary/soc-2) report, confirm [MFA](/wiki/glossary/mfa) is enforced rather than optional on every console login, and read their disclosure history and patch speed. A vendor that resists these questions is telling you something. Your own hardening is in [securing your MSP](/wiki/securing-your-msp). ## Typical 2026 costs Community-reported, quote-based, and typical rather than universal: standalone RMM at $2–6 per endpoint per month, or roughly $130–210 per technician with unlimited endpoints; dedicated PSA at $60–120 per user per month; combined platforms at $130–210 per technician. Implementation fees run from nothing to $10,000–30,000 for enterprise-grade PSAs. Together they typically land at 3–6% of [MRR](/wiki/glossary/mrr), inside the 8–15% budget for the full stack. ## When to switch – and when not to Switch when the platform caps the business: automation you cannot build, integrations that need manual re-keying, billing that leaks hours, or a renewal quote that changes the economics. Switch when the vendor has been acquired and the roadmap has gone quiet, or a security incident reveals a culture you no longer trust. Do not switch because a newer product demos better or a peer raves about theirs. Most PSA dissatisfaction is under-implementation – unbuilt workflows, agreements set up wrong, no [SOP](/wiki/glossary/sop) for ticket handling – and a migration carries the mess along. Fix the [ticket management process](/wiki/ticket-management-process) first. And never switch both halves at once unless you are moving to a combined platform: two migrations back to back is survivable; two at once breaks service delivery. ## The migration plan A well-run migration takes 60–120 days. Budget 2–3 months of paying both vendors, timed on your terms rather than the outgoing vendor's renewal date. - **Weeks 1–3, design:** rebuild agreements, boards, statuses, and SLA rules from a clean specification, not a copy of the old configuration. - **Weeks 2–6, data export:** clients, contacts, assets, agreements, open tickets, and twelve months of closed history; archive the rest as read-only exports. - **Weeks 4–10, parallel run:** integrations connected, one pilot client end to end, then the rest. Bill one full month from both PSAs and reconcile every invoice line. - **Agent swap:** deploy the new agent through the old RMM by script, verify check-in and policy assignment against the asset list, then remove the old agent – never the reverse. Expect a 2–5% tail of offline devices needing a manual visit. - **Cutover:** on a month boundary, with a freeze on board changes a week either side, and a [runbook](/wiki/glossary/runbook) for the day. - **Close-out:** confirm the final export, written confirmation the old contract has ended, revoke the old vendor's access, update your [documentation](/wiki/msp-documentation-standards). ## Bottom line Buy the pair as a pair, and buy on shape rather than sticker: pricing model, term and minimums, API depth, automation, and vendor ownership and security posture decide what the platforms really cost over three years – typically 3–6% of MRR. Switch only for reasons that survive a written justification, never both halves at once, and plan the migration as a 60–120 day project: parallel run, scripted agent swap, two to three months of contract overlap in the budget. --- ## Choosing a Niche or Vertical ## Vertical vs horizontal niching There are two ways to specialize. **Horizontal niching** means specializing in a service across all industries – security-first MSP, Microsoft 365-only shop, co-managed IT for internal IT teams. **Vertical niching** means specializing in an industry – dental practices, law firms, construction companies – and serving their whole IT stack. Both beat being a generalist commodity, but vertical niching is where the strongest economics show up, because an industry is a *community*: shared line-of-business apps, shared regulations, shared associations where your name can circulate. A horizontal specialty differentiates your service; a vertical specialty differentiates your service *and* concentrates your referrals. This guide focuses on the vertical path, since it's the one with the clearest data behind it – and the one most technical founders underrate. ## The economics: why vertical pays The numbers reported across the industry are consistent and significant, as of 2026: - Vertical-specialized MSPs report up to **30% higher profit margins** than generalists. - Specialists command **20–40% premium rates** for equivalent scope. - Contracts in regulated verticals run **$200–$400+/user/month**, versus the typical $100–$250 generalist norm – see [pricing models](/wiki/msp-pricing-models) for how that translates into packaging. Why does the market pay this? Three compounding reasons: 1. **You already know their apps and workflows.** A dental-focused MSP has seen Dentrix break a hundred ways; a generalist is learning on the client's dime. That knowledge shortens onboarding, cuts ticket volume, and shows in the sales conversation. 2. **You standardize across similar clients.** Twenty clients on nearly identical stacks means one set of runbooks, one [technology stack](/wiki/glossary/technology-stack), predictable margins. Twenty clients in twenty industries means twenty snowflakes. 3. **Your marketing speaks their language** – more on that below. ## Compliance is the moat Rate premiums invite competition – unless something stops competitors from copying you. In regulated verticals, compliance is that something, and it's slow to fake. Consider the difference in operating posture. A healthcare-focused MSP running 40 clinics treats [HIPAA](/wiki/glossary/hipaa) Security Rule controls, business associate agreements, and breach-notification procedures as *operational routine* – templated, documented, rehearsed. A generalist with one healthcare client treats the same requirements as a one-off project. The difference shows up exactly where it matters: documentation quality, audit readiness, and remediation speed. The same dynamic repeats across regulated verticals: - **[CMMC](/wiki/glossary/cmmc)** for defense contractors – a formal certification regime a generalist cannot bluff through. - **FINRA/SEC rules** for financial advisories and broker-dealers. - **FTC Safeguards Rule** for auto dealers, accounting firms, and other non-bank financial businesses. - **State bar confidentiality rules** for law firms. Because [compliance](/wiki/glossary/compliance) expertise compounds with every audit you survive, it's genuinely hard to copy – and it converts directly into revenue if you productize it as [compliance-as-a-service](/wiki/compliance-as-a-service). There's a referral moat too: vertical clients cluster in associations and peer groups – dental societies, bar associations, contractor groups – and one trusted reference spreads fast through them. The best-compounding verticals cited by industry sources: healthcare, legal, financial services, construction, and manufacturing. ## Verticals that work for solo founders | Vertical | Key LOB apps / tech | What they value | Notes for a solo shop | |---|---|---|---| | Dental | Dentrix, Eaglesoft, imaging integrations | Zero downtime during patient hours, HIPAA routine | Dense local referral networks (study clubs, societies) | | Legal | Clio, document management | Confidentiality (state bar rules), responsiveness, billable-hour uptime | High tolerance for premium pricing when trust is earned | | Construction | Estimating/project apps, field devices | Mobility, job-site connectivity, simple per-project onboarding | Less regulated; wins on reliability and hustle | | Nonprofits | Donor CRMs, cloud suites | Budget discipline; donated/discounted licensing, grant cycles | Viable niche but budget-constrained – price accordingly | | Manufacturing | ERP, OT/plant-floor systems | Uptime, OT/IT segmentation, supply-chain security expectations | Sticky clients; growing compliance pull (e.g., CMMC in defense supply chains) | Healthcare broadly (EHR/EMR environments) is the classic premium vertical, but it's also where compliance expectations are highest – a strong second niche once you've built security and documentation muscle. ## How to pick yours Two inputs matter more than any market-research report: 1. **Your background.** Years as a sysadmin in a hospital, a manufacturer, or a law firm is a niche head start you can't buy: you know the apps, the vocabulary, and probably some future clients. Start where you already have credibility. 2. **Local market density.** A niche needs enough prospects to matter. Count them: how many dental practices, firms, or contractors of 5–50 seats sit within your service radius? A great niche with four local prospects is a hobby, not a strategy. Then let reality choose. The common advice from vertical-specialization guides: **start generalist-local, notice which vertical accumulates, then lean in.** Don't force a niche on day one – your first few clients (see [landing your first clients](/wiki/first-msp-clients)) will show you where referrals actually flow. Be honest about the risks before committing: an industry downturn hits your whole pipeline at once, a fired client is harder to replace from a smaller pool, and regulated verticals demand upfront investment in certifications and frameworks. ## Going deep once you choose Half-niching – a landing page that says "we serve dental practices" over a generic service list – captures none of the premium. Depth does: - **Master the LOB apps.** Install them in your lab, learn the vendor support channels, know the integration quirks. This is the knowledge clients pay 20–40% more for. - **Standardize a vertical stack.** One hardware standard, one security baseline, one backup design tuned to the vertical's compliance needs. Build it into your [service catalog](/wiki/msp-service-catalog) so every new client lands on the same platform. - **Codify the compliance workflow.** Templated policies, evidence collection, audit-prep checklists – documented to a standard a regulator could read; see [documentation standards](/wiki/msp-documentation-standards). - **Show up where the vertical gathers.** Association memberships, society newsletters, sponsoring the local study club – cheap compared to ads, and aimed at the exact referral network that compounds. **The marketing message changes completely when you niche.** A generalist says "we provide reliable IT support and cybersecurity for small businesses" – indistinguishable from every competitor. A vertical MSP says "we keep Dentrix, your imaging, and your patient schedule running, and we handle your HIPAA risk assessment every year." The second message pre-answers the prospect's real question – *do you understand my business?* – and justifies the premium before price ever comes up. Your whole [sales and marketing](/wiki/msp-sales-marketing) motion gets easier because the prospect self-identifies. ## When a generalist start is still fine Niching is a force multiplier, not religion. Staying generalist is a defensible choice when: - **Your market is small.** In a town where no single vertical has critical mass, geography *is* your niche – "the responsive local IT firm" beats a vertical brand with no local prospects. - **You're pre-niche.** In year one, taking varied clients is how you discover which industry fits you. That's a phase, not a failure – just keep noticing where the pull is. - **A horizontal edge is emerging instead.** If what accumulates is a service specialty (say, security-heavy work), lean into that rather than forcing a vertical. The trap to avoid isn't generalism – it's *permanent accidental* generalism: five years in, twenty unrelated clients, twenty snowflake stacks, competing on price against every other generalist. ## Bottom line Vertical specialization is one of the highest-return strategic decisions a small MSP can make: up to 30% higher margins, 20–40% rate premiums, compliance moats generalists can't fake, and referral networks that compound on their own. Pick using your background plus local density, let your first year of clients confirm the choice, then go deep – apps, standardized stack, compliance workflow, association presence. And if your market is too small to support a vertical, be the best generalist in town on purpose, not by accident. --- ## Choosing Your MSP Tool Stack ## The six core categories Every MSP runs on the same six tool categories. Everything else – quoting, accounting sync, reporting – hangs off these. | Category | What it does for the business | 2026 named options | |---|---|---| | [RMM](/wiki/glossary/rmm) | Agents on every endpoint: monitoring, patching, scripting, remote control | Acronis RMM, NinjaOne, Datto RMM, Level, Action1, N-able, Tactical RMM | | [PSA](/wiki/glossary/psa) | Tickets, time tracking, agreements, invoicing – where profitability is measured | Acronis PSA, HaloPSA, ConnectWise PSA, Autotask, Zest MSP, DeskDay | | RMM+PSA combined | RMM and business operations managed together | Acronis Cyber Protect Cloud, Syncro, Atera, SuperOps | | Documentation | Client configs, credentials, runbooks – what makes the business sellable | Hudu, IT Glue | | Remote access | Standalone or RMM-integrated remote sessions | [Acronis RMM remote desktop and assistance](https://www.acronis.com/en/products/cloud/cyber-protect/rmm-solution/), ScreenConnect, Splashtop | | Password vault | Per-client credential sharing and rotation | Bitwarden, Keeper MSP, Passwordstate | Rough list pricing as of 2026: RMM runs $2–6 per endpoint monthly or comes bundled per technician; dedicated PSAs run roughly $60–120 per user; documentation ~$27–44 per user; remote access $30–55 per tech; password vaults $4–6 per user. Most enterprise vendors are quote-only, so treat community-reported numbers as directional. ## Startup-friendly picks vs graduate-to choices **Startup-friendly** means no contract, no minimums, and pricing that scales down to zero clients: - **Level** – typically $2/endpoint/mo flat, first 10 endpoints free, month-to-month, no minimums, billed on prior-month peak count. Arguably the most startup-friendly commercial RMM as of 2026. - **Action1** – free for the first 200 endpoints, forever, full-featured; ~$4/endpoint beyond. Not a full-depth RMM, but for a solo shop under 200 endpoints it can be the patching and endpoint layer at $0. See [patch management](/wiki/patch-management-process). - **Syncro** – RMM+PSA per technician: typically $129–179/mo annual ($159–209 month-to-month), unlimited endpoints, no contract. The most-recommended "one bill for everything" option for new MSPs. - **Atera** – similar per-tech model, ~$129–209/mo with unlimited devices. Polished billing and reporting, but AI Copilot, network discovery, and some reporting are paid add-ons, so real per-seat cost creeps up. **Graduate-to** choices offer broader product coverage or greater depth, but introduce commitments or operating complexity that may not suit a new MSP: - **Acronis Cyber Protect Cloud** – combines RMM, PSA, security, and backup. Pricing is quote-based, and direct agreements use monthly commitment tiers; distributor terms may differ. Compare the complete service package and minimum invoice, not only its RMM functions. - **NinjaOne** – provides deeper RMM automation, patching, and reporting, but commonly carries an endpoint floor and annual contract. - **HaloPSA** – provides broad PSA functions for growing teams, but small shops may face onboarding cost and administration overhead. Compare two paths. Acronis Cyber Protect Cloud combines RMM, PSA, security, and backup, but direct pricing is quote-based and uses monthly commitment tiers. The lower-commitment path starts with Syncro or Atera, then may move to NinjaOne + HaloPSA as the team grows. Model the cost of migration against the cost and contract terms of choosing the broader platform early. ## All-in-one vs best-of-breed for a 1–5 person shop For a 1–5 person MSP, compare two types of combined stack: Acronis packages operations and protection around workloads, while Syncro and Atera bundle RMM and PSA per technician with unlimited endpoints. At 150–200 endpoints per technician, Syncro or Atera works out to roughly $0.65–1.20 per endpoint. Acronis is quote-based, so compare the complete client service package rather than the RMM price alone. **Counterpoints worth weighing:** - NinjaOne and Datto RMM still beat the all-in-ones on automation depth, patch reliability, and reporting. - All-in-one lock-in is real: leaving means migrating tickets, billing, and agents simultaneously. - Some founders run best-of-breed lean from day one (e.g., Zest MSP or DeskDay as PSA + Level or NinjaOne + Hudu) precisely to avoid a future platform migration. - SuperOps caps each per-tech license at 150 endpoints – read the fine print on "unlimited." ## Documentation: Hudu vs IT Glue Do not defer this category. Documentation is what lets tech #2 onboard without tribal knowledge, and credentials scattered in spreadsheets are the classic small-MSP breach vector. See [documentation standards](/wiki/msp-documentation-standards). | | Hudu | IT Glue (Kaseya) | |---|---|---| | Price (as of 2026) | ~$27/user/mo annual | $29–44/user/mo by tier | | Minimums | None | 5-user minimum (~$145+/mo for a solo) | | Term | No contract | 36-month term | | Setup fee | None | Non-waivable onboarding fee (~$545+) | | Hosting | Self-hosted or cloud, same price | Cloud only | IT Glue created the category and has the deepest integrations, especially inside the Kaseya suite. But for a new MSP, Hudu is the overwhelming community default: no minimums, no term, mature IT Glue import tooling if you ever inherit one. At ~$27/mo for one seat it is the cheapest habit you will ever build. ## Contract traps The recurring cash-flow killers for new MSPs, in rough order of damage: - **3-year terms.** Kaseya's default; 1-year terms have reportedly run ~30% higher. The community rule of thumb: never sign anything with Kaseya you can't exit, and get any cancellation promise in writing. - **Minimums that survive churn.** Acronis direct agreements use monthly commitment tiers, although distributor terms may differ. Other vendors may impose endpoint or user floors. Compare the minimum invoice with revenue already under contract. See [startup costs](/wiki/msp-startup-costs) for why vendor commitments hitting before revenue does is the classic trap. - **Quote-only pricing.** Acronis, ConnectWise, Autotask, NinjaOne, and N-able require account-specific pricing. Ask for every fee, commitment, overage, and renewal term in writing. ConnectWise PSA implementations have been reported at $10k–30k for mid-size shops. - **Auto-renewals** with narrow non-renewal windows. Calendar every renewal date the day you sign. Year-one policy: keep every vendor month-to-month until client contracts justify commitments. ## The consolidation market Practically every major MSP platform is now private-equity owned. Kaseya bought Datto for $6.2B in 2022 on top of IT Glue, Unitrends, and RapidFire Tools. ConnectWise went through a Thoma Bravo recap in 2019, and in early 2025 a Bregal Sagemount-led consortium took majority ownership at a reported $8B+ valuation, with $100M going into the AI-powered Asio platform. N-able is a post-SolarWinds spin-out. What it means for a buyer: expect continued price engineering, bundling pressure, and acquisitions of your favorite independent tools. The bundles are often genuinely cheap – Kaseya 365 put RMM+AV+EDR+MDR+backup at a few dollars per endpoint – but the structural lesson is to favor vendors with month-to-month terms and easy data export, so consolidation is an inconvenience rather than a hostage situation. ## AI features: assistive, not premium-worthy Most platforms now include AI-assisted features – Acronis RMM offers AI-assisted scripting, patch stability scoring, deployment support, and remote-session summaries; Autotask has Cooper Copilot, Atera has AI Copilot, SuperOps has Monica AI, and ConnectWise has Asio AI. These tools draft and summarize tickets, generate scripts, and reduce ticket time for a human. Useful, but none of it is autonomous operations. Treat AI as a tiebreaker between platforms you already like – don't pay a large premium for it yet. ## What it actually costs For a solo MSP at 100–200 endpoints, as of 2026: | Stack | Monthly | |---|---| | Integrated operations and protection through Acronis Cyber Protect Cloud | Quote-based; calculate from workloads, selected services, storage, and commitment tier | | Lean all-in-one (Syncro + Hudu + Bitwarden + Action1 free tier + accounting) | ~$200–280 | | Best-of-breed lean (Level or NinjaOne + lightweight PSA + Hudu + Splashtop + Bitwarden) | ~$450–550 | | Full point-product stack including [EDR](/wiki/glossary/edr)/MDR, backup, and email security | ~$800–2,000 ($5–13/endpoint) | Security and backup – not the core ops tools – dominate the real budget, which is why per-seat pricing to clients starts near $100+/user (see [pricing models](/wiki/msp-pricing-models) and the [security stack](/wiki/msp-security-stack)). A useful rule of thumb: tool spend should track roughly 8–15% of [MRR](/wiki/glossary/mrr). ## Standardize on one stack Whatever you pick, pick once. One RMM, one PSA, one backup product, one firewall brand, one EDR. Every additional product multiplies training, documentation, integration, and error surface, and "we support whatever the client already has" breaks the one-to-many economics that make managed services profitable. New clients migrate to your stack during [onboarding](/wiki/client-onboarding-process) – priced in, not absorbed. ## Where to start Price the Acronis integrated route first, including its minimum commitment, then compare it with a low-commitment point-product route: Syncro or Atera, Hudu, Bitwarden, Action1's free tier, and an accounting package. Choose from the complete monthly cost, required security coverage, contract terms, and technician workload, not the headline RMM price. Add security and backup per client as you sign them, keep everything month-to-month through year one, and budget any later platform migration before it becomes urgent. --- ## Churn Rate ## Definition Churn rate is the share of clients, or of recurring revenue, that an MSP loses over a period, usually a year. Logo churn is clients lost divided by clients at the start of the period. Revenue churn is [MRR](/wiki/glossary/mrr) lost from departed clients plus downgrades, divided by MRR at the start. The two diverge whenever the clients you lose are larger or smaller than average, so track both. ## Why it matters to an MSP Churn sets the ceiling on growth. An MSP adding $30,000 of new MRR a year against 10% revenue churn on a $500,000 base is losing $50,000 and shrinking; against 4% churn it is growing. Because labor and tooling costs do not fall when a client leaves, lost MRR comes almost entirely out of margin, and replacing it costs more than keeping it – a new SMB client typically consumes several months of its MRR in sales and onboarding labor before turning profitable. Typical ranges for an SMB-focused MSP: annual logo churn under 5% is top-quartile, 5–10% is normal, and above 10% points to something structural – pricing, service quality, or the client base. Revenue churn should sit at or below logo churn; if it is higher you are losing your best accounts. Net revenue retention above 100% – upsells outpacing losses – is the mature-book target. Separate the causes: clients acquired, closed, or out of business are outside your control; those who left for a competitor or took IT in-house are the number to work on, and each deserves an exit interview. Track it monthly in your [PSA](/wiki/glossary/psa) on a trailing twelve-month basis, next to [QBR](/wiki/glossary/qbr) coverage – clients who skip reviews leave without warning. The retention playbook is in [client retention and churn](/wiki/client-retention-and-churn). Related terms: [MRR](/wiki/glossary/mrr), [QBR](/wiki/glossary/qbr), [Client Offboarding](/wiki/glossary/client-offboarding) --- ## CIS Controls ## Definition The CIS Controls (Center for Internet Security Critical Security Controls, currently v8.1) are a free, prescriptive set of 18 security controls broken into specific safeguards, ordered roughly by impact. What makes them usable is the Implementation Group tiering: IG1 – 56 safeguards across 15 controls, labeled "essential cyber hygiene" – is explicitly designed for small organizations without dedicated security staff; IG2 adds safeguards for organizations handling sensitive or regulated data; IG3 covers mature, high-risk environments. ## Why it matters to an MSP CIS is the MSP channel's favorite framework because it answers "what exactly should we do" rather than "how should we think about risk." The proven pattern: run your own MSP at IG1 and graduate toward IG2 – you're a higher-value target than any single client – and use IG1 as the client assessment checklist. An IG1 gap assessment is a natural paid entry engagement and a structured way to scope a managed security offering; regulated clients graduate to IG2. Because it's prescriptive, it converts directly into your service catalog: each safeguard maps to a deliverable – [patch management](/wiki/glossary/patch-management), [MFA](/wiki/glossary/mfa) rollout, backup testing, logging. Then map results to the [NIST CSF](/wiki/glossary/nist-csf) when reporting to owners and insurers: CIS for the to-do list, CSF for the executive story. Related terms: [NIST CSF](/wiki/glossary/nist-csf), [Compliance](/wiki/glossary/compliance), [Vulnerability Management](/wiki/glossary/vulnerability-management) --- ## Client Offboarding ## Definition Client offboarding is the structured process of ending a managed services relationship: settling the contract, returning the client's data and documentation, handing over credentials and resold licenses, removing the MSP's agents and delegated access, and recording that all of it happened. It should be defined in the contract long before either side needs it. ## Why it matters to an MSP Offboarding is where an MSP's liability outlives its revenue. Three parts carry the risk. Credential handoff: every password, admin account, [MFA](/wiki/glossary/mfa) recovery code, and domain registrar login you hold is transferred in writing to the client or incoming provider, and every credential you ever used is rotated afterward – including service accounts and API tokens, which do not complain when missed and keep working for whoever holds them. Data return: the client owns its data and documentation, and you export and deliver them once final invoices are paid; you keep only your own tooling and methodology. Access revocation: [RMM](/wiki/glossary/rmm), backup, and EDR agents uninstalled, [GDAP](/wiki/glossary/gdap) relationships removed from the Microsoft tenant, [CSP](/wiki/glossary/csp-program) subscriptions transferred, VPN and remote-access accounts closed. Miss any of it and you are exposed: an agent left on a former client's machine is a breach path you no longer monitor, standing admin access in a tenant you no longer manage is a liability when that client is breached a year later, and unreturned data is a dispute you lose. Done well, offboarding is 10–25 technician hours for a small client, billed as transition assistance, and closed with a signed attestation that lists what was handed over and rotated – the document that ends the argument when the next provider blames you. The step-by-step version, with contract language and checklist, is in [the client offboarding process](/wiki/client-offboarding-process). Related terms: [GDAP](/wiki/glossary/gdap), [CSP Program](/wiki/glossary/csp-program), [MFA](/wiki/glossary/mfa), [Churn Rate](/wiki/glossary/churn-rate) --- ## Client Offboarding Process ## Offboarding starts in the contract Define [client offboarding](/wiki/glossary/client-offboarding) contractually *before* you need it. Your [MSA](/wiki/msp-contracts-and-msa) should state the transition assistance you will provide, at what rate, and the condition that all invoices are paid before data and credentials are handed over. Without that language you're negotiating terms during a breakup – the one moment when neither side is generous. **Roles and trigger:** assign a single offboarding owner (a senior tech or service manager) and run the exit as a project with a checklist – not as a loose pile of tickets. The trigger is written termination notice from either side. ## The process 1. **Confirm the contractual position.** Notice period, early-termination fee (commonly the remaining contract value or a defined buyout), and exactly what transition assistance you owe at what rate. Freeze new project work. 2. **Settle final billing.** Contracts usually condition data and credential handover on all invoices being paid – enforce it. Invoice transition assistance at the contracted rate as you go. Collecting is awkward now and nearly impossible after handover, when you no longer control the handoff. 3. **Enumerate everything you hold.** Pull the full inventory from your documentation platform: every credential, resold license, domain, tenant, deployed agent, and integration. This step is where [documentation standards](/wiki/msp-documentation-standards) pay off – with complete docs it's an export; without them it's archaeology under deadline. 4. **Hand over data and documentation.** Export and transfer all client data, documentation, and configurations: network diagrams, credential lists with MFA recovery codes, licensing inventory, ISP and vendor details, backup configuration. The client owns its data; your contract should already say so – what you keep is your own "Provider Work" (scripts, tooling, methodology), whose license to the client ends at termination. 5. **Transfer licenses, domains, and tenants.** Transfer or cleanly terminate every license you resold, per your contract obligations – for Microsoft 365 that means a [CSP](/wiki/glossary/csp-program) transfer to the incoming partner. Hand over domain registrar and DNS control if you held it, and remove your delegated admin relationships ([GDAP](/wiki/glossary/gdap)) from their tenant. 6. **Rotate credentials and remove access.** Enumerate every credential you ever held: domain admin, local admins, firewall and switch logins, VPN, [RMM](/wiki/glossary/rmm) and remote access, service accounts, scheduled tasks, backup agents, monitoring integrations, API tokens, SaaS admin logins – and the credential vault itself. Rotate in **published, sequenced batches**: rotating everything at once breaks integrations and looks like an outage to the client. The non-human credential sweep is where offboarding fails – service accounts and API tokens don't complain when you miss them; they just keep working for whoever holds them. 7. **Remove your agents and tools.** Uninstall RMM agents, AV/EDR, backup agents, and monitoring per your standard removal procedure, coordinated with the incoming provider's deployment. 8. **Record and attest.** Keep dated records of every credential rotated, access revoked, license transferred, and agent removed – then get the handover attested (below). ## The condensed checklist - Termination notice received; contract terms and dates confirmed - Final invoices issued and paid before handover - Data and documentation exported and delivered - Resold licenses transferred or terminated (M365 CSP, line-of-business apps) - Domain registrar / DNS control handed over - Delegated admin (GDAP) relationships removed - All human credentials rotated in sequenced batches - All non-human credentials swept: service accounts, scheduled tasks, API tokens, integrations - Agents and tools removed - Dated offboarding record archived; attestation of handover signed ## Protect yourself: the attestation of handover Dated records of everything rotated, revoked, and transferred are cheap to produce during offboarding and nearly impossible to reconstruct if a claim or audit lands a year later. If the former client suffers a breach six months out, your dated record showing when your access ended is the difference between a five-minute answer and a legal problem. Close the engagement with a short **attestation of handover**: a signed document listing what was delivered (data, documentation, credentials, licenses), what was rotated and removed, and confirming that your access has ended as of a stated date. It marks the clean end of your responsibility – and pairs with the offboarding terms your contract defined up front. Archive it with the dated records and your final copy of the client's documentation, and keep the bundle for as long as your contract's survival clauses and your insurer expect. ## Exit criteria and the long game The offboarding is done when: - No credential you ever held remains valid, human or non-human - No agent of yours is still reporting from their environment - No license is still billing to you - The final invoice is paid and the signed attestation is archived with the dated records Then exit gracefully. Departing clients boomerang and refer – the shop they leave you for may disappoint, and the person who managed the exit remembers exactly how it went. Some [churn](/wiki/glossary/churn-rate) happens to even well-run MSPs; a professional exit is the last impression you control, and in a local market it's also marketing. Run the departure with the same discipline as your [client onboarding](/wiki/client-onboarding-process) – the two processes bookend every relationship, and both get talked about. --- ## Client Onboarding Process ## Why onboarding sets the churn trajectory Onboarding is where the client relationship is won or lost – months before any renewal conversation. The economics force the point: onboarding a 100-seat client typically costs roughly $10–15K in tool deployment, documentation, monitoring setup, and security baselining, and payback usually lands around month 9–10. A client who churns early is a straight loss, so everything about onboarding should be designed to make the first 90 days feel decisive: visible improvements the client can feel, clean communication, and no billing surprises. First impressions calcify – a client who experiences a crisp, structured start extends that trust for years; one who experiences 90 days of silence and mystery invoices starts comparing vendors. Onboarding is also when you have maximum permission to change things. "New provider, new standards" is expected on day 30 and resented on day 300. Two structural decisions precede day 1: a signed agreement – see [contracts and the MSA](/wiki/msp-contracts-and-msa) – and the commitment that this client moves to your standard stack during onboarding, priced into the onboarding fee or the first-year rate. Taking over whatever they have, as-is, indefinitely is a classic new-MSP mistake. ## Phase 1 – days 1–30: discovery, documentation, quick wins **Kickoff meeting (day 1).** Attendees: the client's decision-maker plus their day-to-day contact, and you (or the account lead plus lead tech). Cover: scope and what's explicitly out of scope, how to get support (channels, hours, what "P1" means), the 30/60/90 plan itself with dates, named contacts on both sides, and what will change for staff. Leave with access grants scheduled and the approved-requester list agreed – who may authorize changes and password resets. **Discovery and assessment.** Run a full [network assessment](/wiki/network-assessment-process): topology, asset inventory, access validation (can you actually administer everything you're now responsible for?), licensing, backup viability check – verify backups exist *and restore* – and a security posture review. Deploy the [RMM](/wiki/glossary/rmm) agents and endpoint protection early; monitoring data enriches everything after it. **Documentation capture.** Everything discovery touches gets captured into your standard structure – diagram, credentials into the vault, ISP/vendor/licensing details, backup configuration – per your [documentation standards](/wiki/msp-documentation-standards). Completed documentation is an explicit onboarding deliverable with a due date, not something that accretes from tickets over the next two years. **Quick wins the client can feel.** Don't wait for "stabilization" – triage the high-risk findings immediately: enforce [MFA](/wiki/glossary/mfa), get [EDR](/wiki/glossary/edr) on every endpoint, deploy email security, and patch the scary stuff. These matter twice: they close the riskiest gaps during the window when an incident would be blamed on you anyway, and they give the client visible evidence in week two that hiring you changed something. **Communication to client staff.** End users decide whether onboarding "worked" as much as the owner does. Send (or have the client sponsor send) a short announcement: who you are, how to open a ticket, what will change and when. Announce each rollout – MFA enrollment especially – before it happens, with a deadline and a help path. Surprise security prompts generate a flood of suspicious-email reports and resentment; announced ones generate compliance. **Exit criteria for Phase 1:** - Kickoff held; support channels and approved-requester list communicated to staff - Assessment complete; findings triaged with high-risk items remediated or scheduled - RMM/agents and endpoint protection deployed to all in-scope devices - Backup viability verified with at least one test restore - Core documentation set complete in the platform (diagram, credentials, vendors, licensing, backup config) - 30-day check-in call held with the sponsor ## Phase 2 – days 31–60: standardization This is the migration phase: move the client onto your standard stack – backup, AV/EDR, email security, and the rest of your one-of-each toolset – and remediate the remaining assessment findings. Every product you leave in place "for now" is a permanent special case that multiplies training, documentation, and error surface; margin leaks trace directly to stack sprawl. Alongside the technical work: tighten process (ticket habits are forming now – reinforce "every request becomes a ticket"), and run user training where the assessment showed the need, security awareness first. **Exit criteria for Phase 2:** - Client running on your standard backup, endpoint, and email security stack (or a dated exception documented per item) - Assessment findings remediated or explicitly accepted by the client in writing - Staff using standard support channels; walk-up/DM requests redirected to tickets - Documentation updated to reflect the migrated environment - 60-day check-in call held ## Phase 3 – days 61–90: optimization and the first QBR With the environment standardized, tune it: adjust alerting thresholds so the noise floor drops (a misconfigured environment announces itself as ticket volume), establish baseline reporting, and reconcile the asset inventory against what monitoring actually sees. Then convert onboarding into an ongoing strategic relationship: schedule and hold the first [QBR](/wiki/qbr-process) at roughly day 90. Present what was found, what was fixed, the baseline scorecard, and the agreed 12–36 month technology roadmap. This meeting sets the cadence that becomes your best long-term [churn](/wiki/glossary/churn-rate) defense – the client's first quarter ends with proof of progress and a plan, not an invoice and silence. **Exit criteria for Phase 3:** - Alerting tuned; monitoring noise at a sustainable level - Baseline service report produced (ticket volume, response attainment, endpoint counts) - First QBR held with the decision-maker; technology roadmap agreed - 90-day check-in complete; onboarding formally closed with the client ## Cadence and roles summary | Element | Rhythm | Owner | |---|---|---| | Kickoff | Day 1 | Account lead + client sponsor | | Check-in calls | Days 30 / 60 / 90 | Account lead | | Assessment and remediation | Days 1–30 | Lead tech | | Stack migration | Days 31–60 | Lead tech | | First QBR | ~Day 90 | vCIO / founder | The 30/60/90 check-ins are not ceremony – they surface friction while it is still fixable, before it hardens into the quiet dissatisfaction that shows up eighteen months later as a termination notice. ## Bottom line Run onboarding as a project with three phases and hard exit criteria: discover, document, and deliver security quick wins by day 30; standardize onto your stack by day 60; optimize and hold the first QBR by day 90. Price it properly, communicate relentlessly with the people who live in the environment, and treat finished documentation as a deliverable. The MSPs with sub-5% churn didn't get there at renewal time – they got there in the first 90 days. --- ## Client Retention and Churn ## Churn is the number your multiple is built on An [MSP](/wiki/glossary/msp) is valued on the durability of its recurring revenue, and [churn](/wiki/glossary/churn-rate) is the direct measure of durability. A shop losing 15% of its clients a year has to resell 15% of its base just to stand still; a shop losing 4% compounds. The difference shows up in growth rate, sales cost, and the multiple a buyer will pay. Most small MSPs only compute churn when a broker asks. Compute it monthly. ## Logo churn versus revenue churn **Logo churn** is the share of clients lost. Monthly: clients who terminated this month divided by clients at the start of the month. Annualize by summing twelve months, not multiplying one by twelve – a single lumpy month distorts the picture. **Revenue churn** is the share of [MRR](/wiki/glossary/mrr) lost, in two flavors. *Gross revenue churn* is MRR lost to cancellations plus downgrades and seat reductions, divided by starting MRR. *Net revenue retention* (NRR) is starting MRR plus expansion – added seats, upsold services, price increases – minus churn and contraction, divided by starting MRR. NRR above 100% means the existing base grows without a single new logo. The two diverge. Losing three ten-seat clients is 3% logo churn at a hundred clients and barely dents MRR; one 150-seat anchor is 1% logo churn and can be 15% of revenue. A client who drops from 60 seats to 35 shows up nowhere in logo churn while taking 40% of the contract with them. Pull both numbers from your [PSA](/wiki/glossary/psa) agreements and accounting each month, and put a name on every dollar lost. ## What healthy looks like Typical as of 2026: top-quartile MSPs hold logo churn under 5% per year, roughly 0.4% per month. The broad middle runs 5–10%; above 10–12% something structural is wrong – wrong-fit clients, weak onboarding, or a failing service desk. On revenue, gross revenue churn under 1% per month is good; NRR of 100–110% is healthy for an MSP that does annual price increases and grows with its clients, and NRR below 95% means the base is shrinking under you regardless of what sales reports. Track clients you fired on purpose separately; a buyer will ask about both. ## The leading indicators Churn is rarely sudden. The notice letter arrives six to twelve months after the relationship actually broke. Watch for: - **Ticket sentiment.** Not volume – tone. Per-ticket CSAT dipping, terse replies, "again" in subject lines. Three negative surveys from one client in a quarter is a phone call, not a dashboard entry. - **QBR attendance.** The client who reschedules the [QBR](/wiki/glossary/qbr) twice and then sends a junior instead of the decision-maker has already downgraded you from partner to vendor. - **Declining seat counts.** Each reduction is either a business in trouble or a business moving work somewhere else. Ask which. - **Payment lateness.** A client who paid net-15 for three years and slides to net-45 is either cash-strapped or has decided your invoice matters less. - **A new internal IT hire.** The most reliable predictor of all. Sometimes it means co-managed growth; often someone was hired to "evaluate our IT spend." Meet them in their first two weeks and make them successful, or they will make their case by replacing you. - **Silence.** No tickets and no calls for 90 days is not a happy client; it is one who has stopped expecting anything from you. Score every client quarterly; two or more flags puts them on an at-risk list the owner reviews personally. ## The first 90 days decide most churn Clients who leave in year one almost always decided in the first quarter. Onboarding is where sales promises meet delivery, and any gap – a migration that ran long, a ticket that fell through – becomes the story the client tells about you for the rest of the contract. Over-invest here: a named point of contact, a 30-day check-in with the owner, a 60-day ticket-volume review, and a 90-day mini-QBR that shows what changed. The [client onboarding process](/wiki/client-onboarding-process) covers the mechanics; the retention point is that the first 90 days are a sales activity. ## The retention levers **QBR cadence.** The single most effective retention activity is a QBR a business owner finds worth attending: risk register, roadmap, budget, what you did and what it prevented. Quarterly above roughly 25 seats, semi-annual below. The [QBR process](/wiki/qbr-process) is worth running even when it feels like overhead; the clients who skip it are the ones who leave. **vCIO.** A [vCIO](/wiki/glossary/vcio) function moves you from ticket-taker to advisor. A client with a three-year roadmap built with you cannot leave without abandoning the roadmap. **Documented value reporting.** Clients do not see the 200 patches or the backup that restored quietly. Send a one-page monthly or quarterly report that says what you did and what it prevented, in business terms. Invisible work is unvalued work, and unvalued work gets shopped. **Price increases done right.** Not raising prices is itself a retention risk, because it erodes margin until you cut service. The clients who leave over an increase are the ones surprised by it. Write annual increases into the MSA at signing, notify 60–90 days ahead with a value summary, apply them to everyone on the same date, and never negotiate individually. Typical annual increases run 5–8% as of 2026, higher when tool costs jump. ## When to fire a client Some churn should be yours. Fire a client who stays unprofitable after a pricing correction, refuses baseline security controls, abuses your staff, or habitually pays late. Run the agreement-profitability report from your [KPI review](/wiki/msp-kpis-and-benchmarks) monthly and give the bottom client a choice: new price, or a referral to someone better suited. Give 60–90 days and run the [client offboarding process](/wiki/client-offboarding-process) cleanly. Deliberate churn of the wrong clients improves margin, morale, and the churn number that matters. ## How churn feeds valuation Buyers pay for recurring revenue and discount it by how sticky it is. Typical as of 2026: shops under $1M EBITDA trade around 4–7x adjusted EBITDA, larger and better-run ones 8–12x, and the spread is mostly explained by three things a buyer checks in the first week of diligence – recurring revenue percentage, logo churn, and NRR. Sub-5% churn and NRR over 100% support the top of the range; 12% churn and NRR under 95% push you to the bottom or into an earn-out. Client concentration compounds it: a top client over 15–20% of revenue is a discount regardless of how loyal they seem. A year of clean monthly churn data, with a recorded reason for every lost client, is one of the cheapest things you can bring to diligence. ## Bottom line Measure logo and revenue churn monthly from your PSA and accounting, name every dollar lost, and aim for under 5% logo churn and NRR above 100%. Watch the leading indicators – sentiment, QBR attendance, seat counts, payment timing, the new IT hire – and act on two flags. Win the first 90 days, run QBRs that owners attend, report value in writing, raise prices on a schedule, and fire the clients who cost you the rest. Churn is the multiple you will sell for. --- ## CMMC ## Definition CMMC (Cybersecurity Maturity Model Certification) is the US Department of Defense program that verifies contractors and their subcontractors protect federal contract information (FCI) and controlled unclassified information (CUI). CMMC 2.0 has three levels: Level 1 is an annual self-assessment against the basic safeguarding practices of FAR 52.204-21 for companies handling only FCI; Level 2 is the 110 controls of NIST SP 800-171 for anyone handling CUI, verified every three years by a certified third-party assessor organization (C3PAO) for most contracts; Level 3 adds a subset of NIST SP 800-172 and is assessed by the government itself. ## Why it matters to an MSP CMMC clauses have been in DoD contracts since November 2025, with C3PAO certification becoming a condition of award for Level 2 work through 2026 and 2027. The DoD's own estimates put the Defense Industrial Base at roughly 220,000 companies, with on the order of 75,000 needing Level 2 certification. Few can reach 110 controls alone, which makes this a genuine niche: engagements typically start at $50K for the enclave build plus a monthly managed stack at a 25–35% premium over a comparable commercial client. The price of entry is your own [compliance](/wiki/glossary/compliance). An MSP that touches CUI or the systems holding it is an external service provider inside the client's assessment scope; assessors expect a shared responsibility matrix stating which controls you own, and most MSPs here pursue Level 2 themselves to evidence their side. Expect a CUI enclave in a government cloud, US-persons support staff, [MFA](/wiki/glossary/mfa), FIPS-validated encryption, and audit logs you can produce on demand. Don't enter opportunistically: a failed client assessment is a lost contract, and the fault is yours. See [compliance frameworks comparison](/wiki/compliance-frameworks-comparison) for how it compares with SOC 2 and HIPAA. Related terms: [Compliance](/wiki/glossary/compliance), [NIST CSF](/wiki/glossary/nist-csf), [SOC 2](/wiki/glossary/soc-2), [MFA](/wiki/glossary/mfa) --- ## Compliance ## Definition Compliance is demonstrable conformance to an external standard – a law, a regulation, a contractual framework, or an insurer's requirements – proven with evidence a third party can examine. It is not the same thing as security. Security is the actual state of your controls; compliance is the documented proof that specific required controls exist, operate, and are checked on a schedule. A client can be compliant and still get ransomed, and a well-secured client with no evidence trail still fails the audit. ## Why it matters to an MSP For an SMB-focused MSP, four frameworks cover most of the demand: [HIPAA](/wiki/glossary/hipaa) for healthcare clients and their business associates, [SOC 2](/wiki/glossary/soc-2) for services firms whose customers require it, [CMMC](/wiki/glossary/cmmc) for defense-supply-chain manufacturers, and PCI DSS for card payments. They overlap heavily – [MFA](/wiki/glossary/mfa), patching, logging, backup, access review – so the [CIS Controls](/wiki/glossary/cis-controls) work as one baseline mapped to whichever framework a client needs; see [compliance frameworks comparison](/wiki/compliance-frameworks-comparison) for the differences. The economics make compliance worth specializing in. The work is recurring – evidence collected monthly, policies reviewed annually, audits repeated on a cycle – so it fits a managed contract naturally. Compliance-managed seats typically price 15–35% above a standard plan depending on the framework, and regulated clients churn less because switching providers means re-proving everything to an auditor. The same artifacts do triple duty: a monthly patch-compliance report is QBR material, audit evidence, and [cyber insurance](/wiki/glossary/cyber-insurance) documentation. Exposure cuts both ways: as the client's IT provider you are inside their audit scope, and a control you promised but did not run becomes your finding and your liability, so treat every contractual compliance commitment as a deliverable with an owner and a schedule. Productizing it is covered in [compliance as a service](/wiki/compliance-as-a-service). Related terms: [HIPAA](/wiki/glossary/hipaa), [SOC 2](/wiki/glossary/soc-2), [CMMC](/wiki/glossary/cmmc), [vCISO](/wiki/glossary/vciso) --- ## Compliance as a Service ## Why compliance is the stickiest revenue you can sell [Compliance](/wiki/glossary/compliance) work is recurring by nature: regulations don't churn, audits and renewals come every year, and evidence has to be collected every month. It's high-margin because you're selling expertise and process, not reselling licenses at thin markup. And it's a moat – a generalist competitor can undercut your per-seat price, but they can't quote a CMMC enclave or walk a dental practice through a HIPAA risk analysis. Healthcare-focused MSPs typically command 25–35% price premiums as of 2026, which is the niche math working as intended – see [choosing a niche](/wiki/choosing-a-niche). The standard packaging: an initial paid gap assessment as the anchor engagement, then an ongoing compliance retainer sold as a $500–2,500/mo add-on per client, depending on framework and client size. ## The frameworks an SMB-focused MSP actually meets | Framework | Who it hits | Status as of 2026 | |---|---|---| | HIPAA | Medical, dental, health-adjacent | Proposed Security Rule overhaul pending; sell to it now | | CMMC 2.0 | Defense contractors and their suppliers | DFARS clauses live in DoD contracts since Nov 2025 | | FTC Safeguards Rule | Auto dealers, mortgage/finance-adjacent | Fully enforced since June 2023 | | SOC 2 | Any client selling B2B services | Market-driven, demanded by clients' customers | | State privacy laws | Consumer-data businesses | Growing state-by-state patchwork | **[HIPAA](/wiki/glossary/hipaa).** As the IT provider for a covered entity, your MSP is a Business Associate: you sign BAAs and your own stack must be HIPAA-fit. The December 2024 HHS OCR proposed rule – the biggest Security Rule update since 2003 – would make MFA, encryption, asset inventories, and annual penetration testing mandatory rather than "addressable." It remained pending through 2025–26, but sell to it now: clients who close those gaps early avoid a scramble later. **[CMMC](/wiki/glossary/cmmc) 2.0.** The program rule took effect December 16, 2024, and the DFARS acquisition rule took effect November 10, 2025 – CMMC clauses now appear in actual DoD contracts, in Phase 1 of a three-year rollout (self-assessments first, then third-party certification). Level 1 covers FCI with 17 self-assessed practices; Level 2 covers CUI with 110 NIST 800-171 controls, mostly third-party assessed. The critical catch for MSPs: **if you touch CUI or the systems holding it, your MSP must meet the client's CMMC level**, and assessors expect a Shared Responsibility Matrix documenting who does what. Typical delivery is a GCC High enclave plus a managed 800-171 stack in $50K+ engagements – lucrative, but enter deliberately, not opportunistically. **FTC Safeguards Rule.** Applies to auto dealers and other finance-adjacent "financial institutions"; fully enforced since June 2023, with a 2025 FTC FAQ clarifying dealer expectations. It requires a written information security program, a designated Qualified Individual (often an MSP-supported role, though the dealer keeps legal responsibility), risk assessments, MFA – explicitly including service-provider and DMS vendor access – encryption, monitoring and pen testing, vendor oversight, an IR plan, and FTC breach notification within 30 days once 500+ consumers are affected. Dealers are an underserved vertical tailor-made for a packaged compliance bundle. **[SOC 2](/wiki/glossary/soc-2).** Not a law but a market force: your clients' enterprise customers demand it in vendor reviews. The MSP implements and evidences the controls; an independent CPA firm performs the audit. Helping a client reach SOC 2 makes you structurally involved in how they win their own deals – stickiness money can't buy. **State privacy laws.** A growing patchwork of state statutes governing consumer data. The practical MSP work is data inventory and mapping, retention and minimization, and breach-notification readiness – usually folded into the broader compliance retainer rather than sold standalone. ## What you actually deliver 1. **Gap assessment – paid, always.** The anchor engagement: assess the client against the framework and produce a findings report. HIPAA security risk analyses typically run $2K–20K as of 2026 depending on practice size. A prescriptive checklist like [CIS Controls](/wiki/glossary/cis-controls) IG1 mapped to the target framework keeps assessments consistent and repeatable. Never do this free – free assessments position you as a sales gimmick, paid ones as a professional. 2. **Remediation roadmap.** A prioritized, priced plan to close the gaps. This is where your standard [security stack](/wiki/msp-security-stack) gets sold – the same EDR, MFA, backup, and training the framework demands. 3. **Policies and procedures.** A tailored policy library, typically $2K–5K as of 2026 – tailored being the operative word; auditors and regulators recognize an untouched template instantly. 4. **Workforce training.** Framework-specific training on top of general security awareness, typically $20–100/employee/yr. 5. **Evidence collection.** Continuously filed proof – EDR console exports, backup restore-test logs, MFA enforcement reports, access reviews, tickets. Audits are won or lost here, not in the two weeks before the auditor arrives. 6. **Ongoing monitoring and quarterly reviews.** Compliance drift review in the QBR, plus [vCISO](/wiki/glossary/vciso)-style reporting that translates control status for the client's leadership. ## Tooling Compliance platforms automate control mapping, evidence collection, and reporting so the retainer doesn't drown in spreadsheets. Acronis Cyber Compliance, built into Acronis Cyber Protect Cloud, provides CIS Controls v8.1 scoring, centralized visibility across client tenants, and guidance for closing technical-control gaps. For framework-specific workflows, healthcare platforms such as Compliancy Group and ComplyAssistant typically run $100–500 per practice per month as of 2026. Todyl also bundles GRC functions with its security platform. Treat the platform as the delivery vehicle: the license is a pass-through cost, and the margin lives in the assessment, remediation, and review services wrapped around it. ## The attestation trap Insurance carriers and compliance frameworks send questionnaires the client can't answer alone – "Is MFA enforced on all remote access?" – so the MSP maps each question to deployed controls and supplies the evidence. Do that work. But the hard rule, backed by broker guidance and channel consensus: **fill in the facts, never sign the form.** Misstatements on insurance applications have led carriers to rescind coverage or deny claims after a breach – the ICSR/Travelers rescission case is the canonical example – and an MSP that wrongly attested "MFA everywhere" lands in the E&O crossfire alongside its client. The safe practice: provide written control status to the client, have the client's own officer sign the attestation, keep your evidence on file, carry your own E&O and cyber coverage, and put client-must-carry-[cyber insurance](/wiki/glossary/cyber-insurance) language in your MSA – see [MSP legal and insurance](/wiki/msp-legal-and-insurance). ## When to partner instead of DIY - **Certified assessments.** CMMC Level 2 requires a C3PAO; SOC 2 requires a CPA firm. You can't audit your own work, and the frameworks require independent assessors anyway. - **Legal judgment calls.** Breach notification decisions, BAA disputes, and regulator responses are attorney territory – notification clocks are counsel's call, not yours. - **Penetration testing.** Use independent testers; HIPAA's proposed update would make annual pen tests mandatory, and self-testing convinces no one. - **Your first engagement in a new framework.** Partner with an experienced consultant on client one, keep the managed-services side, learn the process, then deliver client two yourself. The governing principle from the CMMC world applies everywhere: compliance can be outsourced in implementation, but never in accountability. The client owns the outcome – say so in writing. ## Where to start Pick the one framework your niche actually faces – Safeguards for dealers, HIPAA for practices, CMMC only if you're prepared to certify your own shop. Productize a fixed-price gap assessment, take one client end-to-end with a consultant partner if needed, then package what you learned as a monthly retainer. Compliance clients rarely leave: every audit cycle, insurance renewal, and new regulation deepens the relationship you already own. --- ## Compliance Frameworks Compared: HIPAA, SOC 2, CMMC, PCI DSS, and NIST CSF ## Five frameworks, three kinds of obligation Clients say "we need to be compliant" as if it were one thing. Of the five frameworks a small-business [MSP](/wiki/glossary/msp) actually meets, one is federal law, two are contract terms, and two are voluntary – and "compliant" ranges from a self-signed checklist to a year-long third-party assessment. [Compliance as a service](/wiki/compliance-as-a-service) covers selling and delivering the retainer; this is the comparison behind choosing which framework to build it on. ## HIPAA **Who:** covered entities – providers, health plans, clearinghouses – and every business associate handling protected health information for them. **Obligation:** federal law, enforced by HHS Office for Civil Rights. Penalties top out above $2M per violation category per year as of 2026. **What compliant means:** there is no [HIPAA](/wiki/glossary/hipaa) certification. Compliance is self-attested and evidenced – a documented risk analysis, policies, training, signed business associate agreements, and proof the safeguards exist. Nobody checks until something goes wrong; then OCR's first request is the risk analysis. **Typical cost and timeline:** a small-practice risk analysis $2K–20K, a tailored policy set $2K–5K, a compliance platform $100–500 per practice per month; three to six months to documented compliance, refreshed annually. **For your shop:** you are a business associate with direct liability. You sign a BAA with every covered-entity client, and your own stack must be HIPAA-fit. ## SOC 2 **Who:** any company whose customers ask for it – B2B SaaS, professional services, anyone selling into enterprises. **Obligation:** voluntary attestation that becomes contractually required the day a large customer's procurement team asks. No regulator, no law. **What compliant means:** an independent CPA firm audits the client's controls against the AICPA Trust Services Criteria and issues a report. Type I covers control design at a point in time; Type II covers operation over a three-to-twelve-month window. There is no pass or fail – only a report with or without exceptions, shared under NDA. **Typical cost and timeline:** audit $10K–30K plus readiness work and evidence-automation tooling of $5K–20K a year; a first Type II takes six to twelve months, then annually. **For your shop:** in the client's report you are a subservice organization. The auditor either carves you out – noting the client relies on its MSP for certain controls – or includes you, and your controls get tested too. An MSP holding its own [SOC 2](/wiki/glossary/soc-2) Type II answers evidence requests with one attachment instead of a week of screenshots. ## CMMC **Who:** Department of Defense contractors and subcontractors handling federal contract information or controlled unclassified information. **Obligation:** contractual. The DFARS clause has been in new DoD solicitations since November 2025, phasing in through 2028; no level, no contract. **What compliant means:** Level 1 is an annual self-assessment against 15 basic safeguarding requirements, affirmed in SPRS. Level 2 is the 110 controls of NIST SP 800-171; most contracts require a certified third-party assessor, with certification valid three years and annual affirmations between. **Typical cost and timeline:** Level 1, a few thousand dollars. Level 2 implementation $50K–150K for a small contractor, the assessment $30K–60K, twelve to eighteen months end to end. **For your shop:** you are an external service provider. Touch CUI or the systems holding it and you are inside the client's assessment scope, expected to meet Level 2 yourself and to document which controls you own in a shared responsibility matrix. You cannot sell [CMMC](/wiki/glossary/cmmc) to one client and stay out of scope. ## PCI DSS **Who:** anyone that stores, processes, or transmits payment card data – retail, hospitality, medical front desks. **Obligation:** contractual, imposed by the card brands through the merchant's acquiring bank. Not a law. Non-compliance means acquirer fines and liability for fraud losses after a breach. **What compliant means:** nearly every SMB client is a Level 4 merchant completing an annual self-assessment questionnaire plus, for most questionnaire types, quarterly external scans from an approved scanning vendor. Version 4.0.1 has been fully mandatory since April 2025. **Typical cost and timeline:** with hosted payment pages and encrypted terminals, under $1K–3K a year including scans. **For your shop:** the job is scope reduction. Keep card data off the client's network – validated terminals, tokenized payments, a segmented VLAN for what must remain – and the questionnaire shrinks from hundreds of questions to a few dozen. Manage in-scope systems and PCI treats you as a third-party service provider whose responsibilities the client must document in writing. ## NIST CSF **Who:** everyone and no one. Version 2.0 (2024) is the vocabulary regulators, insurers, and boards use for security programs. **Obligation:** voluntary. Nobody is certified against it. **What compliant means:** there is no compliant. An organization profiles itself across six functions – Govern, Identify, Protect, Detect, Respond, Recover – producing a current state and a target state. **Typical cost and timeline:** a current-profile assessment for a small business $5K–15K over a few weeks. **For your shop:** write assessment reports in [NIST CSF](/wiki/glossary/nist-csf) language, because the client's insurer, lawyer, and future auditor all speak it. It is not a niche. ## Where the controls overlap Strip the paperwork and all five ask for the same technical core: an inventory of assets and accounts, [MFA](/wiki/glossary/mfa) and least privilege, patching and [vulnerability management](/wiki/glossary/vulnerability-management), endpoint protection, logging, tested backups, [security awareness training](/wiki/glossary/security-awareness-training), incident response, and vendor management. [CIS Controls](/wiki/glossary/cis-controls) Implementation Group 1 – 56 safeguards – covers that core and publishes mappings to each framework, so a client at IG1 is most of the way through any of them. What differs is everything around the core. Scope: which data triggers the obligation. Governance: HIPAA wants a risk analysis and BAAs, SOC 2 wants policies and change evidence, CMMC wants a control-by-control system security plan. Verification: self-attestation for HIPAA, CMMC Level 1, and small PCI merchants; independent assessment for SOC 2 and CMMC Level 2. Build one technical baseline and one evidence habit, then layer framework-specific paperwork on top – never five separate programs. ## Pick one, not all five Claiming all five marks you as a generalist, and buyers can tell. HIPAA points at practices that exist in every metro, buy on trust, and rarely leave. SOC 2 points at growing B2B firms that pay well and expect you to hold a report yourself. CMMC points at defense manufacturing clusters where engagements are large, slow, and require your own certification first. PCI is an adjacent obligation for hospitality and retail clients, not a specialty; NIST CSF is what you assess against when a client has no regulator. Match the pick to the businesses within an hour's drive and to your appetite for auditing your own shop – see [choosing a niche](/wiki/choosing-a-niche) – and take three clients through a full cycle before adding a second framework. ## Bottom line HIPAA is law with self-attested compliance and a BAA on your desk. SOC 2 is a customer-driven audit that makes you a subservice organization. CMMC is a contract gate that pulls your own shop into scope. PCI is a card-brand contract you win by keeping card data away from anything you manage. NIST CSF is shared vocabulary, not a credential. The technical controls overlap almost entirely, so the real choice is which paperwork, which verifier, and which clients you want for the next decade. Choose one. --- ## CSP (Cloud Solution Provider) Program ## Definition The Cloud Solution Provider (CSP) program is Microsoft's channel licensing program: it lets partners resell Microsoft 365, Azure, and Dynamics subscriptions, own the customer billing relationship, and administer customer tenants (via [GDAP](/wiki/glossary/gdap)). It comes in two flavors: direct-bill, where you transact with Microsoft directly – with revenue thresholds and support obligations most small partners can't meet – and indirect, where you buy through a distributor (Pax8, Sherweb, Ingram Micro, TD Synnex) at a discount off MSRP and resell at MSRP or a small markup. Almost every small MSP is an indirect reseller; Pax8 and Sherweb are the MSP-native favorites. ## Why it matters to an MSP License margin is thin – typically 8–16% gross before the labor of billing reconciliation – so CSP isn't a profit center; it's strategic control. Owning the tenant and the billing keeps support clean, raises switching costs, feeds your all-in [per-seat price](/wiki/glossary/per-seat-pricing), and keeps rival advisors out of the account. The trap to manage is NCE (New Commerce Experience) commitment terms: monthly-term subscriptions cost about 20% more than annual-term; annual and 36-month terms lock seat counts (you can add, not reduce) with only a 7-day cancellation window; and since April 2025, annual-term-with-monthly-billing carries a ~5% surcharge. Standard pattern: annual term for the stable seat base, monthly term for volatile seats – and make clients contractually own the commitment so a shrinking client doesn't leave you paying for abandoned seats. Related terms: [GDAP](/wiki/glossary/gdap), [Per-Seat Pricing](/wiki/glossary/per-seat-pricing), [MRR](/wiki/glossary/mrr) --- ## Cyber Insurance ## Definition Cyber insurance (also sold as cyber liability) covers the costs of a security incident – forensics, breach counsel, notification, business interruption, extortion payments, and third-party claims. For an MSP it exists in two forms: the policy you carry yourself, usually bundled with technology errors and omissions (E&O) coverage, and the policy each client carries, whose application questionnaire has become the de facto security standard for small business. ## Why it matters to an MSP Your own policy is the backstop for the worst day in the business: a client breached through your [RMM](/wiki/glossary/rmm), a technician's mistake wiping a server, a [ransomware](/wiki/glossary/ransomware) event that spreads across tenants. Tech E&O plus cyber at $1M–$2M limits typically costs a small MSP low-to-mid four figures a year as of 2026, and the premium is underwritten on your own controls – [MFA](/wiki/glossary/mfa) everywhere, [EDR](/wiki/glossary/edr) on your systems, tested backups, no standing admin access. Serious MSA negotiations will ask for your certificate of coverage. The client-side policy is where the sales and delivery mechanics live. Since the 2020–22 ransomware losses, the standard questionnaire demands MFA on email, remote access, and privileged accounts, EDR or [MDR](/wiki/glossary/mdr) on every [endpoint](/wiki/glossary/endpoint), offline or immutable backups with documented restore tests, email filtering, [security awareness training](/wiki/glossary/security-awareness-training), and patching cadence. Weak answers mean 40–100% premium increases, ransomware sublimits, co-insurance, or declination – so "your carrier requires this" closes upgrades ROI arguments cannot, and every renewal is a sales event. Never sign the attestation yourself: give the client written control status with evidence, have their officer sign, keep your copy, and require in your MSA that they carry their own policy. Post-incident, the carrier's hotline is the first call, because an unapproved responder can forfeit coverage. See [cyber insurance readiness](/wiki/cyber-insurance-readiness) for the questionnaire-to-control mapping. Related terms: [MFA](/wiki/glossary/mfa), [EDR](/wiki/glossary/edr), [Ransomware](/wiki/glossary/ransomware), [BDR](/wiki/glossary/bdr) --- ## Cyber Insurance Readiness for MSP Clients ## Underwriting became a technical audit Five years ago a client got [cyber insurance](/wiki/glossary/cyber-insurance) by answering six yes/no questions. After the 2020–22 [ransomware](/wiki/glossary/ransomware) loss cycle, carriers rewrote the process: multi-page applications, external scans of the applicant's attack surface, and a short list of controls without which they will not write the policy. That list – [MFA](/wiki/glossary/mfa) everywhere, [EDR](/wiki/glossary/edr) on every endpoint, immutable or offline backups, a patching cadence, email security, privileged access controls, [security awareness training](/wiki/glossary/security-awareness-training), and an incident response plan – is now the de facto SMB security baseline, and the carrier enforces it better than any regulator. For a typical SMB, a clean application means a premium of roughly $1,500–5,000 per year for a $1M limit; a weak one means a 40–100% increase, a ransomware sublimit of $100–250K with co-insurance, or a declination. Typical 2026 figures. That is a sales lever no ROI spreadsheet can match: the client's own carrier tells them, in writing, to buy what you sell. ## How the questionnaire works – and why a wrong answer voids the claim The application is not a survey. Its answers become part of the policy, as warranties or representations the carrier relied on. If a claim investigation finds a material misstatement, the carrier can rescind the policy from inception. In the canonical 2022 case the insured checked "yes" to MFA on email and servers when MFA covered only the firewall; after a ransomware loss the carrier sued to rescind the policy and the insured agreed to rescission. So every "yes" must be true for every user, every device, and every system the question covers, on the date of signing. "Mostly" is a "no." The common false positives are MFA (most users, with legacy authentication or a service account left open), EDR (workstations but not servers, or not the owner's home PC), and backups (running, never restore-tested, reachable with domain admin credentials). Read each question literally; where the honest answer is "no" or "partially," say so and attach a remediation date. Carriers price partial controls far better than they treat a rescinded claim. ## The checklist mapped to what you deliver Every application line maps to a service you already deliver: - **MFA on email, remote access, and privileged accounts** – conditional access, legacy authentication disabled, phishing-resistant methods for admins. Evidence: the identity platform's enforcement report; see [identity and access for SMB](/wiki/identity-and-access-for-smb). - **EDR on all endpoints and servers, 24/7 monitored** – managed EDR with an [MDR](/wiki/glossary/mdr) service behind it. Evidence: console coverage reconciled against the asset list. - **Immutable or offline backups, tested** – a [BDR](/wiki/glossary/bdr) design with an immutable copy, credentials separate from the domain, and a dated restore test with a recovery time. See the [backup and DR process](/wiki/backup-dr-process). - **Patching cadence** – critical patches within 14 days under a [patch management](/wiki/glossary/patch-management) schedule, end-of-life systems isolated or replaced. Evidence: the RMM's monthly compliance report. - **Email security** – filtering, anti-[phishing](/wiki/glossary/phishing) policies, SPF/DKIM/DMARC at enforcement. Evidence: DMARC report and policy export. - **Privileged access controls** – separate admin accounts, no standing local admin for users, a [PAM](/wiki/glossary/pam) tool or just-in-time elevation. Evidence: admin account inventory. - **Security awareness training** – quarterly at minimum, with phishing simulations. Evidence: completion and click rates. - **Incident response plan** – written, carrier contacts in it, exercised annually. Evidence: the plan and a tabletop date. See the [incident response process](/wiki/incident-response-process). Vendor choices for each line are in the [client security stack](/wiki/msp-security-stack) guide. What matters here is the evidence column: a control you cannot document is, to an underwriter, a control you do not have. ## Packaging readiness as a service Two workable formats. The first is a fixed-price **readiness assessment** – typically $1,500–5,000 by client size – delivered 90 days before renewal: run the application line by line, mark each control green, amber, or red, collect evidence for the greens, and quote remediation for the rest. It is a gap assessment with a deadline, and the deadline is what closes it. The second is to fold readiness into the managed agreement: every client on your baseline stack is insurance-ready by design, and the annual review becomes a scheduled [QBR](/wiki/glossary/qbr) deliverable. This is the stronger model: controls are always on rather than stood up under pressure, and the baseline becomes non-negotiable for a reason the client's CFO already accepts. Either way, require the client to carry cyber coverage in your MSA, and treat any declined control as a signed risk-acceptance letter – the document that later explains to their carrier, and your lawyer, why the control was absent. See [MSP contracts and MSA](/wiki/msp-contracts-and-msa). ## Your own exposure Three things put the MSP in the claim's blast radius. First, attestations. If you sign the application, or fill it in for the client to sign, and an answer is wrong, you made the misstatement – and the carrier's subrogation counsel and the client's lawyers will both look at you. The hard rule from broker guidance and channel consensus: supply the facts in writing, with evidence, and have the client's officer sign. Never sign, and never answer a question you have not verified in a console that day. Second, the carrier increasingly asks about you: does the MSP enforce MFA on its own tools, is its remote access locked down, does it carry E&O and cyber coverage. A weak answer raises the client's premium and surfaces in their next vendor review; see [securing your MSP](/wiki/securing-your-msp). Third, your own E&O and cyber coverage and the liability caps in your MSA stand between a rescinded client claim and your balance sheet; costs are in [legal setup and insurance](/wiki/msp-legal-and-insurance). ## Running the annual renewal cycle Renewal is predictable. Calendar every client's policy expiry the day you learn it, then work backwards: - **T-120 days:** re-run the checklist against the broker's current application – forms change every year. Quote and schedule remediation. - **T-90 days:** remediation complete, evidence pack assembled, restore test and IR tabletop done within the last twelve months. - **T-60 days:** sit with the client while they complete the application. Answer from evidence, not memory. The client signs. - **T-30 days:** the broker markets the risk. Answer underwriter follow-ups fast – an exposed RDP port on the carrier's scan can hold up binding. - **Post-binding:** file the policy, signed application, and evidence pack in the client's documentation. Put the carrier hotline, policy number, and mandatory panel vendors into the incident response plan. Track one metric across the book: the share of clients with every control green 90 days before renewal. It predicts next year's security revenue and incident risk better than any other number you hold. ## Bottom line Cyber insurance underwriting is now the most effective security mandate your clients face, and its checklist is your baseline stack line for line. Map each question to a delivered control with dated evidence, package the review as a fixed-price assessment or a built-in annual deliverable, and run every renewal on a 120-day clock. Fill in the facts, never sign the form – a wrong answer voids the client's claim and puts you in the lawsuit – and keep your own shop clean enough for the vendor questions on the same form. --- ## Designing a vCIO Service ## What a vCIO is for A [vCIO](/wiki/glossary/vcio) owns a client's technology direction. Every MSP claims to provide one. Few define what the client receives, who does the work, and what it costs, so it appears as a line in the proposal and never as a deliverable. Defined properly, it is the usual first step up in average revenue per client and the strongest retention tool you have: a client who has handed you their three-year plan does not leave over a slow ticket. ## What the vCIO actually delivers Five deliverables, refreshed on a schedule, cover almost all of it: - **Technology roadmap.** A 12–36 month plan of projects, sequenced and dated, each tied to a business reason – the server exits support, the office moves, the insurer requires it. - **Budget forecast.** The roadmap priced: recurring services, projects, hardware refresh, licensing, contingency. Delivered ahead of the client's fiscal year so IT becomes a planned line rather than a surprise invoice. - **Risk register.** Every open finding from assessments and standards audits, with an owner, a rating, and a status – accepted, deferred, funded, or closed. The register makes declined recommendations the client's decision on paper. - **Vendor management.** An inventory of the client's technology vendors and contracts with renewal dates, and the vCIO as the point of contact for evaluating the next tool the client wants to buy – which absorbs [shadow IT](/wiki/glossary/shadow-it) before it accumulates. - **Lifecycle planning.** Hardware and software age tracked against replacement policy – typically five years for workstations, five to six for servers, five for network gear – so refresh is scheduled and budgeted, not reactive. If a deliverable cannot be templated, it is consulting, not a service. ## The cadence Two rhythms hold the service together. The [QBR](/wiki/glossary/qbr) is the formal review where roadmap, budget, and risk register are presented and decisions requested; the agenda and preparation are in the [QBR process](/wiki/qbr-process). Between reviews, a monthly touch – a 20–30 minute call or a short written update – keeps momentum: what landed, what is next, anything on the client's side that changes the plan. Without it, a quarterly meeting becomes a quarterly surprise. Scale the cadence to the client: quarterly reviews plus monthly touches for the top tier, semi-annual reviews plus quarterly touches for the middle, an annual written plan with an offer to meet for the smallest. ## vCIO, vCISO, and technical account manager The three roles are conflated constantly. The vCIO owns direction and budget: what technology the business should have and when. The [vCISO](/wiki/glossary/vciso) owns security governance: policies, control frameworks, [compliance](/wiki/glossary/compliance) programs, risk assessments, and the audit relationship. Clients under a regulatory framework or a demanding insurer need the vCISO scope and will pay separately for it; general SMB clients need a vCIO who can speak to security risk without running a formal program. Do not sell one and deliver the other. The [technical account manager](/wiki/glossary/technical-account-manager) is operational: the escalation point, the person who knows the environment. A TAM looks at last quarter; a vCIO looks at the next three years. In small shops one person wears both hats, which works as long as the two conversations are not held in the same meeting. ## Who does it on a small team Under about 300 managed seats, the vCIO is the owner. It is the highest-value use of the founder's time and why clients chose a small provider. Between roughly 300 and 1,000 seats, the first dedicated hire is usually an account manager with technical depth who takes the monthly touches and the deliverable preparation, with the owner still attending top-tier reviews. Beyond that, a full-time vCIO carries 25–40 clients. Whoever does it needs enough technical judgment to be credible, enough business vocabulary to talk about cash flow and headcount rather than firmware, and a protected calendar. The service dies when review preparation is the first thing dropped in a busy week. ## How to price it Two models work – see [MSP pricing models](/wiki/msp-pricing-models) for the wider context. **Bundled per-seat uplift.** The deliverables are included in the top service tier and priced into the seat – typically $8–20 per user per month over the tier below as of 2026. Every client at that tier receives it and the [MRR](/wiki/glossary/mrr) is predictable; the risk is that the work is invisible on the invoice and gets under-delivered. **Separate monthly retainer.** A named line item, scoped by cadence and deliverables. Typical ranges: $500–1,500 per month for a client under 50 seats with semi-annual reviews, $1,500–3,500 for quarterly reviews and monthly touches at 50–200 seats, and $3,500–7,500 for larger or regulated clients where the role approaches a fractional executive. The retainer makes the service visible at renewal and lets you decline it for clients who will not pay. A hybrid is common: a light version bundled for all managed clients, a retainer for those who want the full cadence. Either way, price to the value of the decisions being made, not the hours in the meeting – the clearest case for [value-based pricing](/wiki/glossary/value-based-pricing) in the catalog. ## Deliverable templates Build these once: - A one-page roadmap with quarters across the top and projects placed by date, each with a cost and a reason. - A budget worksheet: recurring, projects, refresh, licensing, contingency, by quarter, with a three-year view. - A risk register with the columns above and a rule that nothing is removed, only closed. - A vendor and contract inventory with renewal dates flagged 90 days out. - A lifecycle report from RMM asset data, sorted by age against policy. Preparation should take two to four hours with these in place; if it takes a day, the templates are missing something. ## Failure modes **Becoming free consulting.** The client calls for opinions on their phone system, their website vendor, and their nephew's laptop, none of it scoped. Scope the deliverables and cadence in the agreement, route ad-hoc requests to the monthly touch, and quote anything beyond that as a project. **Running it as a sales pitch.** If every review ends with three quotes and no finding the client could decline without pressure, the client learns the meeting exists to sell. Present risk and let the register hold the decision; project revenue follows a credible roadmap, not the other way around. **Delivering it inconsistently.** Reviews slip, the roadmap goes stale, the budget never ships. Inconsistency is worse than absence, because the client was told they had a strategic partner and can see they do not. Track review completion as a KPI alongside service metrics – see [MSP KPIs and benchmarks](/wiki/msp-kpis-and-benchmarks). ## Bottom line Define the vCIO service as five deliverables on a stated cadence, staffed by someone with a protected calendar, and priced as a visible per-seat uplift or a named retainer. Keep it distinct from security governance and from account management, keep the reviews about the client's next three years, and let the risk register carry the decisions. That is the difference between a vCIO line in a proposal and a vCIO service a client will pay for and stay for. --- ## Designing Backup and Recovery for Clients ## Design first, then run the process The daily discipline – job review, test restores, runbooks, exit criteria – lives in the [backup and DR process](/wiki/backup-dr-process). That process assumes a design already exists for each client: which systems are protected, how, where the copies live, how long they are kept, and what happens on the bad day. Most backup failures at small MSPs are design gaps found during a restore, not failed jobs. ## Gather recovery objectives per system, not per client Ask a client for an [RTO](/wiki/glossary/rto) and [RPO](/wiki/glossary/rpo) and you get "immediately" and "zero." Ask per system, with a cost attached, and you get a real answer. Walk the inventory with the owner and an operations lead and ask three questions about each server, application, and data set: how long can you work without it, how much rework can you afford to lose, and who would you call first if it were gone. The practice-management or ERP database gets hours and minutes; the file share gets a day and a few hours; the archive nobody has opened since 2021 gets a week. Record the result as a signed schedule to the [business continuity plan](/wiki/glossary/business-continuity-plan): system, owner, RTO, RPO, tier. It sets scope for everything below and turns "you never told us the CRM needed backing up" into a line item the client saw and signed. ## 3-2-1-1-0 and what immutability actually buys Three copies, two media, one offsite – plus two more digits. The extra **1** is a copy that is offline, air-gapped, or immutable: object lock in cloud storage or a retention lock on the appliance that no administrator credential, including yours, can shorten before it expires. The **0** is zero errors on automated verification: the image boots, the database mounts, the checksum matches. The immutable copy defeats the attacker's playbook. [Ransomware](/wiki/glossary/ransomware) crews sit in an environment for days, find the backup console, and delete copies before detonating. A cloud mirror synced by the same service account is not a defense; a locked copy with a window longer than typical dwell time is. Set immutability to at least 14–30 days, and put the [BDR](/wiki/glossary/bdr) platform's admin access behind phishing-resistant MFA on an identity separate from your RMM. The [cyber insurance](/wiki/glossary/cyber-insurance) questionnaire asks about exactly this. ## Image-based, file-based, and SaaS backup Most designs need all three. - **Image-based** captures the whole volume – OS, applications, configuration, data – so a machine can boot as a virtual machine or restore to different hardware. It is the only approach that meets an RTO measured in hours. Every server gets it, plus the few workstations whose loss would stop the business. - **File-based** captures selected folders. Cheap, light, adequate for general workstations and for archives where you need the document, not the machine. It cannot rebuild a server in useful time. - **SaaS backup** captures data the client does not host. Microsoft 365 data is not backed up by default – Microsoft runs the service, the customer owns the data, native retention is not a point-in-time copy, and tenant configuration is not retained at all. Treat it as mandatory and list the platforms in scope in writing. ## Local appliance plus cloud, or cloud-only **Appliance plus cloud replication.** A local device takes image backups over the LAN, can boot a failed server as a VM in minutes, and replicates to immutable cloud storage. It fits any client with a tier-1 server, an RTO under a day, or more than a few terabytes. **Cloud-only.** Agents send backups straight to cloud storage; recovery means restoring over the internet or booting the image in the provider's cloud. No hardware, lower entry cost, right for clients with no on-premises servers or a tolerable RTO. The constraint is bandwidth: a 2 TB full restore on a 100 Mbps link takes most of two days, so cloud-only with a four-hour RTO is a contradiction unless cloud failover is in the plan. Choose per client from the RTO schedule, not from what you already own. ## Retention design and what it costs Storage is billed per gigabyte-month, and every extra recovery point is paid for every month it is kept. A defensible default: daily points for 30 days, weekly for 90, monthly for a year. Regulated clients need longer for specific data – medical and financial records typically six to seven years – but apply that to the archive data set, not to every workstation image. Two rules keep it affordable: long-term points are file-level or deduplicated archives rather than full images, and retention is set per tier rather than as one global policy. Get the client's legal and compliance requirements in writing first. Under-retention is a liability; over-retention is a margin leak. ## DRaaS failover tiers [DRaaS](/wiki/glossary/draas) answers "where does the server run while we rebuild." Tier it to match the RTO schedule: - **Local virtualization** on the appliance – minutes to boot, but dependent on the office and its network being intact. - **Cloud failover** of the replicated image – hours to bring up, works when the building is gone, needs a plan for how users reach it. - **Restore to new hardware** – days; the fallback for everything below tier 1. Cloud failover is often included in appliance pricing for a limited runtime and billed per day beyond it. Put the runtime allowance and the failback procedure in the design – failback is harder than failover and nobody rehearses it. ## Testing cadence and evidence The process article sets the cadence – quarterly file and boot tests, an annual DR exercise for tier-1 clients – and the design decides what evidence those tests produce. Each test records the system, restore type, elapsed time against contracted RTO, age of the point used against contracted RPO, and who validated the result – stored in the client's documentation, not a technician's inbox. ## Mapping the design to price tiers The design maps onto three tiers, typically sold per protected device plus per user for SaaS: - **Standard** – file or endpoint backup, cloud-only, 30-day retention; typically $5–15 per workstation per month. - **Business** – image-based server backup, immutable cloud copy, 90-day retention, cloud failover on request; typically $50–150 per server per month. - **Critical** – appliance with local virtualization, cloud replication, extended retention, DR exercise included; typically $250–500 per server per month. Microsoft 365 backup at $3–5 per user per month sits under all three. ## Documenting the design so it survives turnover Keep the design in the client's documentation record: the RTO/RPO schedule, protected systems and the backup type for each, storage locations and immutability settings, retention per tier, failover tier and runtime allowance, test evidence, and the recovery [runbook](/wiki/glossary/runbook). Write it to your [documentation standards](/wiki/msp-documentation-standards), at the level a new technician can execute. Review it at onboarding, whenever a system is added, and annually. ## Bottom line Backup design is a negotiation about time and money, recorded per system and signed. Get real recovery objectives, keep an immutable copy the attacker cannot reach, use image backups for anything with a tight RTO, match appliance-or-cloud to the schedule, set retention deliberately, and write it down where the next technician can find it. --- ## Designing Your SLAs ## Commit to response, target resolution The most important structural decision in an [SLA](/wiki/glossary/sla): contractually commit to **response** times, and treat **resolution** times as targets, not guarantees. You control how fast a technician engages a ticket. You do not control how fast Microsoft restores a tenant, how fast a hardware vendor ships a part, or how deep the root cause turns out to be. Guaranteeing resolution means guaranteeing the behavior of vendors and problems you don't own. The clean way to draw the line: response commitments are contractual terms; resolution times are published objectives – closer to an [SLO](/wiki/glossary/slo) – that you report on honestly but don't guarantee. Clients accept this readily when you explain the reasoning, and it keeps a slow vendor from becoming your breach of contract. ## The priority matrix Priority is a function of **impact × urgency** – how many people are affected, and how badly. The standard four-level matrix: | Priority | Definition | Typical examples | |---|---|---| | **P1 – Critical** | Site down or active security incident; all users affected | Office-wide outage, server down, ransomware or active breach | | **P2 – High** | Major function down or many users impacted | Line-of-business app degraded, a department offline | | **P3 – Medium** | Single user impacted; workaround exists | One user's application failing, non-critical device down | | **P4 – Low** | Minor issue or routine request | How-to question, new-user setup, cosmetic problem | One rule that saves you: **the MSP assigns final priority per the matrix, not the client.** Every caller believes their issue is critical; the matrix is what lets you say "this is a P3" without it being personal. The matrix itself belongs in the SLA attachment to your [MSA](/wiki/msp-contracts-and-msa), where it can be revised without reopening legal terms. ## Realistic targets for a small shop Typical business-hours (8×5) numbers a small MSP can actually sustain, as of 2026: | Priority | Response commitment | Resolution target (not guaranteed) | |---|---|---| | P1 | 30–60 minutes | ≤4 hours | | P2 | 2 hours | ≤8 hours | | P3 | 4–8 business hours | 24–72 hours | | P4 | Next business day | 24–72 hours | Shops running genuine 24/7 operations typically tighten P1 response to 15–30 minutes. Set numbers you can hit at your **worst** staffing week – one tech on vacation, another out sick – not your best. A conservative SLA you beat consistently builds more trust than an aggressive one you miss. ## Business hours vs 24/7 The common pattern: P1 and P2 covered 24×7 via an on-call rotation; P3 and P4 handled 8×5. That gives clients the assurance that a real emergency gets answered at 2 a.m. without pretending you staff a night shift. A 1–3 person shop should sell business-hours SLAs with an emergency line, and price genuine 24/7 coverage as a premium tier. Real around-the-clock coverage requires roughly four or more technicians or an outsourced [NOC](/wiki/glossary/noc) – promise it with two people and one bad on-call month burns them both out. If a prospect genuinely needs 24/7, that's a pricing conversation, not a free checkbox. ## Service credits as the sole remedy The typical remedy for an SLA miss is a service credit of 5–20% of the monthly fee, scaled by severity and by repeat misses, and applied **automatically** – not "upon request," which quietly punishes clients for not auditing you. Two pieces of language do the real work: - **Credits are the sole and exclusive remedy** for SLA misses. This is what stops a missed response time from escalating into a damages claim. Without it, the credit schedule is a floor, not a ceiling. - **Penalties must be in the contract to be enforceable.** An SLA that lives in a sales deck binds no one. Many small MSPs skip credits entirely in the early years. The modern view is that a modest automatic credit signals accountability and works as a sales asset – prospects notice when you put money behind your numbers, and the sole-remedy language means the downside is bounded and known. ## Measure attainment in the PSA An SLA you don't measure is marketing copy. Configure the priority matrix and SLA clocks in your [PSA](/wiki/glossary/psa) so attainment is tracked per ticket: - **Pause the clock on "Waiting on Customer."** Time spent waiting for a client to reply is not your response time; without pause states your numbers are fiction in both directions. - **Report attainment against the SLA per priority** – "97% of P1s responded to within target" – rather than a single blended average, which hides exactly the misses that matter. For overall first response, under one hour during business hours is a commonly targeted number as of 2026. - **Report it in QBRs.** SLA attainment is one of the few operational numbers clients actually understand; showing it quarterly in your [QBR](/wiki/qbr-process) turns the SLA from a liability into proof of performance. None of this works without ticket discipline underneath – accurate priorities, honest statuses, clocks that reflect reality. That's the [ticket management process](/wiki/ticket-management-process). ## Why overcommitting kills small MSPs Aggressive SLAs are the classic deal-closing temptation: a prospect hesitates, so you promise 15-minute response on everything. Here's what that costs a small shop: - **Every ticket becomes an interrupt.** If everything must be touched in minutes, no one can do focused project work, documentation, or automation – the activities that actually reduce ticket volume. - **On-call falls on too few shoulders.** Tight commitments across a 1–3 person team mean someone is always tethered to a phone. That's how you lose your first good technician. - **Misses compound.** Missed commitments mean credits, awkward QBRs, and a client relationship anchored to a number you can never sustainably hit. You don't win against a larger competitor by matching a response promise you can't staff. You win by publishing honest numbers and beating them every quarter. ## Bottom line Commit to response, target resolution. Use a four-level priority matrix that you – not the client – apply. Publish business-hours numbers you can hit in your worst week, cover P1/P2 with an on-call line, and sell true 24/7 as a premium tier only when you have the staff. Offer a modest automatic service credit and make it the sole and exclusive remedy. Measure attainment in the PSA with paused waiting states, and show the numbers at every QBR. Revisit the SLA attachment annually – it's an attachment precisely so you can. --- ## Documentation Standards ## Documentation is an asset, not admin overhead Every MSP says documentation matters. Very few treat it like the asset it is. Good documentation is what lets a second tech resolve a ticket without pinging the first, what lets you take a vacation, what makes a new hire productive in weeks instead of months – and, at exit, what a buyer's due-diligence team actually reads to decide whether your client base is transferable or trapped in your head. Documentation quality is also becoming the ceiling on automation gains: AI-assisted triage escalates to humans exactly where docs are sparse. The MSPs getting real gains from automation as of 2026 are the ones whose documentation was already disciplined. This guide covers what to document per client, where to keep it, how to name it, and – the hard part – how to keep it alive. ## The per-client minimum set Every client should have the same core documentation, structured identically, regardless of which tech built it. The minimum set: - **Network diagram / topology.** Firewall, switches, VLANs, servers, key SaaS dependencies, site-to-site links. Auto-discovery helps (IT Glue's Network Glue; Hudu pairs with embedded Lucidchart or auto-diagram tools) but a human should validate it. - **Credentials – in the vault, nowhere else.** Admin accounts, local admin, firewall/switch logins, service accounts, API keys, and [MFA](/wiki/glossary/mfa) recovery codes. Never in spreadsheets, never in ticket notes. This is also what makes clean [client offboarding](/wiki/client-offboarding-process) possible: you can only rotate what you can enumerate. - **ISP and vendor information.** Account numbers, support numbers, circuit IDs, contract and renewal dates. The 2 a.m. outage is not the time to hunt for the circuit ID. - **Licensing inventory.** M365 tenant and SKUs, line-of-business apps, keys, renewal dates. - **Backup configuration.** What is backed up, on what schedule, with what retention, where restores are tested, and who receives alerts. This document is the first thing anyone should check in a recovery scenario – see the [backup and DR process](/wiki/backup-dr-process). - **Asset inventory** synced from the [RMM](/wiki/glossary/rmm), with warranty status. - **Runbooks and SOPs** linked to ticket types – "what to do when X" – each with an owner and a review date. A [runbook](/wiki/glossary/runbook) tied to a recurring ticket type is the cheapest efficiency gain in the business. - **Site information.** Physical access procedures, alarm codes, key contacts, VIP list, and the approved-requester list (who may authorize changes or password resets – a social-engineering control, not a courtesy). If a client folder is missing any of these, that gap is a finding to fix, not a permanent condition. ## Documentation is an onboarding deliverable The single best structural decision: treat completed documentation as an explicit deliverable of [client onboarding](/wiki/client-onboarding-process), with a due date, not something that accretes over years of tickets. During onboarding days 1–30 you are already doing discovery – assessment, asset inventory, access validation, backup checks. Capturing that into the standard structure while you're in there costs a fraction of reconstructing it later. Onboarding isn't done until the client's documentation passes your own checklist. ## Where to keep it: IT Glue, Hudu, and structure Use a dedicated documentation platform with a credential vault – not SharePoint, not a wiki, not the [PSA](/wiki/glossary/psa)'s notes fields. The two names that dominate the conversation as of 2026: **IT Glue** – **Pros:** market leader, deep integrations across the Kaseya suite, Network Glue auto-discovery. **Cons:** Kaseya-owned (a factor if you avoid that suite), 5-user minimum makes it pricier for very small shops. **Best fit:** MSPs already in or comfortable with Kaseya tooling. **Hudu** – **Pros:** the popular independent alternative, cheaper, self-hostable, includes a vault. **Cons:** lighter native auto-discovery; you assemble more yourself. **Best fit:** small independent MSPs and anyone wanting to own their data location. Either way, the structure matters more than the tool (as with the rest of your [tool stack](/wiki/msp-tool-stack)). Build **standardized templates** – one flexible-asset template per documentation type (ISP, LOB application, backup config, site info) – so every client is the same set of typed records, not freeform pages. Identical structure is what makes documentation searchable, auditable for gaps, and usable by a tech who has never touched that client. ## Naming conventions Agree on conventions once, write them down as an internal [SOP](/wiki/glossary/sop), and enforce them in review: - **Prefix by client code.** A short unique code per client (e.g., `ACME`) leading every asset name: `ACME-FW01`, `ACME-DC01`. - **Predictable device names.** Role + number: FW, SW, DC, FS, HV. A tech should know what `ACME-SW02` is before opening the record. - **Credential titles that state system + account**, e.g., `ACME-FW01 admin`, `M365 Global Admin – break-glass`. "Password 3" in a vault is barely better than a sticky note. - **Runbook titles that match ticket types**, so the runbook surfaces when the ticket is categorized. - **No orphan documents.** Every page belongs to a template type and a client. If it doesn't fit, either the taxonomy needs a new type or the document doesn't belong. ## Keeping documentation alive Stale documentation is worse than none – a tech who trusts a wrong credential or an outdated diagram loses more time than one who knows to go look. Three practices keep docs alive: 1. **Review dates on everything.** Every runbook and core record carries an owner and a next-review date. Work reviews as scheduled tickets, monthly batch by client. Onboarding new staff doubles as an audit: have them follow the runbook literally and flag every place it lies. 2. **Documentation time is logged, expected work.** It goes against tickets and agreements like any other time, and it is incentivized – never treated as what techs do "when things are quiet." Things are never quiet. 3. **"Doc it or it didn't happen" culture.** The same rule that kills the shoulder tap in [ticket management](/wiki/ticket-management-process) applies here: a fix that isn't captured – in the ticket resolution, and in the runbook if it will recur – will be re-solved from scratch by the next tech. Make the update part of closing the ticket, not a separate virtuous act. ## Documentation as company value At exit, buyers price the difference between a business and a founder-with-clients. Strong documentation is evidence that service delivery is transferable: any competent tech can support any client from the record. Thin documentation reads as key-person risk and gets discounted accordingly – the same way month-to-month handshake deals do. The identical logic applies at smaller scale: every internal handoff, every new hire, every vacation is a miniature exit, and documentation is what makes it uneventful. And when a client relationship ends, complete records of what you held and what you rotated protect you if a claim or audit lands a year later. ## Where to start Don't boil the ocean. Pick your top three clients and build the full minimum set for each using standardized templates – that forces you to design the templates properly. Then make the completed set a hard exit criterion of onboarding for every new client, and schedule the first quarterly review tickets. Within two quarters you'll have the structure, the habit, and a documentation platform that is worth what you pay for it. --- ## DRaaS (Disaster Recovery as a Service) ## Definition DRaaS is a subscription service that continuously or periodically replicates a client's servers to a provider-hosted cloud and can boot those replicas as running virtual machines when the primary environment is lost. It is the failover target in a recovery plan – the answer to "the building is gone" – rather than a copy of files. ## Why it matters to an MSP A DRaaS offering has three parts, and a client is not buying it unless all three exist. Replication: image-based backups or block-level replication of the protected servers, on a schedule set by the [RPO](/wiki/glossary/rpo). A failover target: reserved compute in the vendor's cloud where the replicas boot, plus the networking to reach them – a VPN or remote-access gateway staff can actually use from home. Testing: scheduled failover tests, ideally automated, that prove the replica boots and the application runs. Most [BDR](/wiki/glossary/bdr) platforms bundle the first two; the third is where MSPs cut corners and get burned. Pricing usually has the same shape across vendors: a per-server or per-protected-device fee (typically $50–$150 per server per month wholesale), plus storage per TB retained in the cloud, plus compute charges only while a failover is running – commonly free for a 30–60 day disaster window, then metered. Bill it as a fixed per-server line inside your backup tier, with margin to cover the failover labor you are committing to: a real invocation is 8–20 technician hours of failover, DNS changes, user support, and later failback, and an [SLA](/wiki/glossary/sla) that promises a four-hour [RTO](/wiki/glossary/rto) has to fund that. DRaaS is also the middle option for clients who reject a $5,000 local appliance: same-day recovery from site loss without on-premises hardware, at the cost of a slower, bandwidth-bound failback. Related terms: [BDR](/wiki/glossary/bdr), [RTO](/wiki/glossary/rto), [RPO](/wiki/glossary/rpo), [Business Continuity Plan](/wiki/glossary/business-continuity-plan) --- ## Endpoint ## Definition An endpoint is any device that runs an agent from your [RMM](/wiki/glossary/rmm) or security tooling and is counted as a managed unit: workstations, laptops, and servers first, with mobile devices and virtual machines included on most contracts, and network devices (firewalls, switches, access points) counted separately or as a distinct device class. The practical definition is whatever your tools and your contract say it is – and those two should match. ## Why it matters to an MSP Endpoint count is the number that drives both your cost of goods and, under [per-device pricing](/wiki/glossary/per-device-pricing), your revenue. Nearly every tool in the stack bills per endpoint: RMM at roughly $1–3 per endpoint per month, [EDR](/wiki/glossary/edr) at $3–7, [MDR](/wiki/glossary/mdr) on top at $2–15, endpoint backup at $2–5, and DNS filtering under a dollar. A typical stack lands at $8–25 per endpoint per month in tooling cost as of 2026, so an untracked 10 percent growth in a client's endpoint count is a direct margin leak if you bill a fixed fee. Servers are usually priced at two to four times a workstation rate; mobile devices less. Define in the [MSA](/wiki/msp-contracts-and-msa) exactly what counts, audit the count monthly against RMM inventory, and true-up billing when it moves – the gap between quoted and actual counts is a common source of unbilled work. The count also sets your risk surface: every unmanaged endpoint is a device with no patching, no EDR, and no visibility, which is why [cyber insurance](/wiki/glossary/cyber-insurance) applications ask for the total and for what percentage is covered. Tickets per endpoint per month (typically 0.5–1.5 for a well-run client) is one of the cleanest health metrics you can track. Related terms: [RMM](/wiki/glossary/rmm), [EDR](/wiki/glossary/edr), [Per-Device Pricing](/wiki/glossary/per-device-pricing), [Patch Management](/wiki/glossary/patch-management) --- ## Endpoint Detection and Response (EDR) ## Definition Endpoint detection and response is security software that continuously records process, file, network, and identity activity on each [endpoint](/wiki/glossary/endpoint), detects attacker behavior rather than only known malware signatures, and lets a responder isolate the machine, kill processes, and roll back changes remotely. It replaced antivirus as the baseline control because modern intrusions use legitimate tools and stolen credentials that signatures never see. ## Why it matters to an MSP EDR is the control that turns a [ransomware](/wiki/glossary/ransomware) event from a rebuild-everything disaster into a contained incident on one or two machines. The behavioral telemetry catches the hours or days of reconnaissance, credential theft, and lateral movement that precede encryption, and network isolation stops the spread while you investigate – which is why [incident response](/wiki/incident-response-process) starts with EDR alerts and the console is your primary evidence afterward. Commercially it is table stakes. [Cyber insurance](/wiki/glossary/cyber-insurance) questionnaires ask for EDR on every endpoint by name, and a client without it faces premium hikes or declination; your own carrier asks the same of you. It belongs in every managed agreement's security baseline, deployed alongside the RMM agent on day one of onboarding, with coverage gaps (missing or unhealthy agents) reported at every [network assessment](/wiki/network-assessment-process) and [QBR](/wiki/glossary/qbr). Typical MSP pricing as of 2026 is $3–8 per endpoint monthly, easily absorbed by a per-seat fee. The catch is that EDR generates alerts someone has to read around the clock. A two-person shop cannot triage a 2 a.m. detection, so most pair it with [MDR](/wiki/glossary/mdr) – a vendor [SOC](/wiki/glossary/soc) that watches the telemetry and takes first response – and sell the pair as the security tier. Buy it direct rather than through a bundle you cannot exit, and never let a client exclude it "just for the servers." Related terms: [MDR](/wiki/glossary/mdr), [Endpoint](/wiki/glossary/endpoint), [SOC](/wiki/glossary/soc), [Ransomware](/wiki/glossary/ransomware) --- ## Escalation ## Definition Escalation is the handoff of a ticket from the technician working it to someone with more skill, more authority, or more time – typically from a Tier 1 (T1) help desk tech to T2, from T2 to a T3 senior engineer or the owner, or from a technician to a vendor. Management escalation – pulling in an account manager for an unhappy client – follows the same logic. ## Why it matters to an MSP Escalation is where labor cost, [SLA](/wiki/glossary/sla) compliance, and client satisfaction meet. T1 labor is your cheapest hour and T3 your most expensive; every ticket sitting with the wrong tier either costs too much or takes too long. The failure mode is almost never over-escalation – it is ticket-hogging, where a stuck tech spends half a day on a problem a senior would solve in twenty minutes. The fix is a written escalation path with **time-based triggers**, not judgment calls: commonly, T1 escalates after 30 minutes without progress, T2 after two hours, and a priority-1 outage goes to T3 immediately. Escalating on the trigger is following process, not admitting failure, and the dispatcher enforces that framing. Define who owns each tier, what a ticket must contain before it moves (steps tried, error text, business impact), and who is notified when the SLA clock is at risk. Track escalation rate per tech and per tier – a T1 escalating 60 percent of tickets needs training or better [runbooks](/wiki/glossary/runbook); a T1 escalating 5 percent is probably sitting on things. For a solo owner hiring a first technician, the escalation path is the point of the hire: you become T2 and T3, and the tech owns the queue. The full tiering model is in the [ticket management process](/wiki/ticket-management-process). Related terms: [SLA](/wiki/glossary/sla), [Runbook](/wiki/glossary/runbook), [First Call Resolution](/wiki/glossary/first-call-resolution), [Ticketing System](/wiki/glossary/ticketing-system) --- ## First Call Resolution ## Definition First Call Resolution (FCR) is the share of tickets resolved by the first technician who handles them, without [escalation](/wiki/glossary/escalation), reassignment, or a second contact from the client. The formula is tickets resolved at first touch divided by total tickets closed in the period. In practice, pull it from the [ticketing system](/wiki/glossary/ticketing-system) as tickets closed with one assignee and no escalation flag. ## Why it matters to an MSP FCR is a labor-cost and client-satisfaction number in one. Every ticket that bounces from tier 1 to tier 2 costs the first technician's time, and a more expensive technician's time – a reassigned ticket typically consumes two to three times the labor of one resolved at first touch. Typical MSP figures run 60–75% across all tickets, with mature desks above 75% and a well-defined tier-1 scope near 80%. Below 60% usually means tier 1 is under-trained or lacks documented [runbooks](/wiki/glossary/runbook), technicians lack permissions to fix common issues, or tickets are routed to whoever is free rather than a first-line group. The trap is treating FCR as a number to maximize. A technician measured on FCR alone will hold a ticket they should have escalated, spending 90 minutes on a problem a senior would close in ten, and the client's outage runs longer. Escalation discipline – time-boxed rules such as "escalate after 30 minutes stuck" – deliberately pushes FCR down in exchange for faster resolution and correctly used senior time. Measure both: FCR shows whether tier 1 is equipped; time-to-resolve and escalation rate show whether people escalate when they should. Report FCR in [QBRs](/wiki/glossary/qbr) with that context: "75% fixed on first contact" is good news provided the other 25% moved fast. See [ticket management process](/wiki/ticket-management-process) for the routing and escalation rules that make FCR meaningful. Related terms: [Escalation](/wiki/glossary/escalation), [Ticketing System](/wiki/glossary/ticketing-system), [SLO](/wiki/glossary/slo) --- ## GDAP (Granular Delegated Admin Privileges) ## Definition GDAP is Microsoft's current model for partner access to customer Microsoft 365 and Entra ID tenants, replacing the legacy Delegated Admin Privileges (DAP) that Microsoft force-retired in 2023. Where DAP gave a partner standing, Global Admin-equivalent access to every customer tenant indefinitely, a GDAP relationship is per-customer, scoped to specific Entra admin roles, and time-boxed to 1–730 days, expiring unless renewed. Roles are assigned to security groups in the partner tenant, so only the technicians who need a given role in a given tenant actually hold it – least privilege instead of every tech holding keys to every client. ## Why it matters to an MSP MSPs are supply-chain targets: one compromised partner tenant with standing admin over dozens of client tenants is the Microsoft-cloud equivalent of the 2021 Kaseya VSA attack, and the CISA AA22-131A advisory exists because attackers know it. GDAP is your blast-radius control – a stolen technician token yields limited roles in specific tenants for a limited window, not Global Admin everywhere. It's also table stakes commercially: transacting through the [CSP program](/wiki/glossary/csp-program) requires GDAP, and cyber-insurance questionnaires and security-literate clients increasingly ask how partner access is scoped. Adopt the standard pattern: least-privilege role sets per customer, security-group assignment, phishing-resistant [MFA](/wiki/glossary/mfa) on every partner account, and just-in-time elevation via Entra PIM for the few genuinely privileged roles instead of standing assignments. Related terms: [MFA](/wiki/glossary/mfa), [PAM](/wiki/glossary/pam), [Zero Trust](/wiki/glossary/zero-trust) --- ## HaaS (Hardware as a Service) ## Definition Hardware as a Service is bundling client hardware – workstations, servers, network gear – into the monthly recurring fee instead of selling it as a capital purchase: the MSP owns (or finances) the equipment, and the client pays one per-seat or per-device price that includes the box, its refresh cycle, and its support. ## Why it matters to an MSP The appeal is real: HaaS raises [MRR](/wiki/glossary/mrr) and your all-in seat price, guarantees refresh cycles so you support a standardized, current fleet (far cheaper to run than aging hand-me-down PCs), converts the client's capex into opex, and deepens lock-in. It also beats reselling hardware outright, where margins are thin – mid-single digits to roughly 10–15% against Dell, Amazon, and CDW price transparency. The catch for a new MSP is cash flow and risk: you front the capital and recover it over about 36 months, a serious strain on a young business without reserves; you inherit asset tracking, residual-value risk, and default risk – if a client stops paying, you're repossessing laptops; and clients treat gear they don't own more carelessly. You have, in effect, become a small leasing company. The common advice for new founders: skip owned HaaS early – sell hardware at cost-plus with paid deployment labor, or use third-party financing so the balance-sheet risk isn't yours – and revisit it once you have cash reserves and clients with proven payment history. Related terms: [MRR](/wiki/glossary/mrr), [Per-Seat Pricing](/wiki/glossary/per-seat-pricing), [Per-Device Pricing](/wiki/glossary/per-device-pricing) --- ## HIPAA ## Definition HIPAA (Health Insurance Portability and Accountability Act) is the US federal law, enforced by the HHS Office for Civil Rights (OCR), that governs how protected health information (PHI) is secured and disclosed. Its Security Rule sets administrative, physical, and technical safeguards for electronic PHI; the Privacy Rule governs use and disclosure; the Breach Notification Rule sets reporting clocks. It binds covered entities – providers, health plans, clearinghouses – and their business associates. ## Why it matters to an MSP If you manage systems that store, transmit, or touch PHI for a clinic, dental practice, or behavioral health group, you are a business associate under HIPAA. That status carries direct obligations: you must sign a business associate agreement (BAA) with each covered-entity client, you are directly liable to OCR for Security Rule violations, and you must flow the same terms down to your subcontractors – so your backup, email security, and cloud vendors need BAAs with you. Sign a client's BAA without reading the indemnification and breach-notification terms and you have accepted liability your [cyber insurance](/wiki/glossary/cyber-insurance) may not cover; have counsel review your template once. The Security Rule maps well to what you already sell – risk analysis, access control, [MFA](/wiki/glossary/mfa), encryption, audit logging, backup, workforce training – and the December 2024 OCR proposed rule would make most of them mandatory rather than "addressable," including asset inventories and annual [penetration testing](/wiki/glossary/penetration-testing). Commercially, healthcare is a strong niche precisely because the paperwork is a barrier: templated BAAs and a risk analysis you can run in a day justify a compliance premium – typically 15–25% above your standard seat price – and win on competence rather than price. How HIPAA compares to other frameworks is in the [compliance frameworks comparison](/wiki/compliance-frameworks-comparison). Related terms: [Compliance](/wiki/glossary/compliance), [Cyber Insurance](/wiki/glossary/cyber-insurance), [MFA](/wiki/glossary/mfa), [CMMC](/wiki/glossary/cmmc) --- ## Hiring Your First Technician ## When to hire: the signals and the math The first hire is the scariest check a founder writes, so most write it too late – after months of 60-hour weeks and slipping response times. Watch for the capacity signals: you are consistently more than 100% busy with billable work, you're personally absorbing 20–30 hours a week of steady overflow, tickets are aging, and you haven't taken a real day off in months. Sick days and vacations are the honest tell – a solo MSP has a bus factor of one, and clients eventually notice. Then check the signals against the math: - **Labor revenue trigger:** the common threshold is roughly $100k–125k in labor revenue – enough work to keep a tech busy from day one. - **Revenue per employee:** the industry average benchmark sits around $142k per employee. If a hire drops you well below that, the hire dilutes profit rather than buying growth. - **The 3x rule:** a technician should support roughly 3x their fully loaded cost in revenue – one third wages, one third overhead, one third profit. Fully loaded cost runs about 1.25–1.4x salary once taxes, benefits, and seat licenses are counted. Typical example: a $70k salary is ~$95k loaded and needs ~$210k+ of supported revenue. If the [MRR](/wiki/glossary/mrr) isn't there yet, fix pricing or sales before headcount – see [KPIs and benchmarks](/wiki/msp-kpis-and-benchmarks) for the numbers that should be true first. ## Who to hire first **The majority path: a mid-level (L2-ish) technician.** They're revenue-producing from early on, need minimal handholding, can face clients alone, and – critically – cover you on vacation and sickness, the real bottleneck for solo founders. A green L1 saves salary but consumes the founder time you're trying to buy back, because you become the trainer and the [escalation](/wiki/glossary/escalation) path for everything. **The contrarian pick: an admin assistant.** Billing, scheduling, invoicing, and vendor wrangling typically eat 10–15 founder hours a week, and an admin costs far less than a tech. If your calendar is drowning in admin rather than tickets, this is the better first hire. The practical synthesis most shops land on: tech first once billable work overflows, admin quickly after. **Sales last.** Founder-led sales is the rule until roughly $1M+ revenue; first sales hires at small MSPs fail more often than not. A dispatcher role emerges later, around 3–4 techs. ## What you'll pay (US, 2025–26) | Role | Typical salary | Notes | |---|---|---| | L1 help desk | ~$40–55k | ~$48k typical average; metro listings ~$21–30/hr | | L2 technician | ~$55–75k | ~$70k average; 25th–75th percentile roughly $55–91k | | General "MSP technician" | ~$66k average | Range ~$53–83k | | L3 / senior engineer | $85–110k+ | Not a typical first hire | Multiply by ~1.25–1.4x for fully loaded cost. Budget honestly: a "cheap" hire who can't work unsupervised costs more in founder hours than the salary gap. ## The prerequisite: documentation and process You cannot delegate what lives only in your head. Before the start date: - Client documentation to your [documentation standards](/wiki/msp-documentation-standards): credentials in the vault, network diagrams, vendor contacts, backup configs. Documentation is what lets tech #2 onboard without tribal knowledge. - [Runbooks](/wiki/glossary/runbook) and [SOPs](/wiki/glossary/sop) for your ten most common ticket types – even one-page versions. - A working [ticket process](/wiki/ticket-management-process): every request in a ticket, time logged on every ticket, statuses that mean something. Your new tech will copy whatever discipline they see, including the bad habits. - A defined [tool stack](/wiki/msp-tool-stack) with the new tech's seats budgeted. If none of this exists, spend a month building it before you post the job – it converts the hire from "apprentice to the founder" into "operator of a system." ## Writing the job post Small shops can't outbid corporate IT on salary, so sell what you actually have: variety (real networks, real servers, real security work – not one queue slice), direct client impact, proximity to the owner, and room to grow into a senior role as the company does. Be specific: name your stack, describe a real week, state the salary range. Skip the unicorn wish list – a requirements section demanding five certifications and seven years of experience for L2 money filters out exactly the practical, curious generalists a small MSP needs. Say plainly that it's a small company: some candidates will self-select out, and that's the filter working. ## Interviewing: process over trivia Certifications and memorized facts predict little. You're hiring for two things – troubleshooting process and customer communication: - **Walk me through it.** Give a realistic scenario ("user can't reach a network share; nothing changed") and evaluate the *method*: do they gather symptoms, form hypotheses, test cheapest-first, and narrow scope – or guess randomly and reboot? - **The "I don't know" test.** Ask something they likely can't answer. You want "I don't know, here's how I'd find out" – not bluffing. Bluffers create outages. - **Translation test.** Have them explain a technical failure to you playing a non-technical office manager who is angry. Clear, calm, jargon-free explanation is the skill your clients will judge the whole company on. - **Ticket hygiene.** Ask how they'd document the fix. A tech who writes nothing down doesn't scale past themselves. ## Onboarding: shadow, then supervised, then owned Do not hand over the queue on day one – it's the fastest way to burn a good hire and scare clients. Phase it: 1. **Shadow (roughly the first couple of weeks):** they ride along on your tickets, read the documentation, learn the stack and clients. Access provisioned, nothing owned. 2. **Supervised queue:** they work tickets you select – routine, well-documented types first – and you review every resolution and ticket note before close. Feedback is daily and specific. 3. **Owned queue:** they own day-to-day tickets with defined escalation criteria (time-boxed: stuck 30 minutes, escalate – no ticket-hogging, no hero culture). You stay on escalations, projects, and client relationships. Move between phases on demonstrated competence, not the calendar, and introduce them to clients personally so the handoff builds confidence instead of doubt. ## Utilization without burnout A tech has ~2,080 paid hours a year; at a realistic 65–70% utilization that's roughly 1,350–1,450 productive client-facing hours. Average shops run 55–60%, top performers 75–80% – but chasing beyond ~80% backfires, leaving no slack for documentation, training, automation, or the inevitable P1 spike. Capacity-wise, a well-tooled tech supports roughly 250–400 managed endpoints, with ~350 often cited as the gold standard. Expect ramp-up: months, not weeks, to full productivity – that's why you hire on the leading edge of the math, not after you're drowning. ## Bottom line Hire when the math clears – roughly $100k–125k of labor revenue, a path to 3x their loaded cost – and the capacity signals are chronic, not a bad month. Default to a capable L2 who buys back founder time and covers your absences, pay the going rate (~$55–75k as of 2025–26), and spend the pre-hire month on documentation and process so you're handing over a system, not a mess. Then onboard in phases and manage to sustainable utilization. The first hire done well is the template for every hire after it. --- ## How to Start an MSP ## What you're actually building You already know the technology – that's not what decides whether your [MSP](/wiki/glossary/msp) survives. What decides it is the business machine around the technology: recurring revenue, contracts, pricing discipline, and process. The industry data is sobering: managed-services growth has slowed to roughly 1% worldwide (Service Leadership Index, Q4 2024), and 18% of MSPs ran at a loss that quarter. The same data shows best-in-class shops holding 19%+ adjusted EBITDA – profitability comes from operating discipline, not market tailwinds. The goal from day one is [MRR](/wiki/glossary/mrr): fixed monthly fees for defined outcomes, not hours for problems. Recurring revenue is what makes cash flow predictable, hiring possible, and the company eventually sellable – managed recurring revenue is valued at roughly 4–6x annualized, versus 0.5–1x for project work. Every step below points at that goal. Total launch cost typically runs $10,000–$50,000, with a lean solo start near the bottom of that range – see [startup costs](/wiki/msp-startup-costs) for the full breakdown, and [writing a business plan](/wiki/msp-business-plan) for putting numbers to your own version. ## Step 1: decide the model – side-gig or full-time jump **Side-gig first is the dominant path.** Keep the W-2 job and build nights and weekends until the business proves itself. The common jump criterion: side income replacing roughly **75% of your salary**, and/or **6–12 months of living expenses banked**. Two rules while moonlighting: use a **separate laptop** (employers can claim IP created on their gear), and honor any non-compete or non-solicit clauses before working your employer's contacts. **The full-time jump** trades safety for speed – full-timers typically progress 3–4x faster than side-giggers – but demands the 6–12 months of runway up front, because the revenue curve is slow: a good cold-start first year is **$5,000–$10,000 MRR by month 12**, and only about 20% of solo founders clear $100k revenue in year one. **Best fit:** side-gig if you have a salary to protect and patience; full-time if you have runway, or a warm client base (often an amicable ex-employer) ready to sign. ## Step 2: legal entity and insurance The standard structure is an **LLC first, S-corp election later**. An S-corp is a tax election, not an entity type; the LLC is cheap with minimal compliance, and you elect S-corp taxation once net profit consistently clears roughly $50,000–$60,000/year (typical savings $2,000–$4,000/year at that level, against $3,000–$8,000/year in added payroll and accounting overhead). Add an EIN, a separate business bank account, and a registered agent. Insurance is not optional – clients will demand certificates of insurance (COIs) before signing, often naming themselves as additional insured. Typical solo-MSP costs as of 2026: general liability ~$360/year, tech E&O ~$500–$3,000/year, cyber liability $1,200–$5,000/year (priced on revenue, endpoint count, and your own security controls – insurers treat MSPs as high-risk because compromising one MSP cascades to every client). A realistic bundled total: **$2,500–$6,000/year**. Full detail in [legal and insurance](/wiki/msp-legal-and-insurance). ## Step 3: a focused service catalog and a pricing floor Define exactly what you sell before you sell it: one or two managed plans covering the core – monitoring, [patch management](/wiki/glossary/patch-management), [endpoint](/wiki/glossary/endpoint) security, backup, help desk – with everything else explicitly out of scope or quoted as projects. A tight [service catalog](/wiki/msp-service-catalog) is what makes fixed-fee pricing survivable. Price per user at the market norm – typically **$100–$250/user/month** as of 2026 ($70–$150 at the low end for basic stacks) – and set a floor: a per-client monthly minimum (commonly $500+) and a per-user price you will not go below. The temptation to undercut local competitors by 20% is the classic first-year mistake; it buys you 60-hour weeks at thin margins with no room to hire. Compare structures in [pricing models](/wiki/msp-pricing-models). ## Step 4: a lean tool stack Two pricing camps dominate, and the choice matters for a solo shop: | Camp | Typical cost shape (as of 2026) | Best fit | |---|---|---| | Per-endpoint | RMM around $2.50/endpoint; backup around $2/device; EDR $3–5/endpoint | Scales with client count; fine-grained cost control | | Per-technician | Combined [RMM](/wiki/glossary/rmm) and [PSA](/wiki/glossary/psa) at $129–$209/tech/month with unlimited endpoints | Solo founders – one flat fee while endpoints grow | A realistic month-one stack – RMM/PSA, EDR, backup, email security, password manager, documentation platform (Hudu or ITGlue) – runs **$300–$800/month**. Watch vendor minimum commitments and 1–3 year contracts: they're a classic cash-flow trap that hits before revenue does. Full comparisons in [tool stack](/wiki/msp-tool-stack) and [security stack](/wiki/msp-security-stack). ## Step 5: contracts before the first client Do not start work on a handshake, and do not download a free MSA template. Spend the $1,500–$5,000 on an attorney-drafted or attorney-reviewed MSA and SOW covering: a defined service description, explicit exclusions (unsupported hardware, EOL software), liability caps, and payment terms – billing monthly **in advance**. The defined scope is what you point to when refusing out-of-scope work; without it, "all-you-can-eat" means all-they-can-demand. Details and clause-by-clause guidance in [contracts and MSA](/wiki/msp-contracts-and-msa), and set response-time commitments you can actually hit – see [SLA design](/wiki/sla-design). ## Step 6: land the first clients Warm networks beat every paid channel at the start: referrals convert roughly 3–5x better than cold outreach, and the highest-yield sources are former colleagues, an amicable ex-employer, a hyper-local list of 50–100 small businesses, and partnerships with bigger MSPs handing down their sub-minimum accounts. Lead with a free network assessment as the door-opener, qualify hard, and say no to bad fits – onboarding a client typically costs $10,000–$15,000 with break-even at months 7–12, so one toxic client eats a quarter's profit. The full playbook is in [landing your first 10 clients](/wiki/first-msp-clients), and picking a vertical early multiplies referrals – see [choosing a niche](/wiki/choosing-a-niche). ## Step 7: deliver like a product from day one The founders who scale treat the service as a product: one standardized stack, one way of onboarding, everything documented. From client one: - **Run a real [onboarding process](/wiki/client-onboarding-process)** – credentials captured, network mapped, monitoring deployed, baseline hardening applied. - **Document as you go** to a standard where a stranger could support the client – see [documentation standards](/wiki/msp-documentation-standards). Undocumented environments are unbillable time bombs. - **Standardize ruthlessly.** A messy pile of one-off tools and snowflake configurations kills efficiency; define your stack and versions, and migrate new clients onto them. - **Track a handful of numbers monthly** – MRR, margin, tickets per endpoint – so problems surface early; see [KPIs and benchmarks](/wiki/msp-kpis-and-benchmarks). ## Step 8: the first-year mistakes that kill MSPs Recurring themes across founder retrospectives – each maps to a step above: 1. **Hourly billing.** A race to the bottom that attracts clients who undervalue you and rewards firefighting over prevention. Fix: fixed-fee agreements (Step 3), and get past [break/fix](/wiki/glossary/break-fix) to ≥50% recurring revenue fast. 2. **Underpricing by ~20%.** Cheap prices attract cheap clients who fight every ticket, and leave no margin to hire your [first technician](/wiki/hiring-first-technician) later. 3. **Taking every client.** With $10–15k onboarding cost per client, bad fits are quarter-killers (Step 6). 4. **No real contracts.** No scope, no exclusions, no liability caps – every dispute becomes your loss (Step 5). 5. **No standardization or documentation.** The efficiency debt that caps you at ten clients (Step 7). 6. **No marketing.** Referral flow alone stalls; if people don't know you exist, nothing else matters – build a repeatable motion per [sales and marketing](/wiki/msp-sales-marketing). ## Where to start This month: form the LLC, open the bank account, get insurance quotes, and engage an attorney on your MSA. Next month: stand up the lean stack, define your one managed plan with its pricing floor, and send the first twenty warm-introduction asks. Within a quarter: sign your first managed client, onboard them by the book, and document everything. Keep the day job until the numbers – 75% salary replacement or 6–12 months runway – say jump. And don't build alone: the MSP world runs on shared knowledge, from [peer groups](/wiki/glossary/peer-group) to the forums and podcasts in [community resources](/wiki/msp-community-resources). The technology was never going to be your hard part – the business machine is, and it's entirely learnable. --- ## IAM (Identity and Access Management) ## Definition Identity and Access Management is the discipline and tooling for managing digital identities and what they may reach – the directory of users and groups, authentication ([MFA](/wiki/glossary/mfa), [SSO](/wiki/glossary/sso), passwordless), authorization through roles and group membership, and the joiner-mover-leaver lifecycle that provisions access on day one and revokes it on the last. In most SMBs the identity platform is Entra ID or Google Workspace, with SaaS applications federated to it. ## Why it matters to an MSP Identity is where most breaches start – stolen credentials remain the leading initial access vector – so the identity platform is the control plane you are really defending, not the firewall. It is also where [shadow IT](/wiki/glossary/shadow-it) gets governed: a sanctioned app behind SSO with automated provisioning is covered by MFA, appears in sign-in logs, and loses access the moment the user is disabled; the same app on a personal login is invisible and survives offboarding. The operational upside is measurable. Password resets and access requests are a large share of an SMB help desk's ticket volume; SSO, self-service reset, and group-based access assignment cut most of it, which is labor you keep as margin under a flat-fee contract. A documented offboarding runbook that disables one identity and cascades to every application is also what insurers and auditors mean when they ask about "timely access revocation." Package it: identity governance – MFA enforcement, conditional access, SSO onboarding for the client's key SaaS apps, quarterly access reviews – sells as a security tier or a $5–$15 per user per month line. The one part that needs discipline rather than tooling is privileged accounts, which is where [PAM](/wiki/glossary/pam) picks up. Sequencing is covered in [identity and access for SMB](/wiki/identity-and-access-for-smb). Related terms: [SSO](/wiki/glossary/sso), [MFA](/wiki/glossary/mfa), [PAM](/wiki/glossary/pam), [Shadow IT](/wiki/glossary/shadow-it) --- ## Identity and Access Management for SMB Clients ## Identity is the perimeter now A typical SMB client in 2026 has no server room worth defending. Email, files, accounting, CRM, and the line-of-business app all live in someone else's cloud, reachable from any device on any network with nothing but a username, a password, and whatever second factor you enforced. Stolen or phished credentials remain the most common way into an SMB, and the dominant technique – adversary-in-the-middle [phishing](/wiki/glossary/phishing) that steals the authenticated session – walks straight past SMS and push prompts. Whoever controls the identity controls the business. The practical consequence: [IAM](/wiki/glossary/iam) is one buying conversation, not five products. MFA, SSO, conditional access, privileged access, and [Zero Trust](/wiki/glossary/zero-trust) are layers of the same build, and clients buy it best when you sell it as a sequence. ## The build-out, in order **One identity provider.** Every client gets exactly one source of truth for user accounts – for almost every SMB that is the Microsoft 365 tenant or Google Workspace. Sync or retire the on-premises directory, kill shared mailboxes used as logins, and make every SaaS app trust that provider instead of keeping its own password list. Nothing further works until this is true. **[MFA](/wiki/glossary/mfa) on every account.** Enforced by policy, not by asking nicely; no SMS; number matching on push prompts so users cannot approve blind. Admins, finance staff, and executives – anyone worth phishing deliberately – get phishing-resistant methods: FIDO2 keys, passkeys, or platform authenticators bound to the device. Hardware keys run roughly $25–60 each; a set for a client's admins costs less than an hour of incident response. **[SSO](/wiki/glossary/sso) for SaaS apps.** Connect each business application to the identity provider through SAML or OIDC, with automated provisioning where the vendor supports it. This is what makes offboarding a single switch and turns [shadow IT](/wiki/glossary/shadow-it) into managed IT. Expect the "SSO tax" – many vendors sell SSO only on a higher plan – and budget for the upgrades. **Conditional access and device compliance.** Rules that decide whether a sign-in is allowed at all: block legacy authentication protocols, require a managed and compliant device for company data, refuse sign-ins from countries the client has no business in, and step up authentication for risky sessions. **Least privilege and privileged access.** Nobody works day to day with admin rights – not on the laptop, not in the tenant. Admins get separate, named admin accounts, standing global-admin roles shrink to two break-glass accounts in the password vault, and elevation is just-in-time and time-boxed. [PAM](/wiki/glossary/pam) tooling that removes local admin from endpoints and grants it per task closes the last common gap. **Joiner, mover, leaver.** Identity decays without process. HR triggers a ticket for every hire, role change, and departure; the leaver ticket has a clock – account disabled within one business hour of notice, sessions revoked, licenses reclaimed within a week – and access is reviewed quarterly, with dormant accounts disabled after 45 days. Tie this to your [client onboarding process](/wiki/client-onboarding-process) so it is written in the first 30 days and lives in the client's documentation. ## What the insurer and CIS actually require Every [cyber insurance](/wiki/glossary/cyber-insurance) application since about 2022 asks the same three questions: is MFA enforced on email, on remote access, and on privileged accounts. As of 2026 more carriers add whether admin MFA is phishing-resistant, whether privileged accounts are separated from daily-use accounts, and how quickly departed employees lose access. A weak answer costs the client a declined application or a 40–100% premium hike; a strong answer is the layered build above, item for item. [CIS Controls](/wiki/glossary/cis-controls) v8.1 says the same thing in control language. Control 5 covers account management – an inventory of accounts, unique credentials, dormant accounts disabled, admin rights restricted to dedicated accounts. Control 6 covers access control – a documented grant and revoke process, and MFA for externally exposed applications, remote access, and administrative access. All of those safeguards sit in Implementation Group 1, the floor every framework expects. ## Your own tenant first You cannot sell identity hygiene from a shop that fails its own test. Partner access to client tenants runs through [GDAP](/wiki/glossary/gdap) – per-client, role-scoped, time-boxed – never legacy delegated admin. Every technician has a named account; there is no shared support login and no standing "msp-admin" global admin parked in every client tenant. Technician MFA is phishing-resistant across the board, privileged roles activate just-in-time, and a per-client break-glass account lives in the vault with its use alerting. The full hardening sequence is in [securing your MSP](/wiki/securing-your-msp). ## Packaging and pricing Identity belongs in the standard per-seat offer, not in an optional tier a client can decline. Where you run a base seat plus a security tier, the identity bundle – MFA, conditional access, SSO management, quarterly access reviews – is typically a $5–15 per user per month uplift as of 2026, most of it service rather than licensing, since the core licensing already sits in the business-tier Microsoft bundle most clients own; premium identity licensing for risk-based policies and just-in-time elevation adds roughly $6–9 per user at list where a client needs it. The rollout is a project, priced separately: typically $2,500–10,000 for a 25–100 user client, or $75–150 per user, covering discovery, policy design, pilot, enforcement, and the helpdesk surge. Do not fold the project into the monthly fee; a free rollout teaches clients that identity work is free. ## Rollout order that keeps the helpdesk quiet Every identity change generates tickets; sequencing decides how many. 1. Inventory first – pull 30 days of sign-in logs to find legacy-protocol clients, service accounts, shared mailboxes, and every app that will break when authentication changes. The copier that scans to email is the classic surprise. 2. Communicate, then register – a two-week window where users enroll MFA methods with written guidance, while conditional access runs in report-only mode so you can see what would have been blocked. 3. Enforce for admins first, then a pilot group of friendly users, then everyone – on a Tuesday, with an extra technician on the queue. Expect a 15–30% ticket spike in the enforcement week that decays within two. 4. Disable legacy authentication once the inventory says nothing depends on it. 5. Add SSO one application at a time, starting with the apps that have the most users and already support it. 6. Turn on device compliance rules after two to four weeks in report-only. 7. Remove local admin rights last, once SSO and self-service password reset have removed the usual excuses. 8. Hand the client's HR contact the joiner-mover-leaver procedure and book the first quarterly access review. ## Bottom line For a cloud-first SMB the identity provider is the perimeter, and the layers – one provider, MFA everywhere with phishing-resistant methods for admins, SSO, conditional access, least privilege, and a leaver process with a clock – are one product sold in sequence. It is the exact list insurers and CIS IG1 require, it costs the client a modest per-seat uplift plus a one-time project, and it only works if your own tenant already passes the same test. Roll it out in the order above and the helpdesk survives it. --- ## Incident Response Process ## Preparation: before anything burns Incident response is decided in advance. The 2025–26 cyber insurance minimum-controls list includes an incident response plan – increasingly an *exercised* one – so preparation is both survival and a control your clients' carriers will ask about. - **A written IR plan per client**, stored where you can reach it when the client's network is down: severity definitions, containment authority (can you isolate machines without asking?), and the contact tree. - **The contact tree:** client executive sponsor, your incident lead, the client's breach counsel if pre-selected, and – first among equals – the client's [cyber insurance](/wiki/glossary/cyber-insurance) carrier hotline number and policy number. Keep an offline copy. - **First-call rule, agreed in advance:** the carrier hotline gets called before any vendor is engaged. Most policies require pre-approved panel vendors; calling your favorite firm first can delay or void claim payment. - **Your own "the MSP is popped" runbook.** The CISA AA22-131A advisory exists because attackers target MSPs to reach every client at once. Per its guidance: an exercised plan, offline copies of documentation, and out-of-band communications for the scenario where your own RMM or tenant is the incident. See [securing your MSP](/wiki/securing-your-msp). **Roles:** one incident lead per event (owner or service manager), a technical lead running containment, and a single communicator. In a small shop one person wears two hats – never all three. ## Detection and triage Incidents surface through [EDR](/wiki/glossary/edr)/[MDR](/wiki/glossary/mdr) alerts, user reports ("my files have weird extensions"), backup anomalies, mailbox rules nobody created, or a client's bank flagging a payment. Triage answers four questions fast: What is affected and how widely? Is it active right now? Is data leaving? Are privileged accounts or your own tooling involved? Do not start "fixing" until you can answer these – triage determines whether this is a ticket or an event. ## Severity classification Use your standard priority matrix, with security-specific auto-escalation. These conditions make an incident **P1 immediately, no judgment call required**: - Confirmed ransomware encryption anywhere in the environment - Active hands-on-keyboard attacker activity - Confirmed or suspected data exfiltration - Compromise of a privileged/admin account, or of the MSP's own RMM, PSA, or documentation platform - [BEC](/wiki/glossary/bec) with a fraudulent payment in flight Lower severities (single compromised mailbox with no lateral movement, a contained malware detection) run through normal escalation – but they get the same evidence discipline, because "contained" is a hypothesis until verified. An active security incident is a P1 under any sane [SLA](/wiki/glossary/sla) matrix; make sure yours says so. ## Containment: isolate, don't wipe 1. **Isolate.** EDR network-isolate affected hosts; for site-wide events pull WAN, disable VPN and remote access; kill file-sync clients so encrypted files stop propagating to clean copies. 2. **Cut off identities.** Disable compromised accounts, revoke active sessions and tokens, reset credentials – token theft survives a password change, so revoke sessions explicitly. 3. **Preserve evidence.** Do not wipe, rebuild, reimage, or delete anything. The instinct to "clean it up" destroys the forensic record that the DFIR firm, the insurer, and possibly regulators will need – and botched evidence handling creates liability for you. 4. **Activate.** Trigger the client's IR plan and make the carrier hotline call now, in parallel with containment – not after. ## Who leads a major incident: the carrier's panel, not you The MSP is the first responder, not the DFIR firm. For any confirmed encryption or exfiltration, legal or regulatory exposure, or ransom negotiation, the client's policy will route the response through pre-approved panel vendors: breach counsel, a DFIR firm (Arctic Wolf IR, Kroll, ProvenData are typical), and negotiators if needed. Breach counsel typically quarterbacks the whole response so the work is legally privileged. This structure protects everyone, including you. A small MSP should not negotiate with threat actors or run forensics alone. Your job in a major incident: preserve logs and images, provide access and tribal knowledge of the environment, execute containment and rebuilds under DFIR direction, and run the restores. If you or your clients hold IR retainers, verify the retained firm sits on the carrier's panel *before* signing – a retainer with an off-panel firm can be worthless when the claim matters. ## Communication discipline - **One voice.** The designated communicator talks to the designated client executive on a stated cadence. Technicians don't freelance updates, speculate in writing, or use the word "breach" – a legal term of art counsel decides on. - **Counsel reviews written statements** once engaged. Regulatory notification clocks (typically 30–60 days under FTC, HHS, and state rules) are counsel's call, not the MSP's. - **Assume email is compromised.** BEC and mailbox takeovers mean the attacker may be reading incident emails. Move coordination to the pre-agreed out-of-band channel from the contact tree – phone, Signal, or an alternate tenant – the moment identity compromise is suspected. ## Recovery Recovery runs through the [backup and DR process](/wiki/backup-dr-process), from immutable copies – but only after DFIR confirms the attacker is evicted and the initial-access vector is identified and closed. Restoring a system with the same vulnerability, or from a backup taken after the compromise, restores the breach. Rebuild in runbook order, rotate every credential in the environment, re-enroll MFA, and monitor the restored environment closely for re-entry attempts in the following weeks. ## Post-incident review and hardening Within about two weeks, run a blameless post-incident review: timeline, initial access, what each control caught or missed, what the response got right and wrong. Two outputs: (1) a complete documentation package for the insurance claim – every action, timestamp, and decision; (2) a hardening roadmap priced as projects and presented at the next [QBR](/wiki/qbr-process) as risk reduction. An incident is the one moment a client's appetite for security spending exceeds your ability to schedule the work – use it. ## Your own liability When a client is breached, the MSP gets scrutinized – expect the client, the carrier, and counsel to ask what you deployed, monitored, and missed. - **Never sign the client's insurance attestation.** Misstatements have led carriers to rescind coverage post-breach, and an MSP that wrongly attested "MFA everywhere" lands in the E&O crossfire. Provide written control status with evidence; the client's officer signs. - **Carry your own E&O and cyber coverage** – MSP-specific programs exist (SeedPod and Cork are examples) – and align your [MSA's](/wiki/msp-contracts-and-msa) limitation-of-liability and security-incident carve-outs with that policy. Require clients to carry their own cyber insurance in the contract. More in [MSP legal and insurance](/wiki/msp-legal-and-insurance). - **Document contemporaneously.** Dated records are cheap during the incident and nearly impossible to reconstruct when a claim lands a year later. ## Readiness cadence - **Quarterly:** verify the contact tree and carrier hotline numbers; confirm offline documentation copies are current. - **Annually:** tabletop the IR plan with each top-tier client, and run your own "RMM compromised" exercise internally. - **At every onboarding:** capture carrier, policy number, and hotline into documentation; agree containment authority in writing. - **Continuously:** evidence discipline on every security ticket, however small. The MSPs that survive a client's worst day are the ones that made the carrier call first, contained without destroying evidence, and worked calmly under the panel's direction – all of which is decided by the preparation you do this quarter. --- ## Landing Your First 10 Clients ## Why warm beats cold at the start New-customer acquisition is the single biggest challenge named by roughly one in three MSPs in Kaseya's 2025 benchmark – and that's established shops with references, case studies, and a marketing budget. A brand-new [MSP](/wiki/glossary/msp) has none of those, which is exactly why cold channels fail early and warm ones work. Referrals from people who already trust you convert roughly 3–5x better than cold outreach, yet the practitioner consensus is blunt: the vast majority of MSPs never explicitly *ask* for them. The mechanics matter. The ask is not "do you need IT support?" – it's a short, personal message (text, email, LinkedIn) to former colleagues, past clients, vendors, and friends adjacent to your ideal client, asking for *introductions, not the sale*. "Who do you know running a 10–30 person business who complains about their IT?" is a question people can actually answer. The mindset shift that helps technical founders most: you are matching, not convincing. Find prospects with a live problem instead of trying to manufacture urgency in prospects who don't have one. The classic technical-founder trap is the inverse: over-investing in the stack and under-investing in conversations. Your [RMM](/wiki/glossary/rmm) configuration will not land client number one. Twenty coffee meetings might. ## The ex-employer and ex-colleague route For founders leaving a sysadmin or internal IT role, the warmest lead of all is often the company you just left. An amicable ex-employer frequently becomes the first client – or a steady referral source for overflow work and sub-contracting. Colleagues who moved on to other companies are the second circle: they know your work firsthand and can champion you internally. Two cautions before you work this route: - **Check your paperwork.** Read any non-compete and non-solicit clauses before approaching your former employer's contacts or clients. An early lawsuit is a company-killer. - **Leave clean.** Give real notice, document your handover, and never build your side business on employer hardware – the goodwill you bank on the way out is a sales asset. A related shortcut: partnerships with larger MSPs in your area. Taking their sub-minimum accounts – clients too small for their pricing floor – is cited by practitioners as the fastest source of qualified leads for a new shop. You get pre-warmed prospects; they get a graceful place to send deals they'd otherwise decline. ## Local networking that works for technical founders You don't need to become a natural salesperson; you need a repeatable local motion: - **Build a hyper-local target list.** Pull 50–100 businesses with 5–25 employees within 5–10 miles using Google Maps and chamber-of-commerce directories. Visit or call, leave a one-pager, and offer a low-commitment free consult or audit. - **Chambers and BNI-style referral groups.** Dues are cheap (budget them under first-year marketing), and structured referral groups force the weekly repetition that introverted founders otherwise avoid. You're usually the only IT provider in the room. - **Vertical associations.** Dental societies, bar associations, contractor groups – vertical clients cluster in associations and peer groups, and one trusted reference spreads fast there. If you're leaning toward a specialty, this is where it starts; see [choosing a niche](/wiki/choosing-a-niche). - **Helpful presence in LinkedIn and industry Facebook groups.** Conversational, useful answers – not pitches – with the goal of a discovery call. One channel alone is too slow; networking-only growth is described by practitioners as "painfully slow." Run the warm-referral ask, the local list, and one networking venue in parallel. For the longer-term marketing engine, see [MSP sales and marketing](/wiki/msp-sales-marketing). ## Turning break/fix and project work into managed contracts Most young MSPs accumulate [break/fix](/wiki/glossary/break-fix) customers and one-off projects early. That's fine as a door – it's a trap as a destination. Break/fix revenue depends on things going wrong: incentives are misaligned, income is unforecastable, and every hour of prevention destroys billables instead of protecting margin. A managed contract flips this – fixed monthly fee regardless of ticket volume. The rule of thumb from break/fix-to-managed transition guides: push toward **at least 50% recurring revenue** as fast as you can, because [MRR](/wiki/glossary/mrr) is what makes the business plannable and, eventually, sellable. Use every project as a Trojan horse: finish the migration, present what you found, and quote the monthly agreement that keeps it healthy. For legacy hourly clients, set a conversion deadline – a date after which you only work under a managed agreement – and let the ones who refuse go. ## Assessment-led selling: the door-opener The strongest low-commitment offer for a technical founder is the one that plays to your strengths: a network or security assessment, free or cheap, that produces a written findings report. It gives a prospect a concrete reason to let you in the door, gives you a legitimate look at their environment, and converts the conversation from "do you want to switch IT providers?" (scary) to "here are nine specific risks and what fixing them costs" (actionable). Run it as a defined process with a professional deliverable, not an ad-hoc poke around – see the [network assessment process](/wiki/network-assessment-process). The report ends with a proposed monthly agreement. Even prospects who don't sign remember who showed them their exposed backups, and assessments are a natural fit for chamber talks and association newsletters. ## Qualify hard: the courage to say no Here's the math that makes qualification non-negotiable: MSPs typically invest **$10,000–$15,000 per client in onboarding** and don't break even on a new client until **months 7–12**. One bad-fit client can eat a quarter's profit – before counting the morale cost of a client who fights every ticket. Practical filters for a young shop, typical as of 2026: - **Set a monthly minimum – commonly $500+/month – and hold it.** Below that, the client can't afford the service you're actually selling, and you become their cheap break/fix guy with a contract. - **Walk away from prospects who negotiate the price before understanding the service.** Cheap prices attract cheap clients; that dynamic doesn't improve after signing. - **Beware the toxic anchor client** – the one big early logo that demands custom everything, hates your standards, and consumes half your week. Revenue concentration plus operational chaos is how solo MSPs stall. - **Require your paper.** A prospect who won't sign your [MSA](/wiki/msp-contracts-and-msa) or resists a defined scope is showing you the next three years. Saying no feels impossible at client three. It's cheaper than firing them at client twelve. ## The lighthouse client effect One well-served client in a vertical seeds the next five. Verticals are dense social networks – dentists talk to dentists at study clubs, contractors meet at association events, attorneys refer within the local bar. A single trusted reference inside that network converts far better than any campaign, and a great [onboarding](/wiki/client-onboarding-process) experience is what makes that first client an evangelist. Deliberately over-deliver for your first client in a promising vertical, then ask them – explicitly – for introductions to peers. ## What fails early Money-savers, learned the hard way across many founder retrospectives: - **Cold SEO and content-marketing agencies.** SEO is a legitimate long game, but it's too slow to feed a startup, and agencies selling it to zero-brand MSPs mostly burn your runway. - **Bought lead lists and mass cold email.** Cold outreach already converts 3–5x worse than referrals; spraying a purchased list converts worse still and damages your domain reputation. - **Paid ads before positioning.** Ads amplify a message; with no niche, no proof, and no differentiated offer, they amplify nothing – at $1,000+/month. - **Passive social posting and waiting for word of mouth.** Activity that feels like marketing but generates no conversations. ## Where to start This week: list 30 people who know your work and send ten short introduction-asks. This month: build the 50–100 business local list, join one chamber or referral group, and package a free assessment with a written report. This quarter: convert or sunset your hourly clients, set your $500+/month floor, and pick the vertical where your first lighthouse client lives. Ten good clients is not a marketing problem – it's a discipline problem, and warm, local, assessment-led motion solves it. For the full launch sequence around this, see [how to start an MSP](/wiki/how-to-start-an-msp). --- ## Legal Setup and Insurance ## Entity choice: LLC first, S-corp election later The most common mistake technical founders make here is overthinking it. The standard path for a solo or two-person MSP is simple: form an LLC now, and elect S-corp taxation later, once profit justifies it. An S-corp is not an entity type – it's a *tax election* you file with the IRS on top of an existing entity. An LLC is cheap to form, has minimal compliance overhead, and is taxed as a pass-through by default. Corporations, by contrast, require annual shareholder meetings, minutes, and directors' meetings; LLCs don't. That's why LLC-plus-late-S-election is the default for solo founders. **Why the S-corp election eventually pays:** as a plain LLC, all net profit is hit with the 15.3% self-employment tax (up to the Social Security wage base – $176,100 in 2025 – with 2.9% Medicare above that). Under an S-corp election, you pay yourself a "reasonable salary" that is payroll-taxed, and take remaining profit as distributions that avoid self-employment tax. **When to elect:** the consensus threshold is net profit consistently above **$50,000–$60,000/yr**. At that level the election saves roughly $2,000–$4,000/yr; at $100k profit, $5,000–$8,000/yr. Against that, S-corp admin overhead – payroll processing, extra filings, higher accounting fees – typically runs **$3,000–$8,000/yr**, which is why some CPAs argue for waiting until around $150k profit. Below the threshold, the election can cost more than it saves. Run the math with a CPA once you're profitable; don't elect on day one. **The day-one checklist** is short: - Form the LLC in your state - Get an EIN from the IRS - Open a separate business bank account (never commingle funds) - Appoint a registered agent - Get an attorney-drafted [MSA](/wiki/msp-contracts-and-msa) before your first managed contract ## The insurance bundle a new MSP needs MSPs are a high-risk class to insurers for a structural reason: a compromise of the MSP cascades to every client – you are a supply-chain attack vector by definition. That shapes both what you need and what it costs. Typical 2026 costs for a small MSP: | Coverage | What it covers | Typical annual cost (as of 2026) | |---|---|---| | General liability | Third-party bodily injury and property damage; required by client contracts and office leases | ~$360/yr (~$30/mo) | | Tech E&O / professional liability | Lawsuits over work mistakes – a botched migration, a missed patch that causes client data loss | ~$800/yr average; $800–$3,000/yr typical range | | [Cyber liability](/wiki/glossary/cyber-insurance) | Breach response, ransomware, liability from incidents that spread to clients | $1,200–$5,000/yr for most small/mid MSPs ($1M coverage; small-business range runs up to ~$7,500) | A realistic bundled total for a solo MSP carrying $1M/$2M limits is roughly **$2,500–$6,000/yr**. Add workers' compensation the day you hire your [first technician](/wiki/hiring-first-technician) – it's required in most states once you have an employee. Cyber premiums are priced on your revenue, managed endpoint count, claims history, and – importantly – your own security controls: [MFA](/wiki/glossary/mfa) everywhere, [EDR](/wiki/glossary/edr) on your systems, and tested backups. [Securing your own MSP](/wiki/securing-your-msp) isn't just good practice; it directly lowers your premium and keeps you insurable. ## Certificates of insurance: the ticket to play Expect any client above mom-and-pop size to demand a certificate of insurance (COI) before signing. This isn't bureaucratic theater. Every vendor with access to a client's systems creates liability for that client, and insurance requirements in contracts transfer that risk back to the vendor – you. Larger and regulated clients (and *their* insurers and auditors) won't onboard a vendor without a COI, and often require being named as **additional insured** on your policy. Increasingly, clients' own cyber insurers require proof that their MSP carries E&O and cyber coverage – no COI, no contract. Two practical implications: - **Get insured before you sell, not after.** Waiting until a prospect asks stalls the deal for weeks. - **Offer the COI upfront.** Handing it over unprompted signals professionalism and removes a common back-and-forth from your sales cycle. ## How E&O and your MSA's liability caps interact Your E&O policy and your MSA are two halves of the same risk system, and they only work together. The MSA's limitation-of-liability clause caps what a client can recover from you – commonly tied to fees paid over some period. Your E&O policy then covers claims up to its policy limit. When the contract cap sits comfortably inside your policy limits, a worst-case claim is an insurance event. When there's **no cap** – the classic failure mode of free, downloaded contract templates – a client's claim can exceed your policy limit, and the difference comes out of the business. The same free templates typically also lack a defined service scope and exclusions (unsupported hardware, end-of-life software), which is exactly what a plaintiff's lawyer exploits: if the contract doesn't say what you *weren't* responsible for, you were arguably responsible for everything. This is why "no real contracts" shows up consistently on lists of first-year MSP mistakes, and why the fix is an attorney-drafted MSA with a clear scope, exclusions, and a liability cap – not a borrowed PDF. ## Licenses, registered agents, and the boring basics None of this is hard, but skipping it creates problems at the worst times: - **Business license/registration:** requirements vary by state and city; check your local jurisdiction when you file the LLC. Regulated-vertical clients (compliance-driven industries especially) may ask for proof of registration during vendor onboarding. - **Registered agent:** required for an LLC – the address where legal notices are served. Use a commercial registered agent service (typically cheap) rather than your home address if you value privacy or move often. - **Foreign qualification:** if you land clients in another state and establish real presence there, you may need to register the LLC there too. Ask your accountant when it comes up; don't pre-register everywhere. ## When to actually pay a lawyer You don't need a lawyer on retainer, but there are moments where paying one is the cheapest insurance you'll buy. Budget roughly **$1,500–$5,000** for initial legal setup plus insurance, most of it going to documents: 1. **Your MSA and SOW templates.** This is the non-negotiable one. Don't download free templates – the missing exclusions and liability caps are precisely the expensive parts. 2. **Reviewing your non-compete and non-solicit** from your current or former employer before you take clients or contacts with you. An amicable ex-employer can become your first client; a lawsuit from one can end the business. 3. **Regulated-client paperwork** – e.g., business associate agreements for [HIPAA](/wiki/glossary/hipaa)-covered clients – the first time you encounter each type. What you generally *don't* need a lawyer for: forming the LLC itself (state filing plus a registered agent service is usually enough for a single-member LLC), the EIN, or the S-corp election paperwork (your CPA handles that). ## Bottom line Form an LLC now; revisit the S-corp election with a CPA once net profit sustainably clears $50–60k. Buy general liability, tech E&O, and cyber liability before your first real contract – typically $2,500–$6,000/yr all-in as of 2026 – because serious clients will demand a COI before they sign anything. Spend your legal budget on an attorney-drafted MSA with liability caps that sit inside your policy limits. Then get back to [finding your first clients](/wiki/first-msp-clients) – the legal setup is a week of admin, not a phase of the business. For the rest of the launch checklist, see [how to start an MSP](/wiki/how-to-start-an-msp) and [what it really costs](/wiki/msp-startup-costs). --- ## MDR (Managed Detection and Response) ## Definition Managed detection and response (MDR) is a service in which an outside provider's security analysts monitor [EDR](/wiki/glossary/edr) telemetry from your clients' [endpoints](/wiki/glossary/endpoint) 24/7, investigate alerts, and take containment actions – isolating a host, disabling an account, killing a process – on your behalf. EDR is the tool on the endpoint; a [SOC](/wiki/glossary/soc) is the team of analysts; MDR is the packaged service that combines both, sold per endpoint, so you get the team without hiring it. ## Why it matters to an MSP MDR is standard in the MSP stack because of staffing math. Round-the-clock coverage takes eight to twelve analysts before tooling, roughly $1M or more per year fully loaded, which does not pencil until you manage several thousand endpoints. Attackers know this and deliberately act on Friday nights and holiday weekends. Resold MDR buys that coverage at a marginal cost of roughly $3–15 per endpoint per month as of 2026, and it is typically marked up two to three times inside a security tier at $25–50 per user per month. MDR also changes what you can promise. An incident response plan that starts "when the client calls us" is a plan to lose data; with MDR the first response happens before anyone on your team is awake, and your role shifts to the investigation and recovery that follows. Decide up front whether the provider has pre-authorized response – isolating a client's server without asking – or click-to-approve, and put that choice in the contract; a wrongly isolated production host at 2 a.m. is a conversation to have in advance. MDR is on most [cyber insurance](/wiki/glossary/cyber-insurance) minimum-controls lists alongside [MFA](/wiki/glossary/mfa) and immutable backup. How it fits with your other monitoring is in [MSP security operations](/wiki/msp-security-operations). Related terms: [EDR](/wiki/glossary/edr), [SOC](/wiki/glossary/soc), [Cyber Insurance](/wiki/glossary/cyber-insurance), [Ransomware](/wiki/glossary/ransomware) --- ## Monthly Recurring Revenue (MRR) ## Definition Monthly recurring revenue is the sum of all contracted, repeating monthly fees – managed service agreements, seat and device subscriptions, resold licensing, hosted services – normalized to a single month. Project work, hourly billing, hardware sales, and one-time onboarding fees are excluded, however large they are. ## Why it matters to an MSP MRR is what separates a managed service provider from a [break/fix](/wiki/glossary/break-fix) shop with a website. Recurring fees are what let you plan: they cover payroll before the month starts, tell you when the next technician is affordable, and turn a cash-flow forecast into something better than a guess. Hire against contracted MRR, never against pipeline – a first technician is safe once MRR covers the loaded salary plus tools with margin to spare, and a business is genuinely "managed" once recurring revenue passes half of total revenue and rests on [per-seat](/wiki/glossary/per-seat-pricing) or [per-device](/wiki/glossary/per-device-pricing) agreements rather than bundled hours. It is also what the business is worth. Buyers value MSPs on recurring revenue and the profit it produces – typically 4–7x EBITDA for small firms as of 2026, more for larger ones – and discount project and hardware revenue heavily or ignore it. Track MRR with its derivatives: net new MRR (added minus lost each month), [churn rate](/wiki/glossary/churn-rate) measured as lost MRR rather than lost logos, MRR per seat and per technician, and gross margin on MRR (50–60% blended is the typical healthy range; disciplined shops target 70% on the managed services line). Keep these in your [PSA](/wiki/glossary/psa)'s contracts module, not a spreadsheet, because the contract terms make the number real: auto-renewal, annual escalators, and minimum seat counts in the [MSA](/wiki/msp-contracts-and-msa) stop MRR from quietly shrinking. When growth stalls, fix pricing or sales before adding headcount. Related terms: [Churn Rate](/wiki/glossary/churn-rate), [Per-Seat Pricing](/wiki/glossary/per-seat-pricing), [Break/Fix](/wiki/glossary/break-fix), [Value-Based Pricing](/wiki/glossary/value-based-pricing) --- ## MSP Communities and Learning Resources ## Why this list matters Running an [MSP](/wiki/glossary/msp) is a lonely business for a technical founder: your clients can't sanity-check your pricing and your competitors won't. The MSP industry compensates with an unusually open community culture – pricing, vendor experiences, and even P&L benchmarks get discussed in public. But there are more communities, conferences, and podcasts than any one-person shop can absorb. This reference organizes the options as of 2026 and ends with a sane path through them. ## Online communities - **r/msp** – the default free community. Unfiltered pricing threads, vendor experiences, sanity checks, and weekly recurring threads. Read the pricing megathreads before you set your rates – they pair well with [MSP pricing models](/wiki/msp-pricing-models). - **MSPGeek** – free, technical, Discord/Slack-based community. It grew from ConnectWise/Automate roots but is broad now, and it runs its own community conference (MSPGeekCon). The best free technical peer support available. - **The Tech Tribe** – Nigel Moore's low-cost paid global community for small MSP owners. Templates, marketing materials, contract samples, "Tribal Perks" vendor discounts, and meetups. Repeatedly cited as the best value for a solo founder. - **ASCII Group** – the longest-running independent North American MSP association (since 1984, roughly 1,300 members as of 2026), with around eight regional events a year and member vendor discounts. - **GTIA** – the former CompTIA Community, rebranded to the Global Technology Industry Association in January 2025 after the CompTIA certification brand was sold to a for-profit. A vendor-neutral nonprofit channel association with 2,000+ member companies. ## Peer and accountability groups A [peer group](/wiki/glossary/peer-group) puts you in a room with non-competing MSP owners who see your real numbers and hold you to your commitments. These are paid programs – the common guidance is to join once you have staff and roughly $1M in revenue, when you have a real P&L to benchmark and the fee stops being material. | Group | What it's known for | Stage fit (as of 2026) | |---|---|---| | Service Leadership | SLIQ benchmarking against the Service Leadership Index; part of ConnectWise | Owners managing to financial benchmarks | | IT Nation Evolve | Structured peer accountability (formerly HTG); also ConnectWise | Established shops wanting quarterly accountability | | TruMethods / TruPeer | Gary Pica's framework-driven program, strong on pricing and profitability mechanics; now under Kaseya | Shops fixing pricing and margin discipline | All three cost materially more than the communities above and expect real commitment – shared financials, quarterly meetings, homework. What they deliver is the thing free communities can't: accountability against your own [KPIs and benchmarks](/wiki/msp-kpis-and-benchmarks) from people with no reason to flatter you. ## Conferences worth the money (as of 2026) - **IT Nation Connect** – ConnectWise's flagship, Orlando each November. The business-of-MSP event. - **Kaseya Connect** – Kaseya's flagship; DattoCon NA held its final separate edition in October 2025 and folded into it. - **Pax8 Beyond** – fast-growing, with North American and EMEA editions. - **MSP Global** – Zurich, run by the CloudFest team; the European business-of-MSP event. - **Right of Boom** – security-focused and well regarded; the natural pick if security services lead your catalog. - **MSPGeekCon** – community-run, technical, inexpensive by conference standards. - **Regional events** – ASCII's roughly eight events a year and GTIA regional meetings deliver much of the networking value at a fraction of the cost. **Economics for a small shop:** a national conference is not just the registration fee – it's flights, hotel nights, and several days you are not billing, which for a one- or two-person shop is often the largest real cost. Budget for one national conference a year at most, chosen to match your [vendor stack](/wiki/msp-vendor-channel) or growth stage, and fill the rest of the year with regional events. Industry watchers (Omdia) note the energy is shifting from mega-conferences to smaller community-driven events anyway, which favors the small shop's budget. ## Podcasts, blogs, and trade press (current 2025–2026) - **Business of Tech** (Dave Sobel) – daily news and analysis of channel and vendor moves. - **Paul Green's MSP Marketing Podcast** – weekly, focused on the marketing and sales problems covered in [MSP sales and marketing](/wiki/msp-sales-marketing). - **TubbTalk** (Richard Tubb) – long-form interviews with MSP owners and channel figures. - **MSP Zone** – GTIA's podcast; channel policy and association news. - **SMB Community Podcast** (Karl Palachuk) – small-MSP operations and community. - **Trade press:** MSP Success magazine, ChannelPro, ChannelE2E, CRN, and Channel Futures (home of the MSP 501 ranking) for vendor and industry news. ## Vendor-run education **[Acronis MSP Academy](https://academy.acronis.com/en-eu/)** – open-access training for new and established MSPs, covering business operations, sales, marketing, technology, and technician productivity. It offers short modules, learning plans, certification exams, and Credly badges. Acronis also provides separate product-specific training. Most major vendors and distributors run free or bundled partner education. Before paying for third-party training, check what your distributor, RMM, and PSA vendors already include. Use general business courses to improve operations, then use product certifications to train technicians on tools you have already chosen. ## Benchmark and report sources - **Service Leadership Index** (ConnectWise) – the canonical annual profitability benchmark. As of 2026 it shows best-in-class MSPs sustaining 19%+ adjusted EBITDA, with the top quartile earning roughly 2.5x the EBITDA percentage of median peers. - **Kaseya Global MSP Benchmark Report** – the broad annual survey; the 2025 edition found 1 in 3 MSPs naming new-customer acquisition their hardest problem, rising to 71% looking toward 2026. Read one of each per year and compare against your own numbers in [MSP KPIs and benchmarks](/wiki/msp-kpis-and-benchmarks). ## How to use all this without drowning Community time is real time, and Reddit arguments about RMM vendors don't bill. 1. **Starting out:** join r/msp and MSPGeek (free) and consider The Tech Tribe (low-cost). That trio covers pricing sanity checks, technical peer support, and business templates – everything a founder needs alongside [starting the MSP](/wiki/how-to-start-an-msp). 2. **Cap the habit:** a fixed weekly slot for community reading beats ambient scrolling. Subscribe to one daily podcast (Business of Tech) and one weekly. 3. **First few years:** one national conference a year maximum, plus regional ASCII/GTIA events. 4. **Around $1M revenue with staff:** graduate to a paid peer group – Service Leadership, IT Nation Evolve, or TruPeer – and let shared financials and accountability replace anonymous advice. ## Bottom line Start free, stay focused, and upgrade deliberately: r/msp and MSPGeek today, The Tech Tribe when you want its templates, one well-chosen conference a year, and a paid peer group when your revenue justifies real accountability. The MSP community is one of the industry's genuine advantages – used on a schedule, it compounds; used as a distraction, it just feels like work. --- ## MSP Contracts and the MSA ## Why handshake deals fail Managed services has an ugly cash-flow curve: you lose money at the start of every client relationship. Onboarding a 100-seat client typically costs $10,000–15,000 in tool deployment, documentation, monitoring setup, and security baselining before the agreement earns its first dollar of profit, and typical payback lands around month nine or ten. A client who walks in month four of a verbal, month-to-month arrangement is a straight loss – you paid to onboard them and never got it back. That math is why "we'll just work on a handshake" is the classic new-MSP mistake. The damage goes beyond one bad exit: - **Undefined scope.** With nothing in writing, every "can you also just..." becomes free work. Scope creep on verbal deals is invisible until you notice a client quietly eating your payroll. - **Uncapped liability.** No contract means no limitation of liability. If a client suffers data loss or a breach, your exposure is whatever a court decides – not a defined cap your insurance can plan around. - **Depressed valuation.** MSPs with strong written recurring contracts are worth far more at exit than firms running on project work or verbal agreements. Your contract stack is literally part of what a buyer is buying. Month-to-month terms can work, but as a deliberate premium offer, not a default: they generally only make sense with 95%+ retention, and they are typically priced around 25% above the equivalent 36-month term. If you offer month-to-month, price it that way on purpose – see [MSP pricing models](/wiki/msp-pricing-models) for how term length and price interact. ## The structure: one evergreen MSA, many attachments The standard structure – reflected in Scott & Scott LLP's template guidance, developed across roughly 150 MSP contracting engagements – separates the legal shell from the services: - **The MSA is evergreen.** It holds the legal terms: liability, indemnification, data ownership, termination, dispute resolution. It rarely changes. - **Orders, Service Attachments, and SOWs define what you deliver** – the managed services plan, projects, add-ons – and are incorporated into the MSA by reference. A new service line means a new attachment, not a renegotiated contract. - **An order-of-precedence clause** states which document wins when they conflict. - **Response-time commitments live in an SLA attachment**, not the MSA body, so you can revise them without reopening legal terms. Setting those numbers well is its own discipline – see [Designing your SLAs](/wiki/sla-design). Define services in the attachments, never in the MSA body. Your service catalog will change every year; your legal terms shouldn't have to. ## The clauses that matter **Scope of services and exclusions.** Enumerate the covered services, then explicitly exclude what is not covered: projects, after-hours work, hardware and software outside the supported list, and anything not named. State that undocumented requests default to time-and-materials at your current rates. This clause is what converts "can you also just..." from free work into billable work. **Third-party vendor waiver.** A clear, unequivocal waiver of the client's right to sue you for failures of third-party services. When Microsoft 365 goes down, the ISP drops, or a SaaS vendor gets breached, the client's recourse is against that vendor under its EULA – not against you. **Limitation of liability.** Cap recoverable damages, commonly at the fees the client paid over the prior 6–12 months, and exclude consequential damages such as lost profits and business interruption. Include specific carve-out language for backup failures and security incidents – the two scenarios where MSPs actually get sued. **Mutual indemnification, aligned to your insurance.** Indemnity should run both ways, not one-way against you. You indemnify for your own errors, omissions, and negligence; the client indemnifies for its own licensing gaps, changes it demanded over your objection, and client-side privacy violations. Critically, align the indemnity language with your E&O and cyber policies so the contract and the coverage match – see [MSP legal and insurance](/wiki/msp-legal-and-insurance). Indemnities should survive termination, because regulatory fines arrive late. **Client obligations.** The client must provide access, maintain licensing compliance, and keep independent backups; you disclaim data-loss responsibility where the client failed those obligations. Require the client to carry its own [cyber insurance](/wiki/glossary/cyber-insurance). **Data ownership.** The client owns its data, full stop. You own your "Provider Work" – scripts, tooling, documentation methodology – with the client receiving a license that expires at termination. Confidentiality is mutual: their passwords and configs, your pricing. **Term, auto-renewal, and termination.** Auto-renew with a defined non-renewal notice window (30–90 days is common). Include an early-termination fee – commonly the remaining contract value or a defined buyout. Fee escalators are standard; pairing them with a client termination right above a stated threshold makes them easier to sign. **Offboarding obligations.** Define the transition assistance you will provide, at what rate, and the condition that all invoices are paid before data and credentials are handed over. Writing this down before you need it is what makes a clean exit possible – the mechanics are covered in the [client offboarding process](/wiki/client-offboarding-process). **The boilerplate that isn't boilerplate.** A 12-month non-solicitation of your employees with liquidated damages (clients do try to hire your best tech), arbitration or dispute-resolution terms with a claim deadline (around six months is typical), and survival, severability, and entire-agreement clauses. ## Where to get templates - **An MSP-specialist attorney.** Scott & Scott LLP is the best-known US firm in this niche and sells a Contracts-as-a-Service subscription – templates kept current as ransomware and cyber-liability risk evolves. Monjur, founded by an MSP attorney, offers subscription contracts on a similar model. **Best fit:** once you have real [MRR](/wiki/glossary/mrr) to protect. - **The Tech Tribe.** A paid MSP community (roughly $60/month tier as of 2026) whose customizable agreement templates plus SOPs are widely cited on r/msp as the best-value starting point for a young shop. - **Vendor templates.** Free MSA templates from RMM/PSA vendors are a floor, not a finish. Whatever you adopt, have local counsel review it before you use it. Enforceability – especially liability caps and non-solicitation – is state-specific, and a template that has never met a lawyer in your jurisdiction is a guess. ## Review it annually A contract is not a one-time artifact. Cyber-liability language that was fine three years ago may not match what insurers require today, so align contract reviews with your insurance renewal and keep indemnities and coverage in sync. The annual review is also when you exercise fee escalators, add proper attachments for new service lines instead of bolting them on informally, and migrate clients still sitting on old paper. ## Where to start If you have clients on handshakes today: get a real MSA from one of the sources above, have local counsel adapt it, and move every client onto it at the next renewal or price change – clients accept new paper most easily when something else is changing anyway. Every new client, starting with [onboarding](/wiki/client-onboarding-process), signs before the first agent is deployed. The contract you sign on day one determines the margin you keep in year three and the multiple you're offered at exit. --- ## MSP KPIs and Benchmarks ## Why KPIs matter before you think you need them Most technical founders run their MSP on gut feel until something breaks – a big client leaves, payroll gets tight, a tech burns out. By then the numbers that would have warned you were sitting in your [PSA](/wiki/glossary/psa) the whole time. The research behind Service Leadership's benchmarking is blunt on this point: profitability tracks operational maturity, not size or age. A disciplined two-person shop can out-earn a sloppy twenty-person one on a percentage basis, and the discipline starts with measuring the right things. The good news is that the MSP industry is unusually well-benchmarked. Between the Service Leadership Index, the Kaseya Global MSP Benchmark, and vendor-published data, you can compare yourself against thousands of peers. Here are the numbers that matter, what "good" looks like as of 2026, and how to track them without hiring an analyst. ## Financial KPIs **MRR and recurring revenue percentage.** [MRR](/wiki/glossary/mrr) is the single most important number in the business – it is what buyers pay for at exit and what makes your cash flow predictable. Track total MRR, new MRR added, and MRR lost every month. Just as important is the *percentage* of revenue that is recurring: firms with strong written recurring contracts are worth far more at exit than those living on project work. See [pricing models](/wiki/msp-pricing-models) for how packaging drives this number. **Gross margin per service line.** Allocate labor and tool COGS to each agreement type and compute margin separately. Typical targets as of 2026: | Service line | Typical gross margin | |---|---| | Managed services | 50–60% target; best-in-class push ~70% | | Product/hardware resale | ~15–25% | | Below ~45% on managed services | Warning sign: mispricing or scope creep | Never blend product resale into a single margin number – it will mask a managed-services margin problem or make a healthy one look sick. **EBITDA.** Per the Service Leadership Index, best-in-class MSPs run roughly 19%+ adjusted EBITDA, the median sits around 9–11%, and the bottom quartile is under 5%. The striking finding: best-in-class firms earn roughly 2.5–3× the median's bottom line *at every size*. Scale does not fix a broken operating model. **Churn.** Top performers keep logo [churn](/wiki/glossary/churn-rate) under 5% per year. Watch seat-count shrink inside retained clients too – a client who keeps the logo but drops from 40 seats to 25 is churn in slow motion (net revenue retention captures this). Churn is largely set by onboarding quality and QBR discipline, which is why those processes deserve their own attention: see [client onboarding](/wiki/client-onboarding-process) and the [QBR process](/wiki/qbr-process). ## Service delivery KPIs These predict the financial numbers six months out. High ticket noise today is margin erosion next quarter. | Metric | Benchmark (typical, as of 2026) | |---|---| | Tickets per endpoint per month | <1 for mature MSPs | | Endpoints per tech | ~250–400 fully managed; ~350 often cited as the gold standard with strong tooling | | Tech utilization | Average shops 55–60%; good 65–70%; top performers 75–80% | | First response time | <1 hour business-hours is the common target; report SLA attainment, not averages | | CSAT | Best-in-class ~95%+ positive on per-ticket surveys | **Tickets per endpoint per month** is the diagnostic metric. If you're well above 1, the cause is usually misconfigured environments, weak onboarding, or wrong-fit clients – and the fix is standardization, not more help desk. TruMethods data suggests keeping client stacks aligned to your standards can cut reactive tickets by roughly two-thirds. **Endpoints per tech** measures labor efficiency. Below ~250 per tech, your tooling or processes are dragging; above ~400 you risk burnout unless automation is excellent. This number drives your [hiring timing](/wiki/hiring-first-technician). **Utilization** is the percentage of paid hours spent on client-facing work. A tech has about 2,080 paid hours a year; at a realistic 65–70% that is roughly 1,350–1,450 productive hours. Resist chasing 80%+ – it leaves no slack for documentation, training, automation, or the P1 spike, and it burns people out. **First response time** should be measured against your SLA commitments, with clocks paused on "waiting on customer." A single blended average hides the P1 you missed. See [SLA design](/wiki/sla-design) for setting targets you can actually hit. **Customer feedback** should come from surveys tied to ticket or relationship data. **[Acronis PSA](https://www.acronis.com/en/products/cloud/cyber-protect/psa-solution/)** can send customer surveys and report NPS through its service desk. Simplesat is a dedicated option for per-ticket CSAT. Track response rate and score trends by client because a high average based on few responses is weak evidence. ## The OML concept: maturity predicts profit Service Leadership's Operational Maturity Level (OML) framework scores MSPs 1–5 – Beginning, Emerging, Scaling, Optimizing, Innovating – across finance, service, sales, strategy, and compensation practices. The predictive claim, backed by their benchmarking data: profitability tracks maturity level, not headcount. A $5M revenue MSP operating at OML 4 generating around $1M of EBITDA sells at multiples an immature peer of the same size cannot touch. You do not need to buy anything to use this. ConnectWise publishes the framework for free. Read it once a year and honestly grade yourself; the gap between where you score and OML 3–4 practices *is* your improvement roadmap. Joining a [peer group](/wiki/glossary/peer-group) is the fastest way to get honest external grading. ## How a small MSP actually tracks this You do not need a BI stack. Almost everything above falls out of a PSA you use with discipline: 1. **Log all time against tickets and agreements.** This is non-negotiable – untracked work makes gross-margin analysis fiction. See [ticket management](/wiki/ticket-management-process) for building the habit. 2. **Standardize ticket taxonomy** (type/subtype) so ticket counts and trends mean something. 3. **Use "waiting" statuses that pause SLA clocks** so response and resolution reporting is honest. 4. **Sync endpoint counts from the RMM** so per-endpoint and per-tech ratios compute themselves. Kaseya's 2025 benchmark found ~95% of MSPs consider RMM+PSA+documentation integration essential. 5. **Run a monthly agreement-profitability report** – labor hours × loaded cost vs. agreement revenue, per client. This one report finds the client eating your payroll. MRR, churn, and margin come from your accounting system plus PSA agreement data. If you use Acronis PSA, start with its built-in KPI and profitability reports. Otherwise, a simple spreadsheet updated monthly is enough at first; add a dedicated dashboard product such as BrightGauge only when manual reporting consumes material staff time. ## The five numbers to watch monthly when you're small Under roughly $1M revenue, tracking twenty KPIs is procrastination. Watch these five every month: 1. **MRR** (total, new, lost) – is the recurring engine growing? 2. **Managed-services gross margin** – are you above ~50% and trending toward 60%? 3. **Tickets per endpoint per month** – is your noise floor dropping toward 1? 4. **Per-client profitability** – which agreement is underwater? 5. **Logo churn / at-risk clients** – who hasn't had a touch-point in 90 days? Everything else – utilization, CSAT, response-time attainment – check quarterly until you have a team large enough for the monthly version to be signal instead of noise. ## Bottom line Benchmarks exist so you know whether a number is a problem: 50–60% managed-services margin, sub-5% churn, under 1 ticket per endpoint per month, 250–400 endpoints per tech, 65–70% utilization. But the deeper lesson from the Service Leadership data is that the *habit* of measuring – time logged, taxonomy standardized, margins computed per agreement – is itself what separates the 19%-EBITDA firms from the 5% ones. Start with the five monthly numbers, run them for two quarters, and let what they reveal set your priorities. --- ## MSP (Managed Service Provider) ## Definition An MSP (managed service provider) is a company that takes ongoing responsibility for a client's IT – monitoring, maintenance, support, security, and backup – for a fixed recurring fee, typically priced per user or per device per month. The defining feature is the commercial model, not the technology: the MSP is paid to keep things working, so its incentive is to prevent problems, where a [break-fix](/wiki/glossary/break-fix) shop is paid by the hour when things break. ## Why it matters to an MSP Understanding the model is the difference between running an MSP and running break-fix with a subscription invoice. The economics rest on three things. First, recurring revenue: [MRR](/wiki/glossary/mrr) under one- to three-year contracts gives predictable cash flow, a valuation multiple that project revenue never earns, and the ability to hire ahead of demand. Second, tooling multiplier: an [RMM](/wiki/glossary/rmm) and [PSA](/wiki/glossary/psa) let one technician support roughly 250–400 endpoints, which makes a fixed fee profitable instead of a bet against ticket volume. Third, standardization: one defined [technology stack](/wiki/glossary/technology-stack) across all clients, so every environment is supported the same way. The market is crowded and mostly small – most MSPs have fewer than ten employees and serve companies of 10–200 users, competing with other local shops, the client's cousin who "does computers", and vendors increasingly selling direct. What separates the ones that grow is not technical skill; it is picking a [niche](/wiki/choosing-a-niche), pricing to a target margin rather than to the competitor down the road, and treating security as part of the base service. The channel – distributors, vendor partner programs, [peer groups](/wiki/glossary/peer-group) – is built around this model; see [the MSP vendor channel](/wiki/msp-vendor-channel) and [how to start an MSP](/wiki/how-to-start-an-msp). Related terms: [Break/Fix](/wiki/glossary/break-fix), [MRR](/wiki/glossary/mrr), [RMM](/wiki/glossary/rmm), [PSA](/wiki/glossary/psa) --- ## MSP Pricing Models ## Why pricing is the decision you can't easily undo Most technical founders agonize over their tool stack and wing their pricing. That's backwards. Analyses of small MSPs consistently estimate the average shop is roughly 30% underpriced, and the mechanism is brutal: your first price becomes a permanent anchor. Clients internalize a below-market rate as "fair," so every later correction reads as gouging. Worse, cheap pricing wins you clients you can't afford to serve properly, which means you can't fund the tooling and staff to serve them – a downward spiral that starts with one nervous quote. Before you can price anything, you need to know exactly what you're selling – build your [service catalog](/wiki/msp-service-catalog) first. Then pick a model. ## Per-device pricing You charge a flat monthly rate per managed asset. Typical US ranges as of 2026: **$25–$60 per workstation** (some 2026 guides cite higher as tooling costs rose), **$200–$500 per production server**, and roughly $25–$75 per network device or firewall. The bundle usually covers monitoring, patching, AV/EDR, and basic remediation. **Pros:** Dead simple to quote – count the assets, multiply. Fits shared-device environments (clinics, manufacturing floors, retail) where headcount and device count diverge. **Cons:** Penalizes you as clients multiply devices per person, and invoices get haggled line-by-line ("do we really need the lab PC covered?"). See [per-device pricing](/wiki/glossary/per-device-pricing) for the short version. **Best fit:** Environments where devices are shared, headcount fluctuates, or devices-per-user is unpredictable. ## Per-user pricing You charge per human, covering all of that person's devices. This model won the remote-work era: with roughly half of remote-capable employees hybrid and each carrying two to three devices, one clean per-user line item is easier to explain, scales with headcount, and stops the device-counting arguments. Typical US range as of 2026: **$100–$250 per user per month all-in**, with the fat middle at **$125–$200**. Entry-level bundles (monitoring, patching, help desk, AV, backup) run lower; fully managed with EDR and vendor management sits in the middle; premium tiers with 24/7 coverage, advanced security, and compliance reach $250–$300+. Major coastal metros price at the top of the range; secondary markets commonly land at $100–$150 for the same scope. Compliance-heavy verticals typically add 15–25%. One trap: **define "user" contractually.** Is it a named person with a mailbox? Does a part-timer count? A shared warehouse login? A contractor with email but no device? If the contract doesn't say, the client will define it in their favor and your seat count will mysteriously shrink. See [per-seat pricing](/wiki/glossary/per-seat-pricing) and lock the definition into your [MSA](/wiki/msp-contracts-and-msa). Many MSPs quietly run a hybrid – per-user plus per-server and per-network-device. That's fine if it's intentional and documented. ## Tiered good-better-best Package two to four bundles (e.g., Essential / Professional / Complete) at ascending per-user prices. Tiers give price-sensitive prospects a door in, give you a structured upsell path, and let you anchor the conversation on the middle tier. The common failure is building a cheap tier so thin (no EDR, no backup oversight) that it produces unprofitable, breach-prone clients – every tier should include your non-negotiable security baseline, with tiers differing on coverage hours, strategy depth, and advanced services. ## Value-based pricing [Value-based pricing](/wiki/glossary/value-based-pricing) anchors the price to what the client avoids – downtime cost, breach cost, compliance exposure, the salary of the IT hire they don't make – rather than your cost to deliver. Pure cost-plus systematically underprices because it ignores risk transfer; pure value-based is hard to quote repeatably. The practical synthesis used by mature shops: **cost-plus sets your minimum, value-based sets your ask.** ## A la carte vs. all-in The a-la-carte path prices every component separately: base support, plus EDR, plus backup, plus security awareness training, each its own line. It feels transparent but invites procurement to shop each line item, makes every renewal a negotiation, and lets clients decline exactly the security items you'll be blamed for when things go wrong. Mature MSPs converge on the opposite: **one all-in seat price that includes everything recurring** – licenses, security, backup, support. TruMethods (Gary Pica) tracks this as the "all-in seat price" (AISP): total monthly revenue from a client divided by seats. Their data shows the *average* MSP's AISP is **under $100/seat**, while Pica argues the modern benchmark should move toward **$300/seat at a 70% gross margin** as security scope expands. Whatever number you land on, the all-in structure simplifies buying, hides individual tool margins from scrutiny, and gives you a single metric to manage upward. (For the unlimited-support variant, see [all-you-can-eat pricing](/wiki/glossary/all-you-can-eat-pricing).) ## The numbers around the model Whichever model you pick, the deal has more moving parts than the seat price: - **Onboarding fee:** charging roughly **1x your monthly recurring fee** – "the 13th month" – is the standard rule of thumb (observed range: one to two months of [MRR](/wiki/glossary/mrr)). Onboarding is genuinely expensive (agent deployment, documentation, cleanup, credential capture), and a fee filters out non-serious buyers. Some MSPs waive it as a closing concession on three-year terms. - **Out-of-scope and project rates:** typical 2026 benchmarks are **$125–$250/hr** (most SMB MSPs at $150–$200), more in high-cost metros or for senior specialists, and $250–$500/hr for after-hours emergencies. State in the contract that anything not listed in the catalog bills at these rates. - **Minimum engagement:** most established MSPs won't take clients below roughly **$500–$1,000/month**, often expressed as a 5- or 10-seat minimum. Fixed per-client overhead – onboarding, documentation, tooling minimums, QBRs – makes tiny clients structurally unprofitable, and a floor filters for clients who value IT. ## Pricing your floor from cost basis Don't guess your minimum – compute it. The TruMethods-style discipline: tie every recurring cost to a per-seat unit cost. Sum your tool stack per seat (RMM, EDR, backup, email security, licenses – see your [tool stack](/wiki/msp-tool-stack)), allocate labor by realistic tickets-per-seat and loaded tech cost, add a share of overhead, then apply your gross margin target – **70% GM** is the best-in-class benchmark. If your delivery cost is $60/seat, a 70% margin puts your floor at $200/seat. Quote below your computed floor and you're paying to work. Track the result in your [KPIs](/wiki/msp-kpis-and-benchmarks). ## Increases and indexing Vendors raised EDR, M365, and backup prices sharply through 2024–2025, and MSPs without escalator clauses ate every hike. Standard contract terms run 12–36 months, and contracts increasingly include an **annual CPI-plus-tool-cost escalator** so increases happen automatically instead of requiring an awkward conversation. If you must reprice legacy clients, the pattern that works: lead with a service review of what's changed over 12–24 months, give 60–90 days notice, and tie the increase to scope. Experience reports say roughly 5–10% push back, most accept, and the rare departures were unprofitable anyway. Put the escalator in the contract from day one and you mostly avoid the conversation. ## Bottom line Price at market from client number one – typically $125–$200+ per user all-in as of 2026 – because repricing later is far harder than pricing right now. Use per-user unless the environment is genuinely device-centric, bundle security into one all-in seat price, compute your floor from per-seat cost at a 70% gross margin target, charge ~1x MRR for onboarding, hold a $500–$1,000 monthly minimum, and put a CPI-plus-tool-cost escalator in the contract. Then go win deals on value, not discounts – that's a [sales](/wiki/msp-sales-marketing) problem, not a pricing one. --- ## MSP Sales and Marketing Basics ## The sale you're actually in Selling managed services is nothing like selling a product. An SMB owner who signs with you is handing over the keys to their business, so nobody switches IT providers casually. MSP sales cycles of **3–12 months are normal** – some B2B cycles exceed 300 days – and the thing that finally moves a prospect is almost always a pain event: an outage, a breach, a failed audit, "our guy retired," an acquisition. You cannot manufacture the trigger. What you can do is stay consistently visible until it hits, so you're the first call when it does. Every tactic below is in service of that. Kaseya's 2025 benchmark found one in three MSPs name new-customer acquisition as their hardest problem. That's not because the tactics are secret – it's because most technical founders do them sporadically instead of systematically. ## Referrals: the #1 channel, if you ask For small MSPs, referrals outproduce every other channel by a wide margin: existing clients, peer MSPs, vendor and distributor contacts, and professional referral partners – accountants, attorneys, insurance brokers – who serve the same business owners you want. The mistake is treating referrals as luck. Systematize the ask: - Ask at high points: after a well-handled incident, a smooth [onboarding](/wiki/client-onboarding-process), or a strong [QBR](/wiki/glossary/qbr) – "who else do you know who's frustrated with their IT?" - Build a short list of referral partners (CPA firms, business attorneys, insurance brokers) and meet them quarterly; they meet struggling business owners weekly. - Make referring easy: a one-paragraph description of your ideal client that a partner can forward. - Thank and report back on every referral, landed or not – the feedback loop keeps them coming. The caveat repeated across the industry: referrals are the foundation, not the growth engine. They rarely provide the volume to scale on their own, which is why the marketing core below matters. ## Assessment-led selling The dominant motion for MSPs is discovery-led: offer a free or paid IT/security assessment, produce a findings-and-risk report, and let the report do the selling. A "free IT audit" paired with targeted outreach is repeatedly cited as the fastest lead-generation combination. The assessment converts the conversation from "what's your price per user?" to "here is your risk and your roadmap," positions you as an advisor rather than a vendor, and creates a natural close: "here's what fixing this looks like under management." Build a repeatable version of this using your [network assessment process](/wiki/network-assessment-process), and for hot prospects, run a "sample QBR" on their environment – showing them what quarterly strategic review looks like is a strong closer. ## The discovery call, for technical founders Technical founders fail discovery calls in a predictable way: they diagnose and fix on the spot, giving away the value and skipping the business conversation. Structure the call instead: 1. **Their business first** (10 min): what the company does, what downtime costs, what's growing or shrinking, who handles IT today. 2. **Pain and trigger** (10 min): why are we talking now? What broke, or what's worrying you? What happens if nothing changes? 3. **Current state, lightly** (5–10 min): environment size, key applications, security posture, compliance obligations. Resist the urge to troubleshoot. 4. **Next step, always**: propose the assessment with a date. Never end with "I'll send some information." Take notes on business language, not tech specs – you'll reuse their words in the proposal. ## Handling the two objections you'll always hear **"We have a guy."** The most common MSP objection, and arguing with it loses every time. Ask questions instead: How long has he been with you? What's working? What could be better? What happens when he's on vacation, sick, or retires? How are backups and security verified – by whom? The single-point-of-failure angle does the work without attacking anyone. Then offer a no-threat second opinion or assessment. The goal is not to win that day; it's to be first in line when the incumbent stumbles. Expect this objection to recur at the gatekeeper, the champion, and the decision-maker. **"You're too expensive."** Never defend the number; reframe what it buys. Anchor against the cost of downtime, a breach, or the salary of an internal IT hire, and walk through what's actually included versus the cheaper quote (is EDR in there? backup verification? a security baseline?). If they still want the bottom-tier price, refer back to your [pricing floor](/wiki/msp-pricing-models) – clients won below your floor cost you money and attention for years. Some deals you should lose. ## The marketing core: local search plus one niche For a local MSP, **Google Business Profile plus local SEO is the highest-ROI channel**. The Map Pack dominates "managed IT services [city]" searches, and in 2025–2026 page one is increasingly AI summaries and zero-click results – which makes the Map Pack and your reviews *more* valuable, not less. The work: consistent name/address/phone everywhere, correct categories, photos, regular posts, location and service pages on your site, and a systematic habit of collecting and responding to reviews. Pair it with one niche. A website that speaks to one vertical – dental, law, construction, CPA firms, nonprofits – converts far better than "we do IT support," and compliance niches (HIPAA, CMMC) are the clearest wedge because the pain is legible and budgeted. See [choosing a niche](/wiki/choosing-a-niche). **LinkedIn** works for vertical niches with one big caveat: write for prospects, not MSP peers – peer-oriented content is the most-cited mistake. Founder personal-profile content outperforms company pages. And the highest-return networking tactic is giving educational value: speak on cybersecurity at chamber events, run co-hosted breakfasts and workshops, rather than pitching. ## What disappoints (save your money) The trade press verdict is consistent: build the referral engine, Google Business Profile, one niche, and one networking habit *before* spending on any of these: - **Generic SEO agencies** – MSP SEO is a narrow local game (visibility, reviews, conversion content); generic content retainers burn cash for 6–12 months with nothing to show. - **Cold calling and appointment-setting firms** – cold outreach against a trust-based 6–12 month sale has brutal conversion for a founder with no brand, and appointment setters sell meetings, not fits. - **Bought lists and mass email** – the same cold-outreach economics with worse deliverability and reputation risk. ## Expansion: sell to the clients you have Your cheapest revenue is inside existing accounts, and the [QBR process](/wiki/qbr-process) is the machine. A well-run quarterly review translates technical metrics into business outcomes, surfaces lifecycle and technology gaps against your standards, and turns each gap into a funded roadmap project – sold as risk reduction, not upsell. QBRs are simultaneously your best churn defense, your project-revenue source, and the evidence base for price increases. Even solo, run lightweight QBRs with your top clients. ## When to hire a salesperson Much later than you think. The consensus triggers are capability-based, not revenue-based: you have personally closed **10–20 clients**, you can write the sales process down step-by-step, the math is predictable ("X effort yields Y revenue"), and selling consumes more than half your week. Hiring before you have a documented, repeatable process sets the hire up to fail – and MSP sales hires fail often and expensively. As one agency put it: your MSP doesn't need a salesperson yet, it needs a sales and marketing system. Meanwhile, track your pipeline simply in the CRM module of your [PSA](/wiki/glossary/psa) (or any lightweight CRM): stages like Lead → Discovery → Assessment → Proposal → Won/Lost, with a next action and date on every open deal. Review it weekly. The discipline matters more than the tool. ## Where to start This quarter: ask every happy client for one referral, set up referral relationships with two accountants or attorneys, claim and fully build your Google Business Profile, pick one niche and rewrite your homepage for it, and package your assessment as a standard offer with a fixed agenda. Land your [first clients](/wiki/first-msp-clients) with founder-led selling, run QBRs to grow them, and don't spend a dollar on agencies or hire a salesperson until the founder-led machine is documented and repeatable. --- ## MSP Security Operations: Build, Buy, or Partner ## The decision arrives around 500 endpoints Below a few hundred endpoints, security operations means an EDR agent and whoever is awake when it fires. Past roughly 500 [endpoints](/wiki/glossary/endpoint) that stops working: alert volume outgrows the on-call tech, a compliance-driven client asks who is watching at 3 a.m., and a [cyber insurance](/wiki/glossary/cyber-insurance) questionnaire asks for "24/7-monitored EDR" and does not accept "we get push notifications." At that point you are choosing how to source a security operation. The choice is build, buy, or partner, and for almost every [MSP](/wiki/glossary/msp) under a few thousand endpoints the answer is one of the last two. ## Three layers, not three products - **[EDR](/wiki/glossary/edr) is the sensor.** An agent on every endpoint and server that records telemetry, flags suspicious behavior, and can isolate the host. It generates alerts; it does not investigate them. - **A [SOC](/wiki/glossary/soc) is the people and process.** Analysts on shift, a triage workflow, detection content someone maintains, [runbooks](/wiki/glossary/runbook) for what happens when a detection fires, and an [escalation](/wiki/glossary/escalation) path to whoever can act. A sensor without a SOC is a smoke detector in an empty building. - **[MDR](/wiki/glossary/mdr) is the packaged service.** Sensor plus SOC sold as one subscription, priced per endpoint, with a defined response – anywhere from "we will call you" to "we will isolate the host and disable the account, then call you." Buying MDR buys the SOC layer and usually the sensor. Building means hiring the SOC layer and licensing the sensor and a SIEM. The sensor is commoditized; the people are the cost. ## The 24/7 staffing math A year has 8,760 hours. One analyst delivers roughly 1,800 after PTO, sick leave, and training, so covering a single chair around the clock takes about five people. A real SOC needs at least two on shift – one to triage, one to investigate and contain – which means nine or ten analysts. Add a lead who tunes detections and owns the SIEM, and you are at 10–12 people. At typical US loaded costs of $90K–130K each, that is $1M–1.5M per year, plus SIEM licensing and log storage that commonly add $50K–150K. Spread $1.2M across endpoints at a $10/endpoint/month contribution and you need about 10,000 endpoints just to cover cost. An in-house SOC does not pencil below several thousand endpoints. ## Option one: resell white-labeled MDR You license an MDR platform, deploy its agent through your [RMM](/wiki/glossary/rmm), and the vendor's SOC watches every tenant. Alerts land in your [PSA](/wiki/glossary/psa); the SOC contains autonomously or calls you, depending on the authority you grant. Typical wholesale cost as of 2026 is $3–6 per endpoint per month for managed EDR with a SOC behind it, and $8–15 for active-response MDR that isolates hosts and disables identities on its own. This is the default for MSPs from 200 to a few thousand endpoints, and the [security stack](/wiki/msp-security-stack) article covers how it fits with the rest of the baseline. ## Option two: partner with an MSSP An MSSP is a security-only provider that takes on log ingestion, SIEM, threat hunting, and often compliance reporting. You bring the client relationship and endpoint management; they bring analysts and tooling. Typical cost runs $10–25 per endpoint per month, more with firewall, identity, and cloud logs. It suits MSPs whose regulated clients need SIEM retention and audit evidence that packaged MDR does not produce. The risk is the three-party relationship: when something is missed, each vendor points at the other. Settle that in the contract. ## Option three: build Justified only past several thousand endpoints, with many regulated clients, and when you intend to sell security operations beyond your own base. Even then, most start hybrid: a daytime in-house team, with a partner covering nights and weekends. If you cannot fund eight analysts for two years while the SOC loses money, do not build. ## Cost, price, and margin Price it per endpoint and never pass it through at cost. Typical resale as of 2026 is $8–25 per endpoint per month as a line item, or folded into a security tier of $25–50 per seat. Against $3–5 wholesale, managed EDR with SOC yields 60–75% gross margin on the line; active-response MDR at $10–15 wholesale resold at $20–25 yields 40–50%. Include your own triage labor – commonly 10–20 minutes per escalated alert – in COGS, or the margin is fiction. ## What you still own when you buy Buying a SOC does not outsource responsibility; it outsources the night shift. You still own: - **The triage handoff.** The SOC escalates; someone at your shop must acknowledge within the [SLA](/wiki/glossary/sla) you promised the client, decide whether the detection is real, and act. Define who that is at 2 a.m. on a holiday. - **Client communication.** The SOC will never call your client. You explain what happened, what was contained, and what it means. - **Containment authority.** You decide, in writing, whether the SOC may isolate hosts and disable accounts without asking. Declining means a 3 a.m. phone call that may go unanswered while [ransomware](/wiki/glossary/ransomware) spreads. Pre-authorize isolation and accept the rare false positive. - **Incident response.** Detection and containment are the first hour. Eradication, recovery, forensics, legal notification, and the insurance claim are yours to run – see the [incident response process](/wiki/incident-response-process). The MDR contract ends at containment; the crisis does not. ## How to evaluate a provider - **Detection coverage.** Endpoints only, or identity, email, and cloud too? An MDR that cannot see Microsoft 365 sign-ins is watching half the field. - **Response authority.** Can they actually isolate and disable, or only notify? Is it configurable per client? - **SLA on time-to-acknowledge.** Ask for the contractual number on a critical alert – 15 minutes is typical – and the median actual, not the marketing figure. - **Integration with your RMM and PSA.** Alerts must arrive as tickets with the client mapped correctly, and deployment must ride your existing agent push. A portal you have to remember to check is where alerts die. - **Evidence and escalation.** Can they produce the reports insurers ask for, and who do you call when their SOC is wrong? ## Contract questions Before signing: what is in scope per endpoint – servers, VMs, mobile? What is the minimum commitment and true-up cadence? Can you add and remove clients monthly, or are you locked to a seat count? Who owns the telemetry, and how long is it retained? Is there a data export on termination? What is their liability cap if they miss a critical detection, and does their errors-and-omissions coverage extend to your clients? Do they hold a [SOC 2](/wiki/glossary/soc-2) Type II report you can show your own clients? Are you permitted to white-label, and does your client contract name them as a subprocessor? ## Bottom line EDR is the sensor, the SOC is the people, MDR is the two packaged together. Below several thousand endpoints the staffing math makes building a SOC a money pit, so buy: white-labeled MDR for most MSPs, an MSSP where clients need SIEM retention and audit evidence. Price it at $8–25 per endpoint, keep 50%+ margin, and remember what remains yours: the handoff, the client call, the containment decision, and everything after the first hour. --- ## Multi-Factor Authentication (MFA) ## Definition Multi-factor authentication requires a second proof of identity beyond a password – something the user has (a hardware key, an authenticator app, a phone) or something they are (a fingerprint or face) – before access is granted. Methods are not equal: SMS codes and push notifications can be intercepted or fatigued into approval, while FIDO2 hardware keys and passkeys resist [phishing](/wiki/glossary/phishing) because the credential is bound to the legitimate site and never leaves the device. ## Why it matters to an MSP Stolen credentials are the entry point in most SMB breaches, and password-only Microsoft 365 accounts are the raw material for [BEC](/wiki/glossary/bec) fraud and [ransomware](/wiki/glossary/ransomware) footholds. That is why MFA is the first line on every [cyber insurance](/wiki/glossary/cyber-insurance) questionnaire: carriers decline to write or renew without MFA on email, remote access, and admin accounts, and a "yes" that turns out to be false can void a claim. It also sits in [CIS Controls](/wiki/glossary/cis-controls) safeguards 6.3–6.5 and every compliance framework you sell against, so an MFA rollout is a well-defined, billable project. Two rules. First, coverage has to be complete: one legacy protocol left open, one service account excluded, one shared mailbox on basic auth is the account attackers find. Pair enrollment with conditional access that blocks legacy authentication and enforces MFA on every sign-in, not just "risky" ones. Second, raise the method with the privilege. Push and SMS are still acceptable for a general user, but push-fatigue and adversary-in-the-middle phishing kits bypass them routinely; admin accounts, your own technicians, and access to your [RMM](/wiki/glossary/rmm) and [PSA](/wiki/glossary/psa) should use FIDO2 keys or passkeys. Your MSP is the highest-value target in your client base, so start there – and treat MFA coverage as a standing [QBR](/wiki/glossary/qbr) artifact. Related terms: [SSO](/wiki/glossary/sso), [IAM](/wiki/glossary/iam), [PAM](/wiki/glossary/pam), [Zero Trust](/wiki/glossary/zero-trust) --- ## Network Assessment Process ## Where the assessment fits A network assessment does double duty. Pre-contract, it is your best sales tool: a low-commitment free or paid audit is one of the most effective offers for landing your [first clients](/wiki/first-msp-clients), because it replaces a sales pitch with evidence. Post-signature, the same assessment is the input to [client onboarding](/wiki/client-onboarding-process) – the discovery phase of a 30/60/90 onboarding is essentially this process run at full depth. Run it at three cadences: pre-sales (time-boxed, top findings only), at onboarding (full depth, first 30 days), and then periodically as a standards review feeding the [QBR](/wiki/glossary/qbr). In a small shop the founder or senior tech runs the whole thing; once you have staff, a tech runs discovery and the owner presents findings. ## Step 1: scope and written authorization Never scan a network you don't have written permission to scan. Unauthorized scanning is legally risky and looks amateur if discovered. Before any tool touches the environment: 1. Define scope in writing: which sites, subnets, tenants, and systems are in scope; whether you'll deploy temporary agents; what you will not touch (production databases, OT equipment, anything the owner flags). 2. Get a signed authorization – a one-page letter for a pre-sales assessment, or scope language inside the agreement for onboarding. For prospects, include basic confidentiality language both ways. 3. Get named admin credentials or an escorted session for Active Directory and the Microsoft 365 tenant. How hard it is to obtain access is itself a finding. 4. Agree the timeline and the deliverable: a findings report and a roadmap conversation, on a named date. ## Step 2: discovery and inventory Work through the environment systematically. The checklist: - **Directory and identity:** AD and/or Entra review – stale accounts, admin group membership, service accounts, password policy, [MFA](/wiki/glossary/mfa) coverage on admin and user accounts. - **M365 tenant:** license SKUs and waste, mail-flow and email security configuration, external sharing settings, admin roles. - **Network scan:** discover every device with an IP – switches, firewalls, printers, wireless, IoT surprises. Note firmware age, default credentials, and flat-network topology. - **Endpoints and servers:** OS versions and support status, patch levels, local admin rights, disk encryption, AV/[EDR](/wiki/glossary/edr) presence and health. - **Software inventory:** installed applications, versions, EOL software, unlicensed installs, shadow tooling. - **Backup posture:** what is backed up, schedule, retention, where copies live, when a restore was last tested – verify, don't accept the client's word. This feeds directly into [backup and DR](/wiki/backup-dr-process). - **Security posture:** open ports and exposed services, remote access methods in use, firewall rules, patch management state, prior incidents. - **Licensing and vendors:** ISP details, circuit IDs, contract and renewal dates, LOB application vendors and support contacts. Capture everything into your documentation platform as you go – the assessment is the first draft of the client's permanent record per your [documentation standards](/wiki/msp-documentation-standards). ## Step 3: rank findings by risk Resist the wall-of-red-text report. Sort every finding into three or four tiers by business risk – likelihood times impact, in plain language: "no tested backups + admin accounts without MFA" outranks "switch firmware is old." Tag each finding with an owner-relevant consequence (downtime, data loss, breach, compliance exposure, wasted spend) and a rough remediation cost. Findings without a consequence and a price are trivia. ## Step 4: build the deliverable The deliverable is three documents in one: 1. **Findings report** – risk-ranked, each finding with evidence, consequence, and recommendation. Lead with an executive summary of the top five. 2. **Roadmap** – remediation sequenced over quarters: immediate quick wins, 90-day stabilization, and longer-term projects. This becomes the standardization plan below. 3. **Budget** – dollar ranges per roadmap phase, split between one-time projects and ongoing managed spend, so the owner can plan rather than react. ## Step 5: present to the owner You are presenting to a non-technical business owner, so translate ruthlessly. Frame findings as risk reduction and cost control, not technology: what could take the business down, what it costs to fix, what it costs to ignore. Use the tiers – "three things need attention this month, five this quarter" – and stop. Do not tour the full inventory; leave the detail in the report appendix. For prospects, the close is natural: "here's the roadmap; this is what it looks like when we run it for you." ## Step 6: convert findings into the standardization plan Every finding is a deviation from your standards library, and every deviation becomes a roadmap item – this is the standardization discipline that mature MSPs credit with cutting reactive tickets by roughly two-thirds. Two tracks: - **Quick wins (first 30 days):** things the client can feel immediately – MFA enforcement, endpoint protection deployed, email security, patching the scary stuff. Don't wait for "stabilization" to deliver visible value. - **Standardization projects (days 31–60 and beyond):** migrate backup, AV/EDR, email security, and remote access onto your [standard stack](/wiki/msp-tool-stack), priced into onboarding or the first-year rate – not absorbed as free work. ## Tooling and time budget **[Acronis RMM](https://www.acronis.com/en/products/cloud/cyber-protect/rmm-solution/)** is one option for the baseline inventory: Device Sense identifies managed and unmanaged devices, while hardware and software inventory records what is installed. Pair it with the Microsoft 365 admin center for tenant data. If assessment volume justifies a dedicated tool, RapidFire Tools' Network Detective, now Kaseya-owned, automates collection and report generation. For a small shop, time-box the pre-sales version: a half day on site or remote for collection, a half day for analysis and the report, spread across a week of calendar time. The onboarding-depth version fills the first 30 days of the 30/60/90 plan alongside agent deployment. Unbounded assessments are how free audits eat a week of unbilled labor – remember that onboarding a client already typically costs $10–15k before profit. ## Exit criteria The assessment is done when: - Every in-scope system appears in the inventory, and the inventory lives in your documentation platform - Findings are risk-ranked, each with consequence, recommendation, and rough cost - The report, roadmap, and budget have been presented to the owner in person or on a call - Quick wins are scheduled with dates (post-signature) or quoted (pre-sales) - The roadmap items exist as tickets or projects in your [PSA](/wiki/glossary/psa), not just in the PDF If the prospect doesn't sign, you still exit cleanly: hand over the report, revoke any temporary access, and log the work – assessments that don't convert are marketing spend, and they refer surprisingly well. --- ## Network Monitoring ## Definition Network monitoring is the continuous, automated observation of a client's network infrastructure – firewalls, switches, access points, internet circuits, and the devices attached to them – for availability, performance, configuration changes, and unexpected traffic. It's typically done with SNMP polling, flow data (NetFlow or sFlow), syslog, and periodic discovery scans, through a module of the [RMM](/wiki/glossary/rmm) or a dedicated network tool. ## Why it matters to an MSP An [endpoint](/wiki/glossary/endpoint) agent only sees the machine it's installed on. Network monitoring is how you see everything else: the flapping switch port, the firewall pinned at 95% CPU, and the devices and traffic nobody told you about. Discovery scans surface the unmanaged laptop and the printer with default credentials; flow data shows which SaaS and cloud services the client's staff actually use. It's one of the fastest ways to build a [shadow IT](/wiki/glossary/shadow-it) inventory and a strong [network assessment](/wiki/network-assessment-process) artifact. The operational payoff is fewer and shorter tickets. Without it, you learn the network is down when the client calls, and the first 30 minutes of a P1 go to working out whether the fault is the ISP, the firewall, or a switch. With it, the ticket opens with the cause already narrowed. Alert tuning is the discipline: an unfiltered SNMP feed generates hundreds of noise alerts a week, so start with a short list of actionable conditions – device down, WAN down, interface errors, bandwidth saturation, configuration change. Network devices bill at roughly $25–$75 per device per month on most rate cards, and a client who has lived through an unexplained outage rarely argues. Firewalls and switches you can't see are also ones you can't patch, which makes this a prerequisite for [vulnerability management](/wiki/glossary/vulnerability-management) on infrastructure, not only endpoints. Related terms: [RMM](/wiki/glossary/rmm), [NOC](/wiki/glossary/noc), [Shadow IT](/wiki/glossary/shadow-it), [Endpoint](/wiki/glossary/endpoint) --- ## NIST Cybersecurity Framework ## Definition The NIST Cybersecurity Framework (CSF) is the US government's voluntary, risk-based framework for organizing a security program. CSF 2.0 (released 2024) structures everything under six functions – Govern, Identify, Protect, Detect, Respond, Recover – with Govern newly added to make leadership accountability and risk management explicit. Unlike prescriptive checklists, CSF describes outcomes and maturity rather than specific technical steps, which makes it universal scaffolding: nearly every regulation, insurer questionnaire, and security product maps to it. ## Why it matters to an MSP CSF is the lingua franca of business owners, boards, and insurers – when you present a client's security posture, the six functions are vocabulary non-technical decision-makers recognize. The working pattern for MSPs: use the prescriptive [CIS Controls](/wiki/glossary/cis-controls) (IG1/IG2) to decide what to actually deploy and assess, then map results to CSF functions for roadmaps, [QBR](/wiki/glossary/qbr) reporting, and [vCIO](/wiki/glossary/vcio) deliverables. A one-page "here's your maturity across Govern through Recover, here's next quarter's plan" is one of the most effective client-facing security artifacts an MSP can produce: gap-to-roadmap framing turns security from a line-item cost into a multi-quarter program, drives project revenue, and satisfies [cyber insurance](/wiki/glossary/cyber-insurance) and compliance conversations without tying you to any single regulation's letter. CIS tells your technicians what to do; CSF tells the client's owner why it matters. Related terms: [CIS Controls](/wiki/glossary/cis-controls), [vCIO](/wiki/glossary/vcio), [Cyber Insurance](/wiki/glossary/cyber-insurance) --- ## NOC (Network Operations Center) ## Definition A Network Operations Center (NOC) is the team that watches infrastructure health – servers, network devices, backups, patching, [RMM](/wiki/glossary/rmm) alerts – and acts on operational faults: a failed backup job, a full disk, a down switch, a failed patch. Where a [SOC](/wiki/glossary/soc) exists to detect and contain attackers, a NOC exists to keep things running; they share monitoring plumbing but need different skills. ## Why it matters to an MSP For a small MSP the NOC is the piece of 24/7 you can buy. Overnight operational work is mostly repeatable – clear alert noise, remediate failed backups, patch in the maintenance window, restart stuck services, escalate judgment calls to the day team. That work has a market: outsourced NOC providers price it at roughly $2–5 per [endpoint](/wiki/glossary/endpoint) per month, and they work inside your own RMM and [ticketing system](/wiki/glossary/ticketing-system) so nothing leaves your documentation. Compare that to staffing it yourself. A single around-the-clock seat needs four to five technicians, and the overnight shifts are the ones your best people will not take. A two- or three-person shop that promises 24/7 in its [SLA](/wiki/glossary/sla) is really promising that the owner answers the phone at 3 a.m., and one bad on-call month burns out both technicians. An outsourced NOC converts that into a fixed cost, gives you a contractually true answer to "who covers nights and weekends," and – often the larger win – takes daytime alert triage and the patch grind off your technicians' desks. The trade-offs are quality control and client perception. Write the [runbook](/wiki/glossary/runbook) for what the NOC may do without asking, review their ticket notes weekly at first, and decide up front whether clients will know a third party touches their systems. Most do not mind; none like surprises. Related terms: [SOC](/wiki/glossary/soc), [RMM](/wiki/glossary/rmm), [Network Monitoring](/wiki/glossary/network-monitoring), [Escalation](/wiki/glossary/escalation) --- ## PAM (Privileged Access Management) ## Definition Privileged Access Management is the set of controls and tooling that governs accounts capable of changing a system rather than just using it – domain and Global Admin, local administrator, service accounts, and the consoles of the [RMM](/wiki/glossary/rmm), hypervisor, firewall, and backup platform. PAM vaults those credentials, grants elevation just-in-time for a bounded window instead of leaving it standing, and logs or records what was done with it. Where [IAM](/wiki/glossary/iam) covers every identity, PAM covers the few that can do the most damage. ## Why it matters to an MSP Your technicians are the most privileged users in every client environment you manage, and a standing admin account that works across forty tenants is one phished technician away from forty incidents. [GDAP](/wiki/glossary/gdap) decides which roles your partner tenant may hold in a customer's Microsoft 365; PAM decides how a technician actually exercises them – activation through Entra PIM for a few hours with a ticket reference, phishing-resistant [MFA](/wiki/glossary/mfa) on the elevation, and no shared admin logins. Insurers now ask about it by name on questionnaires, and a "no" moves premiums or eligibility. On the client side, the highest-return move is removing local admin from end users – the first thing [ransomware](/wiki/glossary/ransomware) and commodity malware need – and replacing it with endpoint privilege management that approves specific installs on request. Expect a burst of elevation tickets in month one, then pre-approved application rules absorb most of it. Endpoint PAM tooling typically runs $2–$5 per endpoint per month, sold at margin inside a security tier. The one thing PAM cannot fix is a technician using a personal account for admin work; that is a policy and offboarding discipline, covered in [identity and access for SMB](/wiki/identity-and-access-for-smb). Related terms: [GDAP](/wiki/glossary/gdap), [IAM](/wiki/glossary/iam), [Zero Trust](/wiki/glossary/zero-trust), [MFA](/wiki/glossary/mfa) --- ## Patch Management ## Definition Patch management is the recurring process of identifying, testing, deploying, and verifying software updates – operating system, firmware, and third-party application patches – across every managed [endpoint](/wiki/glossary/endpoint) and server. It closes known vulnerabilities on a schedule. It is distinct from [vulnerability management](/wiki/glossary/vulnerability-management), which discovers and prioritizes weaknesses, including ones no patch addresses. ## Why it matters to an MSP Patching is the cheapest security control an MSP delivers. It is [CIS Controls](/wiki/glossary/cis-controls) Safeguards 7.3 and 7.4 at IG1, it appears on every [cyber insurance](/wiki/glossary/cyber-insurance) application as a yes-or-no question, and a documented cadence is now a standard underwriting minimum alongside MFA, EDR, and tested backups. Economically it is automation or nothing: with an [RMM](/wiki/glossary/rmm) policy configured once per deployment ring, patching a thousand endpoints costs a few technician hours a month for exceptions and failed installs; by hand it is a full-time job. That is why it belongs in the base managed plan rather than as an add-on – leaving it out produces the breach you get blamed for anyway. OS patches are easy; third-party applications (browsers, PDF readers, runtimes) are where coverage quietly fails because RMM catalogs vary. Reboots outside a maintenance window generate tickets and resentment. A patch pushed fleet-wide without a test ring breaks printing at forty clients at once. A legacy line-of-business app pinned to an old runtime becomes permanent exposure unless the exception has a compensating control, a review date, and the client's written risk acceptance. Report on it: patch compliance per client – typically targeting 95% or better within 14 days of release for critical updates – is a QBR number business owners understand and insurers ask for. The ring structure, windows, and emergency procedure are in the [patch management process](/wiki/patch-management-process). Related terms: [Vulnerability Management](/wiki/glossary/vulnerability-management), [RMM](/wiki/glossary/rmm), [CIS Controls](/wiki/glossary/cis-controls), [Endpoint](/wiki/glossary/endpoint) --- ## Patch Management Process ## Why this process exists Patching is unglamorous, but it is one of the controls that now decides whether your clients can buy cyber insurance at all. The standard 2025–26 underwriting minimum includes a documented patch and [vulnerability management](/wiki/glossary/vulnerability-management) cadence alongside MFA, EDR, and tested backups – weak answers typically mean 40–100% premium hikes, exclusions, or declination. A written, ring-based process also protects you: when a client asks "why did my machine reboot" or "why weren't we patched before the breach," the answer is a policy they signed, not an improvisation. **Roles:** one named patch owner runs the monthly cycle end to end; the service desk works patch-failure tickets like any other ticket; the account manager handles client-facing scheduling and exception sign-off. In a two-person shop these are hats, not headcount – but the cycle still needs a single owner. ## The patch policy: deployment rings Write one patch policy, attach it to every agreement, and record client deviations as exceptions. The core of the policy is a ring structure that turns "test before broad deployment" into a schedule: 1. **Ring 0 – test group.** Your own MSP machines plus a handful of lab VMs mirroring common client builds. Patches apply within a day or two of release. You are the canary – if an update breaks printing, you find out on your own laptop. 2. **Ring 1 – pilot.** Roughly 5–10% of each client fleet: IT-tolerant volunteers, one machine per department, non-critical servers. Let patches soak here a few days while you watch for failure patterns. 3. **Ring 2 – broad workstations.** The rest of the fleet, deployed automatically once the pilot ring is clean. 4. **Ring 3 – servers and critical systems.** Last, inside contracted maintenance windows, with a snapshot or verified backup taken first. The rings are policy objects in your [RMM](/wiki/glossary/rmm), not a spreadsheet. A typical full cycle runs about two weeks from vendor release to servers patched. ## OS vs third-party patching OS patching is the easy half – every serious RMM automates Windows and macOS updates. Third-party applications (browsers, PDF readers, runtimes, collaboration clients) are where coverage quietly fails, because RMM third-party catalogs vary widely in breadth and freshness. Audit which of your clients' actual installed applications your tooling covers, close the gap with a supplemental patching tool if needed, and treat uncovered line-of-business apps as documented exceptions with a manual update owner. An [endpoint](/wiki/glossary/endpoint) with a current OS and a year-old browser plugin is not patched. ## Maintenance windows and client communication - **Workstations:** patch outside business hours with wake-on-LAN or next-boot retry. Allow user deferral of reboots, but cap it (a typical policy: three deferrals or 72 hours, whichever comes first, then forced reboot with warning). - **Servers:** a contracted monthly window per client – for example, third Saturday 22:00–02:00 – written into the SLA attachment, not negotiated ticket by ticket. Set expectations during [client onboarding](/wiki/client-onboarding-process). - **Communication rhythm:** publish the annual window schedule once, send a reminder before each server window, and otherwise stay silent on success. Notify only on exceptions – a completed-with-issues note beats a monthly "everything was fine" email nobody reads. ## Automating approvals and schedules in the RMM Configure approval policies once, per ring, and stop touching individual patches: - Auto-approve security updates and definition updates after their ring soak; hold feature upgrades, firmware, and driver updates for manual review. - Map schedules to rings globally; per-client overrides exist only as documented exceptions. - Route failures automatically: an endpoint that misses two consecutive cycles opens a [PSA](/wiki/glossary/psa) ticket – silent drift is the failure mode that shows up in breach postmortems. - Patch your own house fastest of all. Your RMM is a supply-chain weapon pointed at every client – the July 2021 Kaseya VSA attack pushed ransomware through the RMM's own agent channel to roughly 60 MSPs and 800–1,500 downstream businesses. Patch RMM servers and agents within days of release, and see [securing your MSP](/wiki/securing-your-msp) for the rest of your own hardening. ## Exceptions and deferrals Every "don't patch that" needs a paper trail: what is excluded, why (usually a legacy LOB app pinned to an old runtime), the compensating control (network segmentation, extra monitoring), a review date, and the client's written risk acceptance. Store exceptions in your documentation platform per your [documentation standards](/wiki/msp-documentation-standards) and review them at every [QBR](/wiki/qbr-process) – an exception without a review date is permanent unpatched exposure you now own. ## Emergency out-of-band patching When a CVE is being actively exploited (CISA KEV listing, vendor emergency advisory) in software your clients run, the monthly cycle is suspended for that patch: 1. **Assess exposure fast.** Query the RMM for affected versions; internet-facing systems first. 2. **Compress the rings.** Test on a handful of machines in hours, not days; if exploitation is confirmed and the vendor patch is stable, skip the pilot soak. Where no patch exists, apply the vendor mitigation (disable the feature, firewall rule) and track it as a deferral. 3. **Patch outside windows.** Your patch policy should pre-authorize emergency work without per-event approval – negotiating window exceptions during active exploitation wastes the hours that matter. 4. **Notify clients on a set cadence.** Initial notice at the start: what the vulnerability is, whether they're exposed, what you're doing, whether any action or downtime is needed. Interim updates at a stated interval (every 4–8 hours is typical for multi-day events). A completion notice with verification results. Keep a reusable template with those four fields – writing prose at 11pm during an incident is how errors happen. ## Verification, rollback, and reporting **Success is verified, not assumed.** After each cycle, reconcile: every endpoint checked in, installed, rebooted, and rescanned clean. Chase stragglers (offline laptops are the usual culprits) and track patch-compliance percentage per client. **Rollback is planned before deployment.** Servers get a snapshot or verified backup before the window; know the uninstall path for each major update. If the broad ring surfaces a bad patch: pause the policy, remove the update from affected machines, document the CVE-vs-stability decision. **Reporting is your evidence.** A monthly patch-compliance report per client, with exceptions listed, does triple duty: QBR material, [compliance](/wiki/glossary/compliance) artifact, and cyber-insurance evidence. Insurers send annual attestation questionnaires the client can't answer – you supply the patch reports, but the client's officer signs the attestation, never you. ## Monthly cadence checklist - **Release day +1–2:** Ring 0 patched; review vendor notes for known issues. - **Day 3–5:** Ring 1 pilot deploys; monitor failure alerts. - **Day 6–10:** Ring 2 broad workstation deployment; failures become tickets. - **Day 10–14:** Ring 3 server windows; snapshot first, verify after. - **Day 15:** Reconciliation – compliance report per client, chase stragglers, file evidence. - **Quarterly:** review exceptions and deferrals; audit third-party coverage. - **Continuous:** monitor KEV/vendor advisories for out-of-band triggers; patch your own RMM within days. Run this cycle unchanged for three months and patching stops being work – it becomes a report you hand to clients and insurers while the RMM does the labor. --- ## Peer Group ## Definition A peer group is a paid, structured cohort of roughly 8–15 non-competing [MSP](/wiki/glossary/msp) owners who meet on a fixed schedule – typically quarterly in person plus monthly calls – to share full financials, benchmark against one another, and hold each other accountable to stated commitments. ## Why it matters to an MSP Owner-operators run blind. Nobody on staff will tell you your gross margin is 15 points low or your seat price is half of market. A peer group replaces that with a table of people who see your P&L every quarter and have already made the mistake you are about to make. What you get is specific. Benchmarks: service gross margin, revenue per employee, EBITDA, [MRR](/wiki/glossary/mrr) per seat, and [churn rate](/wiki/glossary/churn-rate) against a cohort of similar-sized MSPs, refreshed quarterly. Shared financials: seeing a peer clear 20% EBITDA on your revenue with two fewer technicians is a stronger price-increase argument than any consultant. Accountability: you leave each meeting with two or three commitments, and the next one opens with whether you kept them. Typical cost is $8,000–$25,000 a year in fees plus travel, and four to eight owner days away from the business – which is why the common guidance is to join once you have staff and roughly $1M in revenue, when there is a real P&L to benchmark and the fee stops being material. Below that, a free community or an informal accountability group of two or three local owners delivers much of the value at no cost. The failure mode is treating it as a conference: the return is in the quarterly homework and the uncomfortable numbers, not the sessions. Where peer groups sit among forums, conferences, and benchmark reports is covered in [MSP community resources](/wiki/msp-community-resources). Related terms: [MRR](/wiki/glossary/mrr), [Churn Rate](/wiki/glossary/churn-rate), [MSP](/wiki/glossary/msp) --- ## Penetration Testing ## Definition Penetration testing is an authorized, human-driven attack simulation: a skilled tester actively attempts to exploit weaknesses – chaining vulnerabilities, abusing misconfigurations, phishing users, escalating privileges – to demonstrate what a real attacker could actually achieve in a specific environment. That's categorically different from [vulnerability scanning](/wiki/glossary/vulnerability-management), which is automated enumeration of known weaknesses: a scan tells you a door has a weak lock; a pen test picks the lock, walks in, and shows you what was reachable from there. ## Why it matters to an MSP Clients increasingly need pen tests for external reasons: compliance frameworks expect them (the FTC Safeguards Rule expects monitoring or periodic testing, HHS's proposed HIPAA Security Rule update would make annual penetration testing mandatory, and CMMC-bound defense contractors face third-party assessment scrutiny), and cyber-insurance applications ask about them. The near-universal channel practice is to partner with a third-party testing firm rather than self-test – partly because offensive testing is a specialist trade, but mostly independence: an MSP testing the environment it built and operates is grading its own homework, and auditors, insurers, and regulators discount the result. The MSP's profitable role sits around the test: scope it, prepare the environment, receive the findings, and sell the remediation roadmap – which is where most of the revenue lives anyway. Resell through a testing partner with a coordination markup, or pass it through and charge for remediation. Related terms: [Vulnerability Management](/wiki/glossary/vulnerability-management), [Compliance](/wiki/glossary/compliance), [Cyber Insurance](/wiki/glossary/cyber-insurance) --- ## Per-Device Pricing ## Definition Per-device pricing charges the client a flat monthly fee for each managed asset – workstation, server, firewall, switch, printer – regardless of how many people use it. Typical US ranges as of 2026 are $25–$60 per workstation, $200–$500 per production server, and roughly $25–$75 per network device, with the fee covering monitoring, patching, endpoint protection, and routine remediation for that asset. ## Why it matters to an MSP Per-device is the oldest managed services model and the one that maps most directly onto what your tooling costs: the [RMM](/wiki/glossary/rmm), [EDR](/wiki/glossary/edr), backup, and [patch management](/wiki/glossary/patch-management) agents are all licensed per [endpoint](/wiki/glossary/endpoint), so every line on the invoice has a known cost of goods underneath it. That keeps quoting and margin analysis simple, and it's honest where devices don't belong to people – shop-floor terminals, nurse-station PCs, kiosks, warehouse scanners – where a per-user price would put you on the hook for far more hardware than the headcount implies. Its weakness is the same transparency. When each device is a line item, every device gets argued over ("does the conference room PC really need coverage?"), clients quietly leave assets off the list and then expect you to fix them, and revenue stops tracking what drives your labor – people and their problems. A user with a laptop, a desktop, and a phone generates one person's worth of tickets but pays per box, and the shift to two or three devices per employee has moved most MSPs to per-seat pricing for knowledge-worker clients. The common resolution is a hybrid: per-user for staff plus per-server and per-network-device add-ons at the ranges above, so the infrastructure that generates real work is covered explicitly. Worked numbers and model comparisons are in [MSP pricing models](/wiki/msp-pricing-models). Related terms: [Per-Seat Pricing](/wiki/glossary/per-seat-pricing), [HaaS](/wiki/glossary/haas), [RMM](/wiki/glossary/rmm), [MRR](/wiki/glossary/mrr) --- ## Per-Seat Pricing ## Definition Per-seat pricing – also called per-user pricing – charges a client a flat monthly fee for each person you support, covering all of that person's devices, accounts, and support requests. It contrasts with [per-device pricing](/wiki/glossary/per-device-pricing), which bills per managed asset, and with hourly [break-fix](/wiki/glossary/break-fix) billing. ## Why it matters to an MSP Per-seat is the dominant managed services model in 2026 because it matches how clients think about cost: headcount. A prospect with 40 employees and a $150 seat knows their IT bill is $6,000 a month before the meeting ends. Typical US ranges as of 2026 are $100–$250 per user per month all-in, with the fat middle at $125–$200; entry bundles (monitoring, patching, help desk, antivirus, backup) sit low, fully managed plans with EDR and vendor management in the middle, and 24/7 plus compliance tiers reach $250–$300 or more. The economics work when the seat is all-in: licenses, security tooling, backup, and support in one line. That hides individual tool margins from scrutiny, gives you a single [MRR](/wiki/glossary/mrr)-per-seat number to manage upward, and turns license resale through the [CSP program](/wiki/glossary/csp-program) into margin. Compute the floor before quoting: per-seat tool cost plus labor at realistic tickets per seat plus overhead, then apply a gross margin target – 70% is the best-in-class benchmark, so $60 of delivery cost implies a $200 floor. Two contract traps. Define "user" precisely – named person with a mailbox, part-timers, shared logins, contractors – or the client defines it in their favor and your seat count shrinks every renewal. And add a device cap or a per-server line, because a warehouse client with 12 users and 60 devices breaks the model. Minimums, onboarding fees, and escalators are covered in [MSP pricing models](/wiki/msp-pricing-models). Related terms: [Per-Device Pricing](/wiki/glossary/per-device-pricing), [All-You-Can-Eat Pricing](/wiki/glossary/all-you-can-eat-pricing), [MRR](/wiki/glossary/mrr), [Value-Based Pricing](/wiki/glossary/value-based-pricing) --- ## Phishing ## Definition Phishing is a social-engineering attack that uses email, text messages, phone calls, or counterfeit websites to trick a person into revealing credentials, approving a payment, or running malware. Modern variants – spear phishing aimed at a named individual, adversary-in-the-middle kits that proxy a real login page and capture the authenticated session token, QR-code and voice phishing – target the person rather than the perimeter. ## Why it matters to an MSP Phishing is the most common initial access vector in SMB breaches and the on-ramp to [BEC](/wiki/glossary/bec), [ransomware](/wiki/glossary/ransomware), and account takeover. Client risk first: one clicked link in a tenant protected only by push-based [MFA](/wiki/glossary/mfa) can yield a live Microsoft 365 session, hidden inbox rules, and a fraudulent wire request weeks later. Defense is therefore a layered product, not a spam filter – email security with link and attachment detonation, phishing-resistant MFA (FIDO2 keys or passkeys) for finance and admin roles, conditional access, and [security awareness training](/wiki/glossary/security-awareness-training) with simulated campaigns. Insurers now ask about all four on the application. Your own risk second: your technicians hold admin access to every client tenant, which makes them the highest-value targets, and token-theft kits walk straight past push and SMS MFA. Hardware keys, device-bound sign-in, and short session lifetimes belong on MSP accounts before any client's. Operationally, a phishing compromise is a fixed [runbook](/wiki/glossary/runbook): revoke sessions, reset the password, remove inbox rules and OAuth consents, check forwarding, and review sign-in logs for the dwell period. Track simulation results per client – a report rate above roughly 50% and a click rate under 5% after a year of training are typical marks of a program that is working; numbers stuck above that are a conversation about the client's culture. Related terms: [BEC](/wiki/glossary/bec), [MFA](/wiki/glossary/mfa), [Security Awareness Training](/wiki/glossary/security-awareness-training), [Ransomware](/wiki/glossary/ransomware) --- ## Professional Services Automation (PSA) ## Definition Professional services automation is the business system of record for an MSP: a single platform that combines the [ticketing system](/wiki/glossary/ticketing-system), technician time tracking, client contracts and agreements, recurring and project billing, project management, and usually a lightweight CRM. Where the [RMM](/wiki/glossary/rmm) manages the client's machines, the PSA manages your business – every hour, every ticket, every dollar. ## Why it matters to an MSP The PSA is where the economics of a managed service business become visible, or fail to. Every ticket that lands in it carries a client, an agreement, and logged time, so it can answer the questions that decide whether you are profitable: hours consumed per agreement against the fee charged, tickets per [endpoint](/wiki/glossary/endpoint) per month, technician utilization, [first-call resolution](/wiki/glossary/first-call-resolution), and [SLA](/wiki/glossary/sla) response and resolution against target. An agreement quietly consuming twice the labor it was priced for shows up in the PSA months before it shows up in the bank balance – provided technicians log time on every ticket, which is the operating discipline the whole system depends on. It is also the billing engine. Contracts with seat counts, price escalators, and auto-renewal generate the monthly invoice, so [MRR](/wiki/glossary/mrr) is a report rather than a spreadsheet and seat additions get billed. Pricing as of 2026 typically runs $60–120 per user per month for a dedicated PSA, or comes bundled with RMM per technician. The rules that make it work: every intake channel ends in a ticket, no work happens without one, time is logged as it happens, and RMM alerts flow in through integration rather than a separate inbox. Credentials and documentation belong in a dedicated documentation platform, not the PSA's notes fields. The integrated-suite-versus-best-of-breed decision is covered in [choosing an RMM and PSA](/wiki/choosing-rmm-psa). Related terms: [RMM](/wiki/glossary/rmm), [Ticketing System](/wiki/glossary/ticketing-system), [SLA](/wiki/glossary/sla), [MRR](/wiki/glossary/mrr) --- ## QBR (Quarterly Business Review) ## Definition A QBR is a scheduled meeting between the MSP and a client's decision-maker – quarterly for top accounts, semi-annually for most others – that reviews service performance, security findings, and the client's technology roadmap and budget for the next 12–36 months. It is a business conversation, not a recap of last quarter's tickets. ## Why it matters to an MSP The QBR is the most valuable recurring hour in the managed services model because three things are earned in it at once. Retention: clients rarely fire the provider who owns their roadmap, and quiet accounts that skip reviews are the ones that churn without warning – the review is the touch-point that would have caught the drift. Project revenue: hardware refresh, standardization, and security upgrades get sold here as documented risk reduction rather than cold proposals. Pricing power: a scorecard showing SLA attainment, ticket trend, and a shrinking risk register is what lets a rate increase land without a fight. Inputs you already produce: a service scorecard from the [PSA](/wiki/glossary/psa), standards findings from your assessment checklist mapped to a framework the owner recognizes such as [NIST CSF](/wiki/glossary/nist-csf), a risk register, and a refreshed roadmap. Preparation runs two to four hours per client, so cadence is a capacity decision: promising quarterly reviews to thirty clients and delivering four is worse than a reliable semi-annual. Watch who attends – when the owner stops coming and sends the office manager, the relationship is drifting. A strong review is also the best moment to ask for a referral. The founder runs QBRs at first; at scale they move to a [vCIO](/wiki/glossary/vcio) or [technical account manager](/wiki/glossary/technical-account-manager). Agenda, preparation checklist, and completion criteria are in the [QBR process](/wiki/qbr-process). Related terms: [vCIO](/wiki/glossary/vcio), [Churn Rate](/wiki/glossary/churn-rate), [Technical Account Manager](/wiki/glossary/technical-account-manager), [NIST CSF](/wiki/glossary/nist-csf) --- ## Quarterly Business Review Process ## Purpose: relationship and roadmap, not ticket review A [QBR](/wiki/glossary/qbr) is a business meeting with a business owner about where their technology is going – not a recap of last quarter's tickets. Done right, it is the single best churn defense and project-revenue source an MSP has: it is where standardization work gets sold as risk reduction, where price increases get justified with evidence, and where the client hears – on a predictable cadence – that someone is thinking about their business, not just their inbox. Clients rarely leave the provider who owns their technology roadmap. The role running this meeting is the [vCIO](/wiki/glossary/vcio) function (or a [technical account manager](/wiki/glossary/technical-account-manager) in larger shops). In a small MSP that person is you, the founder – and even a solo founder should run lightweight QBRs with top clients. The process below scales down to a 45-minute version. ## Who attends - **Client side:** the business owner or executive sponsor – the person who owns budget and risk. An office manager alone is a warning sign; if decision-makers stop attending, the relationship is drifting. Their internal IT lead attends in co-managed arrangements. - **MSP side:** the vCIO/account owner leads. Optionally the lead tech for that client for credibility on findings – but the meeting is run in business language, not by engineers to engineers. - **Not** the whole service desk, and not a parade of five people that outnumbers the client. ## Cadence by client size Typical practice as of 2026: | Client tier | Cadence | |---|---| | Top clients (largest MRR, most strategic) | Quarterly | | Mid-tier | Semi-annual | | Small clients | Annual review, or a written report with an offer to meet | Don't promise quarterly reviews to thirty clients and deliver four. Commit to a cadence you can sustain; a reliable semi-annual review beats a fictional quarterly one. Start with systems you already pay for: [Acronis Cyber Protect Cloud](https://www.acronis.com/en/resource-center/resource/executive-summary-report-create-and-send-to-your-customer/) can generate and schedule customizable executive reports, while [Acronis PSA](https://www.acronis.com/en/products/cloud/cyber-protect/psa-solution/) provides KPI, profitability, SLA, and NPS reporting. Purpose-built QBR tools such as myITprocess, ScalePad Lifecycle Manager, and vCIOToolbox can help when client volume makes manual preparation expensive. A spreadsheet and editable slide template are enough at the start. ## Preparation checklist Preparation is most of the value. For each review, roughly a week out: - Pull the quarter's service scorecard from the PSA: ticket volume and trend, SLA attainment (response times with waiting-clock pauses honored), CSAT results, endpoint counts. See [MSP KPIs and benchmarks](/wiki/msp-kpis-and-benchmarks) for which numbers belong here. - Run the standards audit: compare the client's environment against your written standards library; every deviation becomes a finding with a risk rating. (This is the TruMethods-style standardization practice – their data suggests keeping clients on standard can cut reactive tickets by roughly two-thirds.) - Update the risk register: open findings, aging hardware, unsupported OS versions, backup test results, security posture gaps, compliance progress where relevant – see [compliance as a service](/wiki/compliance-as-a-service). - Refresh the 12–36 month roadmap and the budget forecast: what's planned, what it costs, what quarter it lands in. - Note business context: anything you've learned about the client's growth, hiring, moves, or plans. - Send the agenda ahead, and confirm the decision-maker is attending. ## Agenda structure A 60–90 minute meeting (45 minutes for the lightweight version): 1. **Business review (client talks first).** What's changing in their business – headcount, locations, applications, plans. This is where roadmap items are born, and it signals the meeting is about them. 2. **Service scorecard (brief).** Tickets, SLA attainment, CSAT – trends, not ticket-by-ticket detail. Five minutes unless something needs explaining. 3. **Standards audit results.** Findings from the standards review and any [network assessment](/wiki/network-assessment-process), framed as business risk: "these machines leave support in March; here's the exposure," not CVE numbers. 4. **Roadmap and budget forecast.** The 12–36 month plan: what you recommend, when, and what it costs – so IT spend becomes a planned budget line instead of surprise invoices. 5. **Risk register and compliance progress.** What's open, what was closed since last time, what needs a decision today. 6. **Decisions and next steps.** Leave with explicit outcomes: projects approved, deferred (with the risk documented as accepted), and the next review booked. Follow up within a week: summary, decisions, and quotes for approved projects. ## Turning QBRs into project revenue The QBR is where the findings-to-projects engine runs: standards audit → findings → roadmap items → funded projects. Sell them as risk reduction, not upsell – "your firewall exits support in Q3; here is the replacement plan" lands very differently from a cold quote. A healthy practice sees a meaningful share of project revenue originate in reviews. When the client defers, document the accepted risk in the register and revisit next cycle; a written, dated "declined" protects you and often converts later. QBRs are also where price adjustments get grounded in evidence – the scorecard and delivered roadmap make the conversation factual instead of awkward. ## Common mistakes - **Rehashing tickets.** The fastest way to teach executives to skip the meeting. Scorecard in five minutes, then forward-looking. - **Tech jargon.** Speak in risk, cost, and downtime. If a slide needs an acronym glossary, rewrite it. - **No decisions requested.** A review that ends with "any questions?" produced nothing. Every QBR should ask for at least one decision. - **Skipping quiet clients.** "No news" clients skip reviews, drift, and churn without warning – the review *is* the touch-point that would have caught it; see [churn rate](/wiki/glossary/churn-rate). - **Presenting without preparation.** An unprepared QBR is worse than none; it demonstrates that the strategic relationship is theater. - **Waiting until the client is big enough.** The first review belongs at day ~90 of [client onboarding](/wiki/client-onboarding-process), setting the rhythm from the start. ## Exit criteria A QBR is done when: the decision-maker attended; the scorecard, standards findings, risk register, and roadmap were reviewed; at least one decision was made or a deferral documented; the summary went out within a week; and the next review is on the calendar. Miss those and you held a status call, not a business review. ## Bottom line Run QBRs quarterly for your top clients and semi-annually below that, prepare with the checklist, keep the agenda pointed at the client's business and the next 12–36 months, and always leave with a decision. It is the highest-return recurring meeting in the MSP business model – the place where retention, project revenue, and pricing power are all earned in the same hour. --- ## Ransomware ## Definition Ransomware is malware that encrypts a victim's files and systems and demands payment for the decryption key. Modern operators practice double extortion: they exfiltrate data before encrypting, then threaten to publish it, so a clean restore removes only half of their pressure. Most attacks arrive through [phishing](/wiki/glossary/phishing), stolen credentials on remote access without [MFA](/wiki/glossary/mfa), or unpatched internet-facing systems. ## Why it matters to an MSP Ransomware is the incident your service exists to prevent, and the reason MSPs are targets themselves. An attacker who compromises your [RMM](/wiki/glossary/rmm) or your partner credentials for Microsoft 365 can push a payload to every client at once – the 2021 Kaseya VSA attack reached roughly 1,500 downstream businesses through about 50 MSPs. Securing your own tooling with MFA, least-privilege access, and [GDAP](/wiki/glossary/gdap) is client protection, not overhead. For clients, the key operational fact: ransomware operators hunt backup infrastructure first. They find the backup server, the NAS, the cloud console with a saved password, and delete or encrypt them before touching production. A backup the attacker can reach is not a backup. At least one copy must be immutable – object lock or a vendor immutability flag that an administrator cannot override – or air-gapped, and restores must be tested on a schedule – insurers now ask for the evidence. Typical SMB recovery costs run into the mid six figures once downtime, forensics, notification, and rebuild labor are counted, paid ransom or not, and [cyber insurance](/wiki/glossary/cyber-insurance) carriers price and decline on the presence of MFA, [EDR](/wiki/glossary/edr), and tested offline backups. For you, an event is weeks of unbilled engineering time and a liability question about whether your controls met the standard of care your contract implied. Have the [incident response process](/wiki/incident-response-process) written before you need it. Related terms: [BDR](/wiki/glossary/bdr), [Cyber Insurance](/wiki/glossary/cyber-insurance), [EDR](/wiki/glossary/edr), [Phishing](/wiki/glossary/phishing) --- ## Remote Monitoring and Management (RMM) ## Definition Remote monitoring and management is the agent-based platform that gives an MSP visibility and control over every managed [endpoint](/wiki/glossary/endpoint) across all clients from one console: hardware and software inventory, health monitoring and alerting, [patch management](/wiki/glossary/patch-management), scripted automation, and remote access. The agent installs on each workstation and server, phones home continuously, and executes whatever the console tells it to. ## Why it matters to an MSP RMM is the multiplier that makes fixed-fee support profitable. Without it, every disk-space warning, failed backup, and missing patch is a site visit; with it, monitoring finds the problem first, a script fixes the routine cases, and a technician handles the rest remotely. That is how a good shop runs 250–400 endpoints per technician instead of 100, and why tickets per endpoint per month should fall as automation policies mature. Pricing as of 2026 is typically $2–6 per endpoint monthly, or a flat per-technician fee with unlimited endpoints, a small fraction of a $100–200 per-seat fee. Deploy the agent on day one of onboarding, because inventory, warranty, and health data enrich every conversation that follows, from the first [QBR](/wiki/glossary/qbr) to the [network assessment](/wiki/network-assessment-process). Feed its alerts into your [PSA](/wiki/glossary/psa) so nothing gets handled outside a ticket, and remove it as the last step of offboarding. It is also the most dangerous tool you own. An RMM console is remote code execution across every client at once, which is why attackers target MSPs through it – the 2021 supply-chain attack on a major RMM vendor encrypted over a thousand businesses in an afternoon. Phishing-resistant [MFA](/wiki/glossary/mfa) on every console login, least-privilege technician roles, IP restrictions, and alerts on new script deployment are not optional. Platform selection is covered in [choosing an RMM and PSA](/wiki/choosing-rmm-psa). Related terms: [PSA](/wiki/glossary/psa), [Patch Management](/wiki/glossary/patch-management), [Endpoint](/wiki/glossary/endpoint), [Network Monitoring](/wiki/glossary/network-monitoring) --- ## RPO (Recovery Point Objective) ## Definition RPO is the maximum acceptable data loss, expressed as time: a one-hour RPO means that after a failure, no more than the last hour of changes may be gone. In practice it is the required interval between good backups. Where [RTO](/wiki/glossary/rto) asks how long the client can be down, RPO asks how much work they can afford to redo. ## Why it matters to an MSP RPO sets the backup frequency, and frequency drives storage, bandwidth, licensing, and monitoring load – which is what separates the price tiers. A 24-hour RPO is a nightly job to the cloud; cheap and adequate for general workstations and most Microsoft 365 data, where the SaaS backup itself typically runs 1–3 snapshots a day. A four-hour RPO on a file server means intermittent image backups with change tracking, usually direct-to-cloud. A one-hour RPO on a practice-management or ERP database means a local appliance snapshotting hourly with an immutable cloud copy – the appliance tier, which costs several times more than direct-to-cloud image backup. Tighter than an hour needs application-level replication, which few small clients will pay for. The client owns this number, but only once you make it concrete: "If the server dies at 4 p.m., are you re-entering the day since last night, or only the last hour?" Ask per system and write the answer into the service agreement and the [business continuity plan](/wiki/glossary/business-continuity-plan). Then police it. Last-good-backup age is the RPO metric; anything past the agreed window is an incident to escalate that day, because a Tier 1 client whose hourly job failed quietly a week ago is running on an RPO they are not paying for. How objectives translate into architecture is covered in [backup and recovery design](/wiki/backup-recovery-design). Related terms: [RTO](/wiki/glossary/rto), [BDR](/wiki/glossary/bdr), [Business Continuity Plan](/wiki/glossary/business-continuity-plan), [Ransomware](/wiki/glossary/ransomware) --- ## RTO (Recovery Time Objective) ## Definition RTO is the maximum acceptable time between a failure and the moment a system or business function is usable again – measured to "staff are working," not to "the restore job started." It answers how long the client can be down. Its companion, [RPO](/wiki/glossary/rpo), answers how much data they can afford to lose; the two are set separately and drive different parts of the backup design. ## Why it matters to an MSP The RTO chooses the recovery method, and the recovery method sets the price tier. A four-hour RTO on a line-of-business server cannot be met by pulling a 2 TB image back from cloud storage over a 200 Mbps line – that is most of a day before Windows repair even starts. Hitting it requires a local appliance that boots the last backup as a virtual machine in minutes, with a cloud copy for site loss. That design typically runs $250–$500 per server per month, versus $50–$150 for direct-to-cloud image backup that honestly delivers next-day recovery, and $5–$15 per workstation for cloud endpoint backup with a 1–3 day RTO. Set the objective per system, not per client: the practice-management server and the marketing file share do not need the same tier. Write the negotiated RTO into the service agreement and the [business continuity plan](/wiki/glossary/business-continuity-plan), and have clients who decline Tier 1 pricing for Tier 1 systems sign that decision. Then test it: the annual DR exercise measures actual recovery time against the contracted RTO, and any gap is either a roadmap sale or a liability you are carrying unpriced. A contracted RTO you have never rehearsed is a promise, not a capability. [Backup and recovery design](/wiki/backup-recovery-design) covers how the tiers map to architecture. Related terms: [RPO](/wiki/glossary/rpo), [BDR](/wiki/glossary/bdr), [DRaaS](/wiki/glossary/draas), [Business Continuity Plan](/wiki/glossary/business-continuity-plan) --- ## Runbook ## Definition A runbook is a step-by-step procedure for handling one specific, recurring technical situation – restoring a server from backup, rotating a service account password, clearing a print-spooler fault – written so that a technician who has never seen the environment can execute it correctly. Unlike an [SOP](/wiki/glossary/sop), which describes how the business does something in general, a runbook is scoped to one task, one environment, and one outcome, with exact commands, credential locations, order of operations, and the points where the tech must stop and escalate. ## Why it matters to an MSP Runbooks are where an MSP's margin lives. The same ten ticket types typically make up 60–70% of volume, and handled from memory, time per ticket varies threefold between your best tech and your newest hire. A runbook attached to the ticket type collapses that spread: the new hire resolves it in the senior tech's time, [first-call resolution](/wiki/glossary/first-call-resolution) goes up, and senior hours go back to project work. It is also how you hire: your first technician is productive on day one only if the common work is written down, even as one-page versions. The other half is recovery. A restore that depends on the one person who knows the domain controller comes before the application server is a single point of failure with a phone. The per-client recovery runbook – restore order, credential locations, vendor support numbers, the local-versus-cloud decision tree – is what turns an [RTO](/wiki/glossary/rto) from a number in a contract into something you can deliver at 2 a.m. Keep them in your documentation platform, linked from the ticket type, and review them when the environment changes; an outdated runbook is worse than none because the tech trusts it. Structure and ownership are covered in [documentation standards](/wiki/msp-documentation-standards). Related terms: [SOP](/wiki/glossary/sop), [RTO](/wiki/glossary/rto), [Escalation](/wiki/glossary/escalation) --- ## Securing Your Own MSP ## You are the highest-value target in your market An attacker who breaches one 200-seat company gets one company. An attacker who breaches an MSP gets every client at once, delivered through the very tools built to push software silently to every endpoint you manage. That supply-chain reach is why MSPs are explicitly and deliberately targeted – privileged access to many networks, concentrated in one place. The defining proof is Kaseya VSA, July 2, 2021. REvil exploited a zero-day authentication bypass in on-prem VSA servers and pushed ransomware through the RMM's own update and agent channel. Roughly 60 MSPs and somewhere between 800 and 1,500 downstream businesses were encrypted simultaneously, with a $70M ransom demand (Kaseya later obtained a universal decryptor without paying). One compromise, entire client bases gone in an afternoon. This is not history. RMM tool abuse rose 277% in 2025 and featured in roughly a quarter of observed incidents. The dominant intrusion pattern is now session-token theft via adversary-in-the-middle [phishing](/wiki/glossary/phishing) kits like Evilginx – an attack that walks straight past push-based MFA and steals the already-authenticated session instead. ## Start with the CISA baseline The canonical reference is joint advisory AA22-131A, "Protecting Against Cyber Threats to Managed Service Providers and their Customers," issued in May 2022 by CISA, NSA, FBI, and Five Eyes partners – and still the standard as of 2026. Its key asks: - Harden and monitor all remote access infrastructure - Enforce MFA everywhere, on internal and customer-facing systems alike - Log widely and retain logs for at least six months - Segregate internal admin systems from customer-facing infrastructure - Offboard accounts rigorously when staff or clients leave - Define security roles and responsibilities contractually with every client - Maintain – and actually exercise – incident response plans Treat that list as your standing internal audit checklist. Everything below implements it. ## Phishing-resistant MFA on every tool, no exceptions [MFA](/wiki/glossary/mfa) goes on every tool that touches client environments or your business – no exceptions, no service accounts quietly excluded: the RMM, the [PSA](/wiki/glossary/psa), the backup console, the EDR console, distributor portals, the domain registrar, and your documentation platform (Hudu, IT Glue). A documentation platform holds every client's credentials and network maps; treat it like the crown jewels it is. Because token theft is the dominant pattern as of 2026, push-approval MFA is no longer enough for privileged access. Move every admin, RMM, and PSA login to phishing-resistant MFA – FIDO2 hardware keys or Windows Hello. A set of hardware keys for your whole team costs less than one hour of incident response. ## Separate admin accounts and least privilege - **No shared logins, ever.** Every admin action must be attributable to a named person; shared credentials also make offboarding a fire drill. - **Daily driver ≠ admin.** The account that reads email and browses never holds admin roles; admin work happens under separate named admin accounts. - **Privileged access workstations** for tenant administration, kept off email and general browsing. - **Just-in-time elevation** (Entra PIM) instead of standing global admin – hold the role for the hour you need it. - **Checklist-driven offboarding** for staff, executed same-day: every portal, every tool, every client tenant. ## GDAP, not legacy DAP Legacy DAP gave partners standing Global Admin over every customer tenant – which is why Microsoft force-retired it in 2023. [GDAP](/wiki/glossary/gdap) replaces it with per-customer, role-scoped, time-boxed relationships (1 to 730 days), assigned to security groups instead of the whole partner tenant, with PIM-style just-in-time elevation on top for the few genuinely privileged roles. If your partner tenant still carries broad, never-expiring delegation, migrating to properly scoped GDAP is the single highest-impact hardening move available to a Microsoft-centric MSP: it converts "one phished tech = Global Admin on every client" into "one phished tech = limited role on one tenant, for a limited time." ## Harden the RMM itself Your [RMM](/wiki/glossary/rmm) is the ransomware distribution system an attacker dreams of – Kaseya proved the delivery mechanism works. Minimum standard: - IP allow-listing on the RMM console so it isn't reachable from the open internet - Patch the RMM within days of release – the Kaseya victims were running unpatched on-prem servers - Remove stale agents from offboarded clients and dead machines; every forgotten agent is a door - Vet the script library and restrict who can create and push scripts - Keep customer-facing infrastructure separated from your internal admin network, per AA22-131A ## Run your shop at CIS IG1 You need a framework so hardening is a checklist, not a vibe. The channel favorite is [CIS Controls](/wiki/glossary/cis-controls) v8.1: prescriptive, free, and tiered. IG1 – 56 safeguards across 15 controls, labeled "essential cyber hygiene" – is explicitly designed for small organizations without dedicated security staff, which is exactly what a young MSP is. Run your own company at IG1, graduate toward IG2 as you take on regulated clients, and map the results to [NIST CSF](/wiki/glossary/nist-csf) when insurers or client executives want board-level reporting. The bonus: the same IG1 checklist doubles as your client gap-assessment product, so hardening yourself is also product development – see [Building Your Client Security Stack](/wiki/msp-security-stack). ## An IR plan for "our RMM is popped" Responding to a client's incident and responding to your own are different plans; you need both. Pre-stage a runbook for your own compromise: 1. How to sever RMM connectivity to all clients fast, and who has authority to pull that trigger 2. Out-of-band communications – assume your email and PSA are attacker-readable 3. Offline copies of documentation and credentials, so containment doesn't depend on compromised systems 4. Six-plus months of retained logs so forensics has something to work with 5. A client notification order and script – who calls whom, saying what 6. Your own E&O/cyber policy details and carrier hotline at hand Then exercise it. CISA specifically calls for exercised plans, and a tabletop costs one afternoon. Model the client-facing side on your [incident response process](/wiki/incident-response-process), but write the self-inflicted version separately. ## Your posture is a sales asset Every control above eventually shows up in someone else's due diligence. Clients' cyber-insurance carriers ask about the MSP's own controls. CMMC-bound clients must document what their MSP touches via a shared responsibility matrix – an unhardened MSP is disqualified from that revenue entirely. And in competitive deals, "here is the CIS IG1 checklist we run our own company against, and here's our own IR tabletop schedule" is credibility that no brochure buys. Prospects extrapolate: the MSP that secures itself rigorously will secure them rigorously. Make your own posture a named section in sales conversations and QBRs – see [MSP sales and marketing](/wiki/msp-sales-marketing). ## Bottom line Harden in this order: phishing-resistant MFA on every tool, GDAP migration, RMM lockdown, separate admin accounts with just-in-time elevation, then work methodically through CIS IG1 and write and exercise the "our RMM is popped" runbook. None of it requires new headcount – mostly configuration, keys, and discipline – and every control does double duty as sales collateral. You sell security for a living; the first client is you. --- ## Security Awareness Training ## Definition Security awareness training (SAT) is recurring, managed education that teaches client employees to recognize and report attacks – [phishing](/wiki/glossary/phishing), credential theft, and payment fraud – paired with simulated phishing campaigns that measure clicks, reports, and changes over time. Modern platforms automate enrollment, short lessons, scheduled simulations, assignments, and reporting. **[Acronis Security Awareness Training](https://www.acronis.com/en/products/cloud/cyber-protect/security-awareness-training/)** is an MSP-focused option managed through Acronis Cyber Protect Cloud. Other options include KnowBe4 (roughly $20–25/user/year at small-business tiers), Breach Secure Now, usecure, and Huntress SAT. ## Why it matters to an MSP Insurers now list SAT among the standard minimum controls on cyber-insurance applications – alongside MFA, EDR, and tested backups – so clients need it whether or not they want it, and platform reports give you documented evidence to support renewal attestations. The economics can support a bundled add-on. Point-product COGS commonly runs roughly $1–2/user/month, while Acronis pricing is quote-based. Confirm the actual per-user cost, minimum commitment, and administration time before setting a $25–50/user security-tier price. It also generates client-facing proof of value – phish-prone percentages trending down are great QBR material. One caution: training reduces human error, never eliminates it. It complements [MFA](/wiki/glossary/mfa), email security, and the finance-process controls that stop [BEC](/wiki/glossary/bec); it doesn't replace any of them. Related terms: [Phishing](/wiki/glossary/phishing), [BEC](/wiki/glossary/bec), [Cyber Insurance](/wiki/glossary/cyber-insurance) --- ## Shadow IT ## Definition Shadow IT is any application, service, or device employees use for work without IT's knowledge or approval – the marketing team's unsanctioned Dropbox, a personal ChatGPT subscription processing customer data, a department SaaS tool bought on a credit card, an unmanaged home PC syncing company files. It's rarely malicious; it's employees routing around friction – which is exactly why it accumulates silently in every SMB. ## Why it matters to an MSP Every shadow app is data outside the security perimeter you're paid to defend: no [MFA](/wiki/glossary/mfa) enforcement, no backup, no offboarding (departed employees keep access), no visibility during incident response, and unknown compliance exposure when regulated data lands in it. There's a licensing and cost angle too: duplicate subscriptions, unlicensed use, and SaaS spend nobody tracks or budgets. Discovery requires several data sources. **[Acronis RMM](https://www.acronis.com/en/products/cloud/cyber-protect/rmm-solution/)** uses Device Sense and hardware and software inventory to identify unmanaged devices and locally installed applications. DNS-filtering logs, including DNSFilter, show cloud-service domains users access. Microsoft 365 sign-in and OAuth consent logs show which third-party applications can reach company data, while [network monitoring](/wiki/glossary/network-monitoring) identifies other unmanaged traffic. Combine these sources because none provides a complete shadow-IT inventory alone. A shadow-IT report is a strong assessment finding and QBR artifact because it makes invisible risk concrete to a business owner. The fix is governance, not prohibition: sanction the tools people genuinely need, put them behind [SSO](/wiki/glossary/sso), fold them into onboarding and offboarding checklists, and give the client a lightweight approval path so the next tool comes to you first. Related terms: [SSO](/wiki/glossary/sso), [IAM](/wiki/glossary/iam), [Network Monitoring](/wiki/glossary/network-monitoring) --- ## SLA (Service Level Agreement) ## Definition A service level agreement is the contractual attachment to a managed services agreement that defines what you support, the measurable targets you commit to – above all response time by ticket priority – and the remedy the client receives when you miss. It differs from an [SLO](/wiki/glossary/slo): an SLO is an objective you measure and report, while an SLA is a promise with a penalty attached. ## Why it matters to an MSP The SLA is where your help desk stops being a best effort and becomes an enforceable obligation. The key distinction is response versus resolution. Response – a technician acknowledges the ticket and starts work within a set window, typically 15–30 minutes for a P1 outage and four to eight business hours for a P4 request – is under your control and belongs in the contract. Resolution depends on vendors, parts, and client cooperation, so treat it as a published target you report on, not a guarantee; commit to resolution times and you're in breach every time a carrier is slow. Priority is yours to assign, not the client's, and an active security incident is a P1 under any sane matrix. Remedies are normally service credits of 5–20% of the monthly fee, applied automatically and written as the sole and exclusive remedy – the clause that keeps a missed response from becoming a damages claim. Measure attainment in the [PSA](/wiki/glossary/psa), with the clock paused while a ticket waits on the client, and show the numbers at every [QBR](/wiki/glossary/qbr). Publish business-hours targets you can hit in your worst week, and sell true 24/7 as a premium tier only once you have the staff. The full priority matrix and contract language are in [SLA design](/wiki/sla-design). Related terms: [SLO](/wiki/glossary/slo), [Escalation](/wiki/glossary/escalation), [PSA](/wiki/glossary/psa), [First Call Resolution](/wiki/glossary/first-call-resolution) --- ## SLO (Service Level Objective) ## Definition A Service Level Objective (SLO) is an internal, measurable target for one aspect of service – for example, 90% of priority-3 tickets resolved within two business days, or [endpoint](/wiki/glossary/endpoint) patch compliance above 95% within 14 days of release. It is what you aim for and report on. An [SLA](/wiki/glossary/sla) is what you promise in a contract, with consequences if you miss it. ## Why it matters to an MSP Most MSPs write their SLA as a wish list and then guarantee things they cannot control. Resolution time is the classic example: how long a fix takes depends on the vendor, the client's willingness to reboot, and whether the problem is reproducible. Promise a four-hour resolution in the contract and you have handed the client a credit every time a third party is slow. The cleaner design, covered in [SLA design](/wiki/sla-design), puts response times – the part you control – into the SLA and turns resolution times, patch compliance, backup success, and uptime into SLOs you publish and track. The practical differences: an SLO can be more aggressive than anything you would commit to contractually, because missing it costs a conversation rather than a credit. It can be tightened quarterly as the team matures without touching the contract. It can differ by client tier without splitting the desk. And it is the right unit for managing people: technicians can be coached against an SLO; nobody can do anything about an SLA credit after the fact. Report SLO performance to clients in the [QBR](/wiki/glossary/qbr) alongside SLA attainment. A desk hitting 88% against a 90% SLO while meeting 99% of contractual response commitments is a healthy desk. One with SLAs only, all reading 100%, has usually set the bar low enough to guarantee. Related terms: [SLA](/wiki/glossary/sla), [Escalation](/wiki/glossary/escalation), [First Call Resolution](/wiki/glossary/first-call-resolution) --- ## SOC 2 ## Definition SOC 2 is an attestation report, defined by the AICPA, in which an independent CPA firm examines a service organization's controls against five Trust Services Criteria – security (mandatory), availability, processing integrity, confidentiality, and privacy. A Type I report tests whether controls were designed correctly at a point in time; a Type II tests whether they operated effectively over an observation window, typically 3–12 months. It is not a certification and not a law: the deliverable is a report you share with buyers under NDA. ## Why it matters to an MSP Nobody is required to have SOC 2 – it is demanded. The requests come from enterprise procurement and vendor-risk teams reviewing your clients as suppliers, and increasingly from your own larger prospects and [cyber insurance](/wiki/glossary/cyber-insurance) carriers asking the same of you. That creates two lines of work. Helping a client reach it is high-stickiness [compliance](/wiki/glossary/compliance) revenue: you implement and evidence controls you mostly deploy anyway – [MFA](/wiki/glossary/mfa), [EDR](/wiki/glossary/edr), backup, logging, offboarding – and the CPA firm audits them. Getting your own is a sales asset that closes deals a competitor without one cannot bid on. Budget honestly for the latter: a small MSP typically spends $20,000–$50,000 in the first year – a compliance-automation platform and readiness work at $5,000–$20,000, plus an audit fee of $10,000–$30,000 for a Type II from a mid-size firm – and roughly half that annually to renew. Timeline is 6–12 months from kickoff to a Type II report, since the observation window alone is at least three months. Skip straight to Type II if you can wait; sophisticated buyers discount a Type I. See how it compares with other frameworks in [compliance frameworks comparison](/wiki/compliance-frameworks-comparison). Related terms: [Compliance](/wiki/glossary/compliance), [Cyber Insurance](/wiki/glossary/cyber-insurance), [CMMC](/wiki/glossary/cmmc) --- ## SOC (Security Operations Center) ## Definition A Security Operations Center (SOC) is the team and tooling that monitors security telemetry – endpoint, identity, email, network, cloud – around the clock, triages alerts, investigates suspicious activity, and contains confirmed threats. It is defined by continuous human coverage, not by a product: an [EDR](/wiki/glossary/edr) or SIEM console with nobody watching it at 3 a.m. is not a SOC. ## Why it matters to an MSP The question is never whether clients need SOC coverage – [ransomware](/wiki/glossary/ransomware) crews deliberately work nights and weekends because that is when nobody is watching – but whether to build one or buy one. The staffing math settles it for most shops. One seat covered 24/7/365 is 8,760 hours; at roughly 1,800 productive hours per analyst that is about five people per seat before vacation and turnover. A minimum-viable SOC needs two analysts on shift plus a lead and someone tuning detections, which is why in-house builds land at roughly 8–12 analysts and typically $1M+ per year fully loaded – before SIEM licensing and before the year it takes to make the detections useful. Few MSPs under $10M in revenue can justify it. The buy option is SOC-as-a-service, typically sold as [MDR](/wiki/glossary/mdr): a vendor's analysts monitor your clients' EDR and identity telemetry and either alert your team or take containment actions under agreed rules. Typical cost is $3–15 per [endpoint](/wiki/glossary/endpoint) per month, resold inside your security tier at 2–3x. That gives you 24/7 coverage, a defensible answer on [cyber insurance](/wiki/glossary/cyber-insurance) applications, and a named party who was watching when something happened. You still own the response: the on-call path, the client communication plan, and the [runbook](/wiki/glossary/runbook) that says who isolates what. See [MSP security operations](/wiki/msp-security-operations) for how to structure that around an outsourced SOC. Related terms: [MDR](/wiki/glossary/mdr), [EDR](/wiki/glossary/edr), [NOC](/wiki/glossary/noc) --- ## SOP (Standard Operating Procedure) ## Definition A standard operating procedure (SOP) is a written, approved description of how your MSP performs a recurring activity – who does it, in what order, with what tools, and what "done" looks like. It differs from a [runbook](/wiki/glossary/runbook), which is a technical fix script for a specific ticket type ("printer offline at client X"); an SOP governs a business or operational process that spans tickets – onboarding a client, offboarding a user, handling a security alert. ## Why it matters to an MSP An MSP without SOPs runs on the owner's memory, and the owner's memory does not scale, take vacations, or survive a hire. SOPs are what make a first technician productive in weeks instead of months: they follow the procedure for a new-user request instead of asking you, and the output is the same either way. Clients buy a managed service because it is repeatable, and an SOP is the only evidence that it is. A documented process cuts labor hours per instance (a client onboarding that takes 40 hours ad hoc typically drops to 15–25 with a checklist), reduces rework from skipped steps, and lets you push work down to cheaper tiers. SOPs are also audit and insurance artifacts: [SOC 2](/wiki/glossary/soc-2), [CMMC](/wiki/glossary/cmmc), and [cyber insurance](/wiki/glossary/cyber-insurance) questionnaires ask for documented procedures for access, patching, backup verification, and incident handling – "we just know how" does not pass. Keep them short – one page where possible – with an owner and a review date. Store them in your documentation platform, link them to the ticket types or [PSA](/wiki/glossary/psa) workflows that trigger them, and revise them when a process fails: a postmortem that does not update an SOP has not finished. Conventions for naming and structure are in the [documentation standards](/wiki/msp-documentation-standards). Related terms: [Runbook](/wiki/glossary/runbook), [PSA](/wiki/glossary/psa), [SOC 2](/wiki/glossary/soc-2) --- ## SSO (Single Sign-On) ## Definition Single sign-on lets a user authenticate once with a central identity provider – in an SMB, usually Microsoft Entra ID or Google Workspace – and then reach every connected application without separate passwords, using standards such as SAML and OpenID Connect. The application trusts the identity provider's assertion instead of keeping credentials of its own. ## Why it matters to an MSP SSO is the mechanism that makes [IAM](/wiki/glossary/iam) policy enforceable. Every application connected to the identity provider inherits its [MFA](/wiki/glossary/mfa), conditional access, and device-compliance rules automatically, so you configure security once instead of app by app, and disabling one account cuts off every connected service at the same moment – the only reliable way to make employee offboarding complete. Without it, each SaaS tool is an island with its own password, its own MFA setting (usually off), and an account that outlives the employee – which is how [shadow IT](/wiki/glossary/shadow-it) persists and how a forgotten login becomes the entry point for a [BEC](/wiki/glossary/bec) incident. The answer to shadow IT is not prohibition but putting sanctioned tools behind SSO, where they're visible and governed. Password resets typically make up 20–30% of help desk ticket volume, and SSO with self-service reset removes most of them. Microsoft 365 Business Premium includes Entra ID P1, so conditional access and SSO to thousands of gallery apps are usually already licensed. The catch is the "SSO tax": many SaaS vendors gate SAML support behind enterprise tiers that can double per-seat cost, so audit the client's application list before promising everything goes behind SSO. [Cyber insurance](/wiki/glossary/cyber-insurance) questionnaires now ask whether MFA covers all cloud applications; SSO is how you answer yes honestly. For the full design, see [identity and access for SMB](/wiki/identity-and-access-for-smb). Related terms: [IAM](/wiki/glossary/iam), [MFA](/wiki/glossary/mfa), [Shadow IT](/wiki/glossary/shadow-it), [Zero Trust](/wiki/glossary/zero-trust) --- ## Technical Account Manager ## Definition A Technical Account Manager (TAM) is a named point of contact assigned to a client account who owns the technical relationship: tracking open issues, coordinating projects, reviewing environment health, and translating between the client's staff and the MSP's service desk and engineers. The role sits between the account manager who sells and the technicians who fix. ## Why it matters to an MSP Small MSPs run their [QBRs](/wiki/glossary/qbr) through a [vCIO](/wiki/glossary/vcio) – usually the owner or a senior engineer wearing that hat. The distinction matters around 30–40 managed clients or 1,500 seats, when the owner can no longer hold every environment in their head. The vCIO works at the strategy layer: budget, roadmap, risk, the three-year technology plan. The TAM works at the delivery layer: why the migration slipped, which recurring ticket pattern needs a root-cause fix, whether the client is using the licenses they pay for, what the next 90 days of project work look like. A vCIO who is also doing that operational follow-up stops being strategic; a TAM without a vCIO produces well-run accounts with no growth conversation. The economics are straightforward. A TAM carries 20–40 accounts and typically costs $80–110K fully loaded – treat it as overhead at roughly 3–5% of the revenue it protects. The return shows up in [churn rate](/wiki/glossary/churn-rate): clients rarely leave because a ticket was slow; they leave because nobody seemed to own their account. In a larger shop the TAM also runs the [QBR process](/wiki/qbr-process) day to day, collecting ticket trends, project status, and open risks that the vCIO then frames as decisions. Under that size, do not hire a TAM – give the owner the vCIO role and make one senior technician the named technical owner for each account. Related terms: [vCIO](/wiki/glossary/vcio), [QBR](/wiki/glossary/qbr), [Churn Rate](/wiki/glossary/churn-rate) --- ## Technology Stack ## Definition An MSP's technology stack is the fixed set of tools and platforms it standardizes on and deploys to every client: the [RMM](/wiki/glossary/rmm), [PSA](/wiki/glossary/psa), documentation platform, [EDR](/wiki/glossary/edr), email security, backup, identity, firewall line, and the reference configurations for each. By extension it also means the client-side environment the MSP will support – the operating systems, productivity suite, and line-of-business applications it knows well. ## Why it matters to an MSP Standardization is where margin comes from, and it is the practical reason to pick a niche. One firewall model means one set of [runbooks](/wiki/glossary/runbook) and one firmware schedule instead of six. One EDR means technicians know every alert on sight and [first-call resolution](/wiki/glossary/first-call-resolution) climbs. One backup platform means daily job review takes twenty minutes across all clients instead of two hours across five consoles. Every exception is a snowflake that costs labor hours forever: a client on a non-standard stack typically consumes 30–50% more technician time per seat than a standard one, which is why mature MSPs either charge a documented premium for exceptions or decline them. A vertical niche multiplies the effect. Twenty dental practices run the same practice-management software, imaging system, and integration quirks, so the reference build, onboarding checklist, and troubleshooting knowledge transfer client to client and the twenty-first onboarding is faster and cheaper than the first. Twenty clients in twenty industries mean twenty stacks, twenty vendor relationships, and no learning curve. Standardization also concentrates purchasing: more seats with fewer vendors earns better tier pricing and real support relationships. The discipline is saying no – new tools enter the stack through a deliberate evaluation, not because a client asked. Which tools to standardize on, and in what order, is covered in [the MSP tool stack](/wiki/msp-tool-stack). Related terms: [RMM](/wiki/glossary/rmm), [PSA](/wiki/glossary/psa), [Runbook](/wiki/glossary/runbook), [SOP](/wiki/glossary/sop) --- ## Ticketing System ## Definition A ticketing system is the software that records every unit of work the service desk does – requests, incidents, alerts, project tasks – as a ticket with a requester, a client, a priority, a status, time entries, and a history of everything done. For most MSPs it is the ticket module of the [PSA](/wiki/glossary/psa), not a standalone product; the PSA's contracts, billing, and reporting hang off the tickets. ## Why it matters to an MSP The ticketing system is the only source of truth about what your business does. Utilization, [first-call resolution](/wiki/glossary/first-call-resolution), tickets per [endpoint](/wiki/glossary/endpoint) per month, which client consumes three times the hours its [MRR](/wiki/glossary/mrr) justifies, whether a technician is drowning – all of it comes from tickets, and only if the tickets are complete. The rule that runs a healthy desk is "if it is not in a ticket, it did not happen." A desk that captures 80% of its work reports on a business that does not exist, and every decision made on that report is wrong by an unknown amount. What it must capture for the reporting to work: client and contact; a type and category you can trend on; priority set by a rule rather than a mood; a status that means something (new, in progress, waiting on client, waiting on vendor, resolved); time entries with notes a colleague could pick up from; and a link to the configuration item involved. [RMM](/wiki/glossary/rmm) alerts should create tickets automatically, and support email should never be answered outside one. The system also enforces your process. [SLA](/wiki/glossary/sla) timers, [escalation](/wiki/glossary/escalation) rules, and client-facing status updates all run from ticket fields. Setting those up is the subject of [ticket management process](/wiki/ticket-management-process); the tool matters far less than the discipline around it. Related terms: [PSA](/wiki/glossary/psa), [RMM](/wiki/glossary/rmm), [Escalation](/wiki/glossary/escalation), [First Call Resolution](/wiki/glossary/first-call-resolution) --- ## Ticket Management Process ## The one rule: every channel terminates in a ticket If it's not in a ticket, it didn't happen. Every intake channel – email, phone, portal, walk-up, a text to a tech's cell – must end in a ticket in your [PSA](/wiki/glossary/psa). The standard intake set is **email-to-ticket**, a **client portal**, and **phone**. Progressive MSPs push portal or agent-tray submission because it captures triage-quality data (user, machine, category) at intake – but never remove email and phone; you meet clients where they are and convert the request into a ticket yourself. Everything else in this process – [SLA](/wiki/glossary/sla) measurement, profitability analysis, staffing decisions – is built on this rule. A [ticketing system](/wiki/glossary/ticketing-system) that captures 80% of the work reports on a business that doesn't exist. ## Roles - **Dispatcher / service coordinator** – once you're past roughly 3–4 technicians, appoint one. The dispatcher owns priority assignment, scheduling, and the SLA clocks, so engineers execute instead of self-selecting the easy tickets from the queue. Two working models: a dedicated dispatcher, or a rotating intake/triage tech. Before that size, the founder or service lead owns triage at fixed times each day. - **Engineers (T1–T3)** – work what's assigned, log time as they go, escalate on the time-box (below). ## The ticket lifecycle 1. **Intake.** The request arrives via any channel and becomes a ticket before work starts. 2. **Triage.** The dispatcher sets priority by impact × urgency per your published [SLA matrix](/wiki/sla-design), and sets type/subtype from a standardized taxonomy. Inconsistent categorization makes ticket-count and trend reports useless – the taxonomy is small, fixed, and enforced. 3. **Dispatch.** Assign by tier and schedule. The dispatcher, not the engineer, owns the SLA clock. 4. **Work.** Notes and time entries go in as the work happens. Known issues should have a [runbook](/wiki/glossary/runbook) linked to the ticket type, per your [documentation standards](/wiki/msp-documentation-standards). 5. **Wait honestly.** "Waiting on Customer" and "Waiting on Vendor" pause the SLA clock – essential for honest metrics, and the difference between measuring yourself and measuring your clients' reply speed. 6. **Resolve, then close.** Resolved means the fix is delivered with a resolution note; Closed follows after client confirmation or a defined aging window. Keep statuses minimal: | Status | Meaning | SLA clock | |---|---|---| | New | Logged, not yet triaged | Running | | Assigned / In Progress | Owned by a tech | Running | | Waiting on Customer | Blocked on client response | Paused | | Waiting on Vendor | Blocked on third party | Paused | | Resolved | Fix delivered, pending confirmation | Stopped | | Closed | Confirmed or aged out | Stopped | Every extra status you invent is a place for tickets to hide. ## Escalation tiers | Tier | Handles | Notes | |---|---|---| | **T1** | Password resets, known issues, routine requests | Typically ~60–70% of volume; aims to fix at first touch ([first-call resolution](/wiki/glossary/first-call-resolution)) | | **T2** | Servers, networking, deeper diagnostics | Specialized skill sets | | **T3** | Senior engineering, projects, architecture | Scarcest and most expensive time – protect it | Define [escalation](/wiki/glossary/escalation) criteria by **time-boxing**, not by feel: for example, T1 escalates after 30 minutes stuck. Time-boxes stop ticket-hogging – the tech who sits on a ticket for half a day rather than admit they're stuck. Escalating on the time-box is following the process, not failing it, and it's the dispatcher's job to enforce that framing. ## Time entry: every minute logged Time logged against tickets is the only way to know cost-per-ticket, per-client profitability, and true agreement margins – it is literally how you answer "which client is eating my payroll?" The consensus antipattern across the industry is letting untracked work become the norm: a one-minute favor occasionally is fine, but systemic untracked work makes gross-margin analysis fiction. Enter time in real time, as the work happens – not reconstructed on Friday afternoon, when memory invents a flattering week. ## Kill the shoulder tap Undocumented walk-up and DM work destroys metrics, hides toxic clients, causes double work (the next tech has no history), and burns out your best technicians – the helpful ones absorb an invisible workload nobody staffs for. The standard script: help happily, but first – "let me open a ticket so this gets tracked." Clients train to the process within weeks. Apply the same rule internally: founders are the worst shoulder-tap offenders in most shops. ## Daily queue hygiene - **Morning (dispatcher):** triage everything new, assign owners, work the queue SLA-risk first. - **During the day:** confirm P1/P2 tickets are actually moving; chase stale "Waiting on Customer" items. - **End of day:** no untriaged tickets, no unassigned tickets, every tech's time entries complete. - **Weekly:** review aged tickets oldest-first, close out confirmed resolutions, spot-check taxonomy consistency. ## Metrics to watch - **Tickets per endpoint per month** – mature MSPs target below 1. Sustained high noise signals misconfigured environments, weak onboarding, or wrong-fit clients – not a need for more techs. - **First response time** – commonly targeted under one hour during business hours as of 2026; report attainment against SLA per priority, never a single blended average. - **SLA attainment** – honest only if waiting states pause the clock. - **CSAT and NPS** – [Acronis PSA](https://www.acronis.com/en/products/cloud/cyber-protect/psa-solution/) can send customer surveys and report NPS through its service desk; Simplesat is a dedicated option for per-ticket CSAT. Track the metrics separately because they measure different questions. ScalePad's 2025 trends research links high CSAT with retention. - **Time logged vs. hours worked** – the discipline metric that makes every other metric trustworthy. Benchmarks and targets for these live in [MSP KPIs and benchmarks](/wiki/msp-kpis-and-benchmarks). ## Exit criteria You know the process is working when: - No work reaches a technician without a ticket, from any channel, including the founder's. - Every ticket has a priority, type, and owner by the end of morning triage. - Escalations happen on the time-box, not after a day of quiet struggling. - Time entries are same-day, and your agreement-margin reports are believable enough to price from. - Queue reviews are boring – which is exactly what you want. --- ## Value-Based Pricing ## Definition Value-based pricing sets the fee for a managed service according to what it is worth to the client – avoided downtime, reduced breach and compliance exposure, the IT hire they do not make – rather than the MSP's cost of tools and labor plus a markup. ## Why it matters to an MSP Cost-plus systematically underprices because it ignores the risk you absorb: a fixed-fee contract transfers ransomware recovery, outage response, and audit exposure from the client to you, and none of that shows up in a tool-cost spreadsheet. Value-based pricing is how you get paid for it. It starts with discovery numbers you should be collecting anyway – revenue per hour, headcount, regulated data, what a day of downtime costs. A 40-person firm losing $8,000 an hour when its systems are down will not compare a $220 seat to a $120 seat the way a commodity buyer does. This is why it works best in a defined vertical: a healthcare, legal, or defense-contractor client has a concrete, quantifiable exposure, while a general "small business" pitch collapses into seat-price shopping. The discipline most established shops use, consistent with [MSP pricing models](/wiki/msp-pricing-models), is to compute a cost-plus floor at a 70% gross margin target and then quote above it on value – cost-plus sets the minimum, value sets the ask. The catch is that value decays if it is not re-proved. Twelve months in, the client remembers the invoice and forgets the incident that did not happen, so the [QBR](/wiki/glossary/qbr) becomes part of the pricing model: tickets prevented, patch and backup evidence, and a plain-language line on what the same period would have cost unmanaged. Skip that and renewal reverts to per-seat comparison. Related terms: [Per-Seat Pricing](/wiki/glossary/per-seat-pricing), [Per-Device Pricing](/wiki/glossary/per-device-pricing), [QBR](/wiki/glossary/qbr), [MRR](/wiki/glossary/mrr) --- ## vCIO (Virtual CIO) ## Definition A vCIO (virtual chief information officer) is the role, usually filled fractionally by the MSP, that owns a client's technology strategy: the multi-year roadmap, the annual IT budget, vendor and lifecycle decisions, and the [QBR](/wiki/glossary/qbr) where those are reviewed with the client's leadership. It is distinct from a [vCISO](/wiki/glossary/vciso), which owns the security program, risk register, and compliance posture. The vCIO decides where the business's technology is going; the vCISO decides how much risk it is allowed to carry on the way. ## Why it matters to an MSP The vCIO function is the difference between vendor and advisor, and it shows up in retention and revenue. Clients who get a roadmap and a budget forecast every quarter rarely leave over price, because you explained the price; clients who only see you at ticket time churn without warning. It is also where project revenue comes from – a roadmap with a hardware refresh, a migration, and a security uplift across eight quarters is a pipeline the client has already agreed to in principle. Under about 300 managed seats the vCIO is the owner, and the practical minimum is a quarterly meeting per client with three artifacts: a roadmap, a 12-month budget forecast, and a scorecard of what was delivered last quarter. Budget two to four hours of preparation per client per quarter. A dedicated vCIO typically carries 25–40 accounts, and larger shops hand the relationship side to a [technical account manager](/wiki/glossary/technical-account-manager). Bundle it into every plan or sell it as a tier or retainer, typically $500–$2,000 per month for small accounts and several thousand for larger ones. Either way it belongs in the [service catalog](/wiki/msp-service-catalog) as a named deliverable with a cadence, not a favor for clients you like. Service design is covered in [vCIO service design](/wiki/vcio-service-design). Related terms: [QBR](/wiki/glossary/qbr), [vCISO](/wiki/glossary/vciso), [Technical Account Manager](/wiki/glossary/technical-account-manager) --- ## vCISO (Virtual CISO) ## Definition A vCISO (virtual chief information security officer) is a fractional executive role that owns a client's security program: the risk register, the policy set, the [compliance](/wiki/glossary/compliance) posture against whatever framework applies, and decision authority during an incident. It is distinct from a [vCIO](/wiki/glossary/vcio), which owns technology strategy, roadmap, and budget. The vCIO decides what the business builds; the vCISO decides what risk it accepts, which controls are mandatory, and who is in charge when something goes wrong. ## Why it matters to an MSP Most SMBs cannot justify a full-time CISO, but more are being asked for one – by a [cyber insurance](/wiki/glossary/cyber-insurance) questionnaire, a customer's vendor-security review, or a [CMMC](/wiki/glossary/cmmc) or [SOC 2](/wiki/glossary/soc-2) auditor asking who owns the program. That creates a service line with different economics: it is billed as advisory, typically $1,500–$5,000 per month for an SMB, and carries little tooling cost because the deliverables are policies, risk assessments, control reviews, leadership reporting, and tabletop exercises, not agents and licenses. It sits above [compliance as a service](/wiki/compliance-as-a-service): that work collects evidence; the vCISO interprets it and decides what to do about the gaps. The risk sits on your side. A vCISO signs off on the client's posture, so a breach after a documented "accepted risk" is a conversation with lawyers. The role needs errors-and-omissions coverage, an engagement letter that separates advice from operations, and a person with real security judgment – not a technician with a new title; small MSPs often partner with an independent vCISO rather than staffing it. Conflict of interest matters: if the same team runs the controls and grades them, an auditor will discount the assessment, so keep the vCISO's reporting separate from operations. How the two roles fit together is in [vCIO service design](/wiki/vcio-service-design). Related terms: [vCIO](/wiki/glossary/vcio), [Compliance](/wiki/glossary/compliance), [Cyber Insurance](/wiki/glossary/cyber-insurance) --- ## Vendors, Distributors, and the Channel ## How a new MSP actually buys You will not buy most of your stack directly from the vendors whose logos are on it. The channel sits in between: distributors aggregate hundreds of vendors into one catalog, one bill, and one partner agreement, and almost every small [MSP](/wiki/glossary/msp) buys the bulk of its licensing that way. The distributors that matter for a new shop as of 2026 are Pax8, Sherweb, Ingram Micro, and TD Synnex. Pax8 and Sherweb are the MSP-native favorites – Pax8 built its reputation on a broad marketplace and billing automation, Sherweb on Microsoft-heavy hands-on support and historically strong margin splits. Ingram Micro and TD Synnex are the traditional broadline distributors, stronger on hardware and enterprise vendors. Direct vendor programs come into play for your core operating tools – your [RMM](/wiki/glossary/rmm), [PSA](/wiki/glossary/psa), and [EDR](/wiki/glossary/edr) are usually direct relationships – and for anything you resell at real volume. The practical pattern: one primary distributor for licensing and the long tail, direct agreements for the handful of tools that define your service delivery. See [the MSP tool stack](/wiki/msp-tool-stack) for what belongs in that core. **[Acronis Cyber Partner Program](https://www.acronis.com/en/partners/)** is a useful example of how partner access and product economics differ. Joining the program has no entry fee or minimum revenue requirement. Approved partners can receive portal access, training, evaluation licenses, deal registration, support, and tier-based incentives. Product licensing is separate: Acronis Cyber Protect Cloud uses account-specific pricing and commitment tiers, while distributor terms may differ. Request direct and distributor quotes, then compare the minimum monthly invoice, included services and storage, support path, incentive conditions, and exit terms. ## The Microsoft CSP program Microsoft licensing is the anchor tenant of your vendor relationships. Under the [CSP program](/wiki/glossary/csp-program), almost all small MSPs operate as *indirect resellers*: the distributor holds the direct Microsoft relationship, gives you a discount off Microsoft MSRP, and you resell to the client at MSRP or a small markup while administering the tenant. **The margin is thin.** Gross margin on M365 licensing runs roughly 6–20%, most commonly **8–16%**, depending on distributor tier, volume, and whether you mark up over MSRP. Published audit examples land around 10% before labor on Business Standard and about 8% before labor on E3 – and "before labor" matters, because billing reconciliation and license administration eat a real slice of it. Do not build your business plan on license margin as profit. **So why resell at all?** Because the license relationship is strategic, not financial: - **Control.** You administer the tenant, so support is cleaner and offboarding friction protects the relationship. - **Stickiness.** Owning the billing relationship raises the client's switching costs. - **It feeds your all-in seat price.** Licenses folded into one per-seat number support the packaging described in [MSP pricing models](/wiki/msp-pricing-models). - **Portfolio pricing.** Distributor marketplaces bundle the rest of the stack – security, backup – at partner pricing. - **Defense.** A client buying licenses elsewhere has invited another advisor into the account. ## NCE commitment terms and traps Microsoft's New Commerce Experience (NCE) is where new CSP resellers get hurt. The terms as of 2026: | Term | Price | Flexibility | |---|---|---| | Monthly | ~20% premium over annual | Reduce or cancel seats month to month | | Annual | Baseline | Seat count locked for the term – you can add, not reduce | | 36-month | Lowest | Same lock, three years long | After purchase you get a **7-day (168-hour) window** to cancel or modify; after that, the commitment stands for the full term. As of April 2025, Microsoft also added a roughly 5% surcharge for annual-term subscriptions billed monthly. The trap: *you*, the reseller, own the commitment to the distributor. If a client on annual-term licenses lays off a third of their staff in month four, Microsoft still expects payment on every committed seat – and unless your paperwork says otherwise, that's your bill. Two defenses: 1. **Match commitments.** Put language in your agreement making the client contractually own any annual license commitments placed on their behalf – see [MSP contracts and the MSA](/wiki/msp-contracts-and-msa). 2. **Split terms deliberately.** The standard pattern is annual term for the stable seat base (capturing the ~20% saving) and monthly term for seasonal or volatile seats, with the premium passed through. ## Hardware resale: convenience, not profit Hardware margins are thin – mid-single-digit to roughly 10–15% on SMB gear as of 2026 – and getting thinner against Dell, Amazon, and CDW price transparency. Any client can check your quote against a public price in thirty seconds, so quoting fat markups on commodity hardware erodes trust for a few hundred dollars. Most MSPs therefore treat hardware as a procurement service: cost plus a fixed markup or a flat procurement fee, quoted transparently, with the real money made on deployment labor – imaging, configuration, migration, disposal. Quote the box near market and price the project work properly. Deal registration on larger infrastructure deals (see below) improves this, but for day-to-day refreshes, convenience pricing is the durable model. ## HaaS: read the cash-flow warning first [HaaS](/wiki/glossary/haas) – bundling hardware into the monthly seat price – is regularly pitched to MSPs as an untapped opportunity. **Pros:** raises [MRR](/wiki/glossary/mrr) and your all-in seat price; guarantees refresh cycles, and a standardized fleet is genuinely cheaper to support; turns the client's CapEx into an OpEx pitch; deepens lock-in. **Cons:** **you front the capital.** For a new MSP without reserves that is a serious cash-flow strain – you buy the laptop today and recover it over 36 months. Add asset-tracking overhead, clients mistreating gear they don't own, and the ugly scenario where non-payment leaves you repossessing laptops. You have become a leasing company, with residual-value and default risk to match. **Best fit:** established MSPs with cash reserves and a standardized client base. The common advice for new founders is to skip HaaS early, or use third-party financing so the balance-sheet risk isn't yours. Factor this into [startup cost planning](/wiki/msp-startup-costs) before promising it in a proposal. ## Lock-in vs multi-vendor bargaining power The channel is consolidating – platform vendors keep acquiring tools, communities, and events (Kaseya alone absorbed TruMethods, Robin Robins' Technology Marketing Toolkit in July 2025, and DattoCon after 2025). Single-platform stacks buy integration and one bill; the cost is reduced bargaining power and exposure to one vendor's pricing decisions and roadmap. A pragmatic middle path for a small shop: consolidate where integration genuinely saves labor (PSA + RMM), keep at least the security and backup layers portable, and never sign a multi-year tool commitment you couldn't migrate away from in a quarter. Your distributor relationship also affects your buying power – volume concentrated with one distributor earns better splits and support attention. ## Evaluating a vendor's MSP program Before signing any partner agreement, check: - **Partner pricing model.** Real wholesale discount, or MSRP with a rebate you'll never collect? - **Minimums.** Monthly spend or seat minimums can quietly exceed what your client base supports. A minimum you can't cover is a subscription you pay for. - **Deal registration.** Does registering an opportunity protect your margin against the vendor's other partners (and their direct sales team)? - **NFR licenses.** Not-for-resale licenses for internal use let you run the product in your own shop before betting clients on it. - **Monthly billing and no long lock-in.** MSP-friendly vendors bill monthly per unit and let you flex down; enterprise-style annual prepay is a red flag at your size. - **Support and escalation.** When the tool breaks at a client, you own the incident – how fast can you reach a human? Community sentiment is the best due diligence: pricing and support experiences get discussed candidly in the venues covered in [MSP communities and learning resources](/wiki/msp-community-resources). ## Managing vendor sprawl Every conference booth and cold email adds a candidate to your stack, and each vendor added means another bill to reconcile, another portal, another breach-notification surface, another renewal date. Keep it controlled: - Maintain a one-page vendor list – product, cost, renewal date, term, owner – as part of your [documentation standards](/wiki/msp-documentation-standards). - Review it quarterly; cut anything not earning its line. - Standardize one product per function across all clients. Two backup products means two sets of runbooks and double the ways to fail. - Concentrate purchases with your primary distributor for one bill and better splits. ## Bottom line Pick one MSP-native distributor and make it your default. Resell M365 for control and stickiness, not the 8–16% margin, and never carry an NCE annual commitment your client hasn't contractually matched. Treat hardware as a fee-based procurement service, skip HaaS until you have real reserves, and hold every vendor program to the same test: partner pricing, monthly flexibility, no minimums you can't cover. The channel rewards MSPs who buy deliberately – and quietly taxes everyone else. --- ## Vulnerability Management ## Definition Vulnerability management is the continuous cycle of discovering assets, scanning them for known weaknesses (missing patches, end-of-life software, misconfigurations, exposed services), prioritizing findings by severity, exploitability, and asset criticality, remediating them, then verifying and reporting the results. It differs from [patch management](/wiki/glossary/patch-management), which is one remediation mechanism inside it: patching applies vendor fixes on a cadence, while vulnerability management finds what patching misses – unpatchable legacy systems, configuration flaws, unknown devices, third-party apps outside your patch tooling – and proves with scan data that the whole loop is actually closing. ## Why it matters to an MSP It has shifted from enterprise luxury to SMB baseline: insurers now list a patch/vulnerability-management cadence among the standard minimum controls for insurability, and the frameworks MSPs sell against – [CIS Controls](/wiki/glossary/cis-controls), HIPAA's proposed Security Rule update, CMMC – all expect it. As a service line the economics are attractive: scanning is largely automatable, the differentiated labor is prioritization and remediation, and it produces exactly the artifacts clients need – vulnerability trend reports for QBRs, evidence for [cyber insurance](/wiki/glossary/cyber-insurance) renewals, and findings that justify project work like server replacements and network upgrades. It's typically sold inside a $25–50/user/month security add-on tier rather than à la carte. Start internally: scan your own MSP first, since a breached provider is a supply-chain incident for every client. Related terms: [Patch Management](/wiki/glossary/patch-management), [Penetration Testing](/wiki/glossary/penetration-testing), [Cyber Insurance](/wiki/glossary/cyber-insurance) --- ## What It Really Costs to Start an MSP ## The honest range: $10k–$50k all-in The commonly cited figure for launching an MSP is **$10,000–$50,000**, and a lean solo founder can genuinely start near the bottom of that range. The spread comes from a handful of decisions: - **Side-gig vs full-time jump.** Going full-time on day one means funding your salary from savings – by far the biggest line item (more below). - **Tool stack ambition.** Per-technician bundled tooling keeps month one under a few hundred dollars; signing per-endpoint contracts with minimum commitments before you have endpoints burns thousands. - **Legal and insurance depth.** Roughly $1,500–$5,000 for LLC filing plus attorney-drafted MSA/SOW templates, and typically $2,500–$6,000/yr for the insurance bundle – covered in detail in [legal setup and insurance](/wiki/msp-legal-and-insurance). - **Marketing spend.** $2,000–$10,000 in year one is typical (website, Google Business Profile, one-pagers, chamber/BNI dues) – the range depends on how much you do yourself. - **Hardware.** $1,000–$2,000 for a primary laptop plus a cheap test machine. A small homelab is optional but useful. If you're building as a side gig, use a separate laptop regardless – employers can claim IP created on their gear. First-year software alone typically lands at **$5,000–$20,000**, and certifications add $500–$2,000 (Security+ runs ~$400/exam, Microsoft role-based exams ~$165 each – worth noting that certs are staff-level credibility, not company-level; clients buy outcomes and compliance fluency more than acronyms). ## The minimum viable tool stack: $300–$800/mo A realistic solo month-one stack – [RMM](/wiki/glossary/rmm)/[PSA](/wiki/glossary/psa), EDR, backup, email security, and a password manager or documentation tool such as Hudu or IT Glue – runs **$300–$800/month** as of 2026. Compare three cost structures: | Model | Examples | Typical 2026 pricing | Best fit | |---|---|---|---| | Per-workload or solution bundle | [Acronis Cyber Protect Cloud](https://www.acronis.com/en/products/cloud/cyber-protect/pricing/) | Quote-based; RMM and security are typically licensed per workload, with commitment tiers | MSPs that want RMM, PSA, backup, and security managed through one console | | Per-technician, unlimited endpoints | Syncro, Atera | $129–$209/tech/month, RMM + PSA bundled | Solo founders and small teams with few technicians | | Per-endpoint | NinjaOne, Datto, N-able, Kaseya; SentinelOne or Bitdefender for EDR | ~$2.50/endpoint for RMM, ~$2/device for backup, and $3–$5/endpoint for EDR | MSPs whose endpoint volume makes this cheaper than per-technician licensing | **The trap to avoid:** minimum commitments and contracts sized for clients you do not yet have. Acronis and other platforms may use monthly commitment tiers, although distributor terms can differ. Compare the minimum invoice, per-workload or per-seat cost, included services, storage charges, and exit terms. Choose the lowest committed cost for your current client base, then switch models only when the actual workload math supports it. Full comparison in [the MSP tool stack](/wiki/msp-tool-stack). ## Personal runway: the cost nobody budgets The standard advice before going full-time: **6–12 months of personal living expenses banked**. This dwarfs every other startup cost, which is why the dominant founder path is side-gig first – keep the W-2, build nights and weekends, and jump when side income reaches a meaningful fraction of your salary (one survey found 57% of side-hustlers used ~75% of current salary as the bar) and the runway is in place. Keep business and personal reserves separate: on top of personal runway, hold **3+ months of business operating expenses** in the business account, because tool commitments and onboarding costs hit before client payments do. Bill monthly in advance from day one. ## What year one actually looks like Be sober about revenue. Established 1–4 person MSPs average roughly **$337k/yr** (Kaseya/Datto benchmark) – but those are mature shops with a built-out client base, useful only as a "where this goes" reference. For a cold start: - A **good** first year for a full-time solo founder is **$5k–$10k [MRR](/wiki/glossary/mrr) by month 12** – roughly $50k–$120k in total year-one revenue. Many land well below. - Only about **20% of solo founders clear $100k** in year one. - Full-timers progress **3–4x faster** than side-giggers – the side gig de-risks the jump, but it also slows the build. - The solo/small-team ceiling before specialized hires is typically **$1M–$1.5M ARR**. What you charge matters as much as how many clients you land – see [pricing models](/wiki/msp-pricing-models) before you quote anyone. ## The client break-even trap The number that surprises technical founders most: MSPs typically invest **$10,000–$15,000 per client in onboarding** – discovery, cleanup, standardization, documentation, tooling deployment, and the unbilled hours that go with all of it – and don't break even on a client until **months 7–12** of the relationship. Two consequences: 1. **Growth consumes cash.** Every client you sign makes the next few months *worse* before they get better. Budget for it. 2. **Bad-fit clients are expensive.** With a 7–12 month break-even, one client who churns early or fights every invoice can eat a quarter's profit. Taking every client is a classic first-year mistake – qualify hard, and run a disciplined [client onboarding process](/wiki/client-onboarding-process) to pull break-even earlier. ## What not to spend on early The consistent pattern in first-year budgets that go wrong: over-investing in the stack, under-investing in conversations. - **An office.** You're remote-first by the nature of the work, and early clients don't visit. Sign a lease when there's a team that needs it, not before. - **Branding agencies.** A clean self-built website and a Google Business Profile cover year one. Your first 10 clients will come from [warm referrals and hyper-local outreach](/wiki/first-msp-clients), not your logo. - **Enterprise tooling and long contracts.** No SIEM, no premium PSA tiers, no three-year commitments – the minimum viable stack above genuinely suffices until real client requirements force upgrades. - **Paid ads and SEO plays.** Both burn cash before your positioning exists; SEO is too slow to matter in year one. - **A certification collection.** One or two targeted certs, then stop – clients buy outcomes. ## A sample month-one budget A lean full-time solo launch, typical figures as of 2026: | Item | One-time | Monthly | |---|---|---| | LLC filing + registered agent | $150–$800 | – | | Attorney-drafted MSA/SOW templates | $1,000–$3,000 | – | | Insurance (GL + E&O + cyber, annualized) | – | $200–$500 | | RMM + PSA (per-tech bundle) | – | $129–$209 | | EDR, backup, email security, docs/password mgmt | – | $150–$400 | | Laptop + test machine | $1,000–$2,000 | – | | Website + Google Business Profile + one-pagers | $500–$2,000 | – | | Networking dues (chamber/BNI) | – | $50–$150 | | **Totals** | **~$2,650–$7,800** | **~$530–$1,260** | Add personal runway (6–12 months of living expenses) and a 3-month business operating reserve on top, and the widely cited $10k–$50k all-in range stops looking inflated – the low end is achievable, but only for a side-gig start with disciplined tooling choices. ## Bottom line Plan for $10k–$50k all-in, but understand the structure: a few thousand in one-time setup, $300–$800/mo in tooling, and the real cost – personal runway plus the cash that client onboarding consumes for 7–12 months per client. Start per-tech on tooling, avoid contracts and offices, bill in advance, and hold your quality bar on which clients you take. Before you spend anything, sketch the numbers into a simple plan – [writing an MSP business plan](/wiki/msp-business-plan) covers the model, and [how to start an MSP](/wiki/how-to-start-an-msp) covers the sequence. --- ## Writing an MSP Business Plan ## Why a lean operating plan beats a 40-page document Nobody is going to read your 40-page business plan – not a bank, not a partner, and within three months, not even you. Business-school plan templates are written for raising capital; an MSP is a cash-flow business you bootstrap. What you need is a **lean operating plan**: a short document (a few pages, or a spreadsheet plus one page of narrative) that states who you serve, what you sell, what it costs to deliver, and what has to be true for the numbers to work. The point of the plan is not prediction – it's *falsifiability*. Every section should contain assumptions specific enough that reality can prove them wrong, so you can correct course quarterly instead of discovering in month 18 that the model never worked. This matters more than it sounds: as of the most recent Service Leadership index (Q4 2024), **18% of MSPs ran at a loss**. Profitability is not automatic in this industry, and the difference is usually a model someone actually checks. ## The six sections that matter **1. Target market and niche.** Define who you serve tightly enough to build a list: industry, company size, geography. "SMBs in my metro" is not a target market; "law firms with 10–50 seats within 25 miles" is. You don't need to commit to a vertical on day one – the common advice is start generalist-local, notice which vertical accumulates, then lean in – but the plan should name your starting focus and the criteria for narrowing. Vertical specialization is a real economic lever: specialized MSPs report up to 30% higher margins and 20–40% premium rates, with regulated-vertical contracts running $200–$400+/user/mo versus the $100–$250 generalist norm. See [choosing a niche](/wiki/choosing-a-niche). **2. Service catalog and pricing.** List exactly what's in your managed offering, what's out of scope, and what each tier costs. Fixed-fee per-user pricing ($100–$250/user/mo is the typical national norm as of 2026; $70–$150 at the low end for basic stacks) with a defined catalog is the standard – hourly billing caps your income at your hours and attracts clients who fight every ticket. Work through [the service catalog](/wiki/msp-service-catalog) and [pricing models](/wiki/msp-pricing-models) before setting numbers. **3. Financial model: MRR and gross margin per service line.** Build the model on [MRR](/wiki/glossary/mrr), not projected total revenue. Recurring revenue is the business – it enables forecasting, hiring, and eventually valuation (managed-services recurring revenue is valued at roughly 4–6x annualized, project revenue at 0.5–1x). For each service line, model **gross margin**: price minus the direct cost to deliver (tool licenses per seat, labor hours, third-party services). Project work deserves its own line with honest margins – project-services gross margin collapsed from 23.0% to 12.9% year-over-year in the latest index, a strong argument against a project-heavy model. **4. Tool stack and cost basis.** Your stack is your cost of goods sold, so the plan needs it itemized: RMM/PSA, EDR, backup, email security, documentation – typically $300–$800/mo per technician as of 2026. Standardize on one stack and treat the service like a product; a messy pile of one-off tools kills the margins you just modeled. Details in [the MSP tool stack](/wiki/msp-tool-stack). **5. Sales pipeline assumptions.** Write down where clients actually come from and at what rate: how many warm-network introductions you'll ask for, the size of your hyper-local target list (50–100 businesses of 5–25 employees is a common starting point), expected conversion. Referrals convert 3–5x better than cold outreach, so weight the plan accordingly. Be pessimistic: 1 in 3 MSPs name new-customer acquisition their single biggest challenge (Kaseya 2025 benchmark). Tactics in [getting your first clients](/wiki/first-msp-clients). **6. Hiring triggers tied to revenue.** Don't plan hires by date – plan them by threshold. Common triggers for the [first technician](/wiki/hiring-first-technician): roughly **$100k–$125k in labor revenue**, or 20–30 hours/week of steady overflow you're personally absorbing. Sanity-check against industry average revenue per employee of ~$142k – below that, each hire dilutes profit. A useful framework: the first hire should reach revenue covering their cost, then ~2x their cost, before you plan the next. ## Modeling break-even honestly This is where most first plans quietly lie to their authors. Three realities to build in: - **Client-level break-even takes 7–12 months.** Onboarding a managed client typically consumes $10,000–$15,000 in labor, cleanup, and tooling before the relationship turns profitable. Model each new client as a cash *outflow* for its first several months. - **Growth consumes cash.** Because of the above, a quarter in which you sign three clients is a quarter your bank balance drops. Your plan should show the trough, not just the trendline. - **Costs front-run revenue.** Vendor commitments, insurance, and legal setup all hit before the first invoice clears. Bill monthly in advance and keep 3+ months of operating expenses in the business account – put both in the plan as policy, not aspiration. Then compute two numbers: **company break-even MRR** (fixed monthly costs plus your minimum salary, divided by blended gross margin) and the **month you expect to cross it** given your pipeline assumptions. If the answer requires conversion rates you've never achieved, the plan fails its own test – fix the pricing, the costs, or the runway, not the spreadsheet formatting. ## Sanity-check against real benchmarks Your model's outputs should be plausible against what the industry actually achieves. Key figures from the Service Leadership / ConnectWise index (Q4 2024) and related benchmarks: | Metric | Average | Best-in-class | |---|---|---| | Managed-services gross margin | ~46% | 50%+ | | Adjusted EBITDA | ~11% | 19%+ (held 5 straight years) | | Revenue per employee | ~$142k | – | | Per-user pricing (typical, 2026) | $100–$250/user/mo | $200–$400+ in regulated verticals | If your plan shows 65% gross margin on managed services or 30% EBITDA in year one, you've mis-modeled your delivery costs – average shops run ~46% GM, and the best sustained operators hold 50%+ GM and 19%+ EBITDA. Conversely, if your modeled GM is below 40%, your pricing or stack costs need work before you sign anyone. Also note the market context: managed-services revenue growth has slowed to ~1% worldwide (0.2% North America), so growth comes from taking share and adding security services – 67% of MSPs list security among their fastest-growing lines. A plan assuming a rising tide is a plan assuming wrong. Track your own numbers against [MSP KPIs and benchmarks](/wiki/msp-kpis-and-benchmarks) once you're operating. ## Revisit the plan quarterly A lean plan only beats the 40-page version if you actually re-open it. Put a quarterly review on the calendar – the same discipline you'll later apply to client QBRs, applied to your own business: 1. **Compare actuals to assumptions:** MRR, gross margin per line, pipeline conversion, churn. 2. **Kill or correct** the assumptions reality disproved – reprice, cut a tool, narrow the niche. 3. **Check hiring triggers** against current labor revenue and overflow hours. 4. **Re-run break-even** with the corrected numbers. One page of notes per quarter is enough. The plan that gets revised badly every quarter beats the perfect plan nobody touches. ## Where to start Open a spreadsheet, not a word processor. Model your first ten clients at your intended price point, subtract your real stack and labor costs, and find your break-even MRR and the month you cross it – hedging every assumption you haven't tested. Then write one page naming your target market, catalog, pipeline plan, and hiring triggers. If the numbers survive contact with the benchmarks above, you have a plan; if not, better to learn it now. From there, [startup costs](/wiki/msp-startup-costs) will pressure-test your budget and [how to start an MSP](/wiki/how-to-start-an-msp) lays out the execution sequence. --- ## Zero Trust ## Definition Zero Trust is a security model in which no user, device, or network location is trusted by default: every access request is authenticated, checked against policy, and limited to the least privilege needed, whether it comes from inside the office or a coffee shop. It is an architecture described in NIST SP 800-207 and CISA's Zero Trust Maturity Model, not a product – anything sold as "Zero Trust in a box" is one component of it. ## Why it matters to an MSP For an SMB, Zero Trust reduces to three things you can actually deploy. Identity: [MFA](/wiki/glossary/mfa) on every account, [SSO](/wiki/glossary/sso) so applications inherit it, and conditional access that blocks sign-ins from unmanaged devices or impossible locations. Device posture: only enrolled, patched machines running [EDR](/wiki/glossary/edr) get to company data. Least privilege: no standing admin, access granted per role and per task, and application control instead of "trust the internal network." Most of that is configuration inside licenses the client already pays for, which makes it a high-margin security tier – a conditional-access and device-compliance baseline takes a few hours per tenant to deploy from a template. The model applies to you as much as to clients: partner access to customer tenants through [GDAP](/wiki/glossary/gdap), just-in-time elevation, and technician devices held to the same posture rules are Zero Trust turned on the MSP itself, which is what [cyber insurance](/wiki/glossary/cyber-insurance) questionnaires now probe. Commercially, Zero Trust is the answer to "we already have a firewall" – the perimeter stopped being where the data lives once the data moved to SaaS. The failure mode is partial adoption: MFA without device checks, or device checks with standing local admin everywhere. Sell the controls, not the label, and sequence them as in [identity and access for SMB](/wiki/identity-and-access-for-smb). Related terms: [MFA](/wiki/glossary/mfa), [IAM](/wiki/glossary/iam), [PAM](/wiki/glossary/pam), [GDAP](/wiki/glossary/gdap) ---