知识库自己做还是找外面做，这笔账怎么算才不亏

老板们比价时通常只比一件事：软件多少钱。真正决定这笔账亏不亏的，是另一个数字——做这件事要占掉公司里谁的时间，占多久。这笔账不算清，自己做和外面做都可能白花钱。

先算自己做的真实成本，别只算软件钱

自己做的成本有三块，很多人只算第一块：① 工具钱（网盘、文档系统、检索工具，通常几百到几千一年）；② 人的时间（谁来做？多半是行政、办公室主任或老板自己，占掉他多少天）；③ 机会成本（这个人原本该干的活谁接）。
一个常见测算：如果由一个月薪八千的行政来做，前后投入三十个工作日，光人力成本就是一万出头，还没算这段时间她本职工作被耽误的部分。
所以「自己买软件做」在纸面上省钱，实际常常更贵——贵在没有人真正对结果负责。

这三种情况，自己做更划算

① 公司人少、内容少：二十人以下、资料不超过几百份，一个共享文件夹 + 统一命名 + 一份索引页就够用，花钱外包是浪费。
② 有明确的内部负责人：有人懂业务、有权限、能持续推，且愿意每周固定拿出半天。这种人存在，自己做往往做得比外包更贴业务。
③ 内容主要是纯文档归档：不涉及判断、不涉及流程、不涉及经验提炼，只是把东西放整齐。这类事不需要方法，需要勤快。

这两种情况，必须外面做，自己做会烂尾

① 核心是隐性经验，不是文档：老师傅的判断、销售的报价口径、异常处理的排查顺序。这些内容老人不愿意写、新人写不出来，需要有外部人用固定问法一条条逼出来。内部人做这件事，往往卡在「不敢追问老板和老师傅」。
② 已经做过一次，失败了：上过系统、没人用、最后荒废。这种情况自己做第二次，大概率重复第一次——因为缺的不是工具，是结构和验收标准。
判断标准很简单：如果这件事的关键动作是「把已经存在的东西搬进去」，自己做；如果关键是「把不存在的东西问出来」，外面做。

外包报价怎么判断合不合理

报价差异大的原因通常不是良心，是交付物定义清不清楚。同样说「做一个知识库」，可能指三个完全不同的东西：
只给系统：装个软件、开账号、教怎么用。这类几千元以内，本质是卖软件。
系统 + 目录结构：帮你定分类、命名规则、权限。这类几千到一两万，卖的是结构设计。
交付内容本身：把经验问出来、写成卡、建问答库、定标准流程、做索引，最后验收。这类才真正替代内部人干活，报价按范围和资料年限走，几千到几万不等。
比价时先问一句：你交付的是系统、是结构、还是内容？三者混着比，永远比不出结论。

不管谁做，验收标准必须自己定

外包最容易失败的地方在验收：交付了，钱付了，三个月后发现没人用。
把验收写进合同，只写三条就够，但必须能当场验证：① 新人不用问人，自己能在一个地方搜到答案（随机抽三个问题，让新人现场找）；② 关键岗位有人离职，接手的人能在半天内找到要用的东西；③ 同一个问题只有一个版本，不存在两份互相矛盾的说明。
三条都过才付款。这三条写清楚，比任何功能清单都管用——因为它们是结果，不是过程。

• 只比软件价格，不算占掉谁的时间和机会成本
• 二十人的小公司买整套系统，用不上还占地方
• 核心是隐性经验却让内部人做，卡在不敢追问
• 已经失败过一次，不换方法只换工具，重复失败
• 验收只看有没有交付，不看新人能不能查到

常见问题

外包做完，我们自己还要维护吗

要，但维护量应该很小。合理的状态是：外包交付结构和存量内容，日常只做两件事——有人问了库里没有的问题就补一条，发现错了就改一条。每周半小时以内。如果需要专人天天维护，说明结构没做对。

先上系统还是先理内容

先理内容。系统是容器，容器不会告诉你该装什么。反过来做，通常是系统上线三个月、里面空着，然后大家都说「这系统没用」。

怎么防止对方交付一堆我们用不上的文档

在合同里把交付物写成清单，每项带验收动作，而不是写「提供知识库建设服务」。比如：经验卡不少于多少张、每张必须含前提和红线、问答库必须覆盖多少个真实问题、索引必须能让新人三分钟内找到指定内容。写成可数、可抽检的，才有约束力。