What is a PSA? Professional services automation for IT teams, explained

The shared mailbox is where most MSPs are born and where a surprising number of them quietly stall. It works at two clients and ten machines. It stops working the day two people answer the same customer at once, or the day nobody answers at all because each assumed the other had it. The tool that fixes this is a PSA, and the honest answer to what is a PSA has less to do with software categories than with five specific jobs. This piece names those jobs, walks through a day in a two-technician shop with and without one, and gives you a way to work out what doing them by hand is costing you.

What is a PSA? Five jobs, one system

PSA stands for professional services automation, a label invented for consultancies and inherited by IT. Strip the label off and a PSA does five things:

• Ticketing. Every request becomes a record with an owner, a status and a history. Not an email thread, a record. The difference is that a record cannot be archived by accident, buried under a newsletter or answered twice by two different people.
• SLAs. Service level agreements turn "we will get to it" into "first response within four hours, resolution within two business days", and the PSA tracks whether you are keeping that promise. Without tracking, an SLA is a sentence in a contract that nobody measures, which is to say a decoration.
• Time tracking. Who spent how long on what, attached to the ticket it belongs to. This is the function small shops resist hardest and need most, because it is the raw material for both invoicing and knowing which clients are profitable.
• Client records. Contacts, sites, contracts, agreed rates, covered devices, and the history of everything you have ever done for them, in one place rather than scattered across a spreadsheet, a OneNote and the senior technician's memory.
• Billing data. The PSA does not have to be your accounting system, but it should hand your accounting system a clean answer to the only question that matters at month end: what did we do, for whom, under which agreement, and what does that come to.

Ticketing gets the attention. The other four are where the money is.

A day in a two-technician shop, before and after

Before. It is 08:45 and both technicians open support@ at the same time. Forty unread. One starts at the top, one starts with the client who shouts loudest. At 10:20 they discover they have both replied to the same printer ticket with different advice. A request from Tuesday has slipped to page two and will surface on Friday as a complaint. Around 16:00, one of them spends ninety minutes untangling a VPN issue for a client on a fixed monthly agreement, and because there is nowhere obvious to record it, the ninety minutes evaporates. At month end, the invoice for the break-fix clients is assembled from memory, sent notes and a scroll back through the mailbox. It is a guess wearing a spreadsheet's clothes.

After. The same forty requests arrive as tickets, deduplicated against existing threads, each with an SLA clock. One technician owns the queue for the morning, the other works projects; the split is visible, so nothing is answered twice and nothing is answered never. The VPN job has a timer running against the ticket, and at month end that time either bills or shows up as agreement burn, which tells you the fixed fee is underpriced. The invoice takes an hour instead of an afternoon, and it is defensible line by line when the client queries it.

Nothing in that second paragraph is clever. It is bookkeeping for work. That is all a PSA is, and it is why every MSP that grows past three or four people ends up running one, whether the machines they support belong to clients or to their own company.

Why the PSA sits next to the RMM, or inside it

If the PSA tracks the work, the RMM watches the machines: monitoring, patching, remote access, scripts. The two meet at the point where a machine problem becomes a piece of work. A disk-space alert in the RMM should become a ticket in the PSA, with the device context attached, so that the time spent fixing it is logged against the right client and the right agreement. When the two systems are separate products, that join is an integration you build and maintain, and it is usually the first thing to break. When they are one product, the join is free, which is the main argument for a unified stack and the subject of a longer piece on what an all-in-one PSA and RMM should actually include.

Internal IT teams need the same plumbing for a different reason. Nobody invoices, but somebody still has to prove response times to the business, justify headcount with real workload numbers, and stop requests dying in a distribution list.

The audit: which PSA functions are you doing by hand?

The month-end test: how long does it take to produce accurate invoices, and how confident are you in the word accurate? If the answer involves scrolling a mailbox, you are doing billing data by hand. Skip fixing this and you will systematically under-bill, because memory forgets small jobs and small jobs are most of the month.

The holiday test: if your best technician left for two weeks tomorrow, could the other person see every open commitment for every client? If not, client records live in a head, not a system. Skip this and the cost arrives all at once, on the day that person resigns.

The promise test: can you say, with evidence, whether you met your response-time commitments last month? If not, your SLAs are unmeasured, which means unmanaged. Skip this and you will find out you were failing a client at the moment they cancel, not before.

On the arithmetic: suppose each technician loses fifteen minutes a day of genuinely billable or agreement-attributable time because there is nowhere convenient to log it. Two technicians, thirty minutes a day, at £75 an hour is £37.50 a day, and across roughly 230 working days that is over £8,000 a year. Check the numbers against your own rates; the shape of the result rarely changes.

Failure modes: the mailbox versus the PSA

The shared mailbox fails silently. Requests vanish, time evaporates, and the first symptom is a client leaving. A PSA fails noisily and differently: too many mandatory fields, statuses nobody agrees on, a configuration project that never ends. Some products make that second failure mode a near certainty for a small team, which is why choosing one is less about feature lists and more about weight; we have written separately about what a PSA for a small MSP should and should not include. The rule is simple: a PSA should be the lightest system that makes work visible, owned and billed. Anything beyond that is process for its own sake, a rule wearing a safety costume.

Where this fits with Helios

Helios is an RMM and PSA in one product, so the alert-to-ticket-to-time-to-invoice chain described above exists without an integration to build: the service desk shares one database with monitoring, patching and billing, and Helio, the built-in AI agent, triages inbound tickets and drafts or runs fixes for the routine ones. Be clear about the limit: no PSA, ours included, will make technicians log time they have decided not to log. That part is discipline. The tool's job is to make the disciplined path the easy one.

Helios is an AI-native RMM and PSA for MSPs and internal IT teams, on flat monthly pricing with every feature on every plan. 14-day trial, no feature gating, no card required. Start free.