如何通过 Odoo 的一个修复每天节省 12 分钟

Odoo Community 在从潜在客户发送邮件时不会自动将潜在客户中登记的联系人作为收件人填入。搜索、输入、选择：每封邮件大约需 15 秒。听起来微不足道，直到将其乘以销售团队每天从 CRM 发出的邮件数量。下面有一笔算术；这是推算得出的，而不是某个客户的实际测量，您在自己计算时只需要一个数字即可。

本文说明了为何 Odoo 标准在这里对销售团队不利、修复方法是什么，以及何时有针对性的修补比更换系统更合适。

问题：空的收件人字段

使用 Odoo Community Edition 作为 CRM 的人可能遇到过：打开一个潜在客户，点击“E-Mail senden”——邮件撰写器打开，但收件人字段是一个空的收件人字段。

联系人已在潜在客户中登记。电子邮件地址存在。但撰写器没有接管它。

接下来每次都是同样的步骤：

1. 在收件人字段输入联系人姓名
2. 从下拉列表中选择正确的联系人
3. 然后才开始写实际的邮件

每封邮件大约需要 15 秒。听起来并不多。

那些没人算的账

但我们来算一算：如果每天从 CRM 发出大约 50 封邮件，这就意味着每天 12 分钟的时间损失——只是因为手动输入一个本应已经存在的收件人。

按月计算这超过4 小时。按年计算：每位员工大约50 小时。

每年 50 小时。用于一项系统本应自动完成的任务。

而这只是可测量的部分。真正的损失更微妙：每多一次点击就是一个可能分心、断开思路或干脆不写邮件的节点。在销售中速度很关键——每一道不必要的障碍都可能让交易流失。

看起来显而易见的解决办法——以及为什么它不对

显而易见的答案：购买 Odoo Enterprise。在那里邮件撰写器表现更好，功能更多，支持更完善。

但 Odoo Enterprise 是按用户按月授权的。对于一个 10 人的团队，很快就是每月数百欧元——而这个功能本质上只差一行代码。

这并不是反对 Odoo Enterprise 的论点。升级有其正当理由。但如果唯一问题只是空的收件人字段，那么通过更换许可来解决就像用大炮打麻雀。

我们的解决方案：一个 Python 文件

我们分析了问题并发现：Odoo Community 的邮件撰写器在从 CRM 潜在客户打开时根本没有考虑潜在客户中登记的联系人。这并不是传统意义上的 bug——只是缺少了这部分逻辑。

解决方案是一个最小的 Odoo 模块，功能非常单一：当从 CRM 潜在客户打开邮件撰写器时，会自动将潜在客户的联系人作为收件人填入。

就这么简单。 无新菜单、无新数据库字段、无配置。一份 Python 文件，扩展了邮件撰写器在 CRM 潜在客户场景下的行为。其他一切保持不变。

之前

点击“E-Mail senden”，撰写器打开——收件人字段为空。输入联系人姓名，等待下拉列表，点击正确条目。然后才能写邮件。

之后

点击“E-Mail senden”，撰写器打开——收件人已经在。可以直接开始写邮件。

我们为什么要讲这个故事

不是因为技术上有多了不起——恰恰相反。我们讲它是因为它展示了我们经常看到的一个模式：

一个小而具体的问题被用来作为做出重大、昂贵决定的理由。

• “邮件撰写器很烦” 变成 “我们需要 Odoo Enterprise”
• “表格不易读” 变成 “我们需要一个新的 ERP”
• “缺少报表” 变成 “我们需要一个 BI 平台”

有时候这是正确的。有时候大型方案是合适的。但很多时候先问一问：真正的问题是什么——以及修复它的最小办法是什么？

何时仅需修补——何时需要新软件？

有针对性的修补足够，当：

• 问题是明确可界定的——缺少一个功能或一个流程卡住
• 现有软件总体适合并被团队接受
• 修补方案可维护，不是脆弱的权宜之计
• 修补成本明显低于系统更换的成本

需要新软件，当：

• 多个根本性需求无法被覆盖
• 现有系统不再维护
• 架构上结构性不合适——例如没有 API、没有多租户能力
• 为权宜之计付出的代价超过了许可费用

结论

这个例子特意选得很小。它不是为了革命，而是一种态度：在寻找新软件之前，值得先仔细看看已有的东西。

我们每天都在使用这个修补。它为我们节省了时间和精力。除了几小时的分析与开发外，我们没有花费别的成本。

该模块作为开源在 Odoo App Store 免费提供——因为我们认为这样一个基础的工作流修复理应对每个 Odoo Community 用户可用。

您在系统中也有类似问题吗？ 很多情况下一次对话就能判断是否可以通过有针对性的修补解决——在考虑昂贵替代方案之前。