TL;DR
What you bill a client doesn’t always reflect what it costs to serve them. Learn how connecting services, technician effort, contracts, and billing gives you a clearer view of profitability.
MSPs know what they earn from a client. Knowing exactly what it costs to earn that revenue is harder.
A managed services agreement might appear as a single recurring number on an invoice. But underneath it are dozens of moving parts: endpoints being managed, users being supported, networks being monitored, tickets being resolved, licenses being consumed, and technician hours being spent.
And those moving parts rarely stay still.
A client adds 20 devices. Ticket volume starts creeping up. A new site comes online. A senior technician begins spending more time on an environment that was once relatively easy to support.
The contract may not have changed; the economics of delivering it have.
That gap between what you sold and what you're actually delivering is where understanding MSP profitability gets difficult.
A contract tells you what you sold. It doesn't always tell you what you delivered.
Say you've sold a client a managed services package for a fixed monthly fee.
It covers Microsoft 365, endpoint security, network monitoring, and service desk support.
That's simple enough commercially. But your costs don't necessarily follow the same model.
Microsoft 365 follows users. Endpoint security follows devices. Network monitoring follows infrastructure. Support follows the amount and complexity of work your technicians actually perform.
So when the client grows from 100 to 130 devices without adding 30 users, your endpoint costs move even if the unit you bill against doesn't.
When ticket volume doubles, technician cost moves again.
When another location opens, the environment you're responsible for gets larger and potentially more complex.
None of that automatically means the contract is unprofitable. But if the only number you're watching is recurring revenue, you may not know when it becomes one.
The Service Delivery Map creates the connection
SuperOps uses the Service Delivery Map to connect the operational reality of the client environment with the commercial reality of the MSP contract.
At a simple level, it helps answer:
What are we delivering, to whom, and under which contract?
A service can be associated with the entity to which it is actually delivered, such as a user, asset, asset group, requester, client site, or another relevant group.
That matters because the underlying quantities can change. If a client adds devices, a device-based service grows with the environment. If the number of users changes, user-based services change.
Rather than assuming that cost follows the same unit used for billing, the MSP gets a model based on how services are actually delivered.
That produces a better foundation for calculating COGS and, eventually, profitability.
Why this matters for MSP contracts
MSPs simplify pricing for good reason.
Clients don't need an invoice that recreates every operational detail involved in delivering their service. Flat-rate, per-user and bundled agreements make managed services easier to understand and buy.
The problem starts when that commercial simplicity becomes operational blindness.
You might charge per user while incurring costs per user, per device, per site, and per hour of technician effort.
Trying to force all of those costs back into the unit you happen to bill against gives you an incomplete view of the contract.
The better question is:
What are we actually delivering, where are we delivering it, and what is driving the cost?
That's the role of the Service Delivery Map in SuperOps.
Map services to where they're actually delivered
The Service Delivery Map connects a service to the entity consuming it—whether that's a user, asset, asset group, requester, client site, or another relevant group.
That distinction matters because those quantities change independently.
If the client adds devices, device-based service delivery changes with them. If their workforce grows, user-based services change. If their infrastructure expands, the services tied to that infrastructure change.
Instead of assuming the cost of a contract follows the same unit used to bill for it, you can follow the way the service is actually being delivered.
That gives you a much more useful foundation for understanding COGS.
And it lets you keep the pricing model simple for the client without simplifying away the economics you need internally.
Technician time belongs in the same picture
Licenses and services are only one side of delivery cost. The other is your people.
Consider a support request covered under a recurring agreement. The client isn't billed an additional hour when your technician resolves it, but that doesn't make the hour free.
Someone on your team spent time fulfilling the promise made in the contract. The question isn't simply whether that hour was "billable" or "non-billable." The more useful question is:
Which client consumed the time, what work consumed it, and which commercial agreement was that work fulfilling?
Once technician time is connected to the ticket, client, and contract that generated it, utilization stops being purely an operational metric.
It becomes part of the economics of the account.
Preserve the context from work to revenue
This is where the relationship between PSA and RMM becomes more important than simply having both capabilities in one platform.
Your RMM knows what’s happening across the client environment. Your service desk captures the work it generates. Time tracking shows the technician effort involved. Contracts define what you’ve committed to deliver, and billing shows the revenue that comes back in return.
Individually, each piece tells you something useful.
Connected, they tell you whether the work you're doing makes economic sense.
That's the real opportunity behind bringing operations and service management together: the context doesn't disappear as work moves through the business.
You don't have to reach the end of the month and reconstruct the story from different systems and spreadsheets.
The model has to keep up as the MSP grows
Maintaining these relationships manually may be possible when you're managing a handful of clients.
It gets harder very quickly.
Every new client brings more endpoints, services, tickets, contracts, technicians and exceptions. If understanding the economics of each account depends on someone manually keeping all of those relationships current, the model eventually breaks.
Automation is what makes it scalable.
Policies reduce repetitive operational work. Contract rules determine where agreements apply. Service Delivery Maps keep services aligned with changing client environments. Time tracking captures technician effort.
And AI can remove work from those same workflows—across the service desk, scripting, patching, reporting, anomaly detection and analytics.
The point isn't automation or AI for its own sake.
It's to reduce the human effort required to deliver a service without losing the context required to understand what that service costs.
From operational visibility to business visibility
Once that context stays connected, you can start asking much better questions.
Which clients are consuming more technician time than expected?
Which services are becoming more expensive to deliver?
Has the environment changed since the contract was priced?
Is repetitive work eating into the margin of an otherwise healthy agreement?
Is a high-revenue client actually a high-margin client?
These aren't questions about whether your team is doing its job. They're questions about whether the way you're doing that work is good for the business.
MSPs already know how to deliver service. The opportunity is to understand the economics of that delivery while there's still time to act on it.
When you can trace what you manage → what you deliver → the work it requires → the revenue it generates, service delivery stops being something you measure separately from the business.
It becomes the connection between operations and profitability.
And once you can see that connection, the next question is:
What do you change to make the economics better?
That's where we'll go in the final article: how to turn visibility into a profitability engine.