80/20 Rule in
Knowledge Management
Team Knowledge Log and Fixes for Repeat Questions
Your team keeps asking the same questions in chat. Someone answers. The answer disappears. A new wiki page goes up. Nothing changes.
That is the 80/20 rule in knowledge management. A few recurring questions eat most of the support time. A few owned pages - if people can find them - stop most of the noise. The rest is documentation that looks complete but rarely gets reused.
Below: a two-week question log, the vital few habits that cut repeat asks, and the wiki work that rarely moves the needle. For teams drowning in tools - not an enterprise maturity program.
The mismatch: pages published vs questions answered
APQC's Knowledge Flow Process frames knowledge as a cycle - create, identify, collect, review, share, access, and use - not as a pile of files (APQC: Knowledge Flow Process Framework). The identify step is a concentration rule: focus on knowledge critical to strategy and operations instead of collecting everything (Managing Knowledge Starts with Knowledge Flow).
A typical quarter can look “knowledge-rich” - hundreds of pages, a shiny portal - while the same five questions still land in chat. Kept outcomes are narrower: a question that used to take three pings now takes one link; a stale procedure that stopped causing defects; an expert who is no longer the only FAQ bot. If you cannot name those, the wiki lied.
80/20 example: Two weeks of chat logs where three topics generated most “how do we…?” pings, while the team spent the sprint gardening unused template pages. The majority practice was coverage. The concentrated result would have been three source-of-truth pages with owners.
Find your vital few: a two-week question log
Do not invent a universal docs Pareto. Measure your last two weeks. For each repeated question, search fail, or expert ping, log four cells. Keep it ugly and honest.
| Cell | What to write |
|---|---|
| Topic | Short name of the recurring ask |
| Ask channel | chat · meeting · ticket · email · search-fail |
| Doc state | none · exists · stale · unfindable |
| Kept outcome | reused · rewrote · asked-again · none |
After ten to fourteen days, sort by topics with the most asked-again rows - or the highest ping count. That short list is your vital few. Everything else can wait - especially wiki gardening of pages nobody asked for.
Illustrative sample: one product team’s two weeks - 28 logged asks. Top topics: deploy steps (9), expense codes (6), access requests (5). Those three were 20/28 ≈ 71% of asks. Doc state was mostly stale or unfindable. The KM backlog became three pages with owners and links from the chat tools people already used - not a fourth wiki migration.
8020 move: Run the log for the next ten working days before buying a new KM tool or launching a “document everything” drive. Protect the top recurring topics; write or fix only those sources of truth first.
Wiki habits that rarely change the ask-again rate
- Documenting every edge case “for completeness”
- Empty tool migrations with no owners
- Orphan pages nobody maintains
- Experts answering forever in chat with no capture
- Measuring success by page count or AI demos
- Search theater - better ranking of junk
- Writing docs people cannot find from where they ask
Protect the few habits that already create reuse
1. Identify before you collect
APQC’s identify step is the concentration gate: what knowledge is critical to how you operate? Recurring questions are a practical proxy. If it is not asked, searched, or costly when missing, it can wait. Decision framing when stakes force unequal attention: 80/20 in decision-making.
2. One source of truth per top topic
Duplicates are how trust dies. For each top log topic, pick one canonical page (or short video) and make every other mention link there. Collect once; review when reality changes. “Use” fails when five conflicting answers exist.
3. Named maintainer and a light review rhythm
APQC’s review step exists because stale knowledge is worse than no knowledge - people trust it until it burns them. Every vital page needs a human owner and a date. Without that, you have a museum.
4. Access from the ask channel
If questions live in chat, the first link should live in chat - pinned FAQ, bot shortcut, channel topic. If they live in tickets, macros should point at the page. Findability is not a homepage redesign; it is putting the answer on the path people already walk. Productivity cousin when the goal is shipped work, not more systems: 80/20 in productivity.
Chaos filter: one lever when the wiki is loud
When a reorg hits, a tool vendor demos, or “we need to document everything” returns, pick one lever that still matches your log:
- Top-three topics only - fix those pages this sprint
- Capture one expert answer - turn this week’s repeated chat into a page
- Archive one unused hub - reduce noise so search can work
If none of those still fits, you are not doing KM - you are collecting content. Time when the calendar is the bottleneck: 80/20 in time management.
8020 move: For one week, every time you answer the same question twice, log it on the log and either link the canonical page or create a stub with an owner before you close the chat.
Why other “KM methods” are secondary
Ontology projects, full-text AI overlays, and beautiful portals can help later. They are secondary if you have not named which questions already burn the most time. Taxonomy perfection is secondary if nobody maintains the top three pages. Find concentration first; then decide whether a tool upgrade deserves budget.
Before / after: same hours, different concentration
| Scattered quarter | Concentrated quarter | |
|---|---|---|
| Focus | Document everything | Top recurring questions |
| Experts | Answer forever in chat | Capture once, then link |
| Pages | Many orphans | Few owned sources of truth |
| Findability | Hope search works | Links in the ask channel |
| What you measure | Page count / tool demo | Asked-again rate down |
Same rough hours can produce a quieter support channel - or a prettier empty wiki. The difference is which topics you protect.
Misreads that flatten the idea
“Concentration means we only document for executives.”
No. Recurring operational asks - access, deploy, billing, onboarding - often dominate. Concentration follows demand, not hierarchy.
“If we log KM, we should optimize every APQC step at once.”
That turns one sprint into a twelve-step program. Identify the top topics, collect and review those, make them accessible, watch use. Stop there until the next two-week log.
Moves that only make sense if concentration is real
If every page were equally useful, the right strategy would be more coverage. It is not. Run the log. Protect the few topics that keep getting asked. Pick one low-leverage habit - orphan gardening, tool theater, chat-only expertise - and stop funding it this sprint.
Start with ten days of topic / channel / doc state / outcome. That is enough to see whether a few recurring questions - not another tool pilot - were the real bottleneck.
Sources & scope
- APQC, Knowledge Flow Process Framework - create → identify → collect → review → share → access → use.
- APQC, Managing Knowledge Starts with Knowledge Flow - step overview and focus on critical knowledge.
- APQC, What are the Best Four Components of Knowledge Management? - people, process, content/IT, strategy.
- Log cells and sample weeks - practice patterns. Not legal/records advice; regulated industries may require formal controls beyond this guide. Never invent a universal “20% of docs = 80% of answers” law for your org - measure your asked-again topics.
- Composite log sample marked Illustrative:.