PSA stands for professional services automation. Two unrelated product categories use the name. IT and MSP PSA tools are built around the support ticket. PSA software for consulting, architecture and engineering firms is built around the project. That means fees, resourcing, time, margin and billing. Check which one a vendor built before you shortlist it.

‍

What PSA software means, in plain terms

PSA software runs the operational spine of a firm that sells its people's time. It covers the whole life of a piece of work. You win it, price it, staff it, deliver it and bill it. It all runs on one set of records. So the fee you quoted, the team you planned, the hours booked and the invoice you raise tie back to the same numbers.

In most firms, that covers six things:

• Pipeline and quoting, including how a fee gets built

• Resourcing, by named person, forward

• Time and expenses

• Project financials, including budget against actual and work in progress

• Invoicing and revenue

• Reporting that senior people trust enough to act on

It's a mature category for firms like these. SPI Research and CMap surveyed 373 North American boutique IT and management consulting firms for the 'From Spreadsheets to Sustainable Scale' report (February 2026). They found 84.9% already use a commercial PSA. That's 80.7% of firms with 31 to 100 employees and 89.9% of firms with 101 to 300. But adoption and integration aren't the same thing. Only 49.4% have connected their PSA to their CRM. Just 60% have connected it to finance. That's how a firm ends up owning a platform and still running on spreadsheets.

UK firms are further behind. Consultancy BenchPress 2025 is the annual benchmark from The Consultancy Growth Network and The Wow Company. It asked 299 UK consultancies what they use for project resource management. Just 5% use no tools. About a third (32%) work mostly in spreadsheets. Another 38% run several standalone tools. Only 25% run a PSA. CMap sponsors the report, so read it with that in mind. The largest group has bought tools without buying a system.

That brings us to the problem with the term itself. Search for "PSA software" and most results have nothing to do with the firms described above.

‍

Why most PSA software content online is written for IT and MSPs

Two established product categories share one acronym. Both expand it to the same three words.

One serves managed service providers (MSPs) and internal IT service desks. The other serves consulting, architecture, engineering, agency and advisory firms. Both sell services rather than products. That's roughly where the similarity ends.

The MSP category has more content and bigger vendor marketing budgets. So it owns the head term. Your first ten results might talk about ticket queues, dispatch boards, SLA clocks and endpoint counts. If so, you've landed in a different product category. It just happens to share a name with the one you want.

RMM, ticketing and endpoints vs project delivery and billing

A managed service provider sells an ongoing promise. Your IT keeps working, for a monthly fee. That fee is usually priced per device or per seat. Revenue is recurring and fairly predictable. The hard operational problem is the flow of inbound work.

So the MSP PSA is built around the ticket. Work arrives as an alert, a client email or a scheduled maintenance job. The system routes each ticket to a free, qualified technician. It holds the SLA clock and records time against the ticket. At month-end, it reconciles everything to the contract. Most MSP tools also include hardware quoting, a client portal and a dispatch board.

That explains the next thing people search for: PSA vs RMM. RMM stands for remote monitoring and management. It's software that watches a client's endpoints and raises an alert when something breaks. The RMM generates the work. The PSA manages and bills it. Vendors sell the two as a pair, and that pairing is the fastest tell in the category. If a vendor's homepage leads with its RMM integration, it isn't built for your firm.

A consulting or AEC firm has the opposite problem. Work arrives in large, planned units with a fee attached. Named people deliver it over weeks or months. Their time is committed in advance. Nobody's waiting on an SLA clock. What keeps a partner awake is margin. Will the engagement land at the margin it was sold at? And are the right people booked on it next month?

‍

What a professional services PSA has to do instead

Resourcing, utilisation, project accounting and client billing

Here are five jobs an MSP tool has no reason to do well. Your firm can't operate without any of them.

Price the work before you win it. Build the fee from the shape of the team and the stages of the work. Keep the margin visible while you can still change the number. Most firms build fees in a spreadsheet and then re-key the result. That makes it hard to compare what they quoted with what they delivered. Alexander Desyatnik of CIL Pearson Ham described what happens when you finally run that comparison. He was speaking on CMap’s webinar “The professional services firm pricing playbook”:

‍"It was over 200 project cases or so, and we mapped the quoted fee for the project and the actual hours and time delivered on that project. And I would say the hours and time spent on that project exceeded the quoted fee 85, 90% of occasion."

Staff named people, forward, over months. That means knowing who's on what in week nine, at what grade and with which skills. It also means seeing what breaks if a project slips two weeks. Ticket systems assign work that exists now. A resource schedule has to hold work that hasn't started yet.

Measure utilisation and recovery rather than SLA attainment. These numbers drive different behaviour. Billable utilisation and recovery rate tell you whether you're being paid for the hours you sold. First-time fix rate tells you nothing about either.

Do real project accounting. Track work in progress (WIP). Recognise revenue on a fixed fee as it's delivered, rather than when it's invoiced. Compare budget to actual at stage level. See a margin view that updates while the project is still running. MSP tools don't attempt this, because recurring contract revenue doesn't need it.

Bill the way your clients buy. That could mean stage and milestone drawdowns, retainers, capped time and materials, percentage fees, variations or pass-through costs. Often it's several of these inside one job. Per-seat recurring billing is a simpler problem with a simpler answer.

When these pieces sit in different systems, firms tell us the same story. Reporting lives outside the platform, in Power BI or Excel. Resourcing and fee building happen in spreadsheets next to the system, then get typed in afterwards. One firm kept 113 project spreadsheets alongside its time tracking tool. The tool's profitability view was misleading, so the team stopped relying on it.

The point at which a firm outgrows the spreadsheets

SPI calls it the spreadsheet breaking point. It's the moment informal tools stop being flexible and start being a risk. Nobody decides it. The signs include falling confidence in resourcing data and forecasts that change depending on who built them. You'll also see more overruns and rework, and a month-end that drags or gets disputed. Leaders in the study describe it as managing through fog.

SPI calls the economic version the PSA tipping point. It usually arrives between 20 and 50 employees. That's when the cost of not knowing outgrows the cost of changing systems. In the same study, firms running a PSA showed $240,000 of revenue per billable consultant. Firms without one showed $215,000. Project margin was around 40% against 36%. SPI is careful about how to read this. Adoption doesn't cause the performance. Firms buy a PSA once they reach the complexity where informal coordination fails.

‍

IT/MSP PSA and professional services PSA, side by side

‍

How to tell which kind of PSA a vendor built, inside one demo

You can settle this in a 40-minute demo without reading a feature matrix. Here are seven things to do.

1. Ask what the system opens on. Ask to see the default landing screen for a delivery lead. If it opens on a queue of inbound work, you have your answer.

2. Ask them to price a three-stage engagement live. Include mixed fee types and a named team. Ask to see the margin before the work is won. If fee building happens in Excel and gets entered afterwards, that tells you what you need to know.

3. Ask for a forward resource view by named person for the next quarter. Then ask them to move one project back two weeks. Watch whether anything downstream updates.

4. Ask what happens at month-end on a part-delivered fixed fee. Listen for revenue recognition, WIP, accrued income and deferred income. A ticket-based system will struggle to answer in its own language.

5. Read the integrations list from the top. Xero, Sage, QuickBooks, Salesforce, HubSpot and HR or payroll systems point one way. RMM, antivirus and endpoint management point the other.

6. Look at their customer stories and note the job titles. Service desk managers and operations engineers suggest one kind of buyer. Practice leads, finance directors and resource managers suggest another.

7. Ask how they price their own licences. Per technician or per endpoint is an MSP signal. Per user with a minimum is a professional services signal.

There's one complication. IT and technology consulting firms often run both models. Project and programme delivery sits on one side. Managed services and support contracts sit on the other. If that's you, be specific about where the revenue and risk sit. Some firms need a professional services platform for delivery and a service desk tool for support. Forcing either product to do both jobs is how you end up with a system nobody uses. Decide which side carries the margin risk, and buy for that first.

‍

Where CMap sits in this

CMap is listed in G2's Professional Services Automation category. We don't spend much energy defending the acronym. What matters more is whether a firm gets a connected view in one place. That means pipeline and quoting, resourcing, time, project financials, invoicing and revenue, and reporting. We build for firms of roughly 10 to 500 people.  

We've also found a more useful distinction. PSA tells you what happened, like last month's hours and utilisation. What a firm needs next is a view of what's happening now and what's coming. Which engagements are drifting from the margin they were sold at? Who's overbooked, and where will skills run short against the pipeline?

If you're earlier in the process, the PSA buying guide and the definitional guide to PSA software cover the requirements side. Our roundup of PSA platforms includes vendors we lose to.