DEV Community

Dingdang CS
Dingdang CS

Posted on Edited on

Writing Knowledge-Base Entries an Auto-Responder Can Actually Quote

A knowledge base can read well to a person and still fail an auto-responder. People skim, infer, and jump around a document; a responder quotes. It lifts a passage out of an entry and sends it as a chat message, and whatever context it loses in the lift is gone. Writing entries for that reality takes a different discipline than writing documentation, and it starts with granularity rather than style.

The quoting test

Before polishing any entry, run a simple check: if the responder lifted one paragraph from this entry and sent it alone, would it fully answer the question it matched? If the paragraph depends on a definition two screens up, or continues a thought split across sections, the answer is no — and the customer receives a fragment that sounds confident and explains little. Every paragraph intended for outbound replies should survive being sent on its own. Anything that cannot should be rewritten until it can, or moved into internal notes the responder is not allowed to quote.

One question, one answer, one fact per paragraph

Give each entry exactly one job: answer one question. Inside the answer, let each paragraph carry a single fact. Compare two versions of a shipping entry. The packed version reads: "Standard shipping takes several business days, express costs extra, and oversized items ship separately." A customer who asked about express delivery now gets a paragraph where their question is one clause out of three, and the responder has to guess which clause to trim. Split apart, the same facts become three quotable units, and the match picks the right one.

Atomic entries also age better. When a price or a transit time changes, you edit one card instead of untangling a policy essay, and the rest of the library goes untouched. One walkthrough of desktop auto-reply setup describes this shape explicitly: product lists get converted into atomic fact cards covering item, price, spec, and policy, and any draft reply that does not match a verified card is blocked from sending. That safety check becomes possible once the entries themselves are granular; see a step-by-step auto-reply setup guide built on verified fact cards.

Titles are questions, answers stand alone

Write the entry title as the customer's question, phrased the way customers actually ask it: "How long does delivery take after payment?" rather than "Logistics policy, section 3". The title is what matching runs against, and it is also what a human teammate types into search late at night. A title written in policy language hides the entry from both audiences.

Then make the answer self-contained. No "as mentioned above", no "see the next entry for the other half". A customer who receives one paragraph has no view of the rest of the document, and the responder cannot be relied on to send two entries in the right order. If two facts genuinely belong together, they belong in one entry; if they do not, they belong in two.

Do not pack three policies into one paragraph

The compound paragraph is where good intentions go wrong. Someone writes a returns section that also covers exchanges, then appends a line about price adjustments, and now every exchange question risks pulling in the refund-window text. The failure is quiet: the reply is factually accurate and beside the point, which reads to the customer as indifference. Separation is the fix — one policy per entry, one fact per paragraph, and cross-references kept in internal notes rather than the quotable body.

This matters doubly if you layer replies by audience. When replies vary by customer stage or channel, keep the underlying answer text identical and vary the framing; a guide to tiered reply scripts mapped to customer tags argues for changing just the difference point between tiers — greeting, example, link — rather than rewriting the substance, which keeps the fact consistent while the packaging adapts.

Keep entries quote-ready after launch

An entry library is maintenance, not a launch event. Watch the responder's logs for questions it could not answer, and write entries for the recurring ones using the customer's own phrasing. When a policy changes, update the entry the same day the price list or promotion changes, because a responder quotes stale text with the same confidence as fresh text. And when you add a new entry, run the quoting test again — the discipline that made the first hundred entries quotable is the same discipline that keeps the next hundred from becoming a pile of half-answers.

Top comments (0)