Get your PSA data ready for AI triage.
AI triage rarely fails because the model is weak. It fails because it is reading fields that only make sense to someone who already knows how your desk runs. Six things to fix first — none of them require buying anything, and all six are worth doing even if you never turn an agent on.
Vendor-neutral. The same six areas apply whichever PSA you run.
Your configuration is the prompt
This is the part that surprises people. When an engine infers a priority, a queue, or an assignee, it is not reasoning about your business — it is pattern-matching against the words you put in your PSA and the tickets you have already closed. Your field descriptions are the operating policy it reads. Which means a vague field is not a cosmetic problem you can prompt your way around: it is missing input.
That has a useful consequence. Every one of the six fixes below is ordinary configuration hygiene that pays off on its own — faster onboarding, less tribal knowledge, cleaner reporting, fewer misrouted tickets — whether or not you ever deploy an agent. There is no version of this work that is wasted, which is rare enough to be worth saying plainly.
The six areas
For each one: the failure mode, what good looks like, and why an engine cares.
-
1 · Priorities
Common shape: A priority called “High” with no description, or one that means “this client shouts.”
What good looks like: Each level states the business consequence: what is affected, how far it reaches, how fast it must move, and what happens if it does not. Impact, then scope, then urgency, then consequence.
An engine reads priority descriptions as operational policy. If the only definition lives in your dispatcher's head, nothing can infer it.
-
2 · Queues, boards, teams
Common shape: “General Support.” Containers described only by what they hold, so anything plausibly fits.
What good looks like: Each one says what does NOT belong in it and where that work goes instead. The exclusion is what disambiguates two containers that both look right.
Routing is a process of elimination. A description with no exclusions gives an engine nothing to eliminate on — which is how tickets land in the wrong lane.
-
3 · Issue and category types
Common shape: Judging them by their names. “Printer” is one word and perfectly precise; “Problem” is one word and useless.
What good looks like: Measure the LOAD instead: how many genuinely different kinds of work land in each value. One kind is an anchor. Fifteen is a label with no signal in it.
This is the check almost nobody runs, and it is the one that finds real ambiguity. The fix is usually a split, not a rename.
-
4 · Skills
Common shape: Duplicates nobody pruned, and entries like “Email support” that name a topic rather than a capability.
What good looks like: One entry per capability, each describing the technology, the task, and the context. Deduplicated first — duplicates are worse than gaps, because they split the evidence for the same person.
Skill matching is how work reaches the right technician. Two half-populated duplicates beat neither of them.
-
5 · Ticket content
Common shape: “Email not working.” A symptom with no impact, no scope, and no statement of what done looks like.
What good looks like: What is happening, who it affects, what the business consequence is, and whether a workaround exists. A few extra seconds per ticket.
Historical tickets are the training surface. Thin tickets teach an engine that thin tickets are normal, and the quality compounds either way.
-
6 · The metrics you will judge it by
Common shape: Turning on automation with no baseline, then arguing about whether it helped.
What good looks like: Know your first-contact resolution, escalation rate, reopen rate and technician utilization BEFORE you change anything.
Every claim about what automation improved is a comparison. Without a baseline you cannot make it, and you cannot defend it to a client.
The check most people skip
Areas 1, 2, 4 and 5 you can audit by reading. Area 3 you cannot — and it is where the real ambiguity hides, because a classification value's name tells you almost nothing about its fit. The only reliable test is to count how many genuinely different kinds of work land in each value.
We ran it on this model. Across 70 classification values, 9 turned out to be catch-alls and 19 more were broad. The out-of-the-box values a PSA ships with averaged 4.4 different kinds of work each; the ones this model adds averaged 2.5. Tighter — but not clean: our own broadest value absorbs a dozen kinds of work, and it is published in the app alongside the rest.
That is the honest shape of this exercise. Nobody's taxonomy is clean, defaults are generic on purpose so every shop can adapt them, and the useful question is never "is my PSA good" but "which specific values are doing too much work, and what would splitting them look like."
Are you ready? A short self-check
- Every active priority has a description a new hire could route from, without asking anyone.
- Every queue or board says what does not belong in it, not only what does.
- No classification value is absorbing a dozen unrelated kinds of work.
- The skills list has no duplicates, and each entry describes a capability rather than a topic.
- A typical ticket states impact and desired outcome, not only the symptom.
- You know your current first-contact resolution, escalation and reopen rates.
Six yeses and inference has something to work with. Any no is a specific, bounded piece of configuration work — and the first three are usually an afternoon.
A worked reference, if you want one
Writing 5 priority descriptions and an exclusion clause for every queue from a blank page is the slow way to do this. This model is a free, brand-stripped reference of how a modern MSP runs — 552 service items, 125 skills with capability descriptions, and 35 of its 47 ticket containers carrying an explicit exclusion clause — so you can copy the shape instead of inventing it.
The AI Readiness assessment scores your operating model across 7 dimensions, one of which is exactly this: whether your PSA's own fields read as policy. It runs in your browser and your answers never leave it.