How to Keep a Guru Knowledge Base From Going Stale
Direct answer: A Guru knowledge base stays current when every card has an owner, verification intervals are set by how often the fact changes, and expired cards are quarantined rather than shown with a warning.
Six months after launch is the interesting moment. Verification prompts pile up, the owner who wrote 40 cards moved to another team, and the Slack bot starts suggesting answers that stopped being true last quarter.
Here’s the maintenance model we settled on after watching two implementations rot and one survive.
Why do verification prompts get ignored?
Because verifying is all cost and no reward. The owner opens a card, reads it, clicks “verified”, and nothing happens. Meanwhile the prompt keeps arriving for 60 more cards.
Two fixes that measurably worked:
- Cap cards per owner at 15. Past that, people batch-click to clear the queue and verification becomes meaningless.
- Make verification a weekly 20-minute calendar block owned by the team lead, not a silent notification. Reviewed together, cards get corrected; reviewed alone, they get rubber-stamped.
What verification interval should each card have?
Set it by how fast the underlying fact moves, not by how important the card is.
| Content type | Interval | Example |
|---|---|---|
| Pricing, discount, policy | 30 days | “Can I offer a 20% discount?” |
| Process and procedure | 90 days | “How do I escalate a refund?” |
| Product behavior | 90 days or at release | “Why doesn’t the export include attachments?” |
| Company and HR info | 180 days | “What’s our PTO policy?” |
| Immutable reference | 365 days | “What’s our company registration number?” |
Anything you can’t classify goes to 90 days. That’s the safe default and it catches most drift before a customer does.
How should stale cards behave?
This is the most important setting and most teams get it wrong. Guru offers options for what happens when a card expires. The default behavior — showing the card with a staleness warning — is the worst of both worlds: your team sees a warning and clicks through it, so the warning becomes invisible within a month.
Set expired cards to be hidden from Slack suggestions but still findable by direct search. The team member who searches deliberately sees it flagged; the bot doesn’t confidently quote a dead answer into a customer channel.
How do you find cards that are wrong but verified?
Verification catches ageing, not errors. A card verified yesterday can still be wrong if nobody looked at the sub-step that changed.
Use negative feedback as the detector. Every Guru card has a thumbs-down option, and in Slack there’s a quick reaction path. Pull the cards with two or more negative signals in a quarter and put them in the weekly review. Teams that don’t act on thumbs-down lose the feedback habit within two months.
Second detector: new-hire questions. During weeks 1-4, a new hire asks the questions your knowledge base was supposed to answer. Have them keep a running list of questions the cards didn’t answer or answered incorrectly. That list is the highest-value backlog you’ll ever get.
What metrics show knowledge is decaying?
Three, tracked monthly:
- Verified card share. Below 80% means the maintenance is behind.
- Card creation vs archive ratio. If you create 40 cards a month and archive zero, you’re hoarding, not maintaining.
- Repeat questions in Slack. Questions asked helpfully answered by a human despite an existing card are the clearest failure signal — the card exists, is findable in principle, and is not good enough to use.
Who should own the knowledge base?
Not a committee. One person with 20% of their week allocated, called something like Knowledge Lead. Their job is triage, not authoring: they route new questions to the right owner, run the weekly review, and archive dead cards.
When nobody owns it, the plausible failure is not deletion — it’s accumulation. Four hundred cards where 200 are partly true is worse than 80 cards that are all correct, because search returns more and trusts less.
What about migrating away from Guru later?
Worth thinking about before you import 500 cards. Guru exports cards to HTML or PDF, and the export keeps content but not the owner-and-verification model. If you move to a plain wiki, you inherit your knowledge base minus the one feature that kept it honest.
That isn’t a reason to avoid Guru. It is a reason to check, at the 18-month mark, whether the team still verifies anything. If verification has stopped, you’re paying premium pricing for a wiki.
Key Takeaways
- Cap cards per owner at 15 or verification becomes rubber-stamping.
- Set intervals by fact volatility: 30, 90, or 180 days.
- Hide expired cards from Slack suggestions; keep them searchable.
- Track verified share (keep above 80%) and repeat human-answered questions.
- One Knowledge Lead at 20% time beats a committee.
