Most support tickets fall into one of three buckets. The docs answered the question and the user did not find it. The docs almost answered it. The docs did not cover the case at all. The first is a discovery problem. The second two are content gaps, and both kinds can be turned into doc updates with a small amount of help from a language model.
The workflow
A working version of the loop:
- A ticket comes in and gets resolved by a human in the usual way.
- After resolution, a job runs that compares the ticket question to the existing docs.
- The job classifies the ticket: covered, partial, or gap.
- For partial and gap cases, the job drafts a proposed doc update. For partial, it suggests a sentence or example to add. For gap, it drafts a new section.
- The draft goes to a writer or engineer to review.
- The reviewer approves, edits, or rejects.
Nothing ships without human approval. The model only proposes.
Practical notes
A few things that have to be right for this to work:
- The classifier needs the actual resolution from the ticket, not just the question. A user might ask "how do I cancel a subscription" and the answer might be "you cannot, you can only pause." The resolution tells the model what the docs are missing.
- The draft should cite the specific doc page it thinks needs updating. If the model wants to add a new page, it should propose where in the structure it belongs.
- Review needs to be fast. If drafts pile up unreviewed, the model is just generating noise. Five minutes of review per draft is reasonable. Thirty is not.
What changes over time
The interesting effect is not the first batch of drafts. It is the trend. If the workflow is running, the ratio of "gap" tickets should fall over time. New gaps still appear when the API changes, but old ones get closed.
That is the value of the loop: a feedback connection between what users actually ask and what the docs actually contain.
