Outcome-based pricing for MSPs: is your ticket data ready?

The way MSPs price is starting to move. For years it has been seats, devices, or hours. The conversation now is shifting toward value, and toward outcomes.

TSIA's State of Managed Services 2026 lays out the path: subscription for stability, consumption for flexibility, and outcomes on top. The first real step is value-based pricing on a unit of work, and the example TSIA names is tickets resolved. Above that sits outcome-based pricing, where you bill on the result itself: an SLA met, a resolution time held, uptime maintained.

It is early. TSIA puts outcome-based pricing at under 3% of deals today. But the direction is set, and here is the part nobody raises in the pricing meeting. An outcome is not something you count. It is calculated from your ticket data: the created, responded and resolved timestamps, and the status on each incident. The data is not the outcome. It is what the outcome is measured from. Bill on the result, and that data has to be right. Right now, a lot of it is kept current by hand.

What this looks like on the ground

You run one system. Your enterprise customer runs another. The same ticket lives in both, and someone has to keep both current.

That someone is usually you. The customer raises the work in their system. You work it in yours. Then you go back and update theirs so it matches.

How the ticket actually moves

We see this pattern often. The customer runs ServiceNow. The MSP runs ConnectWise.

A ticket starts in ServiceNow. ServiceNow emails the MSP, and the MSP creates the matching ticket on the ConnectWise board. From that point the MSP is running two tickets for one piece of work.

Every update then has to happen twice. A status change, a note, a time entry, a resolution. Each one goes into ConnectWise where the work is done, then into ServiceNow so the customer sees it. The same double-handling applies whether the pair is ConnectWise and ServiceNow, Autotask and Jira, or HaloPSA and ServiceNow.

Two things tend to slip. The customer's system falls behind, because the second update is the one that waits. And the timestamps drift, because the resolution lands in their record whenever someone gets to it, not when your engineer actually closed it.

The cost you're not counting

That double-handling is non-billable. It happens on every ticket, every day, and it grows with every co-managed client you win.

It matters more the moment money rides on the record. Say you hold a two-hour resolution SLA. Your engineer fixes it in ninety minutes and closes it in ConnectWise. The customer's ServiceNow still shows it open, because the update across is the one that waits. On their record, the system of record for the SLA, you missed. You hit the target and the number says you didn't.

So you do what keeps the relationship calm. You explain the gap rather than argue the timestamp. On an outcome deal, that can mean a service credit for an SLA you actually met. Margin leaks out a few tickets at a time, and it never shows up as a line item.

More than 80% of MSPs offer co-managed IT now, and for many it's up to half their revenue. That manual upkeep grows with the part of the business that's growing fastest.

What good looks like

The fix isn't more discipline on the copy-paste. It's one ticket that updates in both systems at once.

When you change the status, add a note, or log time in ConnectWise, the same update lands in ServiceNow within minutes, timestamps and detail intact. The customer's record reflects the work as you do it, not whenever someone gets back to it. Nothing is retyped, so nothing drifts.

That is what has to be true before you price on value, and well before you price on the outcome. Whether the unit is tickets resolved or an SLA held, the number comes from the same ticket data. Get both systems updating from one source, and the record you are measured on is one the customer already trusts.

If you're weighing up value or outcome-based pricing and your tickets live in two systems, check your platform pairing or book a demo.