甲方人工加微信 9 月 21 日至 10 月 14 日的数据、当下的卡点和能不能突破,以及新增不够时怎样在召回资源上扩充。
销售 A / B / C:门店三位销售各自的微信号,由 AI 辅助接待;APK:另一个由 AI 辅助接待的微信号。首触:客户通过好友后,我们发出的第一条消息。破冰:客户还没回过话;培育:客户回过话、还在了解中。召回:给之前加过、后来不说话的客户再发消息。转人工:系统停止自动回复,交给销售本人。交接卡:转人工时推给负责人的提醒卡片;认领:负责人确认「这个客户我接了」。重新开聊:召回发出后 7 天内客户说过话。逐行核对:程序在微信聊天列表里从上往下一行一行点开看,认出刚通过的新好友才发首触。让路:销售正在用这台电脑时,程序不和人抢鼠标键盘,先不发、过一会儿再试。窗口标定:程序定期量一下微信窗口的位置和大小,日志里有这一条说明程序还在运行。重启:程序自己关掉再打开(升级或出错后会发生)。
其中 2 条是同一位客户(备注里的表情被读成两条),实际 48 人。
9 月 21 日到 10 月 14 日这 24 天,三位销售的微信合计通过 49 人(与实时看板一致;其中 1 位客户被记成了两条,实际 48 人,见下文);按每天 10 人的目标是 240 人,完成 20%(APK 不计入)。其中 9/21–9/29 的 21 人是销售 A、B 的人工补录,不含销售 C;9/30 起的 27 人来自系统的好友通过记录(28 条记录里有 2 条是同一位客户),能分到每位销售。「当天人工加了多少人」只有 9 月 21–23 日有逐日汇总、9 月 28 日有一句口头转述,其余 20 天没有记录,所以算不出整段的通过率。10 月 1–8 日系统没有通过记录,看板按 0 计,原因待查。
| 日期 | 人工添加(汇报) | 通过(看板) | 通过 · 销售 A | 通过 · 销售 B | 通过 · 销售 C |
|---|---|---|---|---|---|
| 09-21 | 10 | 7 | 补录 · 销售 A、B 合计,不含销售 C,未分人 | ||
| 09-22 | 10 | 4 | 补录 · 销售 A、B 合计,不含销售 C,未分人 | ||
| 09-23 | 10 | 1 | 补录 · 销售 A、B 合计,不含销售 C,未分人 | ||
| 09-24 | 无记录 | 3 | 补录 · 销售 A、B 合计,不含销售 C,未分人 | ||
| 09-25 至 09-27 | 无记录 | 0 | 无补录,看板按 0 计 | ||
| 09-28 | 口头:实际完成 3 个 | 4 | 补录 · 销售 A、B 合计,不含销售 C,未分人 | ||
| 09-29 | 无记录 | 2 | 补录 · 销售 A、B 合计,不含销售 C,未分人 | ||
| 09-30 | 无记录 | 6 | 2 | 4 | 0 |
| 10-01 至 10-08 | 无记录 | 0 | 系统无通过记录,原因待查 | ||
| 10-09 | 无记录 | 6 | 4 | 2 | 0 |
| 10-10 | 无记录 | 7 | 3 | 4 | 0 |
| 10-11 | 无记录 | 3 | 0 | 2 | 1 |
| 10-12 | 无记录 | 4 | 1 | 3 | 0 |
| 10-13 | 无记录 | 1 | 1 | 0 | 0 |
| 10-14 | 无记录 | 1 | 0 | 0 | 1 |
| 合计 | 30 + 口头 3 | 49 | 11 | 15 | 2 |
分销售的三列只统计 9/30 起的系统记录。表里按看板口径计数:10-10 销售 B 的 4 条里有 2 条是同一位客户(备注里的表情被读成两条),所以销售 B 实际 14 人、合计实际 48 人;下文 9/30 起的分析按去重后的 27 人算。另有 18 位好友有记录但没有通过时间(销售 A 9、销售 B 2、销售 C 7),没算进上表,所以销售 C 被明显低估,这是我方采集的问题。我们已准备好一个逐人登记入口(每天登记加了谁、点「当天已全部登记」),接下来想请销售一起用起来。
这里有两种通过率,分子分母不同,分开列:
| 账号 | 通过 | 发出首触 | 客户先开口 | 首触后回话 | 通过后开过口 |
|---|---|---|---|---|---|
| 销售 A | 11 | 8 | 3 | 3 | 6 |
| 销售 B | 14 | 10 | 3 | 1 | 4 |
| 销售 C | 2 | 1 | 1 | 0 | 1 |
| 合计 | 27 | 19 | 7 | 4 | 11 |
| 首触在通过后多久发出 | 发出首触 | 首触后回话 | 备注 |
|---|---|---|---|
| 1 小时以内 | 12 | 4 | 回话的 4 位,首触都在通过后 35 分钟内发出(其中 3 位在 3 分钟内) |
| 超过 1 小时 | 6 | 0 | 其中 3 位是夜里通过(0–2 点、21 点后):当晚逐行核对停了,第二天上午恢复后才发出,晚了 7.5–13 小时(逐位原因见下表) |
| 只有通过日期、没有通过时刻 | 1 | 0 | 算不出间隔 |
首触只有一个入口:程序在微信聊天列表里从上到下逐行点开核对,认出刚通过的新好友才发。我方加、对方通过不会出现红点,所以只能等逐行核对走到这一行。下面每一位都对着当天的运行日志查过;日志里找不到的直接写没找到,不猜。
| 账号 · 通过时刻 | 首触发出 | 原因 | 依据 |
|---|---|---|---|
| 销售 A · 10-09 09:48 | 43 分钟后 | 3 分钟就认出了,话也备好了,但销售当时正在用这台电脑,程序按规则让路(不和销售抢鼠标键盘),15 分钟后再试;逐行核对 10:30 才再走到这一行 | 日志 09:51 认出,销售正在用电脑、先让路;10:31 发出 |
| 销售 B · 10-10 16:39 | 35 分钟后 | 5 分钟就认出了,但发送前核对聊天窗口标题没通过,按规则 15 分钟后可以再试,但逐行核对 17:13 才走回这一行,22 秒后发出。这位后来回话了 | 日志 16:44 认出,聊天标题核对没过;17:13 发出 |
| 销售 B · 10-10 16:38 | 18 分钟后 | 逐行核对按顺序一行一行点开,16:55 走到他所在的第 4 行,认出后 23 秒发出 | 日志 16:55 认出、16:56 发出 |
| 销售 B · 10-09 18:03 | 65 分钟后 | 18:03–19:03 逐行核对一直在第一页前几行之间来回,日志里没有出现这一位;19:03 程序重启后 3 分钟就认出并发出。为什么之前没走到他,日志里没有找到原因 | 日志 18:00–19:03 核对记录;19:03 重启;19:07 发出 |
| 销售 A · 09-30 14:18 | 71 分钟后 | 15:27 之前日志里没有这一位被核对过的记录;14:24、15:21 程序各重启一次;15:27 在第 2 行认出,2 分钟后发出。原因没找到 | 日志 14:13–15:35 |
| 销售 B · 10-12 11:43 | 2.4 小时后 | 白天逐行核对一直在跑(11:43–14:06 共 214 条核对记录,其中 95 条是半小时内核对过、直接跳过),但直到 14:06 才在第 5 行认出这一位。为什么这么久才走到他,日志里没有找到原因 | 日志 11:43–14:06 |
| 销售 B · 10-11 02:24 | 7.6 小时后 | 前一晚 22:14 起逐行核对停了,到第二天 09:19 才恢复;夜里程序一直在运行(每 15–20 分钟仍有一次窗口标定记录),但核对停止的原因日志里没写明。10:00 走到第 5 行认出,10:01 发出 | 日志 10-10 22:14 最后一条核对;10-11 09:19 恢复 |
| 销售 B · 10-11 21:37 | 12.9 小时后 | 21:37 通过时逐行核对还在跑,22:26 停下前没走到他;当晚 22:07 程序报过一次电脑锁屏;第二天 09:01 恢复,10:29 走到第 7 行认出并发出 | 日志 22:07 锁屏告警、22:26 最后一条核对、次日 09:01 恢复 |
| 销售 A · 10-13 00:42 | 9 小时后 | 00:43 程序报电脑锁屏(锁屏时程序点不开微信),之后到 08:54 没有核对记录;08:55 恢复,09:43 走到第 4 行认出并发出 | 日志 00:43 锁屏告警;08:55 恢复 |
| 销售 B · 09-30 13:26 / 14:17 / 14:25 三位 | 52 / 17 / 17 分钟后 | 日志里没有找到原因:这台电脑 9-30 这段时间云端没有运行日志 | 按时段查日志,0 条 |
| 没有发首触的 | 记录 | 原因 | 依据 |
|---|---|---|---|
| 客户先开口 | 7 | 客户通过后先说了话,按规则不再发开场白,直接由自动回复接待 | 消息库:这 7 位的第一条客户消息早于任何首触 |
| 销售 B · 10-10 20:07 通过 | 2 条(1 人) | 其实是同一位客户被记了两次:备注里的表情一次读成表情、一次读成问号。第二天 10:01 第一次核对到他时,程序判断他已经说过 1 句话、不是新好友,所以不发首触;他的备注末尾那串数字不是完整的 11 位手机号,程序也不把他当客户,不会自动回复和召回。20:07–22:14 逐行核对为什么没走到他,日志里没有找到原因 | 日志 10-11 10:01、10:13 两次核对;两条会话记录同一通过时刻 |
所以系统的 28 条通过记录实际是 27 位客户,本页各处都按 27 人算。日志按北京时间;依据栏只写时刻和判断,不贴原始日志。
样本只有 19 人,1 小时内 4/12、超过 1 小时 0/6 只是一个方向,不是定论。客户回话以消息库里客户一侧的消息为准,已剔除好友验证通过的系统提示;销售在微信里手动发的内容也可能被记成客户消息,所以回话数是上限。查询时刻 2026-10-15 11:05(北京时间)。
首触话术目前三台电脑用的是同一套,没有可比较的对照组,所以这一版不评价话术好坏;回话率差异先看发送时机。
| 卡点 | 依据 | 能不能突破 | 怎么做 | 风险 |
|---|---|---|---|---|
| 平台对加好友的频率限制 甲方主动限量分批 | 9/28 甲方转述;当天 3 / 10 | 空间有限 | 加人的节奏以甲方自己验证过的为准,我们不建议提量;把力气放在「加上的每一个都接住」:立刻首触、有对话、有人跟 | 节奏由甲方掌握,我们不替甲方提量 |
| 通过率在下降 | 9/21–23:70% → 40% → 10%(3 天口头汇报) | 有一些 | 验证语不放活动话术;优先加老客户转介绍、到店留过电话的人;加之前门店先电话打个招呼 | 3 天样本太小,不能当规律 |
| 手机号搜不到 / 对方没开搜索 | 以往线索里有一部分搜不到 | 有限 | 请客户主动加 | 无 |
| 加上了但没接住、没记下(我方问题) | 9/30 起系统记录通过 27 位:19 位已首触、7 位客户先开口(不需要首触)、1 位没首触(原因见上文);登记入口还没用起来 | 有,且我方可控 | 甲方每天在台账登记加了谁;我们修首触、补通过上报、给记录中断加告警 | 无 |
召回对象已经是好友,不需要再加人。现有的存量比每天新增大一个量级,先把存量用足,比逼销售多加人更稳。
| 资源 | 数量 | 能不能进召回 | 前提 |
|---|---|---|---|
| 三台电脑 + APK 的召回候选(已启用) | 587 | 能,已在跑 | 排除聊天里说过已下单的、已拒绝、删好友、同名分不清、群聊、公众号;门店成交的要等订单记录给到才能排除。不含两台停用电脑上的客户(② 召回页的 464 位触达里含这部分) |
| 其中从没召回过 | 195 | 能,最先用 | 销售 A 71 · 销售 B 77 · 销售 C 45 · APK 2 |
| 其中排队待发 | 119 | 能 | 约 3–5 天可发完(与上一行有部分重叠) |
| 召回过、7 天没回话的 | 约 360 | 能,走第二轮 | 第二轮必须换话题、换形式(见 ② 召回页),不重复讲过的内容;已收到 7 条召回的 129 位客户先不再发 |
| 两台已停用电脑上的客户 | 108 | 需甲方确认 | 这两个微信号现在谁在用、还能不能登录 |
| 6 月导入的留电线索 | 401 | 只能进「加好友」 | 还不是好友,不能直接召回;目前只通过 1 位,7 月之后没再跟进,数据已冷;线索归属需甲方确认 |
| 三台电脑和 APK 的微信好友总数 | 取不到 | — | 目前只覆盖聊天列表里出现过的客户。好友总数需要甲方在手机上看 |
我们先按默认做法准备,您随时可以改。
默认:销售每天下班前登记一次,没加人也点「当天已全部登记」。
默认:不在用,108 位客户暂不召回。
人工添加:9/21–23 为运营 9/24 提供的逐日汇总,没有逐人名单;9/28 为群内转述。通过:好友通过记录中有通过时间的条目,按北京时间归日。
首触后回话:分母=9/30 起系统记录通过、且已发出首触的 19 人;回话=首触之后客户一侧出现真实消息(已剔除好友验证通过等系统提示;销售在微信里手动发的内容可能被记成客户消息,所以是上限)。
召回候选:各账号已启用的召回候选客户,「召回过」指至少一条已发送任务。
重跑会变:发送数、通过数、回话数每天增长;已满 7 天的比率会随最近一周的发送逐步成熟而变化;历史日期的格子基本不变。
下面每一条先写我们看到的现状,再写我们的默认做法。哪条不合适,当面改。
现状:目标每天 10 人;9/28 实际 3 人,为控制风险分批加;9/30–10/14 系统记录的通过平均每天约 2 人(27 人 ÷ 15 天,10/1–8 无记录的 8 天也算在分母里)。默认:节奏由门店自己定,我们不建议提量,只把每一个加上的人接住。
现状:9/21–23 三天的通过率从 70% 降到 10%(只有 3 天、来自口头汇报,按当天通过数 ÷ 当天添加 10 人算,不是同一批申请的通过率,只作参考);6 月导入的 401 条留电线索只通过 1 位,7 月后没再跟进。默认:先加老客户转介绍、到店留过电话、近期主动咨询过的人;冷线索放最后。
现状:一部分手机号搜不到,或对方没开搜索。默认:搜不到的不反复尝试,改请客户主动加;明确拒绝过的不再加。
现状:没有不同验证语的对照数据;前面卡点表里的做法是验证语不放活动话术。默认:验证语只写门店名和来由,活动介绍留到通过之后的首触里讲。
现状:夜里通过的 3 位,首触都拖到第二天上午才发,且都没回话;原因是夜里逐行核对停了(其中两晚程序报过电脑锁屏)。默认:先试一周在白天加,我们同时查清夜里核对为什么停;夜里样本只有 3 位,一周后看数据再定。
现状:加好友、发申请由销售人工做;首触、日常回复和召回由系统做;转人工后的跟进回到销售。默认:维持这个分工,加人不交给系统自动做。
现状:系统只看得到聊天列表里出现过的客户,看不到每个微信的好友总数,也看不到每天发出了多少条申请。默认:销售每天在登记入口记一笔加了谁,好友总数每月在手机上看一次告诉我们。