Pricing it support per user or per device, and which is honest

3 days ago
3 min read

Introduction

Per user and per device produce completely different figures for the same business. A company where everybody has a laptop, a phone and a desktop is cheap per user and expensive per device. A shift-based business where forty staff share ten machines is the reverse.

Neither model captures what actually generates work, which is complexity: legacy systems, unsupported software, multiple sites, compliance obligations and the age of the hardware. Two clients with identical headcount can differ by a factor of three in tickets. Headcount alone will never tell you which.

The practical answer is a per-user base with a complexity loading, and knowing your own ticket data well enough to set it. Without the data it is guesswork either way.

1. Pricing it support per user or per device starts with your ticket data

Measure before choosing a model.

Count tickets and time per client per month

Then divide by what they pay. Report it per client, not as an average. The variation across a book is routinely dramatic. Run it for a quarter rather than a month.

Look at what correlates with tickets

Users, devices, age of estate, number of sites, legacy applications. Plot each against ticket volume. Whichever correlates best is your pricing unit. The answer differs between books.

2. Choose per user for most businesses

It is simpler and it usually tracks the work.

Users generate tickets; devices mostly do not

A person with three devices raises roughly as many tickets as a person with one. The human is the variable. Devices break; people ask questions.

Include a reasonable device allowance

Say what is covered per user in the agreement — a laptop, a phone, a shared machine — and price beyond it. Two devices per user is a common allowance.

3. Load the price for complexity explicitly

This is where the model becomes honest.

Publish loadings for named factors

Unsupported operating systems, legacy line-of-business applications, additional sites, compliance obligations, hardware over a stated age. Six factors is enough to be useful.

Explain the loading as a cost of the estate

Clients accept it when the reason is specific. Vague surcharges get challenged. It also creates an incentive for them to modernise, which reduces your tickets. Both sides gain from that.

4. Define what the contract excludes

Project work absorbed into support destroys margin.

List the exclusions in the agreement

Migrations, office moves, new installs, upgrades, out-of-hours work. Each priced separately. Named rather than implied. Put the list in the agreement itself.

Quote projects separately and properly

A migration is weeks of planned work and cannot be delivered inside a monthly fee. Scope and schedule it like any project.

5. Review and true up annually

Contracts drift out of alignment every year.

Check user and device counts

Headcount changes and nobody tells you. It moves in both directions. An annual reconciliation recovers revenue you are already delivering. Check licence counts against the contract.

Reprice the loss-makers with the data

Present the ticket log. A client consuming three times what they pay usually accepts an adjustment when shown the numbers. Data makes it factual rather than awkward.

Conclusion

Measure before choosing: count tickets and time per client per month, divide by what they pay, and see which of users, devices, sites or estate age actually correlates with the work.

For most businesses per user is both simpler and closer to reality, because people raise tickets and devices largely do not — so include a stated device allowance and price beyond it. Then load explicitly for named complexity factors, since that is what genuinely drives volume and it gives clients a reason to modernise. List the exclusions in the agreement, quote migrations and installs as separate projects, and reconcile user counts annually while repricing the loss-makers with the ticket log in hand.