The MSP pricing conversation nobody wants to have: per-device, per-user, or flat-fee

Most MSP pricing conversations happen once, early, and then never get revisited until something breaks — a client with an unusual device-to-user ratio blows up your margin, or a competitor undercuts you on a metric your own pricing doesn't even track. The three common models each protect something different, and none of them is universally correct. The mistake is picking one because it's what the last vendor used, without working out what it actually exposes you to.

Per-device

Per-device pricing tracks your actual cost driver reasonably well — more endpoints roughly means more monitoring load, more patching, more tickets. It breaks down with clients who run lean on hardware but heavy on users: a call center with three shared workstations and forty staff looks cheap under per-device pricing and is anything but cheap to support. It also creates a perverse incentive for the client to under-report devices, which means part of your job becomes an inventory audit against your own invoice.

Per-user

Per-user pricing fixes the call-center problem and tracks headcount-driven support load — new hires, offboarding, account provisioning — better than device count does. It breaks down in the other direction: a manufacturing client with two office staff and eighty pieces of shop-floor equipment looks cheap under per-user pricing while carrying a device fleet that's expensive to monitor and patch. Neither per-device nor per-user is wrong; each is a bet on which resource actually correlates with your cost to serve a specific client, and that correlation is not the same across client types.

Flat-fee

• Flat-fee is the easiest to sell — a client can budget against one number with no per-seat or per-device surprises as they grow or shrink slightly.
• It is the easiest to lose money on if it's priced from a snapshot of the client's environment at signing, and that environment changes materially without the price being revisited.
• It only protects margin if the contract has an explicit re-scoping trigger — a device count band, a headcount band, an annual review — not an informal "we'll revisit if it gets bad" understanding that never actually gets revisited.

The pricing model isn't what protects your margin. The re-scoping trigger is. A model without one just delays the conversation you're trying to avoid.

The practical version of this advice, independent of which model you pick: know your actual cost to serve per client, not per device or per user in the abstract, and revisit it against a real trigger — a renewal date, a headcount change past a threshold, an incident that revealed the environment had drifted from what you priced. A pricing model is a simplification of that cost. The simplification is fine as long as you keep checking it against reality instead of trusting it to stay accurate on its own.

We'll say plainly where Nexus itself stands on this, because it's directly relevant if you're evaluating us: we don't have public pricing yet. We're working with a small design-partner cohort in private beta on terms that fit their actual environment, not a rate card written in the abstract — which is close to the same argument as above, applied to us instead of to your own clients.