Support answer workflow
How to Build a Customer Support Answer Knowledge Base
Keep customer-support answers reviewable after product or policy changes with approved sources, explicit scope, prohibited promises, owners, and review dates.
About this guide
Workflows
Support operations, technical writers, product support, and customer-success content owners maintaining approved customer answers
8 min read
01
Start with one approved product or policy change and the support questions it affects.
02
Record the supported answer, scope, prohibited promises, escalation condition, source revision, owner, and next review date.
03
Keep stale or unsupported answers visible for human review instead of publishing or sending them automatically.
Worked example
Build a customer-support answer knowledge base
A fictional three-file support exercise: reconcile a dated refund policy with a legacy reply, then draft an answer that keeps missing facts visible.
Try this task
Using only the three source files, write a support answer for a refund request. Identify the current window, separate direct checkout from marketplace purchases, list the facts still needed, and flag any stale or unsafe instruction. Cite every conclusion with [[filename]].
Expected reasoning
The dated policy supports 30 calendar days for direct-checkout standard and annual-plan requests. The legacy 14-day reply is stale. Missing channel, date, or transaction ID stays unresolved, and Billing must decide duplicate-charge or exception cases.
Why keep this connected
Plain files plus a careful reviewer can handle this one packet. A source-linked wiki becomes relevant when dated policies, legacy replies, and repeated review ownership need to stay connected across many support answers.
Review boundary
Compare the dated 30-day policy with the 14-day reply, confirm the direct-checkout and marketplace split, and keep missing channel, date, or transaction ID facts open for Billing review.
Inspect the example in Wenlan
Wenlan v0.18.3 interface displaying data read back from an isolated test run. The sources are fictional and the reference answer was written for this exercise. No automatic AI generation or approval is shown.
After the cited source changed, Wenlan marked the page as out of date and kept its original text. The ‘updating…’ label indicates a pending rebuild here; it does not show a completed correction. Review the changed source before rebuilding and accepting a new answer.
Source files
Open a file to read its complete authored Markdown.
The source files are the same authored English dataset in all three locale views.
01refund-policy-2026-04.mdRefund policy — revision 1
# Refund policy — revision 1 Effective: 2026-04-15 Scope: purchases made through the direct checkout. - A standard refund request is eligible when it arrives within 30 calendar days after purchase. - Annual plans follow the same 30-day window; after day 30, do not promise an automatic refund. - For a duplicate charge, verify the transaction IDs and escalate to Billing. Do not promise a refund before review. - If the purchase channel, purchase date, or transaction ID is missing, ask for it before deciding. - Marketplace purchases are outside this policy and must be routed to marketplace support.
02support-playbook.mdSupport answer playbook
# Support answer playbook Revision: 2026-04-20 Before making a policy answer, record the order ID, purchase channel, purchase date, and the customer's requested remedy. For a direct-checkout request inside the stated policy window, explain the rule and offer to send the case for refund review. For a request outside the window, state that an automatic refund is not promised and route an exception request to Billing. If the channel or date is unknown, ask the customer instead of inferring it. Keep marketplace cases with marketplace support. A support answer must separate what the sources say from what Billing still has to decide.
03refund-canned-reply.mdLegacy refund canned reply
# Legacy refund canned reply Status: owner review pending Thanks for contacting us. Direct-checkout refunds can be requested within 14 days of purchase. If the purchase date is missing, use the date shown in the ticket and continue. This reply does not distinguish direct checkout from marketplace purchases and does not describe duplicate-charge escalation.
Reference answer
Reference answer: dated policy wins, missing facts stay open
The dated policy supports a 30-day direct-checkout window. The 14-day canned reply is stale, and a missing channel, date, or transaction ID must remain a question for the customer or Billing rather than an invented decision.
Support refund answer — reference
Warranted answer
For a purchase through the direct checkout, a standard refund request is eligible for review when it arrives within 30 calendar days after purchase. Annual plans follow the same window. refund-policy-2026-04.md
The response must first record the order ID, purchase channel, purchase date, and requested remedy. If the channel or date is missing, ask for it. If the request is outside the stated window, do not promise an automatic refund; route an exception request to Billing. support-playbook.md
Marketplace purchases are outside this policy and go to marketplace support. A duplicate charge requires transaction-ID verification and Billing review; the answer must not promise a refund before that review. refund-policy-2026-04.md
What is stale or unknown
The legacy reply's 14-day window conflicts with the dated 30-day policy and must not be reused as current guidance. Its instruction to infer a missing date is also unsafe. refund-canned-reply.md refund-policy-2026-04.md
The sources do not decide whether Billing grants an exception or whether a specific transaction is a duplicate. A human owner still has to review those facts. support-playbook.md
Changed source: refund-policy-2026-04.md
Expected update after this change
The reference's 30-day conclusion becomes stale and must change to a 45-day direct-checkout window, including annual plans. The 14-day legacy reply remains stale. Duplicate-charge escalation, marketplace routing, and the requirement to ask for missing facts are unchanged; Billing still makes any exception decision.
# Refund policy — revision 2 Effective: 2026-05-02 Scope: purchases made through the direct checkout. - A standard refund request is eligible when it arrives within 45 calendar days after purchase. - Annual plans follow the same 45-day window; after day 45, do not promise an automatic refund. - For a duplicate charge, verify the transaction IDs and escalate to Billing. Do not promise a refund before review. - If the purchase channel, purchase date, or transaction ID is missing, ask for it before deciding. - Marketplace purchases are outside this policy and must be routed to marketplace support.
01
Quick answer
Build one answer pack for one support area and an approved set of product or policy documents. For each customer question, record the supported answer, scope, prohibited promise, escalation condition, source revision, human owner, and next review date. When a source changes, mark dependent answers stale or unresolved until the owner reviews the current passage.
Wenlan can connect supported Markdown, text, text-extractable PDFs, folders, and read-only Obsidian sources to source-backed Pages, citations, revisions, stale state, lint, and human review. It does not ingest help-desk tickets, CRM records, or raw customer conversations; it does not handle PII; it does not connect to support channels; it does not publish customer-facing answers; it does not generate replies; it does not synchronize channels; it does not automatically escalate.
02
When this problem appears
The failure appears after a product release or policy change: a support answer still sounds plausible, but its scope, effective date, exception, or promise no longer matches the approved source. A shared document or polished AI summary hides which revision supports the answer and who must review it. A useful support knowledge base keeps each answer small enough to check and leaves unsupported questions visible rather than filling them with confident language.
03
Build one question-to-answer review loop
Start with one support area and a small set of approved product or policy documents. Keep customer conversations, tickets, CRM records, personal data, and any material you are not authorized to use outside the source boundary.
- Name the product or policy area, effective date, support audience, included documents, excluded material, and human content owner.
- Register the approved Markdown, text, text-extractable PDF, folder, or read-only Obsidian source with its title, revision, date, and allowed scope.
- Create one answer record per recurring customer question. Separate the supported answer from applicability, prohibited promises, escalation conditions, and unresolved exceptions.
- Connect each important answer statement to the exact source passage and keep the source revision beside the record.
- When a release or policy changes, resync the affected source and mark dependent answers stale or unsupported until the owner checks the new revision.
- Before an answer is reused, have the owner open the source, confirm scope and effective date, and record the next review date. This workflow does not publish or send a reply.
Wenlan workflow and a neutral support answer record
wenlan status
wenlan sources add ~/Support/approved-product-policy
# In a Wenlan plugin client:
/distill <support answer topic>
/pages <support answer topic>
/lint
/curate
question: Can an existing subscription change plans immediately?
supported_answer: <answer supported by the approved policy>
scope: <plan, region, account state, and effective date>
do_not_promise: <actions or outcomes the source does not authorize>
escalate_when: <conditions requiring a human owner>
source_revision: <document ID, section, and revision>
owner: <human content owner>
next_review: <date or product-change trigger>04
What to check next
This is a source-backed content review workflow, not a help desk or customer-support automation system. Wenlan does not handle PII or promise redaction, provide team permissions, run support analytics, approve policies automatically, publish customer-facing answers, generate or deliver replies, synchronize channels, or automatically escalate a case. A qualified human owner must decide what an approved answer means and when it can be reused.
Make one support answer reviewable
Choose an approved product or policy source, record one bounded answer, and keep its revision, owner, limitations, and next review visible before anyone reuses it.
FAQ