为什么每个 SaaS 都需要公开更新日志（以及它如何提升留存）
上个季度你交付了四十项改进。一位客户发来邮件，问这个产品是不是还在开发。
这不是罕见的失误，而是默认的结果。软件的改进是隐形的——你修掉的缺陷如今只是「没有问题」这个状态，你新增的功能只是一个没人碰巧点开的菜单项。除非你告诉别人变了什么，否则使用你产品的真实体验就是：什么都没变过。
更新日志是解决这件事最便宜的办法，而且它做的远不止公布版本。
更新日志真正带来什么
它证明产品还活着。 对任何正在评估你的人来说，一份带着本月条目的公开更新日志，回答了他本来就要问的问题。这是落地页和证据之间的差别。
它闭合反馈的回路。 六周前提出需求的人并不知道东西已经上线了。告诉他的那一刻，他学到的是：跟你说话是有结果的。这正是他下次还会开口的原因。
它唤回已经走远的人。 停止使用你产品的人是有理由的。如果理由是缺了某个功能，那么一句「这个功能现在有了」就是你能发给他的最相关的消息。不是新闻通讯，不是挽回活动，而是关于他想要的那件事的一行事实。
它减少支持量。 一份可见的近期变更列表，会在「这是坏了吗」和「这是新的吗」这类工单被写出来之前，就吸收掉相当一部分。
怎么写才有人读
从用户现在能做什么写起。 不是「重构了导出流程」，而是「导出现在包含已归档的条目，并且从几分钟缩短到几秒完成」。目标不是内部的准确，而是可辨认。读者应该在四个字之内判断出这条跟自己有没有关系。
每条都打标签。 三类就够：新增 用于原本没有的东西，改进 用于变得更好的东西，修复 用于原本坏掉的东西。读者会扫视自己关心的标签，而只关心缺陷的人也能找到缺陷。
条目要短，要拆开。 一次变更一条、每条三句话，胜过一篇涵盖一切的月度长文。短条目可以单独链接、可以在支持回复里引用、可以跳过而不丢失上下文。
该配图时就配图。 只要涉及界面，一张截图或五秒的录屏胜过一整段文字。后端工作就别配了——一张什么都没有的图比没有图更糟。
面向没用过这个功能的人写。 不要预设任何上下文。写出界面的名字。如果需要配置，说明在哪里。
不要因为不好意思而攒着发。 小条目不是弱点。上个月有十一条朴素条目的更新日志读起来是势头。一个季度一篇精心排版的长文，读起来是一家每季度才交付一次的公司。
让它出现在人们眼前
没人访问的更新日志是日记。价值的大部分在于分发：
- 邮件订阅。 让人订阅，发布时发出。这是唯一能触达不活跃用户的渠道，因为它不要求对方先打开你的应用。
- RSS。 提供成本极低，而开发者群体确实还在用。
- 产品内。 导航里的一个链接，或账户菜单上一个不打扰人的小红点，会在用户正好能试用的那一刻抓住他们。
- 专门通知提出需求的人。 最有价值的消息不是群发，而是告诉那十一个投过票的人：这件事现在有了。
SupDesk 处在哪里
SupDesk 在你的门户上提供更新日志模块，也可以放在你自己的域名下。
- 新增 / 改进 / 修复标签，让页面在不断变长之后依然可以快速扫读。
- 邮件订阅与 RSS 源。 发布一条会向订阅者发送邮件，退订流程由系统处理。
- 自动通知提出需求的人。 把一条更新日志关联到它所解决的反馈帖，发布时所有投过票的人都会收到通知。这就是不用维护名单也能闭合的回路。
- 机器翻译。 条目可以通过 Cloudflare Workers AI 翻译成你支持的语言，译文在上线前归你审阅和修改——机器的速度，人的最终决定权。
- 受众定向。 一条可以发给所有人，也可以在变更尚未全量时只发给你的测试计划成员。
关于范围有一点要说清楚：条目在你发布时才出现。没有定时发送，所以早上六点上线的版本，是在你按下按钮时才进入更新日志的，不会更早。
难的是习惯
搭好更新日志的机制只需要一个下午。真正产生留存效果的，是每次部署都写上三行的纪律，而这也是最先松掉的部分。
把它变成「交付」的一部分，而不是交付之后的一项任务。这样条目会在你还记得这次变更为什么重要的时候写完——而那也正是最容易下笔的时刻。
配置好你的更新日志，收下第一批订阅者，然后让下一次发布自己宣布自己。前往 supdesk.app 开始