每月十号左右，会计团队都会发出同样的请求。他们需要每个客户提供五个文件：银行对账单、收据存档、薪资报告、销售汇总和库存文件。模板友好、精准且经过测试。它会称呼客户的名字，列出文件清单，并提供明确的截止日期。第一次发送时，一切进展顺利。客户看到了整洁的列表并做出了回应。

问题在第二封邮件时开始了。

想象一下，一位客户发送了四个文件。第五份银行对账单始终没有收到。收据存档确实收到了，但它涵盖的是错误的月份，因此团队拒绝了它。薪资报告其实三天前已经在 Slack 上发过了，而且有人已经归档了。库存文件根本不适用于这位客户，这个细节是你发完第一封邮件后才发现的。如果你重新发送原始模板，你又会要求五个文件。其中四个请求现在是徒劳的，还有一个具有误导性。措辞没问题，问题在于这封邮件没有“记忆”。

邮件模板在处理姓名、日期和指令方面表现出色。对于一次性的简单请求，这通常足够了。一个人发邮件，客户回复，同一个人完成任务。历史记录存在于一个人的大脑和一个个收件箱中。

当下一条消息取决于第一封邮件之后发生的事件时，问题就开始了。模板仍然显示原始列表。它不知道银行对账单昨天已经收到了，也不知道薪资报告被拒绝了。这些数据存在于收件箱（可能是好几个收件箱）中，而生成提醒通知的应用无法读取这些数据。

当“开启”状态还不够时

如果你将整个请求视为单一的状态（如“开启”），你就会丢失重要的细节。各项任务是独立推进的。每一项都需要自己的状态，以便下一次沟通能够准确无误：

  • Bank statement: 缺失。客户尚未发送。
  • Receipt archive: 已上传但尚未审核。它正躺在文件夹中等待内部检查。
  • Payroll report: 已拒绝。客户发送了内容，但格式错误或薪资周期不对。
  • Sales report: 已通过其他渠道收到。它通过 Slack、电话或邮寄副本送达，且你的团队已经记录在案。
  • Inventory document: 不适用。该客户不需要提供此文件，系统应该停止询问。

如果没有这种细分，你的提醒就是“盲目”的。它对缺失的文件和被拒绝的文件一视同仁，对已经收到的文件也视而不见。这不仅浪费了客户的时间，还会削弱信任。在收到两三次无关紧要的提醒后，客户会开始扫视邮件，并认为你的系统出故障了。

只构建你所需的部分

不要一上来就构建一个庞大的规则引擎。你不需要在第一天就拥有带有二十个条件分支的工作流自动化。从跟踪足够的数据开始，只需回答一个问题：客户还需要采取哪些行动？

每个请求的项目都需要一个持久化的结果。这意味着需要一个存在于邮件往来之外的记录，以便应用在起草下一条消息时可以读取。记录不必很复杂，可以只是一个简单的结构化表格，包含项目名称、当前状态、时间戳和简短备注。重要的是，数据要能超出收件箱的范围而存在。

这改变了邮件的角色。模板仍然控制语气和结构。问候语保持亲切，指令保持清晰。但文件列表必须来自请求数据。提醒变成了一个“查询”。你过滤列表，只显示需要客户采取行动的项目。你排除正在等待内部审核的项目，排除已经接受的项目。

如果上传的文件被拒绝了，提醒应当说明原因并解释理由。它不应该默默地将该文件重新放回通用列表中，仿佛客户只是忘了发送一样。客户知道自己已经上传了东西；如果假装不知道，会让你显得组织混乱。

交接测试

有一种简单的方法可以判断你是否需要这个额外的数据模型。问自己：

如果不阅读整个邮件往来记录，另一位团队成员能否接手这项请求？

对于单个文件，答案并不重要。但对于包含许多变动环节的每月定期请求，它就非常重要了。如果主要联系人在休假，同事能否在几秒钟内看出缺少了什么？管理人员能否在不打开十封邮件和三个共享文件夹的情况下，判断客户是否已跟进完毕？如果拒绝记录仅存在于邮件链的第四条消息中，且被淹没在签名和转发信息之下，那么你的系统就是在强迫人类去做数据库本该做的工作。

模板优化了信息表达。追踪请求保留了历史记录。前者处理的是你的表达方式，后者处理的是你的已知信息。

查询，而非脚本

一旦你拥有了条目级状态，生成电子邮件的过程就从编写脚本转变为执行查询。以前，你写下一段话并希望它依然准确。现在，你向数据提问：这些条目中哪些仍需要客户采取行动？你围绕该过滤后的列表编写提醒。如果没有任何需要采取行动的事项，你根本不需要发送提醒。如果有两个事项需要处理，且其中一个因特定原因被拒绝，邮件会根据这些事实自动构建。

这