Odoo 企业版 Helpdesk 短信为什么不是“工单上点一下发短信”：stage 钩子、ticket write 与短信发送边界讲透

Helpdesk 里的短信通知，看起来像一个很小的功能。但 enterprise/helpdesk_sms/models/helpdesk_ticket.py 反而说明：它不是给客服“顺手发条短信”的快捷键，而是一种阶段驱动、模板驱动的流程消息。

一、短信触发点绑在 create 和 stage write 上

create() 在工单创建后立即调用 _send_sms()；write() 则只有 stage_id 被改动时才触发。这说明短信不是任意字段变化都发，而是明确围绕两个业务时机：

1. 工单首次进入系统；
2. 工单进入新的服务阶段。

这其实很符合客户沟通规律。用户最在意的不是“工单描述被编辑了一次”，而是“工单已创建”“工单已转阶段”“工单已处理完成”。

二、真正决定是否发送的，是 stage 模板和 partner 是否存在

_send_sms() 的逻辑非常克制：只有 ticket.partner_id、ticket.stage_id 和 ticket.stage_id.sms_template_id 都存在时，才调用 _message_sms_with_template()。也就是说，系统默认不替你猜收件人、不替你猜模板。

这比很多“自动通知”实现稳得多。因为客服最怕的不是没发，而是发错：发给内部联系人、发给空号码、发了与当前阶段不符的话术。

三、短信模型是在强调“阶段语义”，不是在强调“沟通渠道”

这里最值得注意的不是技术实现，而是设计心态：短信模板挂在 helpdesk.stage 上，而不是挂在客服动作上。换句话说，系统假设客户通知内容应该由阶段定义，而不是由某位客服临场发挥。

对规模化团队来说，这能带来两个直接好处：

• 文案一致，客户不会因为不同客服而收到完全不同的话术；
• 触发稳定，统计和合规也更容易做。

四、实战里真正要管的是阶段设计

如果企业把 stage 设计得过细，write() 上的短信触发会变得过于频繁；如果 stage 设计得过粗，又可能让客户长时间收不到有价值进展。所以短信项目成败，往往不在网关，而在工单阶段是否真正有业务语义。

建议至少把以下阶段想清楚：

• 工单已受理；
• 工程师处理中；
• 等待客户补充；
• 已解决 / 已关闭。

新手误区

• 误以为短信只是客服手工发送的一种补充渠道。
• 误以为任何字段变动都应该通知客户。
• 误以为模板写一份万能文案就够。
• 误以为工单阶段只是内部管理字段，与客户体验无关。

主要源码参考

• enterprise/helpdesk_sms/models/helpdesk_ticket.py
• enterprise/helpdesk_sms/models/helpdesk_stage.py