Writing Help Articles From Tickets You've Already Answered

You have answered the same question four times this month. You know you have, because the fourth time you found yourself reaching for the third answer to copy the good bit out of it.

And each of those four times, the same thought arrived — this should be an article — and each time it lost. Not to laziness. It lost to timing.

Look at where the thought shows up. It arrives at the exact moment you finish a reply: the ticket is answered, the customer is satisfied, and your attention has already left. The next thing in the queue is loading. The branch you were on before support interrupted you is still open in another window. Writing an article right then means voluntarily stopping, opening a different tool, and starting a piece of prose from a blank page — because by the time you get there, the thread you'd be summarising has scrolled away and you have to reconstruct the whole thing from memory.

That's the actual mechanism. The knowledge exists at one moment and the writing has to happen at a different one, and the gap between them is where every unwritten article dies. Nobody has ever solved this with discipline. Support-doc backlogs are the most reliably unwritten documents in software.

The gap is what changed. An agent that just read the resolved thread — the customer's question, your diagnosis, your reply, the follow-up where they confirmed it worked — is holding, right now, everything the article needs. The writing can happen at the moment the knowledge exists instead of hours later from a worse copy of it.

The sequence, and why search comes first

The prompt is short, and it has four steps in a specific order.

• Search before you write. search_articles over the published knowledge base for the question this ticket asked. This step is not optional, and it is the one people skip. If you already have an article that half-answers this, the right move is almost always to improve it rather than to add a second one — two mediocre articles on the same topic are worse than one, because search now splits between them and the reader gets whichever ranks higher rather than whichever is better.
• Draft from the thread. The resolved conversation is the source. Not your memory of it, not a generic explanation of the feature — the actual exchange, including the part where the customer misread the UI, which is the part that tells you what the article has to say first.
• Leave it as a draft. create_article defaults to draft, and drafts are invisible to the public help centre and to the widget's AI answers until you publish. That default is doing something important: it means the agent can write freely without the write being a publication.
• Publish deliberately, later. A separate step, taken by you, after you've read it. list_articles is the management view that includes drafts — the one that answers "what did I write and forget to publish" — because search_articles only ever sees published ones.

The order matters more than the words. Search-then-draft is the difference between a knowledge base that gets better and one that gets bigger.

What compounds, exactly

The argument for doing this is compounding, but it's worth being precise about what compounds, because it isn't only "fewer tickets."

Three things get better at once. The obvious one: a question with a good article behind it stops arriving, or arrives as a link you paste instead of a paragraph you write. The second is that your replies get better, because an agent drafting a response can now cite something you wrote and vouched for rather than generating an answer from scratch — the knowledge base is the grounding, so writing it improves every future reply on that topic and not just the ones you deflect. The third is quieter: the widget's AI answers get sharper, because they're drawing from a corpus that grew out of real confusions rather than out of what you imagined people would ask.

That third one is the reason to write from tickets specifically rather than from a documentation plan. A doc plan describes your feature the way you understand it. A ticket-derived article describes it the way it was misunderstood — and misunderstanding is what a help centre exists to catch.

The volume question is worth asking honestly, though. If four people asked something this month, you don't know whether four hundred wondered it silently or whether those four are unusual. The heuristic that holds up: write the article on the second occurrence, not the first. Once is a person. Twice is a pattern, and the cost of a wrong guess is one draft nobody reads, which is close to zero. If you want the systematic version, ask across a month of threads — what are people asking that the knowledge base doesn't answer — and let the gaps rank themselves by count. Helmdesk's KB Gap Analysis automation runs that on a schedule and files drafts into a review queue, which is the same idea with the remembering done for you.

The concession: the draft is not the article

Here's where this fails, and it fails in a consistent way, so you can plan for it.

Agent-drafted articles are too long. Not occasionally — usually. The model has the whole thread and treats all of it as material, so you get an article that opens with a paragraph about how frustrating this can be, walks through the diagnostic path chronologically, mentions the two things that turned out not to be the cause, and buries the actual answer in step six. It reads like a transcript with headings, because that's what it is.

An article is not a narrative of how the problem was solved. It's the answer, first, followed by the thing you have to know to use the answer. The customer arriving at it is not curious about your investigation; they have the same problem and eleven seconds of patience.

So the edit is the job, and it's mostly deletion:

• Cut to the answer. The first sentence should be the fix. Everything explaining why the problem happens moves below it, or out entirely.
• Delete the dead ends. The two theories that turned out to be wrong were essential to solving it and are noise in the article.
• Strip the empathy. "We know this can be frustrating" belongs in a reply to a person, not in a document.
• Keep the customer's words for the title. They searched for "export button spins forever," not "resolving asynchronous export timeouts." Title it the way it was asked.

Ten minutes, honestly. But it's ten minutes of editing, which you'll do, rather than forty minutes of writing from a blank page, which you won't. That's the whole trade — and it's the same trade that makes the timing work, because editing survives a short attention span in a way that drafting never has.

The article you never wrote is still costing you. It's just charging in instalments, one re-typed answer at a time, and it will keep charging until somebody writes it down at the moment they know it.

Turn a resolved thread into a draft article

Search first, draft from the real conversation, publish when you've read it. Your knowledge base grows out of what people actually asked.

Start freeRead the articles docs