AI is reopening the debate about outcome-based pricing. But before MSPs change how they charge, perhaps they need to change how they discover, implement and manage customer outcomes.
I spend some of my time volunteering on a Made Smarter grant panel, reviewing applications from manufacturing businesses looking for support to invest in digital technology.
The applications vary enormously. One business might be investing in automation or robotics, another in CNC machinery, production software, digital design or systems designed to remove manual processes and production bottlenecks. What they have in common is that the applicant has to explain why the investment should be made and, importantly, what difference it is expected to make.
Reading one of these applications recently got me thinking about a seemingly unrelated conversation I’ve been involved in within the communications industry: how AI might change the way technology and managed services are charged for.
We are beginning to hear much more about outcome-based pricing. Rather than charging simply for licences, users, hours or consumption, could suppliers increasingly be rewarded for what their technology actually achieves?
It sounds attractive, particularly as AI starts to challenge some of the traditional units we use to price technology. But the more I think about it, the more I believe that the interesting question isn’t really about AI pricing at all. It is about what we mean when we call ourselves a Managed Service Provider.
What changed when we stopped being resellers?
The technology channel has spent years talking about the transition from reseller to MSP, but perhaps we’ve concentrated more on the recurring revenue model than on what the word managed actually means.
At its simplest, a reseller sells something to a customer. They may advise on the choice, configure it, install it and support it, but fundamentally the commercial transaction is based around providing a product or service.
A Managed Service Provider surely takes that relationship a stage further. The word managed implies an ongoing degree of responsibility for ensuring that the technology continues to do what the customer needs it to do.
If that’s true, perhaps we should ask whether an MSP prepared to take greater responsibility for the result should also have an opportunity to participate in the value it helps create.
This isn’t entirely theoretical. AI is already putting pressure on traditional technology charging models. We are seeing services charged around successful resolutions and other measurable outputs rather than simply the number of people using the software. At the same time, the wider IT services market is exploring contracts where performance and business outcomes form a greater part of the commercial arrangement.
But outcome-based charging gets complicated remarkably quickly, and that’s where my Made Smarter application comes back into the story.
The business case was more interesting than the technology
I obviously won’t identify the applicant or disclose its commercially sensitive information, but the structure of the application was fascinating.
The company wasn’t simply saying that it wanted to buy some technology because the new system would be better than the old one. It had established where its performance was today, identified what it believed the investment could change, considered the additional productive capacity that could be created and translated that into potential financial benefit. It had also identified other operational measures that should change and explained how the results would subsequently be monitored.
The application went considerably further than a vague promise of “improved efficiency”. It established a productivity baseline and a target improvement within a defined timeframe, and then considered the potential effects on capacity, profitability, delivery performance, inventory, waste, rework and overtime.
One particular observation jumped out at me. The company recognised that creating additional manufacturing capacity didn’t automatically mean that somebody would sell enough additional work to fill it.
That distinction gets to the heart of the difficulty with outcome-based pricing.
Imagine that an MSP implements technology which successfully gives a manufacturer another £500,000 of productive capacity. The implementation works, the bottleneck disappears and the capacity genuinely exists, but the customer doesn’t subsequently sell enough additional product to use it. It would be difficult to argue that the MSP hadn’t delivered simply because another part of the customer’s business hadn’t converted the capacity into revenue.
The same problem appears elsewhere. An AI implementation might remove thousands of hours of repetitive administration, but instead of reducing headcount the customer could redeploy those people into higher-value work. A sales technology might generate hundreds of genuinely qualified opportunities, but the customer’s sales team might fail to follow them up effectively.
The further the commercial reward moves from the thing the MSP directly controls towards the customer’s ultimate financial result, the harder attribution becomes. And that means outcome-based pricing needs a very different quality of discovery.
Outcome-based pricing needs outcome-based discovery
If I am selling 100 licences, my discovery can quite easily gravitate towards questions about users, features, integrations, numbers, contract dates and price.
If part of my reward is going to depend upon improving something within the customer’s business, that is nowhere near enough. Buyer and supplier have to establish where the customer is now, where it wants to get to and what is preventing that outcome today. They need to understand which of those obstacles the proposed technology can genuinely affect and which sit elsewhere within the customer’s organisation.
Implementation then becomes every bit as important as product capability. We need to understand what existing processes have to change, which other technologies the new service will interact with, what the customer itself has to do and whether its people are likely to adopt the changes required. We also need to know what can already be measured, what new measurements will be required and which improvements can reasonably be attributed to the service being provided.
That’s starting to sound much more like a managed relationship than a product sale. But I think it also exposes a weakness in the way we traditionally think about discovery.
Discovery shouldn’t finish when the deal closes
We normally talk about “the discovery meeting” as though discovery is an event. It happens near the beginning of the sales process. Somebody asks lots of questions, makes some notes and uses the answers to shape the proposal. Eventually the opportunity moves through the pipeline, a contract gets signed and everyone moves on to implementation.
That seems increasingly inadequate if we’re selling outcomes.
If the original discovery establishes the baseline against which success will ultimately be judged, it needs to remain part of the relationship. The original conversations and assumptions should be retained, accessible and revisited as the proposed solution develops. And discovery should continue.
The implementation team will inevitably discover things the salesperson couldn’t have known at the beginning. Processes may work differently from the way they were originally described. An integration may prove more complicated. Users may react differently. Another business priority may intervene. Those findings shouldn’t disappear into a separate project-management system; they should enrich and update our understanding of what the customer is trying to achieve.
Once the service goes live, we should be able to return to that same evolving record and ask whether the original assumptions proved correct, whether the customer made the changes it expected to make and whether the measurements we agreed are still appropriate.
Six or twelve months later, we should be able to understand not only what was decided, but why it was decided, what we learned afterwards and how the desired outcome has evolved.
In other words, discovery may start in sales, but it shouldn’t belong exclusively to sales. It becomes a living record that follows the customer through sales, solution design, implementation, service management and account management.
And that creates another interesting possibility.
Perhaps we should split the value of the deal
Most MSPs already have different groups of people responsible for different parts of the customer journey.
The salesperson is skilled at creating the opportunity, finding and managing stakeholders, maintaining momentum, navigating the commercial process and ultimately getting the deal closed. Technical pre-sales and product specialists bring a different discipline. Their job is to ensure that what is being proposed can actually satisfy the requirements being uncovered. Then, once the contract is signed, another group of people often takes responsibility for implementation, service delivery, support and ongoing account management.
We tend to reward those activities very differently.
The salesperson is generally rewarded heavily around the point at which the deal is won. The people who subsequently have to make the promises work tend to be rewarded through a rather different structure.
Outcome-based commercial models create an interesting opportunity to reconsider that. Perhaps there are actually two moments of value in a managed-service agreement.
The first is creating and delivering the right solution. The customer pays an appropriate amount for the technology, implementation and managed service, and the salesperson can still be rewarded for successfully creating and closing that business.
The second comes later, when enough time has passed to determine whether the outcome everybody agreed upon is actually being achieved. Perhaps an anniversary payment, performance element or shared-value payment could sit there.
That wouldn’t only change how the customer pays. It could change how the MSP behaves internally.
Giving delivery a stake in the promise
Imagine that some of the second-stage reward is shared with the technical pre-sales, implementation, service and account-management teams responsible for turning the original proposition into a successful outcome.
Suddenly those people have a direct interest not simply in whether the product can be sold, but whether the outcome being promised is realistic. That could create a very healthy tension during the sales process.
A good salesperson naturally wants to get a deal across the line. That’s part of their skill and exactly what they’re employed to do. But the technical and delivery teams live with different realities. They understand what happens when implementation turns out to be more complicated than expected, when adoption is slower than anticipated or when a customer’s existing processes prevent a perfectly good technology from delivering its theoretical benefit.
If those teams have a meaningful stake in the eventual outcome, they have an additional reason to challenge assumptions before the contract is signed. Not to prevent the sale, but to make it a better sale.
That could mean pushing back on an unnecessary component that adds revenue but little value, identifying an implementation dependency the salesperson hasn’t seen, or being more conservative about an outcome which sounds attractive in the proposal but will be difficult to attribute or measure in practice.
In that environment, technical pre-sales stops being simply the function that confirms that the proposed product fits the specification. It becomes part of the commercial diligence behind the outcome.
And the salesperson isn’t being undermined by that process. Quite the opposite. They are being supported by a wider team whose interests are aligned around creating a deal that will still look good twelve months after everybody celebrated signing it.
The customer relationship changes as well
The same thinking starts to change account management.
If discovery is continuous and some part of the commercial relationship is linked to outcomes, an account review can’t simply become a quarterly conversation about tickets, service levels, licences and the next renewal. There is now a reason to go back to the original business case.
We can remind ourselves where the customer started and what we collectively believed the technology would change. We can look at what actually happened, which assumptions were right and which weren’t, what new information has emerged and whether the objective itself has changed.
That creates a much richer account-management conversation because the MSP isn’t periodically returning to ask what else it can sell. It is continually demonstrating that it remembers why the customer bought in the first place.
And real life will inevitably intervene. Economic conditions change. Customers win or lose major contracts. People leave. Strategies change. Competitors act. New technology appears. Legislation changes. An outcome that made complete sense twelve months ago may no longer be the right outcome today.
Continuous discovery gives both parties permission to recognise that rather than pretending that a business case written at the beginning of the relationship remains permanently true.
This is also why I don’t think outcome-based pricing means transferring all of the risk to the MSP. The provider still has real costs and the customer still controls significant parts of its own performance. A base managed-service charge therefore remains entirely logical. What becomes interesting is whether a second element can sit behind it, based on the things the provider can genuinely influence and perhaps, in the right circumstances, a share of the additional value created.
Maybe that’s what “Managed” should have meant all along
There is a certain irony that AI has prompted so much discussion about pricing. We’re asking whether we should charge per user, per AI agent, per transaction, per conversation, per resolution or per outcome.
Those are all reasonable questions, but perhaps AI will force a more fundamental conversation about what we’re actually being paid to do.
For a reseller, the answer was relatively straightforward: supply the technology.
For a genuine Managed Service Provider, perhaps the answer should increasingly be to understand what the customer is trying to achieve, design the right combination of technology and change around that objective, manage its implementation, continually discover what’s happening in the real world and measure whether the intended improvement is actually materialising.
That would also give different parts of the MSP a much clearer shared purpose. Sales creates and navigates the commercial opportunity. Technical pre-sales tests whether the promise is credible. Delivery turns the promise into reality. Service management keeps it working. Account management continues the discovery and ensures that the outcome remains relevant.
Rather than those being separate stages, they become different contributors to the same customer objective.
We’ve already spent years moving from one-off margin to recurring revenue, from products to services and from break/fix support towards ongoing management. Perhaps the next evolution isn’t another category of technology to add to the portfolio.
Perhaps it is moving from managing the technology towards sharing responsibility for the business improvement that technology is supposed to enable.
If we are prepared to do that, perhaps customers should be prepared to have a different conversation about reward as well.
Because if we’re genuinely prepared to share responsibility for creating the outcome, it doesn’t seem unreasonable to ask whether we should also share in some of the value when we achieve it.