Pricing: Per Device, Per User, Per Outcome

How the service is priced shapes what the provider does. Each model creates an incentive that works against the client in some specific way, and knowing which is the point.

The commercial decision in “Pricing: Per Device, Per User, Per Outcome” is stronger when it rests on consistently recorded delivery effort rather than memory. An MSP can use the full article to relate time to clients, projects and recurring tasks, while keeping service quality, contractual scope and customer outcomes as separate measures.

For an independent operational benchmark, compare the local practice with official ITIL resources; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

Per device

Simple to count, easy to explain, and the most common.

The incentive: more devices is more revenue, so decommissioning old machines reduces your income.

Which means the provider has a reason not to push for the hardware refresh the client needs, and clients notice this eventually.

Per user

Closer to how clients think about value.

The incentive: additional devices per user cost you and earn nothing, so you push for fewer devices.

Generally healthier, and it breaks down where device counts vary wildly between users — a designer with three machines and a warehouse worker sharing one.

Per outcome or flat fee

A fixed amount for a defined service level.

The incentive: fewer incidents is more margin, which aligns with the client's interest better than either of the above.

And it penalises you for a client whose estate is a mess, which is the risk — covered in the margin note.

It requires knowing your cost per client, which many providers do not.

The tiering question

Most providers sell tiers: basic monitoring, managed, fully managed.

The difficulty is that the difference between tiers is frequently unclear to the buyer, and the cheapest tier produces the most dissatisfaction because the client expected the service and bought the monitoring.

If you tier, write what each includes and excludes in client language.

Project work

Separate from the recurring fee, always.

A provider absorbing project work into the managed fee is funding the client's improvements from its own margin.

The boundary needs stating at onboarding, which the scope creep note covers.

Changing the model

Difficult mid-relationship and sometimes necessary.

The honest route: explain what is not working, show the figures, and give a transition period.

Reframing the same price under a new model to extract more is noticed, and it is the kind of thing clients discuss with each other.

What to know before choosing

Your cost per client, which requires time tracking that actually happens.

Which clients are profitable and which are not.

Most providers discover they have two or three clients consuming most of the support capacity, and the pricing model determines whether that is visible.

What to check

Does your model give you a reason to keep old hardware in service?

Do you know your cost per client?

Is the difference between your tiers clear to a buyer?

And is project work separate from the recurring fee?

The point

Per-device pricing gives you a reason not to push for the hardware refresh the client needs, and clients notice this eventually..

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.