Picture a 30-user agreement at its first renewal. The invoice still says 30. But in the last year you have supported two part-time bookkeepers who share one login, a summer intern, an outside accountant who gets VPN access every April, the owner's assistant who is technically employed by a different company, and four people who left months ago and whose accounts nobody told you to disable. Every one of them called your help desk at some point. None of them is on the invoice.
Per-user pricing works when the number you bill and the number of people who generate work are the same number. Most of the advice on MSP per user pricing is about the rate: what to charge per seat and what to bundle. This post is about the two decisions that come before the rate and decide whether it holds: what your contract calls a "user," and where the monthly count comes from. Then it gives you a worksheet to set the rate itself.
What is MSP per user pricing?
MSP per user pricing is a flat monthly fee for each covered person at a client, usually including support for all of that person's devices. A 30-person office at $150 per user pays $4,500 a month, whether those people have one laptop each or a laptop, a phone and a tablet.
It is one of the most common models for fully managed agreements. In Kaseya's 2023 Global MSP Benchmark Survey, 21% of MSPs said they sell an all-in per-user price, 26% combine per-user and per-device pricing, and 28% said they don't offer per-user pricing at all. The prices spread widely: 22% of respondents charged $50 to $100 per user per month and 17% charged $101 to $150, with smaller groups above and below. We broke down those ranges in how much managed service providers charge, and compared per-user with per-device and flat-fee models in MSP pricing models.
The spread exists because "per user" is not one product. It can mean a help desk seat or a bundle with security, backup and after-hours coverage inside it. And it can be counted in very different ways.
A per-user price is three decisions, not one
- The definition. Who counts as a user, who counts as a partial user, and who is not covered at all.
- The count. Which system produces the monthly number, on what date, with what floor.
- The rate. What one covered user costs you to support, plus your margin.
Get the rate right and the first two wrong, and you will still lose money, because you will be charging the right price for fewer people than you actually support.
Define "user" in the contract
"Per user" without a definition means the client decides who counts, and the client's answer is always "the people on payroll who have a computer." Write it down instead. Here is a starting point you can adapt:
| Who | Counts as a user? | How to handle it |
|---|---|---|
| Employee with their own login and mailbox | Yes | Full user rate |
| Part-time or seasonal staff with their own login | Yes, while the account is active | Full rate, or a defined "light user" rate if they only need email and one app |
| Several people sharing one login (front desk, shop floor) | Each person who calls you is a person you support | Count the people, or charge the shared station as a device |
| Shared mailboxes, service accounts, room and equipment accounts | No | Covered as part of the environment, not billed per user |
| Contractors and outside accountants with access | Yes, if you support their access | Bill as users while access is active, or exclude them in writing and bill support hourly |
| Departed staff whose accounts are still active | Yes, until the client asks you to offboard them | Counting them is the incentive for the client to tell you |
| Email-only users with no managed device | Partial | A lower "light user" rate, defined by what it excludes |
Two clauses do most of the work. First, the user is defined by an active account in the client's identity system, not by payroll, because the account is what generates tickets. Second, the agreement says what happens to someone in none of the categories: they are supported at your hourly rate until the client adds them as a user.
The "light user" tier is worth the effort if your clients have a lot of seasonal or email-only staff. Without it, you either overcharge for people who barely call, which invites the client to hide them, or you leave them off and support them for free.
Pick one count source and a true-up date
Every count source is wrong in its own way:
- Licensed accounts in the client's Microsoft 365 or Google Workspace tenant. Closest to "active account," and hard to argue with. But it includes accounts nobody disabled, and misses people who share a login.
- Contacts in your PSA. Easy to bill from, but only as accurate as whoever maintains them. Contacts get added when someone calls and rarely get removed.
- The client's employee list. The number the client trusts most, and the one least connected to the work: contractors and shared logins are invisible to it.
Pick one, name it in the agreement, and count on the same date every month. Then put a floor under it: a minimum user count or minimum monthly fee, so a client who drops from 30 users to 18 in a slow season doesn't cut your revenue faster than your workload drops.
Your PSA can do more of this than most MSPs set up. Autotask's contract billing rules bill per contact or per device: on a date you select, Autotask counts the active contacts or devices tied to a billing product and creates the charges for the next billing period. The same page notes the limits: billing rules support monthly billing periods only, and prorating applies at the beginning but not the end. If you bill per user as a recurring service instead, Autotask's unit adjustments prorate added units from the effective date to the end of the billing period, while price changes wait for the next period. In ConnectWise, the per-user count usually lives as the quantity on an agreement addition, which means someone has to update it. Whatever your PSA, the count should come from a process with an owner and a date, not from whoever notices at renewal.
What per-user pricing should not absorb
Per-user pricing prices people. Servers, firewalls, switches, wireless, a line-of-business application server and the client's phone system are not people, and they generate work whether the office has 12 users or 40.
The usual fix is a site or infrastructure fee alongside the per-user rate: a fixed monthly amount per location, or per server and network device. Without it, a small office with a lot of infrastructure is underpriced, and you will be tempted to raise the per-user rate to compensate, which then overprices your larger, simpler clients.
The per-user pricing worksheet
With the definition and the count settled, the rate is arithmetic. Fill in one row per input, from your own data:
| Input | Where to get it | Example |
|---|---|---|
| Labor hours per user per month | Time entries for clients on the same tier, divided by their covered users, over 6 to 12 months | 0.6 hours |
| Loaded technician cost per hour | Salary, payroll taxes, benefits and service desk overhead, divided by the hours a technician actually works tickets | $65 |
| Tools and licensing per user | RMM, PSA, security stack, backup and anything else you include, divided by covered users | $32 |
| Target gross margin | Your own target for managed services | 55% |
Then:
Per-user rate = (hours per user × loaded cost per hour + tools per user) ÷ (1 − target margin)
With the example inputs: 0.6 × $65 = $39 of labor, plus $32 of tools, is $71 to serve one user. At a 55% margin, $71 ÷ 0.45 is about $158 per user per month. The example numbers are illustrative, not a benchmark. Use your own.
Three things to do with the result:
- Set it per tier, not per client. Compute hours per user separately for each package you sell. A client with after-hours coverage and a client without it should not share an average.
- Compute the light-user rate the same way, from the hours your email-only and seasonal users actually take.
- Price infrastructure separately, from the hours logged to server, network and line-of-business tickets, so it doesn't leak into the per-user number.
The input that breaks the worksheet
The last three inputs are easy to check. The first is only as good as your time entries. And time entries are worst at exactly the work that per-user pricing is supposed to cover: users calling in.
The two-minute password reset done live on a call, the callback to confirm a fix, the "while I have you" question, the after-hours call the on-call tech meant to write up in the morning. That work happened, it cost technician time, and much of it never becomes a time entry. We went through where that time goes in MSP time tracking: the leak is at the phone, and why it makes your busiest clients look the most profitable in MSP profit margins.
For per-user pricing, the damage is specific. Missing phone work lowers hours per user, which lowers the rate the worksheet gives you. And it lowers it most for clients whose users call the most, so the clients who most need a higher rate look like they need the lowest.
Before you trust hours per user, run a check. Export a week of call records from your phone system and a week of time entries from your PSA. For your three busiest clients, look for each support call of more than a couple of minutes and a matching time entry. Count the calls with nothing. If you'd rather estimate the gap first, the free phone-to-PSA gap check takes about two minutes. If the gap is small, your hours per user are honest. If it is large, fix capture before you reprice, or you will set the new rate from the same undercount.
This is the problem Vight was built for. It pulls each recorded support call from your phone system, matches it to the client and ticket, and posts a summary note and a time entry to the ticket in ConnectWise, Autotask, HaloPSA or Syncro, so phone work shows up in hours per user without a technician stopping to write it down. On ConnectWise, Vight's profitability view puts each client's invoices next to the time logged against them. If you want to see what your hours per user look like with phone work included, book a demo.
Common questions about MSP per user pricing
Is per-user or per-device pricing better for an MSP?
Neither, in general. The better unit is the one that predicts your labor. Compare hours per user and hours per device across clients on the same tier; whichever ratio is more consistent from client to client is the unit that tracks your work. The MSP pricing models post walks through that test.
Should a client pay for users who never call?
Yes. A per-user rate is an average across everyone covered. The quiet users pay for the loud ones, and that only works if both are counted. If a group of users truly needs much less, give them a light-user rate with a defined scope rather than leaving them off.
How often should I true up the user count?
Monthly, on a fixed date, from the count source named in the agreement. With an annual true-up, new staff are supported for months before anyone bills for them, and the fix is a catch-up invoice the client didn't budget for.
Should per-user pricing include servers and network gear?
Usually not. Charge a site or infrastructure fee for them, so the per-user rate reflects what people cost to support and the infrastructure fee reflects what the environment costs.
What should I do with a client whose real hours per user are far above the rest?
Check the time data first, then the scope. A client far outside the band is usually a scope problem: a demanding line-of-business app, a compliance requirement, or a few very heavy users. That calls for a different tier or an add-on, not a different per-user rate for everyone.