# Knowledge management tools are judged in the middle of the job

> Most knowledge management tools are bought to store what a team knows. In the cases we researched, storing was rarely the problem: things went wrong when someone needed an answer mid-job and the page was hard to find or never read, or when an AI wrote pages nobody checked.

Clawnify Resources · https://www.clawnify.com/resources/knowledge-management-tools · 2026-09-30

## Knowledge management tools have two jobs, and most of the trouble sits in the second
Every knowledge management tool, from a company wiki to a shelf of SOP binders, is bought to do two things: keep what a team knows, and hand it back to the person who needs it in the middle of a job. The older tools for knowledge management and the AI knowledge management tools that now answer from those same pages share that brief. The teams we researched ran a mix:

- Wikis and doc workspaces: Notion, Confluence, Google Drive and Google Docs, Dropbox Paper.

- Help centers: Intercom, for customer questions.

- SOP manuals: worked through in the field during onboarding, and in one owner's plan, one per role.

- Short training videos: Loom recordings of five to ten minutes, one concept each.

- AI assistants: drafting pages from code or scattered docs, and in one case answering from the SOPs inside the team's Slack.

Most of the effort went into the first job. A pest control owner set out to rewrite every SOP in the business over one winter. An agency founder counted more than 55 detailed docs covering the core of the business, and says a new hire can now onboard without the founder saying a word. And a product builder watched an AI turn scattered artifacts into about 100 standardized wiki pages in 20 minutes, work they'd seen take weeks.

Where things broke, it was usually on the second job. One team member said everyone knew the information existed, yet finding the right version "takes longer than writing the document." We kept running into versions of that. The page was there. The person with the question couldn't get to it in time.
## One handyman owner's SOP life cycle, and what replaced it
The founder of a seven-figure handyman business says every SOP they've ever written went through the same life cycle:

- "I write it."

- "I explain it in a meeting."

- "Everyone nods."

- "Two weeks later someone texts me asking how to do the thing in the SOP."

Then: "Rinse. Repeat. Forever." The pages existed. Nobody made the trip from the jobsite to reach them. Expecting a technician to stop mid-job, open Google Drive and filter through folders for the answer was, in the owner's word, "delusional," and they admitted they'd been exactly that.

Here's how they handle it now. New hires spend two weeks in the field working through the manuals with a supervisor, then get tested. After realizing nobody read the SOPs, the owner added a written exam during onboarding "so you know they read it at least one time." And every manual and process doc went into a chat assistant hooked into Slack, which answers a technician's question "from the SOP I already wrote." The crew already talked only in Slack, so the assistant answers there and the owner doesn't have to be on call for it.

The assistant answers from SOPs the owner had already written. What moved was the place a technician finds the answer: into the chat, where the questions were already being asked. They've only just started and haven't reported results.

The same week, a pest control owner was making a different bet: more pages. Their benchmark was a flat-pack table that comes with 8 pages of assembly instructions, and each employee would get a "succinct, role specific SOP manual" to turn to when unsure. Five minutes after the owner handed their operations plan to a colleague, a customer called, angry at the whole staff over something the owner said wasn't the business's fault, and wanted a refund. The business offered half. The owner had already conceded the limit: "there are always exceptions that we will never be able to address on paper." A colleague at the same business put the bind in two sentences: "You can't have an SOP for every situation. You need an SOP for every situation."
## Teams argue about the tool, and the ones that drifted off it stopped opening it
Ask teams which tool to use and you get an argument. Here's what six of them said.

TeamTool historyWhat they said about it
A Notion criticArgued for a shared drive per department, in 2024A layout "organized in your own idiosyncratic way"; lost pages
An engineer at a large payments companyConfluence to Notion, two years earlier"Huge upgrade", but it "keeps trying to be an operating system"
A SaaS company's product and engineering leadConfluence, Dropbox Paper and Google Docs, into Notion"Overall loving it"; first gripe was drafting comments
An agency founderOn Notion every day since 2020Uses it daily; would rather not pay Notion to "resell us AI credits"
A software media company's founder, and a second teamOff Notion, without cancelling"Usage drops to zero quietly"
A performance ad-creative agency founderNotion guidelines and screenshot SOPs, to short Loom videos"a 50 page doc nobody reads after week one"

The complaints don't line up. One is about a home-grown layout new hires have to learn. Another is about a tool that keeps reaching past being a document editor. Neither says much about why pages stop getting read.

The longest run in the table is the agency's: six years on one tool, with tasks, client calendars and the wiki in the same place, used every day. Our guess is the wiki gets opened because the work is already open beside it. The two teams that drifted off Notion went the other way. The media founder said their agents "have no need for it" and that they didn't notice they'd stopped. The second team put it flatter: "nobody cancelled, usage just faded to zero." The work moved elsewhere, to agents in one case and a meeting-notes app in the other, and nobody went back.

The creative agency changed the format instead. The long doc gave way to a short video on one specific thing, sent every day or every other day.

Our hunch is that which wiki you pick matters less than whether it sits inside the daily work.
## AI made writing the pages cheap and made checking them the job
AI knowledge management tools have made drafting fast. In two of the cases we looked at, a wiki or a help center's worth of articles came out in an afternoon or less. How fast the pages came out didn't decide how they held up.

What happenedWhat decided it
Product builder: a standardized wiki drafted from scattered artifactsToo early to say; nothing reported yet on upkeep
Solo app founder: 7 to 109 help articles in an afternoonWritten from the code, drift-checked, live only once the founder approves
SaaS founder: a help center that updates itself as features shipTied to the code: an interface change triggers the update
Account manager: a ChatGPT-written doc shared in a customer spaceNo expert read before sharing; "all of it" wrong, per the specialist
An AI summary of correct customer feedbackIt "added additional wrong info"; hard to trace back to the sources
Developer's support bot: guessed when unsureFixed with a "let me check on that" step

The two help centers share a shape. Both are tied to the code: one is written from it, the other updates when a code change alters the interface. The code has to change when the product does, so every page has something true to be checked against. The solo founder adds a second guard, and nothing goes live until they approve it.

The failures had no check between the draft and the reader. The account manager's doc reached a customer engagement space before the specialist went through it. The feedback summary started from something true and wrote past it, and the person who caught it lost "a ton of time" working out what was real. The support bot's guess ended in an apology to a real customer.

So drafting is cheap now. What costs something is knowing which page is still true, and in these cases that took a source and a person.
## Where we would start with a trades business and forty SOPs
Say the owner of a trades business comes to us with forty SOPs in a shared drive and technicians who text them the same questions every week. The pages exist. Some of them are probably still right. Nobody's sure which.

We'd leave the pages alone at first and set up five things around them:

- Every document gets one named owner and a date by which they re-check it, and nothing goes live until that owner approves it, whoever drafted it. One agency founder once gave several people "shared ownership" of a big project. "Two months in? Nothing had moved." Their fix, a single name on every initiative, was about projects, but the same logic holds for a page.

- The next SOP gets written once a task has been done three times. One founder who runs several businesses in Notion, and sells Notion templates, works to that rule: "If I've done it three times it gets an SOP." The library grows at the pace of the work rather than in one big rewrite.

- The answer goes where the technicians already ask, which is the team chat. It comes from the owner's own SOP and names the page it used, so anyone can open that page and check it.

- When a page's check date passes, its owner gets a reminder. If it still holds, they re-check it and it's back in use. If it's wrong, they flag it out of date and it stops being used to answer. We'd rather send a technician to a person than hand them last year's procedure.

- Refunds, angry customers and anything the pages don't cover go to a person. The pest control owner's refund call is the reason.

The real test comes on a Tuesday afternoon, when a technician halfway through a job asks in the chat and gets the checked answer, page and all, before they've put the tools down.