KB article generation from resolutions

Support teams solve the same problem for the tenth time and notice the help center never covered it. Article generation closes that gap by drafting a knowledge-base page from the ticket where the problem was actually solved. The draft arrives with a title, symptoms, steps, and links to the source tickets.

The trigger matters more than the drafting. A solved ticket is checked against existing content. If a customer could have found the answer without writing in, nothing happens. If no article covers it, the ticket becomes a candidate.

What comes out is unpublished. It sits in a review queue with the resolution attached, the search terms that found nothing, and the count of similar tickets. A person edits and publishes.

Coverage is the other half of the value. The candidate queue is a running list of what the help center is missing, ordered by how many customers hit it. That list earns its keep even in weeks when nothing gets published.

The system does not decide the help center's structure. Where an article lives, what it is called, and which product it belongs to are editorial choices with search consequences.

Most closed tickets should produce nothing. A drafting job that fires on every resolution creates a help center nobody can maintain and search results full of near-duplicates.

Set the criteria before turning it on. A candidate usually needs three things. The issue appeared on several distinct accounts. The fix is something a customer can perform. No existing article covers it.

Customer-performable is the sharpest filter. Steps that require an internal admin tool, a database change, or an engineer belong in an internal runbook, not the public help center. Draft those separately and mark them internal.

One-off account fixes are the biggest source of waste. A refund issued as a goodwill exception is a decision, not a procedure. Publishing it as help content creates an expectation the business never agreed to.

Coverage checks need to run against the same search customers use. An article that exists but never surfaces is functionally missing. When the check finds an article that should have matched, the output is a retitle request rather than a new page.

Language matters as much as topic. Tickets arrive in the customer's words, and articles are often written in the product's words. Feeding the candidate the phrasing captured by fine-grained topic tags keeps the eventual title searchable.

If the coverage check cannot run, nothing gets drafted. A silent failure that produces duplicates is worse than a quiet day.

The draft is built from the resolved conversation, not from the model's general knowledge of thermostats or software. The structured record produced by problem, cause, and fix summarization on the closed ticket is the natural input.

Give the model the product documentation it may quote. Version numbers, screen names, menu paths, and supported configurations come from documentation, not from an agent's paraphrase in a chat reply.

Steps that were never written down cannot be drafted. When the reply says the customer was walked through it on the phone, the article needs a gap marker at that point. A plausible guess at the missing screens is worse than a blank.

The house format decides the shape. Symptom first, then who is affected, then steps, then what to do if the steps fail. Ask the model to fill a template rather than write freely, and rejects become easier to spot.

Retrieval helps the draft cover variations. Pulling the neighbors through similar resolved tickets and their fixes shows whether the fix differed by device generation or account type. One article covering three variants beats three thin pages.

This walkthrough describes an imaginary company. A hardware maker sells a smart thermostat that pairs with a phone app over the home network. Setup tickets are the largest category during the winter months.

Over three weeks, 62 tickets from 58 households describe the same failure. Pairing succeeds, then the thermostat drops off the app within a day. The agents solve it the same way each time: the router puts the phone and the thermostat on separate guest and main networks.

The coverage check finds nothing. Two articles mention pairing, and both stop at first-time setup. Searching the help center for the customers' own phrases, such as thermostat keeps going offline, returns neither one.

The system drafts a candidate from the cleanest ticket in the group. It carries a symptom section in the customer's words and an affected-devices line covering second and third generation units. Six steps cover checking network separation, and a closing section explains what to do when the router hides that setting.

The content owner makes three edits. She changes the title to match the phrase people actually searched. She removes a step referencing one router brand's menu, since the article cannot cover every model. She adds a warning that the fix does not apply to thermostats on a cellular bridge.

The published article gets linked back to all 62 tickets. Volume in that group falls over the next month. The drop is not immediate, since households already mid-setup keep writing. That decline appears in the contact-driver view over closed tickets.

Near-duplicates are the common failure. Three articles about pairing problems compete in search, each partly right, and the customer picks the wrong one. Merge before writing new, and make merging the default outcome of a coverage check.

Drafts inherit the ticket's blind spots. An article written from one household's ticket will describe one router, one phone platform, one firmware version. Say what the article was tested against, and keep the scope line honest.

Confident wrong steps are the expensive failure. A model that fills a documentation gap with an invented menu path sends customers into settings that do not exist. Gaps have to appear as gaps in the review queue.

Stale content accumulates faster than it is written. Every article needs a review date and an owner. When the app redesigns its settings screen, articles generated from last winter's tickets are wrong and still ranking.

Internal detail leaks into public pages. Ticket text contains account identifiers, internal tool names, and sometimes a home address. Strip and check before publication, and never let a source quote through unreviewed.

Articles written for agents rather than customers read wrong. A draft that says escalate to tier two was written from an internal seat. Public help ends with what the customer can do next, including how to reach support.

A person publishes every article, and their name is on it. That owner edits the title, checks the steps on a real device or account, and decides where the page sits.

Testing the steps is not optional. Following six steps once catches most errors that review misses. An article nobody has executed is a draft with a publish date.

Contesting a published article should be easy. Any agent who follows the steps and finds them wrong can flag the page, and the flag reaches the owner with the ticket attached. Agents hit the errors first.

The owner also decides not to publish. Some candidates describe problems the company would rather fix than document. Routing those to product instead of the help center is a legitimate outcome, and the ticket group is the evidence.

Published content feeds back into replies. Once the article exists, drafted responses grounded in knowledge-base sources can cite it. That is why the accuracy of a page matters more than the number of pages.