The short version
Key takeaways
- Treat every answer as a claim with a source, owner, and review date.
- Separate public facts, operating instructions, and restricted information.
- Test for refusal and escalation as carefully as correct answers.
Inventory the decisions the knowledge must support
Start from customer and employee questions rather than uploading every file available. Group questions into stable facts, frequently changing facts, policies, procedures, and judgment calls. Hours and addresses are stable facts; staff availability and inventory may change quickly; refunds and eligibility may require judgment.
For each answer, record the authoritative source, content owner, approved wording or constraints, audience, sensitivity, effective date, expiration trigger, and escalation path. This converts a pile of documents into governed knowledge.
Separate knowledge into safety layers
| Layer | Examples | Control |
|---|---|---|
| Public factual | Locations, published services, general hours | Source link and scheduled review |
| Operational | Routing rules, staff handoffs, qualification questions | Role-restricted editing and approval |
| Transactional | Availability, account status, order or appointment data | Authenticated system lookup and least privilege |
| Restricted | Credentials, unnecessary sensitive data, privileged advice | Exclude or isolate behind purpose-specific controls |
Do not assume that content is safe because it appears in an internal document. Remove secrets, personal data, expired policies, private notes, and contradictory drafts before ingestion.
Design source-aware answers
A reliable answer system should preserve where information came from and make uncertainty visible. Give the model a preferred source order, define which sources may override others, and decide what happens when sources conflict. Dynamic facts should come from a live system when possible rather than a copied paragraph.
Customer-facing tools should be able to say they do not know, ask a clarifying question, or hand off. Receptionist Max’s public workflow, for example, emphasizes approved website knowledge, source visibility, testing, and review. That combination is more useful as a design pattern than simply “training the AI on the website.”
Create a regression test suite
Build a question set from real support, sales, and operations work. Include paraphrases, incomplete questions, adversarial requests, policy edge cases, and facts that recently changed. Store the expected behavior—not always an exact sentence—along with the source and risk level.
Run tests before launch and after changes to prompts, models, retrieval settings, integrations, or important source content. Review accuracy, source alignment, action safety, tone, privacy, and escalation. High-risk failures should block release.
Operate a knowledge lifecycle
Assign review frequency based on volatility and impact. Publish through a draft-review-approve-retire process. Log who changed an answer and why. Give frontline staff a simple way to flag a wrong answer without granting them unrestricted publishing access.
Monitor unanswered questions, corrections, repeated handoffs, and source conflicts. These are not only AI quality signals; they often reveal unclear business policies. Respect privacy commitments about how customer data and model inputs are used. The FTC has repeatedly emphasized that actual data practices must match the promises made to customers.
Common questions
Frequently asked questions
Can a website be the only knowledge source?
It can be a starting source for public facts, but live availability, customer records, operating rules, and restricted data require different sources and controls.
How often should knowledge be reviewed?
Review by risk and volatility. Hours may need event-driven updates, prices and policies may need owner approval, and stable background information can use a longer scheduled review.
References and examples
Primary sources and product examples used to ground this guide. Product links are editorial references, not endorsements.