从 CRM 回流到 Helpdesk，是很多团队都会遇到的场景：客户不是要下单，而是需要处理问题、排期支持或售后协助。crm_helpdesk 没把这件事做成“复制一张工单”，而是做成了一次有边界的对象转换。
主要参考：
enterprise/crm_helpdesk/wizard/crm_lead_convert2ticket.pyenterprise/crm_helpdesk/models/helpdesk_ticket.pyenterprise/crm_helpdesk/tests/test_crm_helpdesk_convert_ticket.py
一、default_get 先替你补好转换上下文
向导在 default_get() 阶段就会尝试给 partner_id 和 team_id 赋默认值。这个细节看起来不起眼，但企业流程里非常重要：它减少了跨团队转单时的悬空状态。
新手常常只盯着“点完按钮会发生什么”，却忽略了向导默认值本身就在表达设计意图：系统知道 lead 转工单不是纯技术动作，而是一次组织分工切换，所以要先把落点补齐。
二、如果 partner 不完整，系统会先做 partner assignment
action_lead_to_helpdesk_ticket() 里，如果当前 lead 没有 partner，但有 partner_name 或 contact_name，会先调用 _handle_partner_assignment(create_missing=True)。这意味着系统更希望把问题交给一个真实客户上下文，而不是一张孤零零的 ticket。
这对实战特别关键。售前阶段容忍一些模糊客户信息，但一旦进入 helpdesk，很多 SLA、通知、portal 交互都依赖 partner。如果这里不先补客户，问题只是被推迟，并不会消失。
三、真正被迁移的，不只是标题和描述
创建 ticket 时，向导会把 campaign / medium / source 一起带过去，并处理 partner_phone、partner_email。这说明企业版并没有把 Helpdesk 看成“脱离获客链路的终点站”，而是把它看成客户生命周期中的另一段流程。
换句话说，转成工单以后，企业依然希望知道这个客户原先从哪里来、为什么会进入当前支持流程。
四、线程、附件和返回动作，才是细节含量最高的地方
创建完 ticket 后，系统会：
- 用
message_post_with_source()建立来源说明； message_change_thread()把 lead 的消息线程迁过去；- 把
crm.lead下的附件改挂到helpdesk.ticket； - 在原 lead 上记录“已转工单”；
- 将 lead 归档；
- 如果当前用户无权读新 ticket，就返回原 lead 的动作。
这最后一步很容易被忽略，但非常企业化。系统知道跨模块转换后，权限不一定对称，因此返回动作必须防止把用户丢进一个他根本看不到的新对象里。
五、新手误区
- 以为 lead 转 ticket 会切断营销来源。其实企业版保留了来源字段。
- 以为附件迁移只是锦上添花。没有附件，支持团队经常要二次追资料。
- 以为权限检查是前端问题。这里其实是业务动作的一部分。
六、落地建议
- 明确哪些 lead 应该转 ticket，例如售后、实施支持、排障，而不是一切跟单困难都转。
- Helpdesk team 默认分配要先配置好，否则向导只能把问题从销售悬空转成服务悬空。
- 做跨团队培训时，把“转换后旧 lead 归档”的原因说清楚，避免业务误以为数据丢了。
七、结论
crm_helpdesk 的 lead 转 ticket 并不是“换一个模型存一下”，而是在做一条有组织边界意识的回流链：补客户、带来源、搬历史、迁附件、守权限。这样从销售回到服务时，客户上下文才不会断裂。
DISCUSSION
评论区