SaaS 帮助文档：早期文档不是附属品，而是可复制交付

开场：文档不是等产品成熟后才写

很多 SaaS 团队觉得早期不用写文档，因为产品还在变，客户也不多。于是所有问题都靠创始人一对一解释。

短期看，这样很快。长期看，团队会被同样的问题反复消耗：怎么导入数据、怎么邀请成员、为什么报表不对、权限怎么设置、通知为什么没收到。

早期文档的价值，不是做一个完整知识库，而是把高频解释变成可复制交付。

先写三类文档

早期不需要百科全书。先写三类最有用的文档：

这三类文档直接服务激活、留存和支持效率。

文档按任务写，不按功能写

不要把文档写成菜单说明。

较差的标题是：

• 用户管理说明。
• 报表模块介绍。
• 系统设置说明。

更好的标题是：

• 如何邀请客服并分配工单权限。
• 如何查看本周超时工单。
• 如何把 Excel 里的客户名单导入系统。

客户打开文档时，通常是为了完成任务，不是为了学习你的产品结构。

每篇文档要有成功标志

一篇好的操作文档，最后要告诉用户什么叫完成。

例如数据导入文档可以写：

• 你能在客户列表看到导入记录。
• 记录数量和 Excel 行数一致。
• 异常数据会显示在导入结果页。
• 负责人字段为空的记录会进入未分配列表。

成功标志能减少用户不确定感，也能减少支持沟通。

把支持问题转成文档

不要凭空规划文档目录。最好的文档来源是支持记录。

每周复盘客户问题，把它们分成三类：

• 已经有文档，但客户找不到。
• 没有文档，需要补一篇。
• 文档解释了，但产品本身太难用。

前两类进入文档改进，第三类进入产品优化。不要用文档掩盖糟糕设计，但也不要把所有可解释问题都推给产品开发。

文档要进入产品和销售

文档如果只放在页脚，很少有人会看。它应该出现在客户需要它的地方：

• 导入页放导入模板和排错文档。
• 邀请成员页放权限说明。
• 报表页放指标口径说明。
• 试用邮件里放上线指南。
• 销售演示后发送场景教程。

文档越贴近任务，越能减少客户中断。

同时维护内部支持手册

外部文档给客户看，内部手册给团队看。

内部手册可以记录：

• 常见客户问题的标准回答。
• 哪些问题可以客服处理，哪些必须开发介入。
• 临时脚本或后台操作步骤。
• 客户升级和退款的处理原则。
• 已知问题和当前替代方案。

早期团队即使只有两个人，也值得维护内部手册。否则所有知识都在创始人脑子里。

常见误区

第一个误区，是等功能稳定才写。早期文档可以短，但不能没有。

第二个误区，是文档写得像产品说明书。客户需要完成任务，不需要读模块介绍。

第三个误区，是写完不更新。文档过期会制造更多支持问题。

第四个误区，是只写外部文档。内部支持手册同样能提高交付效率。

从 0 做 SaaS，帮助文档不是附属品。它是让销售、上线、支持和客户成功可复制的基础设施。