AI-Native Service Desk: Recovering $25K per Technician per Year
Service teams were quietly losing 5–15% of billable time to a broken ticket workflow: fragmented intake, manual triage, inconsistent runbook association, painful closure that technicians defer until billable detail is lost. The industry's answer was cosmetic AI again: a copilot in a sidebar that says "summarise this," "suggest a reply." It didn't move the needle, ours included, because AI living beside the workflow is a feature, not a working surface. The technician still opens the ticket, scrolls the thread, hunts for the asset, guesses the priority, and starts working.
The bet: don't add AI to the workflow; rebuild the workflow around it. When a ticket lands, the work is already done before the technician opens it: the AI has read the request, identified the asset, classified the issue, pulled related patterns and KB, drafted a first response, and assembled a numbered execution plan. The technician opens a plan, not a blank canvas. We could do this because we're the PSA and the RMM: the AI recommends from how this customer has solved this problem before, not from what the email says. That context is the moat.
The Plan Card: the plan is the unit of trust. The AI runs ahead and drafts the plan; the technician reviews, edits, talks to it, and approves before anything happens. Deliberately "do-it-with-me," not autopilot: a plan you can read and edit is inspectable; an action that already fired is not.
Trust earned through autonomy-sequencing. An explicit path (assisted plans → pattern intelligence → auto-remediation), and no skipping steps. You earn the right to automate a class of work by being demonstrably right while only assisting first.
Monetisation designed in, not bolted on. Because "native" means the AI is load-bearing, switching away breaks the ticketing workflow itself. That structural switching cost is why AI-native ticketing belongs inside platform pricing, not as a metered upsell. The thing that makes it sticky and the thing that makes it monetisable are the same thing.
The honest version of this story is that the first version shipped fast and under-delivered on the one thing that mattered: trust. It surfaced genuinely useful intelligence, and technicians still wouldn't act on it. Diagnosing why is what made the product.
Three failures, and the rebuild each one forced.
The AI assumed instead of asking. It generated a full plan on page load without knowing what the technician intended, then drafted communications confirming things that hadn't happened. So I changed the model to ask before assuming: surface the intelligence first, ask the technician a scoped question on ambiguous or high-severity tickets, and generate the plan against the path they chose. Routine tickets still auto-plan; judgment tickets get a question.
Execution felt unsafe. "Execute" went from plan to sent in one click, so technicians never pressed it. I moved to an Execute-to-Draft model (actions land as drafts in the ticket for review before they fire) and split low-risk field updates (priority, category) from outbound communications, which always draft, since different risk profiles get different defaults.
It was slow and expensive. The first version fanned out into many redundant model calls per ticket: duplicated retrieval, competing processes overwriting each other. I worked with engineering to redo the PRD around cost and speed: consolidate into a single streamed pipeline, cache shared context at the account level instead of regenerating per technician, and prefer the model's own grounded knowledge over noisy web fallback. Same product, a fraction of the cost and latency.
And the differentiator doubles as the data engine: every edit a technician makes to a plan is a labelled signal about what the AI got wrong; every approval, what it got right. Now the work is tuning the AI with a real eval discipline: Langfuse traces with marked metadata, separate reasoning and scoring prompts (a model that grades its own output rationalises it), banded rubrics with anchored examples, and an LLM-as-judge that gates whether retrieved sources are even relevant before they reach the technician. We validate against real human-written resolutions, not simulated ones. If you can tell which one the AI wrote, the prompt isn't done. That's what lets us gate each release on observed quality instead of a ship date.
Translated directly into a usage-based monetisation lever in the 2026 plan. The product didn't just save customers money; it gave the business a defensible way to price.
AI products don't lose because the model is bad. They lose because the workflow stays the same and (I learned the hard way) because you ship speed over trust. The first version was fast and smart and unused. It started working when I made the AI ask before it assumed, made execution feel safe, and built the eval loop so quality is observed rather than hoped for. Design AI into the workflow at the trust boundary (the exact point a human says "yes, run it"), and adoption and monetisation stop being separate problems.
Shipped the trust boundary first (assisted, human-approves), pushed automation to a later stage, and gated every release on a metric.
Read the thesis