花了钱三个月没动静，多半是把「搭好」当成了「见效」

第一个月能看到的只有「找文件快了」，看不到「新人能独立干活」。
把这两层说成一个时间点的人，不是没做过，就是想快点签单。

第一个月：只能验证找得到

第一个月能验证的只有一件事：东西找不找得到。做法是抽二十份常用文件，让三个不同岗位的人找，记录耗时。中位数从十分钟降到两分钟以内，说明结构和命名立住了。这时候还验证不了「用得上」，因为用得上需要新人真的遇到问题、真的去查、查完敢照着做。把这两件事混为一谈的项目，通常在这个月就开始被质疑没效果，然后停掉。第一个月该有的期待很朴素：不再为找一份文件打电话问人。

第三个月：看新人独立处理率

第三个月看一个数：新人独立处理率，定义是新人独立完成、不需要问人的工单或事项占比。搭之前通常在三成左右，第三个月能到六成，说明库真的被用起来了；还在三成，说明库建了但没入口，或者答案写得没法照着做。这个数每月统计一次，取一周的数据就够，不需要上系统。它是唯一能同时反映内容质量和有没有人用的指标，其他指标要么只反映一头，要么根本测不准。

半年：看关键的人请假会不会乱

半年看的是一个场景：关键的人请假一周，公司会不会乱。具体点，老员工休假时，他手上的事有没有人能在不打电话的情况下接着做。这个判断很土，但很准，因为打电话这件事本身就是知识没留下的证据。另一个信号是重复提问次数：同一个问题，一个月内被不同的人问超过三次，说明它该进库而没有进。这两个现象都不需要报表，老板自己能感觉到，感觉不到就是没做成。

为什么大半项目死在第四十五天

项目死掉的时间点很集中：第四十五天前后。原因不是内容不够，是三件事同时发生——第一批内容做完了，没人再往里加；入口只有一个共享文件夹，没人点开；负责人换成了不关心这件事的人。防的办法在开工时就定好：指定一个每周花两小时维护的人，明确他维护什么，新增问题、过期内容、失效链接；把入口放到大家每天都在用的地方，而不是新建一个系统；每月出一页使用数据，一页就够。

三个数决定要不要继续投

要不要继续投，看三个数。一，老员工被问的次数，从每天八次降到三次以下，说明时间省下来了；二，新人上手周期，从六周缩到三周，按人力成本折算，一个岗位省下的钱通常超过建库费用；三，同一问题重复回答的次数，一个月内降到两次以下。三个数里有两个改善，就继续投；一个都没有，先别加预算，回去查入口和答案质量。钱不是花在写内容上，是花在让人真的用上。

• 第一个月就在问怎么还没效果
• 库建好了，入口藏在一个共享盘里
• 内容写了三千条，没人查过一次
• 没人负责更新，半年后全是过期答案
• 用员工说好用当验收标准
• 把搭好当成交付，把用上当运气

常见问题

为什么别人说一个月就能见效？

一个月能见效的通常只是「找文件快了」，这一层确实快。但「新人能独立干活」需要新人真的干过一轮，三个月是生理下限，压不下去。把两层说成一个时间点的人，要么在卖软件，要么只做过文件整理。签合同前把这两层拆开谈，后面少很多争执。

内容还没写完，能不能先上线一部分？

必须分批上线，而且要早上线。先放二十到三十条最高频的，让人开始用，用出来的问题才是真问题。全部写完再上线，通常意味着三个月后才有人第一次点开，那时候负责人的热情已经耗掉一半。分批还有一个好处：能验证结构，结构错了改二十条比改三百条便宜得多。

花了钱没人用，能退吗？

看合同怎么写的。按交付物验收的，内容交付完就算完成，用不用是另一件事；按效果验收的，要写清指标和统计口径，比如新人独立处理率、老员工被问次数，以及统计的时间窗。建议签成两段：交付验收一段，三个月后看指标一段，第二段留两到三成尾款。这样双方都有动力。