AI in your PSA: integration realities and the build-vs-buy question

Every AI tool pitched at MSPs eventually meets the same question: does it work inside the PSA, or beside it? The answer decides whether the tool becomes part of the desk or another tab nobody opens. This guide covers what PSA integration actually means, why your ticket history matters more than any model, and the build-versus-buy question answered without pretending either answer is free.

The PSA is the desk's centre of gravity

Everything your desk knows lives in the PSA: every ticket, every client, every agreement, every hour logged. Technicians live in its queues; managers live in its boards; billing lives in its time entries. A tool that operates outside it — its own inbox, its own dashboard, its own numbers — asks every technician to run a second system of record, and second systems of record lose. Not because the tool is bad, but because the desk's habits are load-bearing and fifteen years old.

So the first question for any AI product is blunt: does its output land in PSA fields your workflows already read? Classification that appears in a vendor dashboard is invisible at the moment of dispatch. A drafted resolution that lives outside the ticket is a draft nobody finds.

What "integrates with your PSA" should actually mean

• Reads the real objects — tickets, clients, agreements, configurations — not a nightly export of them. Priority set against an SLA requires the SLA.
• Writes to the real fields — type, priority, assignment, notes — so downstream automation and reporting see the AI's work as ordinary PSA data, because it is.
• Meets users where tickets start. A growing share of issues arrive through Teams and Slack; intake that captures them as proper tickets beats a portal users avoid.
• Names its scopes. An integration that cannot enumerate exactly what it reads and writes has not thought carefully enough to be trusted with either. Ask for the list; a serious vendor has it ready.

Your ticket history is the moat — including against the vendors

Here is the fact that reframes most AI evaluations: the model is not the scarce asset. Capable models are available to everyone, including your competitors and your vendors. The scarce asset is your closed-ticket history — years of real problems, real fixes, and real outcomes for your specific clients on your specific stack. A generic model answers like the internet. A system grounded in your history answers like your best technician's memory, because that is literally what it is reading.

This has a practical consequence for evaluation: weight the vendor's retrieval over the vendor's model. Ask how the system uses your history, how it cites what it used, and what happens with the client whose environment is unusual. The demo that dazzles on sample data and the system that works on your queue are separated by exactly this.

Build versus buy, honestly

An MSP with engineering talent can absolutely wire an LLM to the PSA API. A weekend prototype that summarises tickets is genuinely achievable, and instructive. The gap between that and a production system is where the real cost lives, and it is worth itemising because each line is invisible from the prototype:

• Retrieval, so answers come from your history rather than the model's imagination — including chunking, indexing, and keeping the index current as tickets close.
• Confidence handling, so the uncertain cases reach a human instead of shipping with the certain ones.
• Write-back discipline, so a hallucinated field value cannot corrupt the system of record your billing runs on.
• The correction loop, so a technician fixing a classification teaches the system rather than just fixing one ticket.
• Model churn, because whatever model you build on will be deprecated, repriced or leapfrogged within the year, and the migration is yours.
• The bus factor, because the engineer who built it now owns a production system forever, and their actual job was billable.

None of this says never build. It says the build is a product, not a project — and the question is whether owning that product is your business. For some MSPs it genuinely is. For most, the engineering hours are worth more pointed at clients.

Measuring it without fooling yourself

Vendor ROI claims in this category are mostly unfalsifiable, ours included if we made them — which is why we do not. The honest method costs nothing: take your own ticket volume, your own average handling time, your own loaded rates, and compute what a given change is worth to your desk. Then measure the change, on your queue, after deployment. Any number a vendor hands you before seeing your queue is a number about someone else's desk. The ROI calculator does this arithmetic from your inputs and published prices — it will not assert an automation rate, because before deployment nobody honestly has one.

The security questions that belong in the first call

An AI system reading every ticket is reading client data at scale, and the vendor should expect to answer for that early: which AI providers process the data, whether your data trains anyone's models, what is retained and for how long, and what happens on termination. The answers should be written down before you ask. Ours are, on the security page — including the questions we get asked most, answered the way we answer them in procurement.

Where AI Autopilot fits

Claudia runs the ticket lifecycle through five service-desk agents inside ConnectWise, Autotask, and HaloPSA — the concierge, triage, dispatch, resolution, and the watchdog — grounded in your ticket history and writing to your PSA fields. The integrations page lists the connectors Claudia reaches through StackJack, provisioned per MSP; nothing is wired to a tenant by default, and nothing unshipped is implied. The comparison pages cover the adjacent categories honestly — RPA workflow builders, helpdesk chatbots, and hiring instead — including where each of them genuinely wins.