Write knowledge that produces useful answers

Good knowledge does more than contain the correct fact. It makes the scope, conditions, exceptions, and next step clear enough that the assistant can use them in a real conversation without guessing what your team meant.

You can use the same writing principles for public website pages and private text sources. The goal is a small collection of clear, owned answers rather than a large archive of loosely related information.

In this article, you'll learn:

• How to organize knowledge around customer questions
• How to write precise rules and exceptions
• How to structure topics for easier use
• How to write a useful source hint
• How to avoid conflicts and sensitive content
• How to test both answers and boundaries

Start from customer questions#

Start with the language customers already use. List the questions your team receives most often, then identify the approved answer and the person or team responsible for keeping it current.

Create sources around recognizable topics such as delivery, cancellations, plan selection, service eligibility, and support steps.

Avoid one large source named “Everything about the business.” Smaller, well-scoped sources are easier to name, update, and test. They also make conflicts easier to spot.

State rules precisely#

A customer often needs the condition around the answer as much as the answer itself. Include the details that change the outcome:

• who or what is eligible;
• the exact time period or amount;
• required conditions;
• important exclusions;
• the next action the customer should take;
• where to go when the standard rule does not apply.

Use customer language and define specialist terms. Replace words such as “normally,” “soon,” or “reasonable” with an exact rule when your business has one. If the business has not decided the rule, resolve that internally before asking the assistant to explain it.

Separate topics and exceptions#

Use descriptive headings and short sections so each answer has an obvious home. State the standard rule first, followed by named exceptions. If two policies apply to different regions, products, or customer types, label those scopes explicitly.

Write a specific source hint#

The hint is a short description of when the source should be useful. It should distinguish the source from neighboring topics without trying to repeat the full policy. A strong pattern is:

Use for [topics] when [scope or condition].

Examples:

• Use for cancellation eligibility and fees for annual subscriptions.
• Use for delivery times and restrictions for orders shipped to Poland.
• Use when qualifying a business customer for an implementation call.

Avoid conflicts and unsafe content#

Before adding another source, check whether an existing one already owns the topic. Do not repeat the same rule across many sources unless the copies are maintained together. Remove old promotions and superseded policies.

Never add credentials, private personal data, or instructions that should not be shared with customers. A private text source can still influence a customer-facing answer.

Behaviour instructions cannot fix incorrect source facts. Update the knowledge itself.

Test for usefulness and boundaries#

Testing should confirm both where the source works and where it stops applying. For every important source, test:

1. a direct question using the source's own terms;
2. the same question in everyday customer language;
3. a follow-up that depends on the previous answer;
4. an exception described in the source;
5. an unrelated question that should not use the source.

Check numbers, dates, eligibility, links, and next steps against the approved material. Repeat the same test after every material update so you can compare the result directly.

For source workflows, see Knowledge sources overview.