A PSA is professional services automation, and for an MSP it is the business management software the company runs on rather than the tool its technicians work in. The RMM watches the machines.
The PSA holds the tickets, the time entries, the contracts, the service levels and the invoices, which means it is where the money is calculated.
That is why the two get bought together and confused constantly, and it is why the PSA decision deserves more care than it usually gets: an RMM can be swapped in a quarter because it only has to be reinstalled, while a PSA holds years of history that everything else references.
- PSA stands for professional services automation
- The RMM watches endpoints; the PSA runs tickets, time, contracts, billing
- They are bought together because an alert should become a ticket
- The PSA is the system of record, so replacing it is far harder
- A PSA is not a CRM, and using one as the other fails slowly
On this page
The partsWhat is actually in a PSA
Under the PSA features lists, MSP PSA software is five things that happen to share one database, and the sharing is the entire point.
Ticketing. Service desk management that collects client requests from email, a phone call, a portal and automated alerts from the monitoring tools, then routes and prioritizes them. This is the part people see and the part demonstrations lead on.
Time tracking. Hours recorded against a ticket, a project or a client contract, along with expenses. Unglamorous, and it is the reason the rest exists.
Contract management and service levels. What each client has bought, what is included, what is billable beyond it, and what response time was promised. This is where an agreement stops being a document and becomes something the software can check.
Billing and invoicing. Turning the time entries and the contract terms into an invoice, usually monthly, usually recurring. This is where errors are expensive in a way that a missed alert is not.
Project management and reporting. Work that is not break-fix, such as onboarding a new client, and the management numbers that say whether any of the services are profitable.
The reason MSPs buy one service management platform rather than five tools is the integration between those features. A ticket knows which contract it falls under, so the time entered on it knows whether it is billable, so the invoice writes itself.
Assemble that from separate software and somebody re-keys the same information three times a month.
How it worksHow an MSP PSA works day to day
The short answer to what is PSA software is a workflow. An MSP PSA follows one piece of client work from the first request to the paid invoice, and each step feeds the next without anybody copying data between tools.
1. Intake. A request arrives by email, phone, the client portal or an RMM alert, and the PSA ticketing system opens a ticket under the right client and contract. 2. Dispatch. Ticketing automation applies the rules: category, priority, the service level clock, and which technician or queue gets the work.
3. Work. The technician resolves the ticket and logs time against it, often with a timer running inside the ticket. 4. Approval. Time entries and expenses are reviewed, then matched to the agreement that decides what is included and what is billable. 5. Billing.
The platform builds the invoice from recurring services, billable time and any products sold, and passes it to the accounting software. 6. Reporting. The same tracking data shows service level performance, technician utilization, and profitability by client and by agreement.
Project management runs beside that loop for onboarding, migrations and other planned work, with tasks, budgets and resource scheduling in the same system.
That is what professional services automation means for MSPs in practice. The automation is mostly unglamorous: routing, reminders, escalations, recurring invoices. What it buys MSPs is service operations that do not depend on one person remembering what to bill, and management data nobody has to assemble by hand.
The other MSP tools a PSA connects to
The PSA RMM integration, covered in the next section, comes first, and it is not the only one. PSA software for MSPs usually sits in the middle of the tool stack, and the common connections are these.
- Accounting software, so invoices and payments are not typed twice.
- Documentation tools, so a ticket opens beside the client's passwords, network notes and procedures.
- Quoting and procurement tools, so an accepted quote becomes a project, a product order and an invoice line.
- Email, calendar and chat, for ticket intake, scheduling and client updates.
- A client portal, where customers raise requests, follow ticket status and approve quotes.
Vendors sell this two ways. A standalone PSA integrates with whichever RMM and tools the MSP already runs. An all in one platform puts PSA, RMM and sometimes documentation under one login, trading choice for fewer joins to maintain.
The asymmetryWhy the PSA is the harder decision
This is the part that buying guides skip, and it is the one that costs money.
An RMM is a deployment. Its value is in the agents, the scripts and the alerting rules, and all three can be rebuilt. MSPs move between RMM tools regularly and it is unpleasant rather than dangerous.
A PSA is a record of the MSP's operations. It holds every ticket the business has ever raised, the time entries those tickets carry, the contracts that price them and the invoices that came out of the whole arrangement.
It is referenced by the accounting software, by the reporting somebody presents to clients, and by any question that starts with what did we do for them last year.
So the two decisions are not symmetrical. Choosing RMM software badly costs a migration. Choosing PSA software badly costs a migration plus the history, and the history is the part that cannot be redeployed. That asymmetry is a reason to spend the evaluation effort on the PSA and to be more willing to compromise on the RMM.
The practical consequence is a question to ask early rather than late: what does an export look like. Not whether one exists, but what comes out of it, in what format, including closed tickets, time entries and the contract each one was billed under. A provider that cannot answer that has told you the cost of leaving.
PSA vs CRMA PSA is not a CRM
PSA vs CRM is the other comparison that comes up in every evaluation. These tools overlap enough to be substituted for each other, and the substitution fails slowly enough that nobody notices for a year.
A CRM tracks the relationship before it is a contract: prospects, conversations, proposals, the pipeline and why deals were won or lost. Its unit is an opportunity.
A PSA tracks the relationship after it becomes a contract: what was promised, what was delivered, how long it took and what it should be billed. Its unit is a ticket or a time entry.
Small MSPs commonly run one and pretend it is the other. Using a CRM as a PSA means time and tickets live in spreadsheets and billing becomes a monthly reconstruction. Using PSA software as a CRM means prospects are stored as clients with no contract, which quietly corrupts every management report about how the business is doing.
By stageWhich parts you need yet
PSA software is sold as one platform for running service operations, and MSPs adopt its features in stages whether or not they meant to. What follows is what tends to hurt first at each size, because that is what decides which modules matter.
| Stage | What actually hurts | What you need from the PSA |
|---|---|---|
| One or two people | Remembering what was promised to whom | Ticketing and time entry, and nothing else yet |
| Three to ten | Billing takes most of a week every month | Contracts, rates and invoicing that follow from the tickets |
| Ten to thirty | Nobody can say which clients are profitable | Reporting per client and per contract, which needs the time data to be complete |
| Thirty and up | Scheduling, utilization and work that is not break-fix | Resource planning and project accounting |
Two things follow from reading that downward. The modules arrive in an order, and each one depends on the discipline of the one above it: contract billing is worthless if time entry is patchy, and profitability reporting is worthless if contracts are wrong.
Buying the whole platform on day one does not skip the sequence, it just means paying for the later rows while failing at the earlier ones.
The other is that the pain listed in the middle column is the honest buying signal. MSPs that adopt PSA software before billing hurts tend to configure it for a business they do not have yet.
What to askWhat to ask before buying
How does an alert become a ticket, and can I see it happen. Ask for the path in a demonstration rather than on a slide.
What does the export contain. Closed tickets, time entries, contracts and invoices, in a format something else can read. This is the cost of leaving and it is knowable on day one.
Can it bill the way we actually sell. Recurring per seat, per device, blocks of hours, projects, and combinations. If billing has to be adjusted by hand each month, the PSA is not doing its main job.
Who has to be licensed. Service desk staff are obvious. Whoever raises the invoices and whoever reads the management reports may also need seats, and that changes the price considerably.
What happens to service level tracking when a client is in several contracts. This is where PSA products differ most and where demonstrations are least specific.
How much of this do we need now. The staging table above is the short answer, and the long answer is that tickets, time and invoices have to agree with each other before anything else matters.
Once those questions are settled, the ranked comparison of seven platforms applies them product by product, and starts with the split that decides most shortlists: three of the seven publish a price and four do not.
PitfallsWhere people go wrong
Treating it as an MSP ticketing system. Ticketing is the visible part and the least differentiated. The contract and billing joins are what you are buying.
Buying the PSA because the RMM vendor sells one. The integration between the two tools is genuinely easier that way, which is a real advantage. It is not automatically the right system of record for the next ten years.
Leaving time tracking optional. A PSA with incomplete time data produces invoices that are wrong and reports that are worse, and no amount of configuration fixes an empty field.
Deferring the contract setup. Getting tickets flowing is quick and feels like success. Until contracts and rates are correct, nothing downstream can be trusted.
Assuming the migration is like the RMM migration. It is not, and treating it that way is how an MSP ends up running two systems for a year.
ComparisonA PSA and an RMM, side by side
| Criterion | PSA | RMM |
|---|---|---|
| What it watches | The MSP business: tickets, time, contracts | The machines: health, patch state, inventory |
| Who is in it all day | The service desk and whoever bills | The technicians and the automation |
| What it produces | Invoices and service level reporting | Alerts, scripts and remote sessions |
| What it holds that is irreplaceable | Years of history everything references | Agent configuration, which is rebuildable |
| Time to replace | Long, and it touches the finances | A quarter, because agents redeploy |
| Failure looks like | Billing that is wrong or late | Machines nobody is watching |
These get sold as a pair and described as if they were halves of one platform. They are not. They answer different questions and they are used by different people on different days.
The integration between them is one specific thing worth naming, because it is what a buyer is actually paying for: an alert raised by the RMM should create a ticket in the PSA, and closing that ticket should record time against the right contract. If that path is broken or manual, the pair is two products rather than a system.
FAQFrequently asked questions
What is a PSA in the MSP world?
Professional services automation: the software holding tickets, time entries, contracts, service levels and invoicing. It is the business management system, as distinct from the tools that watch endpoints.
What is the difference between PSA and RMM?
The RMM watches machines and produces alerts, scripts and remote access. The PSA runs the service business and produces tickets, time records and invoices. Most providers run both and integrate them.
Do I need both a PSA and an RMM?
MSPs generally do, because the two answer different questions. A small internal IT team often needs only the ticketing half.
Is a PSA the same as a ticketing system?
No. Ticketing is one module. What separates a PSA is that the ticket is joined to a contract and a time entry, so billing follows from the work rather than being reconstructed.
What is the difference between a PSA and a CRM?
A CRM tracks prospects and deals before a contract exists. A PSA tracks delivery, time and billing after it does. Using either as the other fails slowly.
What are the core PSA features?
Ticketing, time tracking, contract and service level management, billing and invoicing, and project management, with management reporting across all of them.
Why do PSA and RMM get sold together?
Because the useful path runs between them: an alert should raise a ticket, and closing that ticket should record billable time against the right contract. Vendors that own both make that path easier.
Which is harder to replace, the PSA or the RMM?
The PSA, by a wide margin. An RMM is agents and scripts, which redeploy. A PSA holds years of history that the accounting and the reporting both reference.
What should I check before choosing one?
What the export contains, whether it can bill the way you actually sell, who needs a license, and how service levels are tracked when a client holds more than one contract.
Can a small MSP run without a PSA?
For a while. The point at which it stops working for most MSPs is when monthly billing takes longer than a day, or when nobody can say which clients are profitable.
Does a PSA replace accounting software?
No. It produces the invoices and the billing detail, and that usually feeds an accounting system rather than replacing one.
Is there open source PSA software?
There are open source ticketing and service desk projects, and they cover the ticket half well. The contract, service level and billing joins are where the commercial PSA software is genuinely further ahead.
Is a PSA the same as an MSP ticketing system?
Ticketing is one part of it. An MSP ticketing system logs and routes support requests. A PSA adds time tracking, contracts, billing, projects and reporting around those tickets, so the MSP can see whether an agreement makes money. Many small providers start with ticketing alone and move to a PSA later.
Keep readingRelated concepts
Read next · Managed IT What Is an MSP, and What Are You Actually Buying The business model all of this exists to run, and where recurring contracts come from in the first place. Open this next10 min- Tools · 11 min Network Management Software, and the Three Questions It Has to Answer The third monitoring category, for the switches and firewalls that will never run an agent.
- Managed IT · 9 min What RMM Is, and What the Agent Can Actually Do The other half of the pair, and the one whose value lives in agents and scripts that can be redeployed.
- Operations · 9 min MTTR, and Why Two Teams Quoting the Same Number Disagree What the ticket timestamps are used to calculate.
- Managed IT · 13 min Open Source RMM, and What Each Project’s License Actually Allows The RMM side of the stack, where only Breeze includes ticketing and invoicing.