How FlowTux auto-triage cuts ticket resolution time by 50%

Every internal support team has the same bottleneck: a human reading each new ticket, guessing the category, picking a priority, and deciding who should own it. It feels like five minutes. Across hundreds of tickets a week, it is the single biggest drain on response time — and the one nobody has a dashboard for.

Auto-triage removes that step. The moment a ticket lands, it is read, categorized, prioritized, deduplicated, and assigned — grounded in your actual codebase and resolved-ticket history, not keyword rules. This post covers what that means concretely, where the headline number comes from, what the system still gets wrong, and how to roll it out without betting the queue on it.

Calling it "triage" hides how much work it is. Every ticket that arrives forces five separate judgements before anyone can start fixing anything, and each one is a place the queue can go wrong.

Classification decides what kind of thing this is. Prioritization decides how much it should displace. Deduplication decides whether this is new information or the ninth report of an incident already open. Routing decides who owns it. And the first diagnosis — the part that rarely gets counted as triage at all — decides whether the person who picks it up starts from a clue or from the subject line.

The reason triage resists optimization is that four of the five are cheap individually and expensive in aggregate. Nobody refuses to spend ninety seconds categorizing a ticket. Everybody refuses, implicitly, to spend three hundred hours a month on it, which is what ninety seconds becomes at ten thousand tickets. The cost is real, it is just never itemized.

When a ticket is created, Tux AI restates the request in plain language, then consults the map of the linked repository to surface the files most likely involved — each tagged by module and importance, with a confidence score attached rather than a bare assertion.

That map matters more than the model choice. It is built once when the repo is connected and updated per merge, so a diagnosis reflects the code as it is today, including the deploy that landed two hours ago. We wrote up the mechanics in Your repo is 1.4M tokens; the short version is that a system re-reading your repository from scratch on every ticket cannot afford to know your history, and one with a living map can.

From there it sets a priority against your own severity definitions, folds obvious duplicates into the open incident instead of spawning parallel threads, assigns an owner by load and expertise, and — for categories you have explicitly promoted — applies and verifies a fix before a human ever opens the ticket. Every step is written to the ticket timeline: what it decided, what it read, what it was uncertain about. Triage you cannot audit is not triage, it is a black box that happens to be fast.

The number in the title is a modelled target for a mature, well-configured queue, not an audited average across customers. We are a young product and we would rather say that plainly than dress a projection up as a case study.

Here is the arithmetic behind it. Most internal queues have a large routine band — password and access requests, known regressions, cache and DNS issues, questions answered by an existing runbook — that typically runs somewhere between a third and half of intake. Autonomous resolution addresses that band and nothing else. If your routine band is 30%, the ceiling is 30%, and no amount of model quality moves it.

The part we have actually measured is narrower and more useful: whether code-grounded triage identifies the right place in the codebase. On a set of 81 real bug reports, the indexed system named a file that the real fix touched 50.6% of the time, against 14.8% for the same model with no index and the repository name hidden. On a private repository no model has seen in training, the indexed arm held at 50% while every baseline scored zero. The full method, including findings we withdrew, is on our benchmark page.

Treat those as two different claims. The benchmark is measured and reproducible. The auto-resolution rate is a target you should verify against your own queue during a trial, which is exactly what suggest mode is for.

If you instrument one thing during a rollout, make it time-to-first-action: the gap between a ticket arriving and someone doing something other than reading it. It moves first, it moves furthest, and it is the metric users actually feel.

Resolution time is dominated by a small number of genuinely hard tickets, so it is slow to respond to anything and noisy when it does. Time-to-first-action responds immediately, because the change is structural — an engineer opens a ticket that already carries a category, a priority, candidate files, and the last three related fixes, instead of a subject line and a screenshot.

The second-order effect is the one teams report as the real relief: fewer context switches. A queue that arrives pre-sorted can be worked in batches. A queue that arrives raw interrupts whoever is nearest, which is how support work quietly eats engineering weeks. We covered the measurement side of this in reducing engineering interrupts from support.

Vague tickets stay vague. "The dashboard is broken" with no URL, no timestamp, and no account gives an AI exactly what it gives a human: nothing to work with. The system asks a clarifying question rather than guessing, which is correct behaviour and still feels like a non-answer to the requester.

Causes that live outside the diff are the hardest class. A config constant changed in one service can surface as an error in three others, and a triage system anchored on the files in the stack trace will confidently point at the symptom. This is why invalidation propagates along dependency edges rather than stopping at changed files, and why low-confidence diagnoses are labelled as such instead of being rounded up to certainty.

And quality drifts after knowledge changes. Rewrite an article, rename a service, bulk-import stale docs, and answer quality steps down on a date. The fix is unglamorous: keep a change log for knowledge and configuration, keep a frozen regression set of past tickets with known-good answers, and re-run it after any significant change. Quality assurance for AI support responses goes through that loop properly.

Autonomy is set per category, which is the whole point — it means the rollout is a sequence of small, reversible decisions rather than one switch you flip and then defend.

Start in suggest mode across every category and change nothing else for two weeks. The system drafts triage decisions, humans accept or override, and the accept-versus-edit-versus-discard distribution becomes a free quality signal generated by work people were already doing. Then promote one category — the highest-volume, lowest-variance one you have — to approve mode, where a human confirms before anything is applied. Only after a category holds a high acceptance rate with low edit volume across enough tickets to mean something does it earn autonomous mode.

Keep the demotion path as easy as the promotion path. If quality slips in one category, roll that category back to suggest, fix the source rather than the prompt, re-run the regression set, then restore it. Teams that can demote a category calmly end up trusting the system far more than teams that treat every rollback as a failure.

Connect a repository, point your chat, error tracker, and repo signals at the same intake, and let auto-triage run in suggest-only mode first. Pricing is flat from $79/month for the workspace, so putting every engineer and requester in the tool during the trial does not change the bill — which matters, because a triage system evaluated by three people on a filtered queue tells you very little.

Then measure two things and ignore the rest for the first month: time-to-first-action, and the accept-versus-edit rate on suggested triage. If those two move, the rest follows. If they do not, no headline auto-resolution number is going to save the rollout.