Justin Woodbridge

Originally wrote this up as a rough Google Doc to share with friends, but decided to publish it here. I spent the last several months looking at building automation tooling for IT MSPs, I built several prototypes with design partners and had collaborators lined up, but decided that the R/R was not there. Part of that exploration is also documented here

It’s not worth buying an MSP and trying to grow it, or trying to do a rollup or some kind of scaled growth buyout strategy:

1. The margin expansion opportunity with software and LLMs is not realistic or worth it to implement.
2. The pure financial play was there in the past, but multiples at this point are quite high (7-10x) now.
3. Anecdotally, operators gave me the sense of growing discontent with the model: decreasing demand, increasing commodification.

Why is the margin expansion opportunity not there?

First and most importantly, the MSP market structure is highly small and fragmented SMB: 80 percent are less than a million of revenue, and about a quarter are not profitable (of course, this is good for a consolidation play, as I’ll go to later, there are other reasons why that is not the right strategy here). Given the small scale and thus small staff size of the business, the marginal impact of relative savings on tech time or even tech headcount do not move the needle. And that’s assuming that you can reliably create meaningful workflow automation

Doing that in and of itself is hard, which leads to the second reason: the day-to-day execution work doesn’t suit automation in a meaningful way:

1. MSPs uniquely deal with a highly varied, non-repetitive set of work for each client. This is because every client has their own environment (they are onboarded after having an existing IT relationship and bring their baggage, and no matter how much the MSP tries to standardize, continue to ask for bespoke tweaks or rejects new tech migrations, etc).
2. Much of the tech work is dealing directly with the end customer staff. This adds another layer of high context, emotional complexity, and thus difficulty bringing in automation. Outsourcing the help desk does not work. Of course, there’s the theoretical future of the AI L1 agent. This is short-term plausible for text-based communication. But, a lot of MSP support happens over the phone. There is a perception that what you are paying for is the human touch - and clients are sensitive to getting that value. We can also look to Electric as a real-world test of this idea, which did not work.
3. The small scale MSP does not have documented workflows or procedures. This is both in part due to the nature of a scaling, or failed to scale, small business, and the general lack of maturity in the industry around pre-AI automation (RPA, etc)¹. So even if there was high-impact, low-externality automation to deploy, doing so is a challenge.

In short: even if you could bring in substantial automation into a highly varied, undocumented environment, the absolute gains on these smaller operations do not justify it. There is definitely some opportunity for automation, but threading the needle between those small, incremental gains and maintaining the client relationship is hard.

Taking a step back - the ideal opportunity here is to find a client-services business, where the work is composed of:

1. Customer Success and Client Management
2. Execution and Fulfillment

In the ideal market, CM is the tip of a very deep iceberg, covering up a big back office of workers executing, who never pop up to meet the actual customer. In other words, a clean, pure function. The theory is of course that we can swap in a cheaper, scalable, AI (and maybe human-in-the-loop) system to make this cheaper, faster, higher quality, more consistent, etc.

MSPs are not that at all. Not only is CM not the tip of the iceberg - in many cases, they are the execution: the tech working the ticket is the one talking to the customer. Customer Success and Execution bleed into each other, leaving very little room for creative tech to meaningfully impact the cost structure of either.

All of the tech margin expansion lack of opportunity aside - the pure acquisition play doesn’t make sense at this point either. It probably did several years ago, but multiples for MSPs are in the 7-10x range. Expensive. This is in part a function of lots of consolidation, both intra-MSP, and by Private Equity and Rollups. A few examples: Lyra, New Charter, and Thrive. It’s worth noting that Lyra takes a decentralized approach, keeping existing management for the most part and maintaining distinct, individual brands. My understanding from conversations is that they do very little centralized services beyond group negotiation on vendors. Anecdotally, I’ve heard that several of these PE consolidations have trouble actively growing revenue and focus on alternate strategies like capturing more IT spend of the existing customer space by cross selling other portfolio co. services (ERP planning, etc.).

There’s probably a world where you can start an MSP from scratch, be very disciplined about the stack you want clients to use, and to develop automation flows from the get go. It is probably entirely software driven, with no configurability by the user (something like https://www.zipsec.com, a friend’s company and great product). However, maintaining a single stack will be hard to maintain if you target existing MSP customers, and will make growing the business hard (which is already intrinsically very challenging). That’s not worth doing. If I was going to do that, I’d start with managed security first - which is less bespoke for each client - and only work backwards to add in IT offerings as necessary, ideally outsourced. I’d also want to target the longer-tail of businesses that don’t already use an MSP, probably don’t value the higher-touch service they offer, and just want a set-and-forget solution for compliance/security/system maintenance.

I do think there is opportunity in IT services - but not with MSPs, in large part due to the out-sourced nature of the business and the execution/CM bleed over. It creates a client services dynamic that then works against all the automation and efficiency potential in the name of high-quality service. There’s a stronger case in internal IT.

One that I find interesting is Fixify: they are an out-sourced help desk focused on enterprise clients, which creates a more consistent tech stack and less pressure on the quality of the service (due to a less direct relationship between the buyer and the people actually consuming the support). Their strategy appears to be offering a complete done-for-you-service: you hire them, they plug into your ticket system, and start handling tickets with a mix of their staff and agents they create.

This model - done-for-you services, not software, where you have a combination of humans (near shore staff) augmented with custom AI tooling to make them higher quality, faster, more reliable, is what I’m exploring next. Wrote a bit about that here: https://blog.justinwoodbridge.com/services-and-software/