Triaging IT help desk tickets with AI

How the bot works

Nine steps. The field extraction, the duplicate search, the routing rules and the audit trail are ordinary code and cost almost nothing to run; the model is only used to read a human sentence and to say what it does and does not contain.

1. It takes the ticket however it arrived. The portal form, an email to the help desk, a message in Teams or Slack, a forwarded screenshot with two words under it, a voicemail somebody transcribed. All of them, normalized into one shape before anything is decided.

2. Every field it fills is quoted, or it is unknown. The exact error, the device, the version, the site, how many people are affected, when it started, what changed. Each one is taken from words that are actually in the ticket — and when they are not, the field says unknown. It does not reason its way to a serial number.

3. It asks the requester for the one thing that is missing. Not a form, not seven questions — the one or two facts that stop the next person from starting, in your wording, once, with a reminder if your rules allow one. An ask small enough to answer in one line gets answered; a questionnaire becomes a task of its own.

4. Category and priority come from your matrix, not its opinion. Impact and urgency as you defined them, applied to what the ticket actually says, with the rule it used written next to the result. A priority nobody can explain is a priority nobody trusts.

5. It finds the other tickets about the same thing. The same error this morning, the same asset last week, the same person for the third time, the same site in the last hour — surfaced as a proposed merge or link, with the matching text shown. Three tickets about one outage are the outage announcing itself.

6. It attaches the known fix only when there is one. The article or the closed ticket whose steps actually match, with the passage that matched. When nothing matches, it says nothing matched. A plausible fix written from general knowledge is worse than a blank field, because somebody will follow it.

7. It routes where your rules point, and flags what is slipping. The queue, the team or the on-call rota your rules name, by category, site, contract or hour — plus a flag on anything already at risk against the targets you set, before it is late rather than after.

8. A technician owns it, and can overrule all of it. The triage arrives as fields a person can accept, edit or throw out in one pass. Nothing is locked, nothing is hidden, and the ticket is theirs from the first minute — the bot has already done the typing, not the deciding.

9. It keeps the reason for every triage. What it read, what it quoted, which rule set the priority, what it asked for, what a person changed. When a ticket comes back a week later, it is tied to the triage that sent it — which is the only honest way to tell whether any of this is working.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your category tree

Types, subtypes and the ones that only exist because of a contract — as they actually are in your system, including the categories your own techs avoid.

Your priority matrix

Impact against urgency, in your words, with the thresholds written down: what makes something a major incident, and what is simply annoying.

Your required fields, per type

What a password ticket needs, what an outage needs, what a new-starter request needs. The list the next person cannot start without.

Your routing

Which queue, team or rota takes what, by category, site, client, contract or hour — and who gets the ones that fit nowhere.

Your service targets

Response and resolution targets by priority and contract, your working hours and holidays, and how early you want to hear that something is slipping.

Your known-fix library

Which articles and closed tickets it may cite, how fresh they have to be, and which ones are out of date but still in the system.

Your asking rules

Whether it may write to the requester at all, in which channel, how it is worded, how often it may chase, and when it stops and hands over instead.

Your masking rules

What is stripped before any model sees a ticket — names, account numbers, patient or client identifiers, credentials somebody pasted in — and what is kept.

Your release switches

Which categories it may triage on its own, which it only suggests, and who flips that switch per category.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every filled field names the words it came from, every unknown says why, and every priority names the rule that set it. A queue can be audited by reading reasons instead of re-deriving somebody's judgment at eight in the morning.

Versioned prompts you can tune yourself

The field rules, the matrix and the prompts behind reading a sentence are yours to tune. A change is a reviewable diff, replayed against tickets you have already closed so you can see exactly what it would have triaged differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Reading, quoting, categorizing, linking and routing are automatic. Resolving, closing, merging, any access or configuration change, every incident and every security matter are a person's — that boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per ticket and one per rule change: the fields and their sources, the rule and its version, what was asked for, who edited what, and the reopen if the ticket comes back — plus token usage and cost for that run.

It can be configured to run in any business. The categories and the rules are yours: your tree, your matrix, your required fields, your queues, your targets, your masking. The help desk wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This runs on the PSA, the service desk or the mailbox you already have. We're not replacing your ticketing system and we're not asking your techs to work somewhere else.

• Autotask or HaloPSA
• ServiceNow
• Jira Service Management
• Freshservice
• Zendesk, Freshdesk or Help Scout
• An RMM or monitoring tool
• Microsoft 365 and Outlook
• Microsoft Teams or Slack
• A shared help desk mailbox
• A knowledge base you already keep

Works well for

• Managed service providers — Every client has its own contract, categories and escalation path, and one queue holds all of them.
• School districts — Tickets arrive in a flood in the first week of term, and almost none of them say which building.
• Manufacturers — A line-side problem and an office problem need different urgency, and the ticket rarely says which it is.
• Healthcare providers — Tickets carry patient detail, so what may be read, quoted and kept has to be settled first.
• Nonprofits — One or two people cover everything, so the triage has to be right the first time rather than reviewed twice.

How a rollout works

Nothing is triaged on day one. The first milestone is a month of tickets you have already closed, triaged again from scratch and compared with what your team actually did.

1. 01Discovery

   The quote call, then a working session. We go through your category tree, your priority matrix, the required fields per type, your routing and targets, which articles may be cited, what must be masked, and whether the bot may write to a requester at all. You get the field rules, the matrix and a written scope.

2. 02Dry run

   The bot triages tickets you have already closed, from the text they had when they arrived. Nothing is written back. We compare its category, priority, routing and missing-field list against what your team did, and every disagreement is either a rule we have not captured or a judgment call worth naming. This is where your own numbers come from.

3. 03Assisted mode

   Live on one queue or one client first, suggesting only: the triage appears on the ticket for a technician or dispatcher to accept, edit or drop. Triage stops being typing and becomes checking. The control doesn't change.

4. 04Optional limited automation

   Optional, and narrower than it sounds. A short list of categories you name — password resets, printers, the request types with no judgment in them — triaged and routed on their own, with every hard stop in force, a sampled share still reviewed, and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No accuracy figure, no share of tickets triaged without a person, no response-time claim, and no "resolved end to end" rate - that last one is a vendor sentence, not an outcome we would promise. We haven't read your queue. The numbers come out of the dry run and they would be yours.
• No customer claims on this page. No names, no case studies, no logos.
• A triage is a suggestion, not a verdict. It is designed to be overruled in one pass, and the audit trail exists so a technician can see what it read before they do. If a tool's suggestions start getting treated as settled fact by people who never read the ticket, the tool has made things worse.
• It is not an agent loose in your estate. It reads tickets and writes fields. It does not reset, grant, install, restart or remediate, and we are not going to offer that later as an upgrade. The reason is in the guard band: the cost of a wrong action in that layer is not symmetrical with the saving.
• It will not understand your weird one. Every help desk has a category that means something only three people know, and a client whose "urgent" means next week. Those get named in discovery and written into rules, or they get routed to a person on purpose. Nothing about this is a model being clever.

Questions people ask

Can AI triage our IT help desk tickets?

Yes - and the boundary is what makes it usable. An agent can read every new ticket however it arrived, fill your required fields with words quoted from the ticket, mark anything it cannot find as unknown rather than inferring it, ask the requester for the one or two missing facts, set a category and a priority from your own matrix with the rule written next to it, link the duplicates, cite a fix only where a passage actually matches, and route it. It resolves nothing and closes nothing. A technician owns the ticket.

Does it resolve tickets, or only sort them?

Only sort, enrich and route - deliberately. It changes no access, resets no password, runs no script, touches no configuration and closes no ticket, and that is not a phase one we plan to remove later. Triage is where the time actually goes on a busy queue, and it is the part where being wrong costs a minute instead of an outage.

What stops it from inventing details?

A mechanical rule rather than a careful one: every field is either quoted from the ticket, directly derived from it, or marked unknown. Hallucinated specifics - a client name, a device, a version that was never in the text - are the failure mode that makes an AI triage worse than no triage, because the next person believes the field. So the missing-information list is a first-class output, not an afterthought.

Will it change a priority on its own?

Inside the band you set, yes, from your matrix, with the rule shown. Above the threshold you name it proposes instead - and anything that reads like an outage or a security event goes straight to a person rather than into a queue with a label on it. It also never downgrades a priority a person has set.

Can it ask the user for the missing information?

If you let it, in the channel you choose, with your wording, once, and with a chase only if your rules allow one. It asks for the one or two things that would unblock the next person, never a questionnaire. If you would rather it never writes to a requester, that is a switch, and the missing-field list still goes to whoever picks the ticket up.

How does it handle duplicates and major incidents?

Duplicates are surfaced as a proposed merge or link with the matching text shown, and nothing is merged by the bot - a wrongly merged ticket is a lost ticket. A cluster of tickets that look like one event is exactly the signal you want early, so it is raised to a person immediately rather than quietly grouped, and it is one of the hard stops.

Will it work with our PSA or service desk?

If it has an API, almost certainly, and if it does not, a scheduled export and a write-back usually do. Autotask, HaloPSA, ServiceNow, Jira Service Management, Freshservice, Zendesk, Freshdesk, Help Scout, or a shared mailbox and a spreadsheet are all normal starting points. The triage is written back onto the ticket, so your techs stay in the tool they already have open.

Is this the same as the bot that sorts customer email?

No, and they are kept apart on purpose. This one works the tickets your own people raise - or, for a provider, the staff you support - and it writes to nobody but the requester. Sorting a customer mailbox and drafting replies to customers is a different job with a different boundary. If you want both, get a quote and we will scope them separately.

Is there a record of how a ticket was triaged?

Yes, per ticket: what it read, every field with the text it came from, which rule set the priority, what it asked the requester for, what a person changed, and the reopen if the ticket comes back later. That last link matters more than it sounds - a triage that looks fast and quietly produces reopens is the thing you want to be able to see.