Keep FAQs current using support conversations
Use resolved support cases to find reusable answers and help articles that have become outdated. Propose targeted updates while preserving valid guidance and pending editorial work.
How this works
After a support case closes, find a reusable answer, check the existing knowledge base, and propose an update to its editor.
Maintain existing support knowledge by comparing new resolved questions with current articles. The core decision is whether to revise, add or do nothing, not simply to generate more FAQ entries.
For a periodic review, start with resolved tickets that cite an article or describe a step it omits. Distinguish a missing answer from an existing answer that has drifted from the product; do not rewrite correct content just to produce an update.
Before you start
Defined operating scope
Support staff resolve questions that the published FAQ does not yet answer.
Required source material
Obtain Resolved support cases; Current knowledge base; Review queue. If connectors are unavailable, use authorized files with the same fields.
Decision and exception rules
A matching draft is already awaiting review. Attach the new evidence to that draft instead of creating another.
Prepare the inputs
- resolved_case
- Required
Question, confirmed answer and case ID
Exclude unresolved or customer-only workarounds.
- knowledge_snapshot
- Required
Article IDs and versions
Use current published and pending drafts.
- reuse_rules
- Required
Applicability and privacy criteria
Define which fixes can help other customers.
- editor_queue
- Required
Article owners and statuses
Check pending changes before proposing duplicates.
- article_ticket_links
- Optional / conditional
Article IDs cited in resolved tickets, affected steps and observation window.
Use direct references where available; label semantic associations as proposed. One case can reference several articles.
- current_product_reference
- Optional / conditional
Approved release, policy or product evidence for the affected instructions.
Required when changing prices, limits or product behavior. Repeated agent wording is not authoritative proof that the product changed.
Implementation, step by step
Establish the working record
- Confirm the selected records, effective versions and responsible owner.
- Check resolved_case, knowledge_snapshot, reuse_rules, editor_queue before beginning. Record the source version and the selected scope; an unavailable value stays unknown rather than becoming an inferred fact.
- For a batch audit, record the eligible article and ticket inventory, time window and accessible coverage. Articles not checked remain unassessed.
Checkpoint: The input record identifies the selected resolved_case and any missing required fields.
Extract the question and confirmed solution
- Extract the reusable question and confirmed resolution while retaining applicability limits.
- Compare proposed changes with both published and pending content.
- Classify the evidence as a missing step, outdated statement, unclear explanation or new question. Retain the exact article passage and case reference.
Checkpoint: A saved intermediate result for: Extract the question and confirmed solution.
Search the knowledge base for matches
- Search semantic and exact matches across published articles and pending drafts, comparing answers rather than titles alone.
- Test the updated answer retrieval using the original question and a paraphrase.
- Link recurring cases to their cited article and count distinct cases separately from repeated messages. Frequency guides editor attention but does not prove the article caused the tickets.
Checkpoint: A saved intermediate result for: Search the knowledge base for matches.
Propose a new entry or an update
- Propose a precise patch to an existing entry, a new entry, or no change; show the case evidence and reason.
- Compare proposed changes with both published and pending content.
- Draft only the affected sections. Preserve screenshots and instructions that remain valid; flag assets needing a product-version check rather than regenerating everything.
Checkpoint: A saved intermediate result for: Propose a new entry or an update.
After review, update the assistant’s answer source
- After editorial approval, update the designated answer source and confirm the assistant retrieves the revised version.
- Test the updated answer retrieval using the original question and a paraphrase.
- Check the revised steps against the approved current-product evidence as well as retrieval. A newly indexed answer can still be substantively wrong.
Checkpoint: A saved intermediate result for: After review, update the assistant’s answer source.
Package the result and unresolved work
- Verify the solution, check for duplicates, and confirm that the answer is reusable.
- Do not publish customer identifiers or unverified workarounds.
Checkpoint: An approved FAQ update linked to its source conversation. Unresolved items remain visible in the review record.
Decisions along the way
A matching draft is already awaiting review.
Attach the new evidence to that draft instead of creating another.
The case contradicts current documentation.
Escalate the conflict to the knowledge owner before replacing guidance.
The published article updates but retrieval remains stale.
Recheck indexing and withhold claims that the assistant uses the new answer.
Several agent replies repeat guidance that conflicts with current product evidence.
Hold the substantive change for the product or knowledge owner; repetition does not validate an answer.
What you will produce
support-faq-update-loop-result.json
JSONAn approved FAQ update linked to its source conversation. Label proposed and completed states separately.
Include: case_id · matched_article · action · proposed_patch · editor_owner · retrieval_version · status · evidence_reference · review_note
support-faq-update-loop-review.md
MarkdownKeep the evidence and unresolved decisions needed to apply this result, including exceptions involving editor_queue.
Include: source_reference · question · owner · next_action
help-center-audit.csv
CSVA periodic audit view linking proposed drift to cases; optional for a single-case update.
Include: article_id · article_version · distinct_case_ids · affected_passage · drift_type · product_reference · proposed_action · audit_state · owner
Check the result
- Compare proposed changes with both published and pending content.
- Test the updated answer retrieval using the original question and a paraphrase.
- Inspect resolved_case and knowledge_snapshot in both the original and output; confirm that record identity and interpretation survived the transformation.
- Verify the solution, check for duplicates, and confirm that the answer is reusable.
- Reconcile eligible, checked and unassessed articles; do not label inaccessible articles current.
- Verify that a targeted patch preserves still-correct instructions and that cited cases fall inside the stated audit window.
When something goes wrong
A matching draft is already awaiting review.
Attach the new evidence to that draft instead of creating another. Retain the affected evidence and recovery status.
The case contradicts current documentation.
Escalate the conflict to the knowledge owner before replacing guidance. Retain the affected evidence and recovery status.
The published article updates but retrieval remains stale.
Recheck indexing and withhold claims that the assistant uses the new answer. Retain the affected evidence and recovery status.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Keep FAQs current using support conversations for the following bounded example; prepare the result for review.
Inputs
Synthetic example: Case C-11 confirms an updated reset path. Article A-3 describes the old menu; draft D-2 already proposes the same change. Two other closed cases cite the same old menu; an unrelated article is unavailable during the audit.
Expected result
Synthetic expected result: Attach C-11 to D-2 and record no new article. After approval, verify A-3’s new version is returned for the reset question. The audit row links three distinct cases to A-3 and marks the unavailable article unassessed; repeated message copies do not increase the case count.
Run a small pilot
Start small
Trial a representative batch containing the ordinary case and the exception demonstrated above.
Record the baseline
Record current preparation time, review effort and correction types for the same records.
Agree success criteria
Agree acceptable review and error limits; measure accepted FAQ updates per review cycle; duplicate or incorrect updates.
Stop or revise
The published article updates but retrieval remains stale. Pause affected records and apply this recovery: Recheck indexing and withhold claims that the assistant uses the new answer.
Keep the scope clear
- Do not publish customer identifiers or unverified workarounds.
- Editorial approval and indexing success are separate recorded states.
Check before using
Verify the solution, check for duplicates, and confirm that the answer is reusable.
Business activities
- Resolve customer questions
- Maintain shared company knowledge
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Resolved support cases · Current knowledge base · Review queue
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow