Kyslan / Library

Billing models

MSP billing models, and the money each one loses

Updated 27 August 2026 · 11 min read · By Kyslan, a Northbeams product

Kyslan finds the unbilled work in your own PSA, then writes the change order that bills it. First report free, read-only. Claim it back →

The six models at a glance

A billing model is not a pricing strategy. The model decides what you count. The price decides what each counted thing costs. Confusing the two is why so many contracts are unprofitable at a price the owner believes is healthy.

Almost no MSP runs a single model. The normal shape is a recurring model (per user, per device or tiered) plus time and materials for anything outside it, plus blocks for projects. That combination is the right one, and it is also where most billing errors are born, because work has to be sorted into the correct bucket by a human at the moment the ticket is closed.

Per user (per seat)

You bill a fixed amount per person per month, and that person's laptop, phone, email account, backup and support are all included. It has become the default for full-service managed IT because it prices the thing a client understands. A finance director knows how many people they employ. They do not know how many virtual machines they own.

What per user gets right

• The client can forecast their bill from their hiring plan.
• You are not penalised when someone buys a second monitor, a tablet or a work phone.
• Headcount is auditable from a source you both trust, usually the directory or the payroll count.

What per user gets wrong

It assumes users are similar. A warehouse worker who logs in twice a week and a partner who travels with three devices and calls at 11pm cost you wildly different amounts to serve, and per user charges them the same. The fix is not to abandon the model, it is to split it: a light seat and a full seat, or a per user base with a device add-on above a threshold.

Per device

You bill per workstation, per server, per firewall, per switch. It was the original managed services model and it still fits any client where devices outnumber or undercount people: manufacturing floors, hospitals, shift-based operations, retail estates with shared tills.

Typical structure separates device classes, because a server is not a laptop:

Per device is the model with the tightest link between your tooling and your invoice, which is a strength and a trap. The RMM knows exactly how many agents are deployed. If the contract does not read that number, the two drift apart within weeks of the first onboarding.

Tiered bundles

Bronze, silver, gold. Or Essential, Advanced, Complete. Each tier adds services on top of the last, and the client picks one for the whole company or per user.

Tiering works because it makes an upgrade conversation easy: you are not asking for a price rise, you are asking them to move up a tier they already understand. It fails when the tiers are not genuinely different. If your bronze clients receive gold service because your engineers cannot be bothered to check the entitlement before helping, you have a flat fee with extra paperwork.

Making tiers hold

1. Every tier boundary must be enforceable by a rule an engineer can check in under ten seconds.
2. Anything outside the tier gets a ticket type that bills, not a note in the timesheet.
3. Review which tier each client should be on once a year, not when they complain.

Flat fee, all you can eat

One number per month, everything included. Clients love it and it is the simplest thing you will ever invoice.

It is also the model that quietly kills margin, because it removes the only signal that tells you a client has changed. When a 40 person client becomes a 70 person client on a flat fee, nothing on your side goes off. The work rises, the invoice does not, and the account slides from your best margin to your worst without a single alert.

If you run flat fee, put a mechanism in it. The usual one is a band: the fee holds between 35 and 45 users, and outside that band the fee is renegotiated. That single clause turns an invisible loss into a scheduled conversation.

Prepaid blocks of hours

The client buys 20, 50 or 100 hours up front at a discounted rate and draws them down. It suits co-managed IT, project work and clients who want support without a full contract.

Blocks fail in one specific way, and it is the most expensive failure in this article: the balance goes negative and nobody notices. The engineer keeps working because the client is a good client. The hours keep being logged against a block with nothing left in it. Nine months later somebody runs a report and finds 60 hours of unbilled work that is now too old to invoice without an argument.

Time and materials

Billed by the hour plus parts. Nobody's primary model any more, but everybody's secondary model, and that is exactly why it leaks. Time and materials work is the overflow bucket. It happens when something falls outside the agreement, which means it happens under pressure, at the end of a long ticket, when the engineer wants to go home.

Three rules keep it honest:

• Time gets entered the same day. Time reconstructed on Friday is time rounded down.
• Every ticket has a billable flag set deliberately, not left on whatever the default was.
• Out-of-hours has its own rate and the rate applies automatically from the timestamp, not from the engineer remembering.

Where each model leaks

Published billing research puts the revenue a typical MSP fails to invoice at 5 to 15% of what it earns. That range is not one big problem. It is the sum of small, model-specific gaps:

Each of these is a query, not a project. The reason they go unrun is that they live in three systems that do not talk: the PSA holds the agreement, the RMM holds the reality, and the accounting package holds what you actually invoiced. Reconciling them by hand takes a day a month, so it happens twice a year, so the drift compounds. That reconciliation is exactly what Kyslan automates.

How to choose one

1. Count what the client can count. If they cannot verify the number on the invoice, every renewal becomes a negotiation about the number instead of the service.
2. Pick the unit that grows when your work grows. If the client doubles their staff and your invoice does not move, the model is wrong.
3. Do not run more than two recurring models across your whole book. Every extra model is another set of reconciliation rules, and rules that are not run are not rules.
4. Price the exceptions before you need them. Out of hours, projects, onboarding and offboarding all need a published rate on day one, or they become free.

Moving clients to a new model

Model changes go badly when they arrive as a surprise at renewal. What works:

• Model the new price for that specific client, on their real numbers, before you say a word.
• Show them both invoices side by side for a month they have already lived through.
• Cap the first-year movement. A client who would jump 40% gets a two-step move, and you say so up front.
• Change the model and the price in separate conversations where you can. Doing both at once reads as a rise dressed up as a restructure.

If the move is really about margin rather than structure, read how to raise MSP prices without losing clients instead. Changing the model to hide a rise is a tactic clients see through.

Common questions

Keep reading