The team did not want an AI that answers tickets, and they were right. What they would accept was an AI that asks the questions they would have asked, and then gets out of the way.
The problem: incoming requests from clients were often a sentence long. “The report is wrong.” “Can we add a field.” Staff spent their first hour on each one asking what the client actually meant, and the client, having moved on, took a day to answer. Nobody was doing anything wrong. The ping-pong was just the cost of a request arriving without enough in it to start.
The mechanism
The requester writes what they want and attaches whatever evidence they have. Before a person sees it, a model checks the request against three things:
- where: which screen or feature
- what: current behaviour versus desired, and the implied acceptance criteria
- evidence: a nudge for a screenshot if there is not one
It asks only for what is missing, and it is hard-capped at two or three rounds. An uncapped clarifier turns into a chatbot maze and people abandon the ticket, which is worse than the vague one you started with.
The output is a structured draft: title, description, area, suggested priority, attachments. The requester confirms the draft, not the conversation. That confirmed draft lands in a review queue, where a person edits, approves or declines it in a batch. One click turns approved drafts into real tickets in the system of record.
The map is the part that matters
Without it, this is a generic chatbot. The model asks generic questions and invents screen names.
With it, “which of these screens?” is answerable in one tap and the resulting ticket names a real part of the application. The map is a short, structured list of each client’s screens and features, kept in an admin section and ideally seeded from the app’s own structure. It is what makes the AI’s questions relevant rather than plausible.
It also goes stale, so it needs an owner. A useful signal turned out to be how often requesters pick “area: other”. When that climbs, the map is behind the product.
Details that decided whether people used it
Declines need a visible reason. A gate with no explanation reads as a black hole, and requesters stop submitting.
This is a small-model job. The context is the map plus a short conversation, the output is structured, and the per-request cost is negligible. Reaching for the biggest model here is habit, not need.
The human step is not a compromise. Every ticket still goes through a person. What changed is that the person reads a ticket with the detail needed to start, and the first questions went back to the client immediately instead of the next morning.
When it is the wrong tool
If requests are already structured, a form is enough. If the request surface is unbounded, there is no map to ground against and the model degrades to generic questioning, which annoys more than it helps. It works when intake quality costs real hours, requesters are external or non-technical, and the thing they are asking about is finite enough to list.