Two Tools That Answer Different Questions
Every MSP runs both, and both create tickets, which is why they get confused. The useful distinction is which question each one answers. RMM answers what is happening on a client's machines and lets you act on it. PSA answers who did the work, against which agreement, and whether it made money.
Put another way, RMM is a technician's tool and PSA is an owner's tool, even though technicians live in both all day. An MSP with a strong RMM and a weak PSA delivers efficient service it cannot bill or measure. An MSP with a strong PSA and a weak RMM has excellent reports about work it is still doing by hand.
What RMM Does for an MSP
RMM software puts an agent on every managed endpoint and server and reports back to a central console. Its job is to turn a fleet of client machines into something a small team can watch and change at scale.
- Monitoring and alerting: disk space, services, hardware health, offline devices and failed backups.
- Patch management, which drives your patch compliance rate.
- Scripting and automation, such as the local administrators audit script run across every client at once.
- Remote access for technicians, so a ticket can be worked without a site visit.
- Asset inventory: hardware, software and warranty data that feeds lifecycle planning.
RMM is also the most powerful account in your business, because it can run code on every client machine you manage. Treat access to it as a security decision, with MFA, named accounts and no shared logins, for the reasons covered in removing shared admin accounts.
The RMM is only as good as the policies you load into it. Out of the box, most products either alert on everything or on almost nothing, and neither helps. Build one standard monitoring and patching policy per device type, apply it to every client, and treat exceptions as a documented decision rather than a quiet override. Standard policies are what let endpoints per technician rise without service getting worse, and they are what a NOC needs before it can work your alerts sensibly.
What PSA Does for an MSP
PSA is the system of record for the business side of service delivery. It knows every client, every agreement and every hour, and it turns them into invoices and reports.
- Ticketing and dispatch, with SLA clocks that track first response time and mean time to resolve.
- Time entry against tickets, projects and agreements.
- Contracts and agreements, including what is covered and what is billable.
- Billing and invoicing, including recurring fees, overages and project milestones.
- Reporting on profitability by client, technician and service, often including CRM, quoting and procurement.
If you run formal ITSM or ITIL processes, the PSA is where they live. It is also where the numbers for a client QBR come from, so the quality of your reviews depends on the quality of your time entry.
The PSA's accuracy depends on how agreements are set up. Each client agreement should state what the recurring fee covers, what is billable on top, and which ticket types count against it. When agreements are loose, technicians guess, and the guesses show up months later as work nobody invoiced. Getting agreements right is also what makes a price increase defensible, because you can show the client exactly what the current fee has been buying.
PSA and RMM Side by Side
| Question | RMM | PSA |
|---|---|---|
| Main user | Technicians and the NOC | Service managers, dispatch, finance and owners |
| Core record | The device | The ticket, the agreement and the client |
| What it creates | Alerts, scripts, patch results, inventory | Tickets, time entries, invoices, reports |
| Failure you notice | Missed alerts and unpatched machines | Unbilled work and margin you cannot explain |
| Security exposure | Very high: it can run code on every client machine | High: it holds client data, contracts and billing |
| KPIs it feeds | Patch compliance, backup success, tickets per endpoint | Utilization, effective hourly rate, SLA attainment |
The failure row of the table is the one to remember when a report looks wrong. A missed alert or an unpatched machine points to the RMM and its policies. Margin you cannot explain points to the PSA, its agreements and the quality of time entry. Knowing which system owns a symptom saves hours of looking in the wrong place.
Why the Integration Matters More Than Either Tool
Most MSPs aim to connect the two so that an RMM alert opens a PSA ticket, the ticket carries the device details, and the time spent lands against the right agreement. Kaseya's 2025 benchmark survey found that 95% of MSPs say connecting their RMM, PSA and IT documentation tools is essential. The value is not in either product alone, it is in the handoff between them.
That handoff is also where things quietly break. The common failures are predictable:
- Alert noise: every monitor opens a ticket, the queue floods, and technicians start closing alerts without reading them.
- Work fixed in RMM but never ticketed, so it is invisible to billing and to hands-on time per ticket.
- Devices mapped to the wrong client or agreement, so costs land on the wrong account.
- Automated fixes that close tickets with no time recorded, which makes tickets per endpoint look better than reality.
A quarterly check of alert-to-ticket mapping, device-to-client mapping and auto-close rules costs a few hours and protects the reports every other decision depends on.
Suite or Best of Breed
Vendors sell PSA and RMM separately and as bundled suites, and the choice is less about features than about who you want to depend on. The trade-offs look like this:
| Approach | What You Gain | What You Give Up |
|---|---|---|
| One vendor suite | Tighter integration, one contract, one support line | Leverage at renewal; switching one tool means switching both |
| Best-of-breed pair | The strongest product on each side | You own the integration and fix it when either side updates |
| Suite plus a specialist | Bundle convenience with one area upgraded | A third integration to maintain and test |
Whichever route you take, price the tools as part of delivery cost. Tooling sits inside your managed services gross margin, and a stack bought for features nobody uses is margin spent twice: once on the license and again on the time to maintain it.
Migrations deserve more respect than vendors suggest. Moving PSA means moving agreements, open tickets, billing history and every report your finance process uses, and moving RMM means replacing the agent on every client device. Plan either one as an internal project with an owner, a test client, a period where the old and new systems run side by side, and a clear date after which the old one is read-only. The cheapest migration is the one you avoid by choosing carefully the first time.
How to Tell Whether Your Setup Is Working
A healthy PSA and RMM setup shows up in numbers you can already measure. If technician billable utilization looks high but effective hourly rate is falling, time is being recorded against work you are not billing for. If SLA attainment is strong but clients still complain, the RMM is probably not opening tickets for the problems they feel.
Treat both platforms as systems someone owns. In a small MSP that is often the owner or a senior technician with protected time each week; in a larger one it becomes a dedicated role. The Operations and Delivery section covers how MSPs structure that work as they grow.
Common Questions
Do I also need a documentation platform?
Yes, in practice. PSA and RMM record work and devices, but neither is a good home for passwords, network diagrams and client-specific procedures, which is what IT documentation tools are for.
Can a new MSP start without a PSA?
It can for a very small number of clients, but billing and time tracking in spreadsheets stop scaling quickly. Adopting a PSA before the client count grows is far easier than migrating years of messy history later.
Should clients get access to our PSA portal?
A client portal for raising and viewing tickets is usually worth offering. Keep internal notes, time entries and cost data out of anything the client can see.
Is the RMM agent a risk to our clients?
It can be, because a compromised RMM account can reach every managed machine. Enforce MFA, restrict who can run scripts, log every action and review access whenever staff leave.
Who should own PSA and RMM administration?
One named person for each, with a backup. Shared ownership usually means nobody reviews alert rules, contract mappings or permissions until something breaks.
Does switching PSA or RMM disrupt clients?
An RMM switch touches every client device, so it needs a planned agent rollout and a period of running both. A PSA switch mostly affects your own staff and billing, but test the first invoice run carefully.