Building a knowledge base an AI can actually answer from

Retrieval-based systems answer from what they can find. If a patient asks how long the redness lasts after a peel and your material says “downtime varies by patient”, the honest reply is “downtime varies by patient”, which helps nobody and books nothing. The model did not fail. The document did.

This is good news, because documentation is a problem your clinic can fix without a vendor. Most of the benefit arrives before any software is switched on: a clinic that writes proper treatment cards finds its human front desk answers faster and more consistently too.

Cards, not documents

The unit that works is a card: one topic, self-contained, two hundred to four hundred words, comprehensible without the document it came from. A fifteen-page treatment brochure retrieves badly because the passage that matches the question arrives without the context that made it meaningful.

The test for a card is simple. Read it alone, with no surrounding material. Can you answer a patient’s question from it? If it says “as described above” or “see the pricing section”, it is a fragment, not a card.

Write the answer, not the brochure

Marketing copy and knowledge cards are different genres and should not share a source. Compare:

The second one is what a good receptionist says. Write cards in the voice of your best-informed staff member explaining something to a patient — plain, specific, numeric where numbers exist.

Cover the questions, not the topics

The most efficient way to find gaps is not to plan a documentation project. It is to read your own inbox. Export three months of conversations, cluster them by what was asked, and sort by frequency. The top twenty questions are your first twenty cards, in order.

This nearly always surfaces topics no brochure covers: whether a treatment can be done during Ramadan, whether a husband can attend, whether there is parking, whether you take instalments, what happens if the patient is late, whether the treatment is visible afterwards at work. These are the questions that decide bookings and they are almost never written down anywhere.

• Every treatment you actively offer has a treatment card, an aftercare card and a preparation card.
• Every card names the questions it is meant to answer, so gaps are visible.
• Every card has an owner and a review date; clinical content is signed off by a clinician.
• Cards exist in every language you reply in, each reviewed by a person — a card the model translated on the fly is an unreviewed clinical document.
• Nothing in a card duplicates a fact that lives in the practice management system.

Write for both languages, separately

A clinic replying in Arabic and English needs cards in both. Machine-translating an English card at answer time produces text that is usually fine and occasionally wrong in ways nobody reviewed — and “usually fine” is not a standard for aftercare instructions.

Write the Arabic card as a card, not as a translation. Patients ask differently in Arabic; the terminology they use for treatments is often the transliterated brand name rather than the clinical term, and your card should contain the words patients actually type. More on this in Arabic, English, and everything in between.

Maintain it, or watch it rot

A knowledge base is a living asset that degrades silently — nothing breaks, answers just drift out of date. Three habits keep it honest.

• Mine the escalations. Every time the agent escalates because it had no answer, that is a candidate card, already prioritised by real demand.
• Mine the corrections. Every time staff edit a drafted reply before sending, the edit describes a defect in a card. Track them.
• Expire the stale. Cards past their review date should stop being retrievable rather than continue answering. Silence is recoverable; a confidently outdated answer is not.