一家软件公司宣布要被收购，创始人有许多值得讲的事。正在用它的顾客，却可能先想到明天的工作：已经安排好的邮件还能发吗，遇到问题该找谁，手里的套餐接下来怎么算？
2021 年 9 月 13 日，Ben Chestnut 在 Mailchimp 官网发表了一封写给客户的信，宣布计划加入 Intuit。信的开头很生活化：他回想早年在亚特兰大小办公室里反复画标志，Dan Kurzius 坐在旁边写代码、和顾客交谈。
随后，信讲到公司长期专注邮件营销，后来顾客希望他们把类似的体验带到其他渠道，产品也逐渐扩展。收购被放在这段发展的叙述里，伴随着更多个性化支持、拓展国际业务和加快创新等愿景。
但客户信没有停在愿景上。它也讨论了交割前的安排：顾客仍可以获得原有的使用体验，包括当时的月度套餐和全天候支持，并说明会继续更新进展。Ben 写到，客户和合作伙伴既期待新功能，也期待一致性和连续性。
这里需要把日期与状态放在一起读。那封信发布时说的是计划收购，尚未把交易写成已经交割。Mailchimp 今天的官方沿革页记载，它在 2021 年被 Intuit 收购。本文讨论的是当时怎样向顾客说明变化，不据这封信判断每项愿景后来是否兑现，也不把当年的套餐安排当作今天的承诺。
我觉得这封信可借鉴的地方，在于它回答了顾客眼前的一部分问题。公司在讲未来几年的方向时，顾客也需要知道下一次使用、续费、求助会怎样发生。
如果一个小型软件准备交给新的维护者，可以把通知中的内容逐项写清楚。下面是本文建议的结构，不是 Mailchimp 当年的操作清单：
| 顾客需要知道的事 | 可以写得更具体的内容 |
|---|---|
| 哪个变化已经确定 | 接手的团队、负责的产品范围、生效时间 |
| 交接期间怎样继续使用 | 登录入口、现有套餐、支持渠道的当前安排 |
| 哪些事项还在确定 | 尚未决定的功能或计划，以及下次更新进展的时间 |
| 遇到问题怎样处理 | 一个明确入口，以及提交问题时需要提供的信息 |
这张表要求经营者先完成一些实际工作。例如，可以拿一张交接前尚未处理完的工单演练：新团队能否找到原来的上下文？用户回复旧邮件时，谁来接收？原负责人处理到一半的承诺，谁来继续跟进？这些是假设中的交接测试，不是本文亲历过的 Mailchimp 现场。
也有些内容不能为了让公告显得完整就提前写满。新的功能尚无确定交付时间，可以明确说仍在规划；数据处理方式有没有改变，应依据实际政策与系统安排核对。一句笼统的“一切照旧”，可能把尚未确认的事项一并许诺出去。
对创始人而言，出售或交接可能是一段创业旅程的转折。对顾客而言，工作还要接着完成。把这两种处境同时写进公告，读者才更容易理解发生了什么，也知道下一次操作该去哪里。
资料：Ben Chestnut，《Big News from Mailchimp》，2021-09-13 官方客户信；Mailchimp 官方沿革（页面未标发表日期）。均于 2026-11-07 查阅。历史经过及当年表述取自原文，交接表与工单演练为本文建议。
