1997 年，Derek Sivers 想在网上卖自己的唱片。他在 2011 年的回顾里写道，自己联系过的几家大型网上唱片店，都要求他通过发行商进入。于是，这个音乐人决定自己搭一个能收款的网站。
等购买按钮终于能用了，事情没有停在他自己的唱片上。朋友也想请他代卖，接着又有朋友介绍来的陌生音乐人找上门。后来叫作 CD Baby 的生意，就从这些具体的请求中长出来。这里讲的是创始人记录的经历，不把他当年联系商家的结果扩展成对整个音乐行业的判断。[1]
这篇故事要讲的选择，发生在订单已经成立之后。
Sivers 记得，1998 年建立 CD Baby 时，系统会在唱片发出后自动通知顾客。最初的邮件很普通：告知已经发货，没收到可以联系。几个月后，他觉得这与自己希望让顾客开心的想法不太相称，花了二十分钟重新写了一版。
新邮件把寄唱片写成一场郑重其事的庆典，甚至安排了私人飞机这样的夸张情节。那些是故意写出的喜剧想象，不能当成真实的物流流程。按他 2011 年的自述，后来不少收件人把邮件转发、贴到了网上，也有人因此成为新顾客。[2]
一封本来只负责报告状态的信，就这样成了顾客愿意讲给别人听的片段。
不过，原文没有提供对照实验，不能据此算出改写邮件使转化率提高了多少。Sivers 对传播和新客户的描述，是亲历者的回顾。我们可以研究他做了什么，不必把一个流传很广的故事包装成人人可复制的增长数字。
我更在意的是他挑中的位置：付款以后、收到商品以前。
如果把产品体验画成一条线，这一段常常只剩系统自动运行。创业者忙着解释为什么值得买、开发下一个功能，却容易漏看已经相信自己的顾客接下来会读到什么。CD Baby 的例子让人看到，这里仍然有表达产品性格的空间。
但顾客此刻首先关心的事情，并没有因为文案有趣就消失。东西有没有寄出？需要等多久？出问题找谁？我会把这些当作改写交易通知的约束：读完之后，顾客至少要和改写之前一样清楚自己的处境。
把这个思路放进独立开发的日常，可以做一个很小的尝试。下面是假设案例，不是我运行过的实验。
假设你做了一个帮助插画师交付作品的工具。文件导出完成后，原来的通知只有“处理成功”。你准备加上一句轻松的话，可以先把真正有用的信息补上：哪一份作品已经生成、文件在哪里、下载链接什么时候失效，以及失败后联系谁。等这些信息清楚了，再决定那句玩笑是否让人舒服。
假如系统仍在处理中，就写正在处理；需要用户重新授权，就直接说明原因和下一步。不能为了让文字活泼，把“排队成功”写成“作品已经送到”，也不能用庆祝的语气遮住失败。
验证改写也不必先追问“喜不喜欢”。把通知单独拿给几位目标用户，请他们指出当前状态、下一步和求助入口，再观察有没有人读错。之后才问，哪句话让他们觉得这款产品有自己的性格。如果大家记住了笑话，却找不到文件，应该先修正文案。
发货通知里的幽默，还不能原样移到退款失败、数据丢失或服务中断的消息中。同一句俏皮话，在已经完成的普通订单里可能亲切，在焦急等待处理问题的人眼里可能显得轻慢。这是我从故事里划出的应用边界，并非 Sivers 做过上述测试。
这位创业者当年修改的，只有一封顾客本来就会收到的信。对今天的小团队来说，也可以从这样的细节开始：打开产品最近发出的一条通知，认真读一次，看看它有没有把事情说清楚，又有没有留下属于你这门生意的声音。
资料与日期：
