经纪人 CRM：别让承诺埋在聊天里

在聊天中，承诺看起来很可靠。“晚上发给你。”“开完会回复。”“我问问业主。”然后又来了四十条消息，承诺被送进小小的文字墓地，几乎得靠良心提醒才能找回来。

我的经纪人 CRM 源于看清整项工作的愿望。联系人、来源、历史、下一步和准备好的消息应该放在一起。否则经纪人忙的不是销售，而是恢复自己的工作记忆。

这个屏幕汇集虚构业主、其物业及工作历史。它展示联系人如何成为工作档案，而不只是一行电话号码。

业主档案

归档界面 · 演示数据

三个数据库，三类信息

当前架构使用 Cloudflare Workers，并为 CRM、二手市场线索和经纪人索引设置独立的 D1 数据库。这样的区分，能避免把找到的任何号码都当作拥有相同权限和历史的完整客户。

另一个屏幕展示虚构买家的需求。由此可以看到经纪工作的另一面：对方在找什么，后续筛选还需要哪些信息。

买家需求

归档界面 · 演示数据

操作层生成工作批次和动作。重复处理有防重保护：同一个准备好的步骤不应因为再次运行而生成第二次。这叫幂等性。术语虽长，日常用途很简单：计算机不该仅因没听清自己，就把工作翻倍。

消息发送仍是独立的手动操作。系统可以准备联系人和文字，但打算发送并不等于已经沟通。拒绝进一步联系后，这一渠道的后续工作会被阻止。

输入时 AI 方便，输出时必须入库

对话界面帮助用日常语言表达任务。但结果必须变成具体记录：有明确对象、状态和下一步动作。如果一切仍留在助手的回答中，CRM 就没有得到任何新信息。

外部表格也不能悄悄继续充当第二个活跃数据库。否则操作员在这里改了联系人，代理在那里读旧导出，双方都以为自己做得很仔细。

并非每个设想中的模块都成了实际流程。估值模块 Comps Engine 及相关 PDF 流程已暂停。部分近期技术修改还需要在工作环境中单独验证。我不会把计划、源代码和已确认操作拼成“全部自动化”的宣传语。

在 CRM 中，我连接联系人、物业信息和下一步。发送与准备分开，便于看清承诺和行动，而不把所有工作说成自动完成。Comps Engine 及相关 PDF 流程另行说明，属于暂停方向。

相关故事：早期 WhatsApp 工具 · 团队 WhatsApp · Comps Engine 探索。