The knowledge a desk actually needs
The editorial job: four content types, the line between prose and facts, and writing down what your knowledge base does NOT cover.
Track 1 taught you to create a knowledge base. This lesson is the harder job: deciding what belongs in it, and in what shape. That is an editorial decision, not a technical one, and it is the single thing that determines whether your desk is trustworthy.
A true story about this exact knowledge base
While this course was being built, the Academy knowledge base contained five documents: refunds, service levels, certification, discounts, corporate terms. All well written. All correct.
One of them, the discounts policy, contained this sentence:
Fees, discounts and instalment amounts must be quoted exactly as recorded. Never estimate, round, or infer a price.
There were no fees in the knowledge base. Not one course price, anywhere. The rule pointed at facts that did not exist. An agent following that instruction to the letter would refuse every pricing question ever asked — and an agent following it loosely would invent one.
The lesson inside the mistake. Policy documents are easy to write, so they get written first. Nobody sits down to author a price list, because everybody already knows the prices. Check what your knowledge base is missing by asking it your customers' most common question — not by reading its table of contents.
Four content types, and who owns each
| Type | Example | Comes from | Goes stale when |
|---|---|---|---|
| Catalogue | What you sell, what each thing is, what it costs | Whoever owns pricing — finance or the founder | You change a price. Immediately, and silently. |
| Policy | Refunds, deadlines, thresholds, escalation limits | Whoever carries the risk — ops or legal | A rule changes. Usually noticed late. |
| FAQ | The forty questions you answer every week | Whoever is on support today | Slowly. It is the cheapest to maintain and the most neglected. |
| How-to | Access, logins, prerequisites, what to do first | Whoever onboards customers | You change a flow and forget the doc describes the old one. |
Catalogue
- Example
- What you sell, what each thing is, what it costs
- Comes from
- Whoever owns pricing — finance or the founder
- Goes stale when
- You change a price. Immediately, and silently.
Policy
- Example
- Refunds, deadlines, thresholds, escalation limits
- Comes from
- Whoever carries the risk — ops or legal
- Goes stale when
- A rule changes. Usually noticed late.
FAQ
- Example
- The forty questions you answer every week
- Comes from
- Whoever is on support today
- Goes stale when
- Slowly. It is the cheapest to maintain and the most neglected.
How-to
- Example
- Access, logins, prerequisites, what to do first
- Comes from
- Whoever onboards customers
- Goes stale when
- You change a flow and forget the doc describes the old one.
The line that actually matters
Content type is a filing question. The distinction that changes your agent's behaviour is a different one, and it cuts across all four:
Prose the agent can safely rewrite in its own words. Facts it must copy or decline. The test is not how important is this — it is how many correct answers are there. "Who this course suits" has many good answers. "What it costs" has one.
Write your documents so the difference is visible on the page. Prices in a table, not a paragraph. Thresholds as numerals. Anything a customer could hold you to, formatted so that quoting it is easier than rewording it.
Write down what is NOT in there
The most useful section in the Academy catalogue is the one that lists what it deliberately omits — corporate pricing, partner rates, instalment amounts, historic prices — and says plainly that no figure for them may be inferred from the table above.
That section is what lets the agent refuse precisely instead of refusing vaguely. It is the difference between "I can't help with pricing" and the reply you will see in a moment, which names exactly which figure is missing and why it cannot be derived from the ones that are present.
A knowledge base has two jobs. Everyone builds it for the first — supplying answers. The second is supplying the boundary: telling the agent where its knowledge stops. Most are built with only the first half.
Do this now
- Ask your own knowledge base the three questions your customers actually ask most. Not test questions — the real ones.
- For each answer, check whether the figures in it appear verbatim in a document, or whether the model assembled them.
- Write the missing document. It is almost always the catalogue.
- Add a section to it listing what it does not cover, and saying that nothing may be inferred from what it does.
Next: having given it the boundary, you have to teach it to respect one. That is lesson 4.
Related lessons
Base rates — what a piece of evidence is actually worth
A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.
ReadConfirmation and survivorship — what you never looked for
Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.
ReadLoss aversion, sunk cost and regression — what it costs you
Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.
Read