MSPs: Your Revenue Model Is Complex. Your Business System Probably Isn't Keeping Up.
Managed service providers operate one of the more structurally complex business models in the SME space. At any given moment, you're managing monthly retainer agreements, responding to ad-hoc support tickets, scoping and delivering one-off infrastructure projects, and renewing contracts that were signed eighteen months ago. Each of those revenue streams has different margin profiles, different delivery rhythms, and different client expectations.
Most MSPs track all of this across a collection of tools that don't talk to each other. A PSA tool for tickets, Xero for invoicing, a spreadsheet for retainer tracking, another spreadsheet for project scoping, and some version of a CRM that nobody updates consistently. The data exists, but it's fragmented across systems that were each built for a single purpose.
The operational cost of that fragmentation is real. According to a 2024 report from ConnectWise, MSP technicians spend an average of 23% of their working week on administrative tasks unrelated to actual service delivery. That's nearly one full day per technician, per week, spent moving information between systems rather than resolving client issues.
The Three Revenue Streams That Define an MSP
Before you can fix the system problem, it helps to be precise about what the system needs to handle.
Retainer revenue is your recurring base. Monthly managed service agreements, per-seat licensing arrangements, ongoing monitoring contracts. This revenue is predictable in theory, but in practice it carries hidden cost variability. A client on a flat monthly fee who logs forty support tickets in a month is far less profitable than a client who logs three. If your system doesn't connect ticket volume to client profitability, you're flying blind on margin.
Project revenue is episodic and scoped. A network refresh, a cloud migration, a new office fit-out. These have defined deliverables, defined timelines, and costs that need to be tracked against a quoted price. Project overruns are where MSP margin goes to die, and they almost always happen because actual hours aren't being measured against budgeted hours in real time.
Ad-hoc and break-fix revenue sits between the two. Work that falls outside a retainer scope, billed at an hourly or per-incident rate. This is often the hardest to track because it's reactive by nature. If your team resolves something quickly and doesn't log the time, you don't bill it. If they log it in a separate system that doesn't connect to your invoicing, it gets lost in the gap.
Three revenue streams, three different operational patterns, and most MSPs are trying to manage all three in systems that weren't designed to see them together.
What Client Profitability Actually Requires
Knowing that a client pays you $3,500 per month is not the same as knowing whether that client is profitable.
To calculate actual margin on a managed service client, you need to know: how many hours your team spent on their account, what those hours cost you in labour, what third-party costs were incurred on their behalf, and whether any of that work fell outside the retainer scope and should have been billed separately.
That calculation requires your timesheets, your project data, your expenses, and your invoicing to all reference the same client record. In a world where timesheets are in Harvest, expenses are in Xero, project notes are in Asana, and the client record is in HubSpot, that calculation either doesn't happen or it happens once a quarter when someone manually pulls it together in a spreadsheet.
By that point, you've already delivered another three months of service at a margin you didn't know was negative.
Opus is built on a single database architecture, which means every timesheet entry, every expense, every project task, and every invoice references the same client record. When you pull up a client in Opus, you're not looking at a summary imported from somewhere else. You're looking at the actual data. Hours logged by your team this month, costs incurred, revenue billed, and the margin between them, all calculated in real time.
That's not a reporting feature. That's a structural decision about how the data is stored.
Managing Retainers Alongside Projects
One of the persistent operational headaches for MSPs is that retainer work and project work often involve the same people, the same clients, and the same time, but they need to be tracked and billed differently.
A technician might spend Monday morning resolving a support ticket for a retainer client, Monday afternoon scoping a new server migration for the same client, and Tuesday on a project delivery for a different client entirely. If your time tracking system doesn't distinguish between retainer hours and project hours, your billing is going to be wrong and your project cost tracking is going to be wrong at the same time.
In Opus, projects and retainer engagements are separate entities, but they're linked to the same client record. A technician logs their hours against the specific engagement, whether that's a named project or a recurring support agreement. Those hours feed into the cost calculation for that engagement automatically. If a retainer client is consuming more hours than their agreement allows, that becomes visible before you've already absorbed the cost.
The same logic applies to equipment. MSPs often deploy hardware and software assets on behalf of clients, assets that need to be tracked for warranty, maintenance, and end-of-life purposes. Opus includes equipment management that links assets to client records and projects. When a piece of client equipment is due for replacement, it's visible in the same system you're using to manage their support tickets and invoices.
Financial Forecasting When Revenue Isn't Uniform
Forecasting is harder for MSPs than for businesses with a single revenue model. Your retainer base gives you a floor, but project revenue is lumpy and ad-hoc work is unpredictable. A meaningful forecast needs to account for all three.
Most MSPs either don't forecast at all, or they forecast only their retainer base and treat everything else as upside. That approach consistently underestimates capacity requirements and overestimates margin, because it ignores the cost of delivering the ad-hoc and project work that actually fills the calendar.
Opus connects the CRM pipeline to financial forecasting. When a project opportunity moves through your sales pipeline, its expected revenue and estimated costs are visible in your forward-looking financial view. Retainer renewals that are coming up for review are flagged. Projects in delivery have their actual costs tracked against budget in real time, so you can see whether the margin you quoted is the margin you're going to realise.
This is where the Business Triangle becomes relevant for MSPs specifically. The administration side of an MSP business, billing, reporting, contract management, asset tracking, tends to expand faster than in most industries because the service delivery model is so varied. When admin consumes 50% or more of your operational capacity, the time available for actual service delivery and business development shrinks accordingly. Compressing admin back toward 10% to 15% isn't about working faster. It's about removing the structural reasons it takes so long.
The Integration Problem MSPs Know Well
MSPs are, by definition, technology businesses. Which means MSP owners often know exactly how much integration debt they're carrying and exactly why it's a problem. They've built integrations for clients. They understand what happens when two systems share data via an API that breaks every time one of them updates.
The irony is that many MSPs tolerate exactly that situation in their own business operations. Zapier automations connecting their PSA to their accounting software, a custom script that pulls timesheet data into a reporting spreadsheet, a Slack bot that's supposed to notify the billing team when a ticket is closed but stopped working six weeks ago and nobody's fixed it yet.
Opus doesn't solve the problem by adding another integration layer. It removes the need for most of those integrations by putting the relevant data in one place to begin with. For the financial data that does need to flow to an external system, the two-way Xero sync means your invoices, payments, and reconciliation stay current without manual intervention.
For MSPs specifically, the practical benefit is that the people doing the work and the people managing the finances are looking at the same numbers. A technician closes a ticket, logs their time, and that data is immediately visible to whoever is managing billing and profitability. There's no end-of-month reconciliation exercise where someone tries to match timesheet exports to invoice line items.
What Changes When the Data Is Unified
When client profitability is visible in real time, you can have different conversations. A client who's consistently consuming more support hours than their retainer covers becomes a conversation about contract restructuring, not a surprise at year end. A project that's tracking over budget at the halfway point is a conversation with the client now, not an uncomfortable invoice dispute later.
When your pipeline and your financial position are in the same system, capacity planning becomes possible. You can see that three projects are due to start next month, that two technicians are already committed to existing deliveries, and that the retainer base is going to generate a certain number of support hours regardless. That's a staffing decision you can make in advance rather than a crisis you manage in the moment.
MSPs that grow past a certain size without fixing their operational infrastructure tend to hit a ceiling where every new client makes the business harder to run rather than more profitable. The margin per client decreases, the administrative overhead per client increases, and the business starts to feel like it's running at capacity without actually being at capacity.
The ceiling is usually a data problem. The information needed to run the business well exists somewhere in the business. It's just not in one place where it can be acted on.
If that description fits where your MSP is right now, the place to start is at [opus.net.au](https://opus.net.au).