AI for MSPs: How Small Providers Should Actually Think About AI (Not the Vendor Pitch)

If you run an MSP between five and fifty people, you have been pitched AI from two directions at once over the last eighteen months.

From above, vendors telling you to resell Copilot, resell their AI-flavoured version of whatever you were already reselling, and add an AI line item to every contract renewal.

From the side, MSP peers and conference speakers telling you that AI is either going to 10x your service desk or eat your business entirely, depending on the slide deck.

Both of these pitches miss the actual opportunity. And the actual risk.

The opportunity is not reselling AI. The opportunity is architecting your own delivery layer so that you get paid for judgement, not for tickets.

The risk is not that AI eats your MSP. The risk is that you keep running your internal operations the way every other MSP runs them, and by the time you realise the model has shifted, you are selling what has become a commodity.

Why AI for MSPs Is Usually Sold as the Wrong Thing

The MSP industry has a structural problem. The business model was built on selling time and support, priced per seat, standardised across a portfolio of clients. It worked well for a decade because the underlying cost (a technician's hour, a software licence) scaled predictably.

AI breaks that pricing logic two ways at once.

First, the thing the client used to pay you for (routine support, standard questions, common fixes) is increasingly something the client can get from their Copilot or their vendor's AI layer. The value of the ticket is dropping.

Second, the thing the client actually needs (judgement on what to automate, how to structure their workflows, which AI to trust, how to integrate it safely) is something most MSPs are not structured to deliver. It is not a ticket. It is a consulting engagement. Your pricing model does not support it.

Most vendor pitches to MSPs right now are about the first problem. Resell more. Add AI to your stack. Keep the per-seat model going.

Very few vendors are talking about the second problem, because the second problem does not sell licences. It sells the MSP's own transformation. And that is exactly the conversation the MSP owner actually needs to have.

What MSPs Sell Today vs What Clients Actually Need

Ask any MSP owner what they sell and you will hear some combination of: managed IT support, cybersecurity, cloud management, compliance, helpdesk, procurement, backup, M365 management.

Ask their clients what they are actually buying and the answer is different. They are buying "someone who makes sure my IT works and tells me what to do when it does not." They are buying a relationship with a technical operator who knows their business.

The ticket is the artefact. The trust is the product.

The MSPs that will win the next five years are the ones that understand this difference and reprice around it. AI is the tool that makes it possible, because it commoditises the ticket and frees up your technicians to do the thing that was always the actual product: judgement.

Your Own Operations Are Probably Un-Architected

Here is the uncomfortable part.

Every MSP I have looked at in the last year is selling substrate that AI runs on (infrastructure, licences, security, M365) while running their own internal operations in a way that is almost completely un-architected.

The common pattern:

• Tickets come in across email, phone, portal, and Teams chat, and nobody has designed the routing properly
• Escalation from L1 to L2 to L3 depends on which technician is on duty, not on the ticket type
• Project delivery (new client onboarding, M365 migration, security rollout) is run by whichever senior tech has capacity that week
• Knowledge lives in fifteen-year-old Wiki articles and one senior tech's head
• Monthly reporting to clients is built by hand by whoever has the bandwidth

This is not a criticism. This is the default state of a successful MSP that grew through relationships. The operations were never designed. They emerged.

The problem is that the very thing MSPs sell to clients (designed IT operations) is the thing MSPs have not done for themselves. And you cannot sell architecture as a service if your own delivery is held together with senior tech memory.

The MSP AI Opportunity Ladder

Here is how I would think about where AI slots into an MSP in order of value. Bottom rungs first, because they compound.

Rung 1: Your Own Internal Delivery Layer

Before you resell a single AI licence, architect your own ticket flow. Which tickets are L1 vs L2 vs L3. What triggers escalation. What your standard response templates look like. Where knowledge lives and how it stays current.

AI fits on top of this in obvious places. First-response drafts from past tickets. Knowledge base search for technicians. Auto-categorisation of incoming tickets. Summary generation for shift handoff. Intake classification from client emails.

This does not show up on a client invoice. It shows up as a forty per cent reduction in senior-tech time spent on tier-one work, which shows up as margin.

Rung 2: Your Project Delivery Layer

Every MSP runs the same core projects: client onboarding, M365 rollout, backup implementation, security baseline, helpdesk integration, endpoint management.

Most MSPs run these as bespoke engagements with a senior tech leading. The logic lives in that tech's head. New engineers take nine months to deliver a full onboarding on their own.

The shift is to productise these delivery layers. A written flow for each project type. Checklists. Pre-built automation scripts. Client-facing status. Internal handoff points.

AI helps with the document generation, the client communication, the summary reports. But the value is the productisation, not the AI. AI without productisation is a drafting assistant. AI on top of productisation is a repeatable delivery engine.

Rung 3: Client-Facing Reporting and Visibility

Most MSPs generate monthly reports the hard way. A tech pulls numbers from the RMM, the PSA, the security tools, the M365 admin. Puts them in a template. Adds commentary. Sends by email.

The client reads the first page and files it.

Reports are not the product. Visibility is the product. Replace the monthly PDF with a live client-facing dashboard that reflects actual health in real time. AI writes the commentary that sits on top of the numbers. The monthly call becomes a thirty-minute review, not a sixty-minute show-and-tell.

This is a selling point for new contracts. It also reduces the hours your team spends on reporting by around seventy per cent.

Rung 4: Advisory Offers to Your Own Clients

Only after rungs one, two, and three are in place does rung four make sense. That is when you start offering your clients genuine advisory services around AI adoption.

The reason this has to be last is simple. You cannot credibly advise a client on AI adoption in their business if your own business is still running on tribal knowledge. The moment they visit your office or ask how you do it internally, the pitch breaks.

MSPs that try to jump straight to rung four without doing rungs one to three first end up reselling Copilot licences and calling it transformation. That is not a durable margin business. That is what every other MSP is doing.

Rung 5: Repriced Contracts

This is the endgame. Once your own delivery is architected, your projects are productised, and you are advising clients on their AI adoption, your contract structure changes.

Per-seat pricing becomes less important. Outcome-based pricing becomes viable. Retainer for advisory plus usage-based for infrastructure plus project fees for architecture work becomes normal. The client is no longer paying for tickets. The client is paying for trust and throughput.

This is a ten-year shift for the industry, but it has already started at the top end of the market. The MSPs that position early will be running this model in two to three years.

The Mistake Most MSPs Are Making Right Now

The mistake is starting at rung four or five without doing rungs one to three. Reselling AI services to clients while your own delivery is still un-architected.

This shows up in the pitch meetings. An MSP owner walks into a client meeting, pitches AI strategy, and then the client asks a simple question: "How do you run your own operations? How does your ticket flow work? What AI are you using internally?"

The answers are usually vague. Because the answers are "we have not got that far."

Clients notice. They may not say anything in the meeting. But they notice.

The MSPs that are landing the best contracts right now are the ones that can show their own internal architecture first. The demo is the MSP's own operations. That is the sales tool.

The Path Forward

If you run an MSP and you want to be relevant in three years, the order of operations is clear.

1. Architect your own delivery layer. Ticket flow, escalation logic, knowledge base, standard templates.
2. Productise your projects. Onboarding, M365, security. One documented flow each.
3. Replace your reporting with live visibility for clients.
4. Start offering advisory services based on what you have built for yourself.
5. Reprice contracts around outcomes, not seats.

AI shows up as a layer at every rung. None of the rungs are actually about AI. They are about architecture. AI is the tool that makes architecture economically viable for the first time at your size.

The MSPs that treat AI as a resale product will be commodities in three years. The MSPs that treat AI as an invitation to finally architect their own operations will be the ones their clients rely on for judgement.

Start With the Diagnostic

If you run an MSP between five and fifty people and more than two of the gaps described here are familiar, the next step is a two-week operational diagnostic. £5K. We map your current delivery layer (tickets, projects, reporting), identify where your own operations are running on tribal knowledge, and scope the highest-leverage fix.

About sixty per cent of diagnostics turn into build engagements. The rest walk away with a pricing-grade audit and a clear plan for what to fix first. Either way, you stop buying AI licences and start building architecture.

The 10 Operational Leaks guide is worth reading before you buy another tool.