很多团队把“工单转商机”理解成一个跨模块按钮。但在企业场景里，这个动作之所以难，是因为它本质上是在做 对象迁移：同一段客户问题，原先被放在服务语境里，现在要转去销售跟进语境里，而且历史还不能丢。crm_helpdesk 处理的就是这个迁移动作。
主要参考：
enterprise/crm_helpdesk/models/helpdesk_ticket.pyenterprise/crm_helpdesk/wizard/helpdesk_ticket_to_lead.pyenterprise/crm_helpdesk/views/helpdesk_ticket_views.xml
一、转换前先找客户，而不是先建 lead
_find_matching_partner() 会优先看现有 partner，再看 email_cc、电话等信息来匹配联系人；必要时还能 force_create。这说明企业版把“客户归属”看得比“lead 快速生成”更重要。
现实里这一步决定了后续会不会形成重复客户。服务团队往往只关心问题有没有解决，但销售更关心这个机会最终算到谁名下。如果 ticket 转 lead 时 partner 归属已经乱了，后续就会在去重和统计上反复补锅。
二、向导真正做的是上下文迁移，不只是字段复制
action_convert_to_lead() 除了写入 name / partner / team / user / description，还会把 campaign / medium / source 一并带过去。这很像一个成熟 CRM 团队的思路：工单不是孤立事件，它仍然属于获客链路的一部分。
如果企业把服务入口看成销售漏斗的补入口，这些营销来源字段尤其重要。否则后续报表里就会出现“销售从哪里来”的断裂。
三、真正难的，是消息线程和附件迁移
源码最值得看的不是 create，而是 message_change_thread() 和附件重挂。系统会把原 ticket 的消息线程迁到新 lead，再把 helpdesk.ticket 上的附件改挂到 crm.lead。随后原 ticket 归档，并再写一条链接消息。
这套动作说明企业版非常在意 上下文连续性。如果只建一条新 lead，不迁移历史，销售拿到的会是一张“没有来历的商机”。而企业实际最怕的，正是这种跨团队交接时的上下文断层。
四、归档原工单，而不是保留两个活跃对象并行推进
转换后 action_archive() 会把 ticket 归档。这不是为了节省列表空间，而是在业务语义上告诉团队：这段线索的主战场已经转到 CRM。服务端保留历史，但不再把它当作当前活跃对象。
如果不这样做，最容易发生的事就是同一客户需求在 helpdesk 和 CRM 两边被同时推进，最后谁负责、哪个状态才算准，都会变得模糊。
五、新手常见误区
- 以为 ticket 转 lead 只是提高协作效率。其实它是在重建业务对象边界。
- 以为消息线程可迁可不迁。没有线程历史，销售很难理解客户到底遇到了什么。
- 以为工单应该保留活跃状态。双活对象往往比归档更危险。
六、落地建议
- 先约定什么类型的 ticket 才允许转商机，避免把普通售后问题都灌进 CRM。
- 客户匹配规则要先和客服对齐，尤其是 email/phone 哪个更可信。
- 转换后的 lead 要有明确 owner，否则只是把上下文从一个黑洞搬到另一个黑洞。
七、结论
crm_helpdesk 的工单转商机，不是一个“创建 lead 的快捷方式”，而是一条完整的对象迁移链：匹配客户、搬历史、带来源、归档旧对象。企业真正需要的，正是这种迁移后上下文不断裂的转换。
DISCUSSION
评论区