Key takeaways:

  • The way you charge matters as much as what you charge. Per-user, per-device, and block-hour pricing each behave differently as you add clients, so the wrong model can turn growth into more work without more profit.
  • Cash in the bank isn’t proof your pricing is working, margins are. Utilization, tool creep, and fuzzy contracts can quietly erode profitability even when revenue looks healthy.
  • There’s no single “right” MSP pricing model, only the one that fits your business right now. It’s worth stress-testing that on a regular basis instead of assuming it still holds up.

One of the questions MSP owners ask most often isn’t about tools or tech. It’s about pricing. Not just what to charge, but something closer to, “Is the way I’m charging actually built to support where I want this business to go?” We’re going to dig into why pricing models matter just as much as service delivery, how the most common approaches help or hurt as MSPs scale, and what to look at when margins feel tighter than they should.

This post draws on insights from Amanda Doucette-Lachapelle’s Frankly IT newsletter on LinkedIn, specifically issue #17, “How NOT to Price Yourself Out of Business.”

Pricing isn’t just about how much you charge, it’s also about scalability

As Amanda puts it, pricing is one of the trickiest parts of running an MSP. You can have your service delivery nailed down, your client relationships solid, and your tools humming along, and still feel like you’re running uphill if your pricing structure doesn’t scale with you.

If you’ve ever tried to figure out how to price MSP services in a way that actually holds up as you grow, the real question isn’t only what to charge. It’s whether the way you charge still makes sense as your business grows.

There are plenty of creative variations out there, but most MSP pricing models fall into three buckets:

  1. Per-user
  2. Per-device
  3. Block-hour

Each comes with real strengths and potential traps, which we’ll cover next.

MSP pricing models & where each one tends to break

Here’s a quick side-by-side, with real-world examples of where each model tends to hold up and where it doesn’t.

Pricing ModelWorks Best WhenWhere it Tends to Break
Per-UserUser counts are stable and your stack is standardized.Clients have volatile staffing or heavy shared-endpoint use.
Per-DeviceYou’re in a device-heavy vertical where hardware volume tracks with actual workload.Value gets anchored to “things” instead of outcomes.
Block-Hour/Time BankYou’re handling special projects or supporting legacy clients.You need to forecast, scale, or lead clients strategically — every hour becomes a transaction.

Per-user pricing is the most common modern MSP model, and for good reason. It’s simple, predictable, and easy for clients to understand. It works best when clients’ user counts are relatively stable and you’ve standardized your stack. It’s a harder fit when clients have volatile staffing or a lot of shared endpoints.

Per-device pricing is old-school, but it’s still valuable in certain verticals. It makes sense when devices matter more than users, though it’s worth being careful not to anchor your value purely to “things” instead of outcomes. The same per-device-versus-per-user tradeoff shows up on the buying side too, when MSPs are choosing their own network management or PSA tools. The model that scales with you matters whether you’re the one billing, or the one being billed.

Block-hour or time bank pricing is still hanging on, though it’s not ideal for most MSPs trying to scale, and it tends to create real contention around value. It’s often the model MSPs lean on when transitioning clients off pure break-fix. A block of hours feels familiar to a client who’s used to paying per incident, which makes it a reasonable bridge into a managed relationship. The growing pains usually show up later as the MSP scales, block-hour arrangements start to strain, and most teams end up needing to move toward some version of per-user or per-device pricing to keep growing. It’s fine for special projects or legacy clients. It’s a tough model for long-term growth: you can’t forecast, you can’t scale, and you can’t lead clients strategically when every hour is a transaction.

Cash in the bank doesn’t mean your pricing is working

Here’s the uncomfortable part. A lot of MSPs think they’re profitable, but they aren’t paying close enough attention to the data that actually confirms it. Money in the bank is not a reliable marker of success on its own.

If clients aren’t also being optimized, with issues caught and handled proactively, utilization stays high for the wrong reasons. As Amanda frames it, a pricing model only drives profitability when something exists to actively drive down the reactive noise that inflates the support cost of a contract.

Layering in new tools or services without recalibrating your rates is a problem too. And if clients can’t easily explain what they’re actually paying for, that’s a bigger one.

Your pricing model should make sense not just to your clients, but to your P&L. Worth reviewing regularly:

  • Does your model align with your service delivery costs?
  • Does it scale efficiently as your client count grows?
  • Does it reward efficiency, or quietly punish it?
  • Are your contracts actually profitable? Every client is worth evaluating individually.

MSP profit margins don’t move because you want them to. They move when one of four specific levers moves, the same idea behind gross service margin — engineer pay rate, billing rate, utilization, and agreement efficiency ratio. Move utilization up while holding pay rate and billing rate steady, and margin goes up. Let engineer pay creep up without adjusting the other levers, and margin goes down, whether your pricing model is technically “working” or not.

It’s also why it pays to treat your own dashboards with a little healthy suspicion. A KPI can look perfectly healthy and still be telling you an incomplete story, especially when it comes to margin.

Match your pricing model to your business, not someone else’s playbook

There’s no one-size-fits-all answer here, and that’s a constant refrain for a reason. The choice is yours, but a few patterns tend to hold:

  • If your business is people-heavy and relationship-driven, per-user pricing probably fits best.
  • If you’re in a device-heavy vertical, per-device pricing makes more sense to reflect actual volume of work.
  • If you’re just starting or doing specialized work, block-hours can work as a bridge, not a destination.

The right model is the one that fits your client base, your operational strengths, and your vision for growth. You might land on a hybrid that bridges the two together. Whatever works, just make sure you’re evaluating profitability regularly so you don’t end up underwater. This is also where it helps to get clear on what kind of MSP you’re actually building before you lock in how you charge for it.

Run the 30-minute pricing stress test before you assume your model still works

Most pricing models don’t break all at once, they bend quietly as the business grows. Amanda built this stress test to help MSPs see whether their pricing actually scales with them, or just relies on the team working harder to keep things afloat.

Try this exercise:

Set a 30-minute timer. No spreadsheet rabbit holes. Pull one “average” managed client, not your best or your worst.

1. Follow the time. Look at the last 30 to 60 days: total support hours logged (including escalations and after-hours), number of tickets and repeat issues, and which roles touched the account. Red flag: if senior or owner time is propping up profitability, your pricing is already leaking.

2. Simulate growth. Pretend this client grows by 20 percent overnight. Does revenue increase automatically under your model? Does workload increase faster than revenue? Red flag: if growth increases effort but not revenue, your pricing is upside down.

3. Check for tool creep. List what’s bundled into the contract: security stack additions, backup or DR changes, monitoring or compliance tools added “just because.” Were rates adjusted when these were added? Red flag: invisible value is expensive value.

4. Get real about margin. Ignore cash in the bank. Look at monthly recurring revenue from this client against fully loaded labor cost and tooling overhead. Then ask: if you cloned this client ten times, would your business be healthier, or exhausted?

5. Do the gut check. Would you sell this contract today at the same price? Would you defend this pricing to a peer? If either answer is “not really,” it’s time to adjust.

A scalable pricing model grows revenue as effort grows, rewards efficiency instead of heroics, and makes margins obvious instead of mysterious. If your pricing only works because your team is working harder every month, it isn’t scaling. It’s sprinting on a treadmill.

You can’t price what you can’t see

Amanda’s stress test hinges on things a lot of MSPs genuinely can’t answer fast: how many devices are actually live on a client’s network right now, how much of last month’s ticket volume was noise versus real work, and where a tool got added to a contract without anyone updating the rate.

That’s usually not a discipline problem. It’s a visibility problem. Our own 2026 IT Trends research found that 36% of MSPs are running 10 or more tools across their stack, and cost has overtaken uptime as the metric IT teams say matters most to how they’re judged. Pricing decisions made without a current picture of what’s actually running, and what it’s actually costing to support, are educated guesses dressed up as strategy.

Sometimes tool creep isn’t even something you added on purpose. It’s something a vendor changed on you. SolarWinds eliminated perpetual licensing in August 2025 following a private equity acquisition, and MSPs and IT teams running it have widely reported renewals coming back 100 to 300 percent higher on the next cycle. That’s exactly the kind of invisible cost shift the stress test above is built to catch: if a piece of your own stack gets more expensive overnight and your client pricing doesn’t move with it, the hit lands on your margin, not the vendor’s.

That gap is part of why we built Auvik AI, the newest addition to the Auvik platform. It’s grounded in your actual network data, topology, device relationships, alert history, performance metrics, not generic guidance pulled from the public internet. For pricing specifically, that shows up in two practical ways:

  • Accurate device counts, in real time. If you’re running any flavor of per-device pricing, your billing is only as honest as your inventory. Auvik’s always-current discovery and inventory mean you’re not relying on a spreadsheet from six months ago to know what you’re actually supporting.
  • Less reactive noise dragging down utilization. Auvik AI surfaces the alerts that actually matter instead of adding to the pile, close to the “arm that drives down reactive noise” Amanda points to as the difference between a pricing model that works and one that just looks like it does on paper.
  • Pricing you can actually plan around. Auvik has been a straightforward per-device subscription since day one — no perpetual-to-subscription switch, no surprise multi-year lock-in, no renewal that lands 2 to 3x higher than last year’s. If you’re currently weighing what a vendor pricing shakeup like that would do to your own margins, here’s a closer look at how Auvik’s pricing model compares.

Run pricing stress tests, then let’s talk

Pick one client contract you’d swear is profitable, and actually go check it. Pull the last 60 days of tickets, count the hours, and see if the story your margin tells matches the one you’ve been telling yourself.

If what you find looks more like a treadmill than a growth engine, that’s usually not a “charge more” problem. It’s a “see more” problem, and it’s exactly what Auvik AI, powered by Aurora, was built to help with. Grounding your operational and pricing decisions in what’s actually happening on your clients’ networks, not assumptions about what should be happening.

Book a demo to see what that looks like against your own environment, or explore Auvik for MSPs to see how the platform fits into how you run and price your business.

Auvik logo

Book an Auvik demo

See how Auvik simplifies network management in a live, guided demo.

FAQs about MSP pricing models

What is the average MSP pricing per user?

There’s no single honest number here, and treating one like gospel is part of what gets MSPs into trouble. Published ranges vary widely by region, service scope, and stack. If you want a broader industry benchmark, ScalePad’s 2026 MSP Trends Report surveys over a thousand MSPs on financial and utilization data, but even that only gets you in the neighborhood. Your own fully loaded cost to deliver is what should set your number, not someone else’s average.

What are the different pricing models for managed services?

Most managed IT services pricing models fall into three categories: per-user, per-device, and block-hour (also called time bank). Plenty of MSPs also blend two models together to fit different client segments.

Is block-hour pricing ever still a smart choice?

Potentially, in specific situations. It works fine for special projects or legacy clients you’re not trying to scale. It’s a weak fit as a primary growth model, since you can’t forecast, scale, or lead clients strategically when every hour is a transaction.

How do I know if my pricing model is actually working?

Look past cash in the bank. Check whether your model aligns with delivery costs, scales efficiently as client count grows, rewards efficiency instead of punishing it, and keeps individual contracts profitable, not just the business overall.

How do I move an existing client to a new pricing model without losing them?

Lead with what changes for them operationally, not just the number on the invoice. The conversation gets easier the more clearly you can already show what’s actually driving their current cost to serve.

Should every client be on the same pricing model?

Not necessarily. A hybrid approach is common, especially when your client base spans different verticals, maturity levels, or service depths. The goal isn’t uniformity. It’s making sure each contract is profitable on its own.

How often should I revisit my MSP’s pricing?

Often enough that “we’ve always priced it this way” stops being a valid answer. A quarterly gut check, plus a fuller review whenever you add tools, services, or a meaningfully different type of client, is a reasonable cadence. Revisiting doesn’t necessarily mean changing anything on the spot. Instead, it means giving yourself enough runway to plan the change properly and decide how you’ll bring it to clients, so the shift doesn’t cause unnecessary churn.

What’s the real difference between raising your rates and fixing your pricing model?

Raising rates buys you time, but fixing your model changes the underlying math. A rate increase on a model that doesn’t scale just delays the same problem at a higher price point.

Leave a Reply

Your email address will not be published. Required fields are marked *