A meaningful share of L1 and L2 resolves without a human touching it.

Service desk automation reads incoming tickets, searches internal documentation and drafts a resolution when confidence is high enough. Everything below the threshold routes to a person, and each human correction feeds back into the system, so the automated share grows on evidence rather than on optimism.

The starting point

The same twenty questions, forever.

Most first-line volume is a small set of recurring issues whose answers already exist in internal documentation. The cost is not difficulty, it is repetition — and it lands on the people you least want doing it.

The disbelief this project meets is "our tickets are too varied for that", and it is usually wrong in a measurable way: the variety is real, but the volume behind it is concentrated in a few dozen recurring patterns. The engagement exists to prove that on your own ticket history before anything is automated — clustering first, templates never.

What we build

How it works

Historical clustering. Past tickets clustered to find what actually recurs, so automation targets real volume rather than assumed volume.
Draft with a threshold. The system reads the ticket, searches documentation and drafts a resolution only when it is confident enough; everything else goes to a person untouched.
Human-in-the-loop learning. Corrections are captured and fed back, so coverage grows from evidence instead of from a vendor's claim.

The ramp-up

Confidence is a gate, not a vibe

Nothing is sent to a customer below the confidence threshold — that is the answer to "what stops it answering confidently and wrongly", and it is enforced in the system, not promised in a slide. During the ramp-up period a human still reviews even the drafts that clear the threshold, until the measured accuracy justifies loosening that.

The threshold is deliberately conservative at first. The cost of a wrong answer sent to a customer is higher than the cost of a correct one routed to a human, and the ramp-up exists to find the operating point where the automated share grows without the error rate growing with it.

What changes

Recurring issues resolve without occupying a specialist.
The team spends its time on the tickets that genuinely need judgement.
Documentation gaps become visible, because the system fails loudly where they exist.

The dependency

The ticket system is the easy part. The documentation is the dependency.

The common ITSM platforms all expose the APIs a service-desk assistant needs — the harder dependency is the quality of the internal documentation the answers come from. The first two weeks assess that honestly: which runbooks exist, which are current, which answers are actually written down anywhere.

That assessment is a deliverable in its own right. Where documentation gaps show up, the system fails loudly on exactly those questions, which turns the automation project into a documentation fix list with a business case attached.

Which tickets first

Start where the volume is, not where the template is

The usual first targets are the recurring L1 patterns — onboarding, access requests, standard hardware, password and account questions — because they are high-volume, low-variance and answered in existing documentation. The clustering step decides which patterns, on your history, not on a vendor's list of supported intents.

L2 is the second wave, and it is where the human loop matters most: the system drafts a diagnostic path, the specialist confirms or corrects, and the correction feeds the next draft. Coverage grows from evidence, which is why the automated share after three months is a number the system can show rather than a promise.

Start with the ITSM sprint. A fixed-price four-week build plus ongoing operation. It begins with clustering your real ticket history, so the scope is set by your volume rather than by a template.

See what it costs

Service desk questions

What stops it answering confidently and wrongly?

The confidence threshold and the review loop. Below the threshold nothing is sent, and above it a human still reviews during the ramp-up period until the measured accuracy justifies loosening that.

Which ticket systems can it read?

The common ITSM platforms all expose the necessary APIs. The harder dependency is usually the quality of internal documentation, which the first two weeks assess honestly.

Next step

Not a sales call. An architecture call.

Thirty minutes with the architect who would actually run the engagement.