Internal KB vs. Customer-Facing FAQ

These are different things, and confusing them is the number one reason internal knowledge bases fail.

Your customer-facing FAQ answers simple questions: "How do I reset my password?" "What's your refund policy?" "Do you ship internationally?" It's written for customers. Clean language, no jargon, links to self-service tools.

Your internal KB is for your agents. It covers the messy stuff. Edge cases, escalation procedures, workarounds for known bugs, which engineer to ping at 2am when the payment system goes down. It can (and should) include internal jargon, links to admin tools, and honest notes like "this feature is broken and we're not fixing it until Q3."

Don't try to make one system serve both audiences. You'll either water down the internal docs or accidentally expose internal procedures to customers.

What to Document

Start with pain. Ask your support team: "What questions do you ask each other on Slack every week?" Those are your first articles.

Processes and Procedures

How to issue a refund. How to escalate a billing dispute. How to transfer a ticket to engineering. Step-by-step, with screenshots. Include which tools to use and what permissions you need.

Product Edge Cases

The stuff that's not in the product docs. "If a customer has two accounts with the same email, here's how to merge them." "The CSV export breaks if the filename has special characters." "This feature says 'unlimited' in marketing but there's actually a 10,000 row limit."

Troubleshooting Decision Trees

Customer says X. Check Y. If Y is true, do Z. If not, escalate to the billing team.

These are gold for new hires. They encode the institutional knowledge that experienced agents carry around in their heads.

Vendor and Integration Notes

API keys, account credentials (stored securely), contact info for vendor support, SLA details. When Stripe has an outage and customers are emailing you, your agents shouldn't have to hunt for Stripe's status page URL.

Policy Clarifications

"Can we offer a discount to keep a churning customer?" Maybe. Here's the decision framework, who can approve what dollar amounts, and what to say.

How to Organize It

Two approaches work. Pick one.

Option A: By Team Function

• Billing
• Technical support
• Account management
• Escalations
• Onboarding

This works well for specialized teams where agents own specific domains.

Option B: By Customer Journey Stage

• Pre-sale questions
• Onboarding issues
• Active use problems
• Billing and payments
• Cancellation and churn

This works better for generalist teams where every agent handles everything.

Whichever you pick, add a search function. No one browses a knowledge base by category. They search. If your KB tool doesn't have good search, pick a different tool.

Keeping It Updated

This is where most internal KBs die. Someone builds it, everyone uses it for a month, then it slowly rots until half the articles reference features that were renamed two years ago.

Assign Owners

Every article needs an owner. Not a team, a person. When the product changes, that person is responsible for updating the relevant articles. Put their name at the top of every article.

Build Updates into Existing Workflows

When engineering ships a feature change, the release notes should include "KB articles to update: [links]." When a support agent finds an article that's wrong, there should be a one-click way to flag it.

Audit Quarterly

Once a quarter, pull up articles sorted by "last updated." Anything untouched for 6+ months gets reviewed. Either it's still accurate (mark it reviewed) or it needs updating. Delete articles for features that no longer exist. Stale docs are worse than no docs because agents trust them and give customers wrong answers.

Tools

You don't need anything fancy. Notion, Confluence, Slite, or even a well-organized Google Drive works. The tool matters less than the discipline of maintaining it.

What does matter: search quality, easy editing (agents should be able to suggest changes), and version history (so you can see what changed and when).

How Supp Fits In

Supp's intent classification (315 intents, 92% accuracy) can route tickets to agents along with links to relevant KB articles. When the system classifies a ticket as "billing-refund-partial," it can surface your internal doc on partial refund procedures right in the agent's view. That's $0.20 per classification, no monthly fee, and your agents spend less time searching for answers.