实战技巧 · 第 30 篇

技术白皮书怎么写客户才愿意看？

你写的不是白皮书，是催眠药

我进售前第一年，老板让我写一份数据安全白皮书。

我花了整整一周，从加密算法写到访问控制，从等保2.0写到零信任架构，洋洋洒洒一万两千字，还配了二十多张架构图。写完发给一个老同事看，他翻了五秒说了一句话："挺好的，就是没人会看完。"

我当时不服气。后来把这份白皮书发给五个客户。三个没回复，一个说"收到了，有空看"，还有一个说"能简单说说吗，太长了"。

没人看完。一万两千字，白写。

后来我慢慢琢磨出来：客户看白皮书，不是来考试的。他是带着问题来找答案的。如果你写的东西跟他的问题无关，写再多也是废话。

先搞清楚客户为什么看白皮书

客户看白皮书，通常就三种情况。

第一种，他在选型。技术负责人要做方案对比，需要一个"外部证据"来支撑他的判断。这时候你的白皮书要能帮他做决策，而不是展示你的知识储备。

第二种，他在内部推动。业务部门想上一套系统，IT需要一份技术文档去说服领导批预算。这时候你的白皮书要能帮他说话。

第三种，他在学习。新来的技术经理想快速了解一个领域。这时候你的白皮书要帮他建立认知框架。

但无论哪种情况，客户都有一个共同点：他没耐心。他不是坐在办公桌前泡杯茶慢慢品读，而是在等电梯的时候刷两段、开会前扫两眼。

你写得越长，他看得越短。

开头三句话，决定生死

我有个土办法判断白皮书开头好不好：把第一段发给三个非技术同事，问他们能不能看懂、有没有兴趣继续往下看。如果两个说"还行"，就过了。

什么叫好的开头？直接告诉客户：这篇白皮书解决什么问题、看完之后能得到什么、你需要花几分钟。

举个例子。一份云原生白皮书，烂开头长这样：

> 随着数字化转型的深入，企业IT架构正从传统单体架构向分布式、微服务化方向演进。云原生作为一种新兴的技术范式，以其弹性伸缩、敏捷交付等特性，正成为企业数字化转型的核心引擎……

客户看到"随着……的深入""正成为核心引擎"这些套话，手指已经滑走了。

好开头长这样：

> 如果你的系统高峰期经常崩，凌晨三点还要爬起来重启服务，这份白皮书是写给你的。15分钟读完，你会搞清楚三件事：为什么单体架构撑不住、容器化到底解决什么问题、迁移需要分几步。

不用高大上词汇，不含糊其辞，直接告诉客户"你能得到什么"。他觉得有用，他就往下看。

结构比文采重要十倍

别以为白皮书要写得像学术论文。客户要的不是文学价值，是信息获取效率。

我现在的白皮书结构，基本都沿用这个模子：

第1段：问题定位。先把客户可能遇到的痛点讲出来，让他觉得"你说的是我"。不用长，半页就够了。

第2段：根因分析。告诉他为什么会这样。这里可以有一点技术深度，但不能堆砌概念。

第3段：解决思路。你的核心方法论是什么。用一张图加几段文字讲清楚。

第4段：方案细节。这里才是技术含量最高的部分。但注意，每一个技术点都要回答一个问题："客户为什么要关心这个？"

第5段：案例印证。挑一两个真实案例，用数据说话。客户不信你的方案，但信数据。

第6段：行动建议。给客户一个明确的下一步。是联系你做POC？是下载试用版？是安排一次交流？

每一段都有明确的功能，不凑字数，不炫技。

几个容易踩的坑

第一，别把白皮书写成产品手册。 白皮书的目的是教育市场、建立信任，不是介绍产品功能。你可以在方案细节里提到产品，但不能整篇都在讲"我们的产品有哪些模块"。

第二，数据要有来源。 你写"70%的企业存在数据孤岛问题"，客户第一反应是"这70%怎么来的"。如果你不注明出处，客户觉得你是编的。

第三，适当留白。 不要试图在二十页里把整个行业都讲清楚。聚焦一个具体问题，讲深讲透，比泛泛而谈有用得多。

第四，一定要有摘要。 客户可能只看摘要和行动建议，正文都不一定翻完。摘要不是把目录抄一遍，是用300字告诉客户：为什么要看、核心结论是什么、看完该做什么。

最后说两句

写技术白皮书，最难的不是技术不够深，而是放弃"我要展示我知道多少"的冲动。

客户不在乎你知道多少，只在乎这些知识能不能帮他做成一件事。

下次动笔之前，把你写的第一段删掉试试。你会发现，文章从第二段开始反而更好看。因为第一段往往是最啰嗦的。

下一期预告：后天聊一个我实打实踩过坑的行业——制造业数字化转型售前。产线不能停、数据全是孤岛、一线工人根本不理你，这个行业有太多反常识的地方。

关注本号，回复 【666】 领取《售前实战手册》入门版

每周一至周五晚 6 点更新，只讲能赢单的售前方法。

? 中心思想

客户看白皮书不是来学习的，是来解决问题的。好白皮书的核心不是知识深度，而是信息效率：开头三句话说清价值、结构清晰不炫技、每个技术点都回答"客户为什么关心这个"。