Pricing AI Services: Closing the MSP Demand-Revenue Gap
Ric Hall, CRO
Price AI service lines the way you price everything else profitable: tie the fee to a unit clients can predict and you can control. In 2026, most MSPs still haven't done that. Client demand for AI has outrun the pricing model built to capture it, and that gap is now the single biggest packaging problem in the channel.
Why is AI revenue lagging behind AI demand?
Because MSPs built AI into delivery before they built it into the price list. Kaseya's 2026 State of the MSP Report found that about 48% of MSPs say AI and automation will be the top IT or service need for their clients in 2026. The same report says that only 13% of MSPs identify AI and automation as a meaningful revenue source. It attributes the gap to the fact that many providers are still defining, packaging and pricing these services.
The Global Technology Industry Association's State of the Channel 2026 research tells a similar story from a different angle. Its summary reports that 75% of ITSPs describe their businesses as "AI-driven" or "AI-invested". The same research shows AI is already contributing to top-line performance, since in DACH and the UK & Ireland, more than a third of ITSPs report that 11-25% of their revenue is currently generated from AI-related products and services. So it's not that AI can't carry real revenue. It's that most providers haven't built the pricing structure that lets it. You're not behind if you haven't cracked this yet. Almost nobody has.
What's actually breaking the old pricing model?
The math that used to work doesn't anymore. TSIA's research on MSP pricing lays out the mechanism plainly: as AI reshapes how services are delivered, automation reduces effort, and pricing based on hours or inputs starts to collapse. That's the trap of pricing effort in a business where AI is actively shrinking effort. TSIA describes a progression from cost-based pricing to market-based, consumption-based, value-based, and outcome-based pricing, and calls outcome-based pricing the future while noting it is still early.
This is a different problem than a margin leak in your current rate card or a deal-size squeeze from bad packaging. Those are structural issues with pricing you already have. This is a newer, narrower question: what do you charge for a capability that didn't exist in your service catalog two years ago, that has a real and sometimes variable cost to deliver, and that clients are asking for by name before you've decided how to sell it.
Three ways MSPs are pricing AI service lines right now
There's no single standard yet, which is exactly why getting ahead of it matters. Three approaches are showing up across the research and the trade press.
Flat-fee bundling folds AI features into an existing tier, usually as a checkmark rather than a line item. It's the easiest sell because nothing changes on the invoice, but it's also the easiest way to give away margin if the underlying compute or licensing cost creeps up and your price doesn't move with it.
Consumption or usage-based pricing charges by what gets used, tokens, seats actively touching an AI feature, or automated actions completed. It scales cost with delivery, which protects margin better, but it puts you in the position of billing something the client can't easily predict.
Outcome-based pricing ties the fee to a result, faster resolution times, fewer escalations, hours of manual work eliminated. It aligns what you charge with what the client actually values, and it's the hardest to execute because you need clean measurement to prove the outcome before you can charge for it.
| Model | How it's charged | Where it fits best | Main risk |
|---|---|---|---|
| Flat-fee bundled | Included in an existing tier | Simple, low-variance AI features | Cost creep erodes margin silently |
| Usage or consumption-based | Per token, seat, or automated action | Features with real variable delivery cost | Client-side bill shock, forecasting pushback |
| Outcome-based | Tied to a measured result | Mature offers with clean reporting | Requires proof before you can invoice |
Most MSPs end up blending two of these rather than picking one outright, flat-fee for the base package with a consumption or outcome layer for the parts of the service that actually scale with use.
Before you pick a model, answer three questions honestly for the specific AI feature you're pricing:
- Does the cost to deliver it move with usage, or is it fixed no matter how much a client touches it?
- Can you measure the outcome it produces cleanly enough to invoice against it without an argument?
- Would your average client rather see one predictable number or pay less in a quiet month and more in a busy one?
The answers point you toward flat-fee, outcome-based, or consumption pricing respectively, and they'll be different for different features in your own catalog. A single answer for every AI capability you sell is usually a sign you haven't actually priced any of them yet, you've just picked a default.
Should you bill for AI usage the way vendors do?
Carefully, and not without guardrails. Zylo's 2026 SaaS Management Index reports that in the last 12 months, 78% of IT leaders reported unexpected charges tied to consumption-based or AI pricing models, according to a survey of 218 IT leaders. That data comes from the enterprise software buying side, not MSP billing specifically, but the lesson transfers directly. If large IT organizations with dedicated procurement teams are getting blindsided by usage-based AI bills, your SMB clients will be too, and they'll blame you, not the underlying vendor, when the invoice lands wrong.
The fix isn't to avoid consumption pricing. It's to never hand a client a pure meter with no ceiling. Cap it, tier it, or wrap it in a predictable monthly band with overage handled as a conversation, not a surprise line item. A pricing model that protects your margin but blows up your client's budget forecast isn't a win, it's a churn risk with a delay on it.
Building the package before you sell it
Getting this right starts with knowing what an AI feature actually costs you to run before you decide what to charge for it. That's an operational question as much as a pricing one, which is why controlling the cost and overhead of delivering AI-enabled work, not just marking it up, is worth solving before you finalize the price list. Catalyst is built around exactly that, cutting the operational overhead of AI-assisted delivery so the margin you price for is the margin you actually keep.
Once you know your real delivery cost, the packaging decision gets a lot more concrete. The stack builder lets you assemble the specific combination of white-labeled AI tools you plan to resell and see how they fit together as a priced offer, rather than guessing at a bundle and hoping the margin holds. And if you're still deciding which AI-enabled service line to add first, the full product catalog is the place to compare what's available to package under your own brand before you commit to a price.
The MSPs closing the gap between AI demand and AI revenue aren't the ones with the flashiest AI pitch. They're the ones who priced the thing before they sold it, matched the pricing unit to the actual cost driver, and built in room to adjust before a client ever sees a surprise on their bill. See the full stack.