SME collaboration, Part 4 of 4: a KB your SMEs will actually use
What makes an SME contribute to a knowledge base versus what makes them ignore the tool. Closing the four-part series — the structural choices that decide whether your KB compounds or rots.
This is the closing post in the four-part SME collaboration series. Part 1 was the async interview, Part 2 was the ticketed-ask discipline, Part 3 was the 20-minute capture call. The thread underneath all three was a knowledge base — the corpus the tickets pull from, the destination the capture-call transcripts feed into, the source the async-interview drafts cite.
A KB the SMEs trust is the difference between a process that compounds and a process that rots. SparrowGenie has written about the failure mode at length: content-library initiatives fail because of unclear ownership and stale content. SMEs respond to questions with “outdated answers from a Google Doc that hasn’t been touched in eight months” or “a PDF written for a completely different vertical.” Shelf’s research on outdated knowledge bases makes the same point: obsolete content actively undermines user trust, readers conclude the company doesn’t care, and the KB becomes a liability rather than an asset.
The question this post tries to answer: what makes an SME contribute to a KB versus ignore it.
What makes them ignore it
Four patterns I have watched repeatedly.
The KB is a folder. Content is dumped into Google Drive, SharePoint, or a wiki without structure. The SME asked to “go look at the content library” finds 800 documents organized by no scheme they recognize. They cannot tell which document is current. They give up and write the answer from scratch.
Ownership is unclear. A block exists. It looks plausible. The SME does not know who wrote it or whether it has been reviewed since. They cannot tell whether they are reading authoritative content or someone’s draft from two years ago. They give up and write the answer from scratch.
Updates are punishing. Updating a block requires opening a wiki, finding the page, navigating an editor, and remembering the formatting conventions. The SME has 10 minutes between meetings; the update takes 25. They do not update.
There is no feedback that the contribution mattered. The SME spent 30 minutes drafting a block. They never see it surface in a response. They never see it cited. They never get a notification that someone used their content. The contribution feels like writing into a void. They do not contribute again.
What makes them contribute
The inverse of the four patterns. None of these are rocket science; all of them are violated routinely.
Structure is visible. The KB is organized by topic, by industry, by question pattern, and by recency. An SME landing on a candidate block sees the block’s topic, its last-updated date, its author, its review status, and the responses that have cited it. Five fields, all visible at a glance. The SME’s first impression of the KB is “I can tell what this is.”
Every block has a named owner. The owner is a human, not a team. Their name and role are on the block. If the block needs an update, the SME knows who to ping. If the SME is being asked to update the block, they know their name will go on the next version. Authorship is visible and weighted.
Updates are five minutes or less. The block surface is structured for fast updates — pre-filled metadata, a single text field for the substantive content, an automatic version bump on save. An SME can update a block from a phone between meetings if needed. The friction floor is low enough that updates happen.
Contribution feedback is automatic. When a block the SME wrote is cited in a response, the SME gets a notification: “Your block on data residency was cited in the Acme RFP response on 2025-09-25. The response was submitted at 2025-09-26.” Three sentences. The SME knows their work shipped. They contribute again.
The structural choices
Three choices that decide whether a KB falls into the “ignore” pattern or the “contribute” pattern.
Block size. Small blocks (one claim, one fact, one short paragraph) are easier to maintain and easier to compose. Long blocks (a full section answer of 1,500 words) become stale faster because more of their content can age, and they are harder for the SME to update because they have to read the whole thing to update one sentence. We covered the chunk-size ablation on the engineering blog earlier this year — small blocks composed at draft time outperform large monolithic blocks at retrieval and at maintenance.
Freshness signals. Every block has a last-updated date and a freshness score. Blocks that have not been touched in 12 months are flagged. Blocks with stale citations (e.g., to an attestation that has expired) are flagged. The freshness signal is on every block surface; the SME sees it without asking. We shipped block freshness alerts in March and the SME-side adoption of the alerts has been the single largest visible improvement to KB hygiene we have measured.
Per-block permissions. Some blocks are owned by engineering, some by finance, some by legal, some by marketing. The owner sees their blocks; the writer sees the candidate blocks; the buyer-facing reviewer sees only the approved versions. The per-block permissions feature we shipped in July separates the editorial workflow from the read workflow and removes the “I don’t want my draft seen by everyone” friction that was killing SME contribution in the early-adopter accounts.
The compounding
A KB the SMEs trust compounds on three loops.
The drafting loop — every bid pulls from the KB, cites blocks, and exposes which blocks were used. SMEs see their work shipping.
The post-mortem loop — every retro updates the KB. Win themes that worked promote, blocks that underperformed retire. The KB gets sharper bid by bid.
The contribution loop — every async interview, every capture call, every ticketed ask produces or updates blocks. New content lands in a structured form, with an owner, with freshness, with feedback. The SMEs see the loop close and contribute again.
Qorus’s research on the persistent SME bottleneck — 48% of teams cite it as the top challenge, five years running — is a structural problem and the KB is the structure. The bottleneck does not move because the underlying KB pattern does not change. Replace the folder with a structured KB, replace the silent contribution with feedback loops, replace the staleness with active freshness signals, and the bottleneck moves.
Closing the series
Four parts, one argument: SME collaboration is a structural problem, not a relationship problem. The async interview, the ticketed ask, the capture call, and the SME-friendly KB are four pieces of the same structure. None of them work alone. All four together are the system that 48%-of-teams have been trying to build for five years and that most have not built because they treat each piece as a separate initiative.
If you read one thing in this series and change one habit, change the feedback loop. Tell the SMEs when their work ships. The KB gets better. The series ends.
For the engineering side of how the KB blocks get structured, retrieved, and cited, the canonical pillar is Grounded retrieval: what it is, what it isn’t, what we measure.