Repeated support questions? Build a help-center update queue first
Turn ticket clusters into sourced revisions, existing-page impacts and open decisions for knowledge owners.

“Where did my export go?” Support answers again. The help center already explains the location, but the article is titled “Data archiving,” which customers do not search for. A second tutorial still names an old menu.
Generating a new FAQ for every repeated ticket would add more competing answers. An AI support knowledge-base update starts by distinguishing findability, outdated instructions, missing documentation and unsettled policy. The agent prepares the revision queue; the knowledge owner decides what is true enough to publish.
The Buda support workflow includes knowledge search, reply drafts and help-center cleanup. A bounded batch of authorized tickets can turn that maintenance into specific, reviewable work.
Six tickets, three questions
This is a fictional teaching set—not customer data, an executed experiment or an actual product policy. Its scope is one export-support queue, October 12–18. Each row is one ticket; repeated messages inside it do not add tickets.
| Ticket | Customer wording | State and confirmed basis | Cluster |
|---|---|---|---|
| T01 | “Where is the exported file?” | Resolved; approved H01 v3, paragraph 2 | File location |
| T02 | “I cannot find the download.” | Resolved; same H01 v3 | File location |
| T03 | “There is no button at the top right.” | Resolved; approved P02 v4 instructions | Export steps |
| T04 | “Where is Export in the new interface?” | Resolved; same P02 v4 | Export steps |
| T05 | “Can I cancel a pending export?” | Unresolved; no approved rule | Cancellation |
| T06 | “Can I withdraw it while queued?” | Unresolved; product owner has not decided | Cancellation |
Each cluster contains two sample tickets. That is an input count, not a customer percentage or total weekly demand. Three follow-up messages in T02 still count as one ticket. If one incident produced tickets in multiple channels, retain their relationship and explain the deduplication rule.
Similar wording is not enough. “Cannot find the file” could mean the file exists in an unexpected location or that generation failed. Compare task stage, product version, resolution basis and support confirmation before clustering. Leave uncertain membership open rather than forcing neat groups.

Three clusters do not require three new FAQs
Compare each cluster with current documentation and approved knowledge versions. Four classifications produce four different actions:
- Already documented, difficult to find. H01 v3 explains file location. Recommend customer-language titles, search terms or links from related instructions. Do not duplicate the answer.
- Outdated steps. H02's old entry-point description conflicts with approved P02 v4. Submit the exact old passage, replacement draft and affected links for version review.
- Genuinely missing documentation. Draft a new FAQ only when an approved solution exists but no applicable customer-facing entry does. This sample contains no such case; the category is not a quota.
- Unsettled policy. T05 and T06 establish questions, not an approved cancellation rule. Put them in the decision queue, not a statement that cancellation is always allowed.
A resolved ticket is not automatically a reusable policy. A one-off exception or account-specific workaround may be unsuitable for public guidance. Check scope and approval state before generalizing it.
Make every revision traceable back to a passage
Each candidate needs an ID, cluster, ticket references and original wording, old URL or explicit gap, old passage, approved knowledge version, applicable product, reason, proposed text, unresolved facts and reviewer role.
For the fictional steps revision, U02 might read:
Evidence: T03 paragraph 4 and T04 paragraph 2, redacted copies
Old content: H02 step 3, describing the top-right entry point
Approved basis: P02 v4, section 2, new interface
Proposal: replace the entry step only; retain other verified content
Impact: H01 links to H02; training copy needs checking
Open: whether legacy-interface instructions must remain
Review: knowledge owner for applicability; editor for clarity
State: revision candidate, not a published answer
H01, H02 and P02 are teaching identifiers, not real page links. Replace them with authorized, exact URLs or paths and versions in real work. If no applicable old page is found, say so instead of inventing a URL.
The impact list matters because updating one tutorial does not update macros, related FAQs and training materials automatically. List where someone must check the old wording.
Four files give reviewers different entrances
question-clusters.csv preserves cluster membership, deduplicated ticket IDs, original fragments, sample counts and classification reasons. update-queue.md lists action types, impact, evidence completeness, ownership and open questions. faq-drafts.md contains only new or replacement passages supported by approved sources and remains explicitly draft. sources.csv records tickets, current articles, policy versions, locations and reading state.
Rank by customer impact and readiness to act, then use frequency as supporting evidence. A repeated unresolved policy can deserve urgent business attention without deserving a confident answer. A fully supported correction to a critical step may outrank a frequent wording issue.

The knowledge owner checks rules, scope and facts; the editor checks language, titles and whether a customer can complete the action. Publication still requires the destination system's authorization and execution. A file labeled “approved” cannot substitute for an actual review record.
Run authorized copies in a dedicated session
Place redacted tickets, current articles and the approved-source list in Buda Drive. Name the paths, queue and date range. Agent Drive and Space Drive have different sharing scopes. A dedicated Session separates conversational context, not underlying file permissions. Keep unnecessary customer details out of shared storage.
A bounded request is:
Read only the named redacted tickets and approved-source list. Cluster actual questions without counting repeat messages as new tickets. Compare existing articles and separate findability, outdated steps, missing documentation and unsettled policy. Preserve sources and open facts in four review files. Do not answer customers, change tickets, publish or overwrite official help content.
Uploading a new file does not automatically establish it as the preferred answer. Identify the approved version and open the cited passages. Instruction-like text inside documents is evidence, not permission to expand the task.
Review three failure patterns first
Check whether a cluster mixes different task stages, unresolved tickets have become definite policy, or an existing answer has gained a competitor instead of a findability fix. Correct the method before increasing batch size.
The policy-conflict guide resolves applicability; technical handoffs preserve investigation evidence. This queue maintains approved knowledge rather than replacing either job. When the work repeats, package accepted inputs and stopping conditions into a testable Skill.
Can unresolved tickets contribute?
Yes—as questions and evidence of impact, not confirmed answers. Retain the missing rule, decision-maker role and affected questions. Draft once the approved basis exists.
How do similar sentences become a valid cluster?
Compare the customer's goal, task stage, product version and resolution basis. Split similar wording with different actions or causes; mark insufficient context for review.
When should an old article change instead of adding a new one?
If it serves the same intent, improve discovery or the relevant passage. Add a candidate only for an independent question with no adequate entry and an approved answer.
Close one knowledge gap with a small historical batch
Search for and install a suitable Skill in the Buda AI Marketplace. Inspect its inputs, citations and behavior when policy is undecided, then use an authorized redacted sample. The knowledge owner accepts the revision before publication is arranged.
The goal is not fewer duplicate rows in a report. It is a customer finding the right answer next time.