Odoo 企业版社媒评论转 CRM 线索：作者匹配、UTM 回填与返回动作是怎么串起来的

很多人看到 Odoo 企业版里“把社媒评论转成线索”的入口，第一反应都是：

• 不就是点一下新建 lead 吗？
• 最多把评论内容丢进描述字段？

但 social_crm 真正做的事情，比“建一条记录”细得多。因为社媒场景天然信息不完整：平台通常不给你邮箱、电话、地址，你手里往往只有作者名、评论正文、发布时间和帖子来源。系统如果不先把这些碎片整理好，后面的 CRM 统计和人工跟进都会很乱。

主要参考：

• enterprise/social_crm/models/social_post.py
• enterprise/social_crm/wizard/social_post_to_lead.py

一、先说结论：它做的是“低信息密度线索整理”，不是“评论直接变客户”

soclal.post.to.lead 这个向导的设计很克制。它并没有假设社媒作者一定是可联络的正式客户，而是把整个过程拆成三步：

1. 先决定这次转换来自 整条社媒帖子，还是 某条评论/回复；
2. 再决定作者该不该挂到现有客户、创建新客户，还是先不挂客户；
3. 最后才组装成 crm.lead，并把社媒来源写进 UTM 字段与描述模板。

这说明官方把它定义成“从弱结构化互动里抽出销售跟进线索”，而不是“从社媒直接造完整客户档案”。

二、第一层判断：来源是 stream post 还是 comment

向导里有个 conversion_source，只允许两种值：

• stream_post
• comment

这不是无关紧要的标志位，而是决定“数据从哪里来”。

如果是 stream_post，系统会从 social_stream_post_id 回填：

• author_name
• post_datetime
• post_link

如果是 comment，这些值则主要依赖前端传入的默认值。也就是说，Odoo 并不假设所有社媒互动都有一条完整后端记录。有些转换是基于已落库的帖子，有些只是基于前端当前看到的评论上下文。

这一步的意义很大：它保证了不同来源的数据在进入 CRM 前，至少被整理成同一种结构。

三、第二层判断：先尝试匹配客户，但不强行假装“已经认识这个人”

_compute_partner_action_data() 会根据 author_name 决定默认动作：

• 如果作者名长度太短，直接不搜；
• 如果搜到且只搜到一个 res.partner，默认走 exist；
• 如果没搜到，或者搜到多个，默认走 create。

这套逻辑看起来很简单，但其实反映了企业版很务实的态度：

社媒作者名只能作为弱匹配信号，不能当成强身份。

因为平台侧常见的是昵称、简称、品牌账号，重名概率很高。官方宁可在“不确定”时退回创建模式，也不愿把线索静默挂错到某个已有客户名下。

同时，向导还允许第三种动作：nothing。这表示即使你想转 lead，也不一定非要立刻绑定客户主数据。对于大量公域社媒互动，这反而更真实。

四、UTM 回填是关键：它决定这条线索还能不能回到营销统计里

_compute_utm_data() 是这条链路最值得读的地方之一。

它的逻辑不是简单把“社媒”两个字塞进来源字段，而是做了分层处理：

1. utm_medium_id 默认取当前 social_account_id 绑定的 medium；
2. 如果 social_stream_post_id 能反查到对应的 social.post，就把这条帖子的 campaign/source 一并继承；
3. 如果反查不到，就退回一个统一的 utm_source_social_post 兜底来源。

这里的设计非常成熟：

• 能关联到 Odoo 内部发出的社媒帖子时，统计要尽量精确；
• 关联不到时，也不能让 CRM 来源完全断掉；
• 所以至少保留一个“来自社媒帖子”的统一来源口径。

这就是为什么它不是“从评论建 lead”这么简单，而是同时在修 营销归因链。

五、真正写入 lead 时，官方保留的是“可跟进信息”，不是“伪装完整客户档案”

action_convert_to_lead() 最终写入 crm.lead 的核心字段包括：

• name: 通常是 Request from <author_name>
• partner_id
• source_id / medium_id / campaign_id
• description

如果用户选择的是 nothing，系统不会硬造一个 partner，而是把 contact_name 写成作者名。这一步非常关键。

因为在社媒场景里，很多互动只适合作为“待人工识别的销售线索”，并不适合立刻落成客户主数据。官方这里保留的是 后续跟进所需的最小闭环信息，而不是为了表面完整去过度建档。

六、描述字段不是纯文本拼接，而是把社媒上下文渲染成可追溯说明

description 不是直接塞评论正文，而是通过 ir.qweb 渲染模板 social_crm.social_post_to_lead_description，把这些内容组织进去：

• 作者
• 发布时间
• 帖子链接
• 正文内容
• 图片 URL（如果有）

这意味着销售打开 lead 时，不需要倒回社媒后台重新找原始评论；最关键的上下文已经被整理成一段可读说明。

换句话说，social_crm 并不是把 CRM 当作“帖子索引器”，而是把社媒互动压缩成 销售可消费的摘要对象。

七、返回动作也做了权限分层，而不是默认把所有人都送进 CRM 表单

创建完 lead_sudo 之后，系统还会检查当前用户在自己环境下是否有读取权限。

• 有权限：直接返回新 lead 的 form action；
• 没权限：只弹成功提示，然后关闭向导。

这个细节很容易被忽略，但它很重要。因为社媒运营人员和销售人员不一定是同一批人。官方允许前者触发线索创建，却不默认放开 CRM 读取能力。

所以这一步真正解决的是：

允许跨团队把社媒互动送进销售漏斗，但不因此打穿权限边界。

八、新手最容易误解的 4 个点

1）误以为作者名足够当客户主键

不是。它最多只是弱提示，系统默认也只在“唯一命中”时才自动关联现有 partner。

2）误以为没有匹配到客户就没法建 lead

也不是。nothing 模式就是为了接受“先记线索、后补主数据”的现实流程。

3）误以为 UTM 在社媒转 lead 时不重要

恰恰相反，这条链路最有价值的部分之一，就是把营销来源继续带进 CRM。

4）误以为创建完 lead 一定会跳转进去

还要看当前用户有没有 CRM 读取权限。没有权限时，系统只给成功反馈，不暴露对象内容。

九、落地建议

1. 不要把作者名自动匹配规则放得太宽，否则重名绑定错客户会比不绑定更糟。
2. 明确哪些社媒账号要绑定 UTM medium，否则后续来源分析会变得稀烂。
3. 给销售团队约定好 lead description 的阅读格式，把社媒上下文看作“跟进前摘要”，而不是要求他们回社媒平台补功课。
4. 如果运营团队无 CRM 权限，别误判为“转换失败”，很多时候只是系统按边界关闭了向导。

十、结论

Odoo 企业版的社媒评论转 CRM 线索，本质上不是“从评论一键建单”，而是一条 低信息密度互动 → 可跟进销售对象 的整理链：先判断来源，再谨慎处理客户匹配，用 UTM 保住营销归因，把上下文渲染成描述，最后按权限决定是否跳转到 CRM。真正值钱的，不是那条 lead 本身，而是这条线索进入销售漏斗时没有把来源和边界弄丢。