企业微信自动获客怎么做

自动的是交接，不是加人

把获客链路拆成四段：渠道曝光、留资或建立联系、首次承接、进入长期跟进。每一段内部的效率，加人手都能提；段与段之间的传递是纯粹的系统问题 —— 线索从渠道落到具体某个人手上花了多久、来源标记有没有跟过来、这条线索现在归谁有没有一个地方能查到。

判断标准很直接：链路里只要还有一段靠人把信息从一个系统抄到另一个系统，先修那一段。这类损耗不会体现在任何报表上，因为漏掉的线索从来不会出现在漏斗的下一层，你看到的转化率反而是被幸存者偏差修饰过的。

• 渠道参数停在落地页，建立联系之后没人知道这个人从哪来
• 线索进来了但没有明确归属，两个人都以为对方在跟
• 客户在第一次对话里说的关键信息只留在聊天记录里，没进任何结构化字段

这三条修完，再谈提高加人效率。顺序反过来的团队，最后都是在给一个漏水的桶加大进水量。

三类线索来源，承接方式不能共用一套

按「来源在建立联系之前是否已知」分三类，这个分法比按渠道名字分更有用，因为它直接决定了你能不能做归因，以及承接第一句话该说什么。

• 来源明确：活码、表单、活动报名。渠道参数在联系建立之前就存在，可以预先登记，归因最干净，也是唯一能做精细化首触的一类。
• 被动咨询：客户自己找过来。来源未知，只能靠首次对话里的问题类型推断，或者直接问一句。别用时间窗猜 —— 同一时段进来的人可能来自五个渠道。
• 存量导入：只有一份名单和一段历史。来源字段大概率已经失真，应该当成「无来源」处理，而不是把导入批次当成来源填进去。

来源必须在建立联系之前绑定，事后回填本质上是猜。可行的做法是把渠道参数先落成一条待认领的线索记录，键选一个渠道侧能生成、联系建立时又能被识别出来的值；用 wecomapi 的事件回调收到联系建立事件后，按这个键认领并把来源写死，认领不到的进人工队列，不要随手挂一个默认渠道。

承接窗口是唯一能被工程改善的转化变量

话术、内容、报价这些东西的效果，工程改不动。首次响应时延能改，而且在多数私域场景里，它和转化率的相关性高到不需要做实验就能感觉出来。这是获客链路上投入产出比最高的一段代码。

先厘清一件事：自动欢迎语不是承接。欢迎语解决的是「不冷场」，承接解决的是「有人负责」。把线索进来这件事建成一个有归属、有时限、有超时告警、有兜底接管人的任务，才叫承接。任务超时必须能升级，而不是安静地过期。

这里有个时序坑：联系建立事件和客户的第一条消息几乎同时发生，到达顺序不保证。如果承接逻辑假设「先建立、后说话」，那批自己先开口的客户会收到一条驴唇不对马嘴的欢迎语。稳妥的写法是两类事件都往同一个队列投，按线索键做 upsert —— 谁先到谁把任务立起来，后到的只做合并。

// 示意逻辑，事件类型与字段名以文档为准
// 回调里已快速 ACK，这里是队列消费者
// 联系建立事件与客户首条消息可能乱序到达，用线索键合并
async function onLeadEvent(evt) {
  const leadId = await resolveLead(evt);       // 按预登记的渠道键认领
  const task = await handoff.upsert(leadId, {  // 已存在则合并，不重复创建
    owner: await pickOwner(leadId),
    dueAt: Date.now() + 5 * 60 * 1000,         // 首响时限：5 分钟
  });
  if (task.created) await sendFirstTouch(task);
}

// 首触发送收敛到一个出口，示意端点与字段：
// POST https://manager.wecomapi.com/message/sendText
// { "guid": "...", "toId": "...", "content": "..." }

时限定多少不重要，重要的是它是个能被监控的量。先把首响时延的分位数打出来，看 P90 落在哪，再决定目标值。平均值在这个指标上完全没有意义 —— 拖到第二天才回的那几条，正是流失的主力，而它们在平均值里会被大量秒回稀释掉。

归因链要能一路穿到成交

多数获客系统在「加上了」之后归因就断了。断点通常是这三个：外部联系人的身份和 CRM 里的客户不是同一个主键；同一个人被两个员工分别加上，在库里成了两条记录；线索转成商机时来源字段没带过去。三个断点里任意一个存在，渠道投放的 ROI 就是编的。

1. 1生成一个线索 ID 贯穿全程，在渠道侧就生成，不要等联系建立之后再补发一个。
2. 2身份合并要有明确的合并键和合并时点，并保留合并前的原始记录 —— 合并逻辑一定会改，改的时候你需要能回滚。
3. 3来源字段只在认领时写一次，之后全链路只读。任何允许后续覆盖来源的设计，最后都会被拿来「修正数据」。

客户与联系人这一侧的读写走 wecomapi 的客户接口，你自己的库只存映射关系和业务字段，不要复制一份完整客户档案 —— 双写迟早漂移，到时候两边对不上又说不清以谁为准。增量同步与对账的具体做法站内另有一篇专门讲。

三件技术上做得到、但该显式关掉的事

这三件在 wecomapi 这类接入方式下都做得到，正因为做得到，才要在系统里留一个明确的关闭位置，而不是靠「我们不这么用」的口头约定 —— 口头约定撑不过一次冲业绩的季度末。

1. 1自动判定线索质量并直接丢弃。打分可以，丢弃不行 —— 打分模型上线三个月内一定会调，被丢掉的线索找不回来。
2. 2自动变更客户归属。归属牵扯提成，让它停在「待确认」由人点一下，是最便宜的防吵架机制。
3. 3无差别提高发起联系的频次。频次是挂在人身上的预算，不是挂在活动上的配额，站内另有一篇讲这套算法。