个人微信获客 · 甲方对接 · 第 3 / 3 份

人工添加个微线索:9 月 21 日以来的数、卡点与资源扩充

甲方人工加微信 9 月 21 日至 10 月 14 日的数据、当下的卡点和能不能突破,以及新增不够时怎样在召回资源上扩充。

通过人数与实时看板同口径(其中 2 条是同一位客户,实际 48 人),取数 2026-10-15 09:20;其余数据取自生产库,查询时刻 2026-10-14 17:27–17:50(北京时间)。数字会随时间增长,页面不自动刷新。客户一律编号,不出现姓名、手机号、门牌和具体金额。

本页用到的几个词

销售 A / B / C:门店三位销售各自的微信号,由 AI 辅助接待;APK:另一个由 AI 辅助接待的微信号。首触:客户通过好友后,我们发出的第一条消息。破冰:客户还没回过话;培育:客户回过话、还在了解中。召回:给之前加过、后来不说话的客户再发消息。转人工:系统停止自动回复,交给销售本人。交接卡:转人工时推给负责人的提醒卡片;认领:负责人确认「这个客户我接了」。重新开聊:召回发出后 7 天内客户说过话。逐行核对:程序在微信聊天列表里从上往下一行一行点开看,认出刚通过的新好友才发首触。让路:销售正在用这台电脑时,程序不和人抢鼠标键盘,先不发、过一会儿再试。窗口标定:程序定期量一下微信窗口的位置和大小,日志里有这一条说明程序还在运行。重启:程序自己关掉再打开(升级或出错后会发生)。

03
甲方人工添加个微线索 · 9/21–10/14

24 天通过 49 人,完成目标的 20%

其中 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 计,原因待查。

30 → 129/21–23 人工添加 → 通过
通过率 40%(口头汇报)
49 / 2409/21–10/14 通过 / 目标
每天 10 人 × 24 天,完成 20%
3 / 109/28 实际完成 / 每日目标
甲方为控制风险分批添加
279/30 起系统记录的通过(28 条记录,2 条是同一人)
A 11 · B 14 · C 2;已首触 19 · 客户先开口 7 · 没首触 1
日期人工添加(汇报)通过(看板)通过 · 销售 A通过 · 销售 B通过 · 销售 C
09-21107补录 · 销售 A、B 合计,不含销售 C,未分人
09-22104补录 · 销售 A、B 合计,不含销售 C,未分人
09-23101补录 · 销售 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无记录6240
10-01 至 10-08无记录0系统无通过记录,原因待查
10-09无记录6420
10-10无记录7340
10-11无记录3021
10-12无记录4130
10-13无记录1100
10-14无记录1001
合计30 + 口头 34911152

分销售的三列只统计 9/30 起的系统记录。表里按看板口径计数:10-10 销售 B 的 4 条里有 2 条是同一位客户(备注里的表情被读成两条),所以销售 B 实际 14 人、合计实际 48 人;下文 9/30 起的分析按去重后的 27 人算。另有 18 位好友有记录但没有通过时间(销售 A 9、销售 B 2、销售 C 7),没算进上表,所以销售 C 被明显低估,这是我方采集的问题。我们已准备好一个逐人登记入口(每天登记加了谁、点「当天已全部登记」),接下来想请销售一起用起来。

通过之后:首触发出多少、客户回了多少

这里有两种通过率,分子分母不同,分开列:

  • 加人申请的通过率 = 通过人数 ÷ 销售发出的加好友申请数。只有 9/21–23 三天有逐日的申请数(30 发出 → 12 通过,40%),其余日子没有申请数,算不出。
  • 首触后的回话率 = 首触发出后客户回过话的人数 ÷ 首触发出的人数。下面按 9/30 起系统记录的 27 位通过者逐人算(28 条记录里有 2 条是同一位客户,合并算 1 人)。
279/30–10/14 系统记录的通过
A 11 · B 14 · C 2
19其中发出首触(70%)
另 7 位客户先开口,按规则不再发首触
4 / 19首触发出后客户回话
首触后回话率 21%
11 / 27通过后客户开过口(任何时候)
41%,含先开口的 7 位
账号通过发出首触客户先开口首触后回话通过后开过口
销售 A118336
销售 B1410314
销售 C21101
合计27197411
首触在通过后多久发出发出首触首触后回话备注
1 小时以内124回话的 4 位,首触都在通过后 35 分钟内发出(其中 3 位在 3 分钟内)
超过 1 小时60其中 3 位是夜里通过(0–2 点、21 点后):当晚逐行核对停了,第二天上午恢复后才发出,晚了 7.5–13 小时(逐位原因见下表)
只有通过日期、没有通过时刻10算不出间隔

首触为什么晚、为什么没发:逐位原因

首触只有一个入口:程序在微信聊天列表里从上到下逐行点开核对,认出刚通过的新好友才发。我方加、对方通过不会出现红点,所以只能等逐行核对走到这一行。下面每一位都对着当天的运行日志查过;日志里找不到的直接写没找到,不猜。

账号 · 通过时刻首触发出原因依据
销售 A · 10-09 09:4843 分钟后3 分钟就认出了,话也备好了,但销售当时正在用这台电脑,程序按规则让路(不和销售抢鼠标键盘),15 分钟后再试;逐行核对 10:30 才再走到这一行日志 09:51 认出,销售正在用电脑、先让路;10:31 发出
销售 B · 10-10 16:3935 分钟后5 分钟就认出了,但发送前核对聊天窗口标题没通过,按规则 15 分钟后可以再试,但逐行核对 17:13 才走回这一行,22 秒后发出。这位后来回话了日志 16:44 认出,聊天标题核对没过;17:13 发出
销售 B · 10-10 16:3818 分钟后逐行核对按顺序一行一行点开,16:55 走到他所在的第 4 行,认出后 23 秒发出日志 16:55 认出、16:56 发出
销售 B · 10-09 18:0365 分钟后18:03–19:03 逐行核对一直在第一页前几行之间来回,日志里没有出现这一位;19:03 程序重启后 3 分钟就认出并发出。为什么之前没走到他,日志里没有找到原因日志 18:00–19:03 核对记录;19:03 重启;19:07 发出
销售 A · 09-30 14:1871 分钟后15:27 之前日志里没有这一位被核对过的记录;14:24、15:21 程序各重启一次;15:27 在第 2 行认出,2 分钟后发出。原因没找到日志 14:13–15:35
销售 B · 10-12 11:432.4 小时后白天逐行核对一直在跑(11:43–14:06 共 214 条核对记录,其中 95 条是半小时内核对过、直接跳过),但直到 14:06 才在第 5 行认出这一位。为什么这么久才走到他,日志里没有找到原因日志 11:43–14:06
销售 B · 10-11 02:247.6 小时后前一晚 22:14 起逐行核对停了,到第二天 09:19 才恢复;夜里程序一直在运行(每 15–20 分钟仍有一次窗口标定记录),但核对停止的原因日志里没写明。10:00 走到第 5 行认出,10:01 发出日志 10-10 22:14 最后一条核对;10-11 09:19 恢复
销售 B · 10-11 21:3712.9 小时后21:37 通过时逐行核对还在跑,22:26 停下前没走到他;当晚 22:07 程序报过一次电脑锁屏;第二天 09:01 恢复,10:29 走到第 7 行认出并发出日志 22:07 锁屏告警、22:26 最后一条核对、次日 09:01 恢复
销售 A · 10-13 00:429 小时后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(北京时间)。

有没有优化空间:有,三处,都在我们这一侧

  1. 通过后尽快首触。首触后回话的 4 位,首触都在 35 分钟内发出;超过 1 小时的 6 位没有一位回话。拖慢的原因见上表:销售正在用电脑时让路、发送前标题核对没过要等 15 分钟、夜里逐行核对停了。做法:先试一周——让路和核对失败后不等下一圈,直接回到这一位重试;查清夜里逐行核对为什么停;一周后看回话率再定(夜里通过的样本目前只有 3 位)。目标是通过后 1 小时内首触的比例从 12/19 提到 80% 以上(80% 为提议值)。
  2. 通过了却没有首触、也没有对话的那 2 条记录。查清了:是同一位客户被记了两次,程序看到他已经说过话就没发首触,而他的备注不规范,自动回复也没接。做法:通过记录出现 2 小时内还没首触、客户也没开口,就提醒销售;同一位客户因为表情读法不同被拆成两条的,合并成一条。
  3. 通过记录本身不全。另有 18 位好友有记录但没有通过时刻(销售 C 7 位),10 月 1–8 日没有任何通过记录,所以上面的 27 是低估。做法:补齐销售 C 的通过上报,配合逐人登记入口,下一版能按天算出加人申请的通过率。

首触话术目前三台电脑用的是同一套,没有可比较的对照组,所以这一版不评价话术好坏;回话率差异先看发送时机。

加微信的卡点,和有没有突破空间

我们收到的直接反馈只有一条(9 月 28 日,经我方对接人转述):当天实际完成 3 个,为控制风险分批添加,第二天继续。下面其余几类是我们从数据和以往经验里的理解,想请您当面补充和纠正。
卡点依据能不能突破怎么做风险
平台对加好友的频率限制
甲方主动限量分批
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 的微信好友总数取不到—目前只覆盖聊天列表里出现过的客户。好友总数需要甲方在手机上看

分步方案(按风险从小到大)

  1. 发完 195 位从没召回过的客户和 119 条排队任务。不新增任何账号动作;约 3–5 天。
  2. 召回过、没回话的客户进第二轮,换成 ② 召回页的新形式(关注点、短视频、同城案例)。停止联系率不高于现在的 6.0%;任一组超过 8% 立即暂停(8% 为提议值)。
  3. 两台停用电脑上的 108 位客户:甲方确认微信号还在用就重新接入召回。需要甲方回答,见下方第 2 个问题。
  4. 扩大候选范围:逐步把更多聊天列表里的老客户纳入候选。小步放开,观察一周有无异常再继续。
  5. 401 条留电线索由甲方销售按自己的节奏人工加。每天加了谁登记进台账,才能算出真实通过率。
  6. 加上之后立刻接住:补齐首触和通过记录,比多找 10 条新线索更划算。与 ① 新客页优化工作第 3 条是同一件事。
?
需要甲方确认

2 个问题,每个都有默认做法

我们先按默认做法准备,您随时可以改。

1. 每天人工加了谁,能否在台账登记?

默认:销售每天下班前登记一次,没加人也点「当天已全部登记」。

2. 两台停用电脑上的微信号还在用吗?

默认:不在用,108 位客户暂不召回。

口径与证据(数字是怎么来的)

人工添加:9/21–23 为运营 9/24 提供的逐日汇总,没有逐人名单;9/28 为群内转述。通过:好友通过记录中有通过时间的条目,按北京时间归日。

首触后回话:分母=9/30 起系统记录通过、且已发出首触的 19 人;回话=首触之后客户一侧出现真实消息(已剔除好友验证通过等系统提示;销售在微信里手动发的内容可能被记成客户消息,所以是上限)。

召回候选:各账号已启用的召回候选客户,「召回过」指至少一条已发送任务。

重跑会变:发送数、通过数、回话数每天增长;已满 7 天的比率会随最近一周的发送逐步成熟而变化;历史日期的格子基本不变。

谈
讨论话题

现在加人的边界在哪里,一起确认

下面每一条先写我们看到的现状,再写我们的默认做法。哪条不合适,当面改。

1. 每天加多少人算安全?

现状:目标每天 10 人;9/28 实际 3 人,为控制风险分批加;9/30–10/14 系统记录的通过平均每天约 2 人(27 人 ÷ 15 天,10/1–8 无记录的 8 天也算在分母里)。默认:节奏由门店自己定,我们不建议提量,只把每一个加上的人接住。

2. 优先加哪些人?

现状:9/21–23 三天的通过率从 70% 降到 10%(只有 3 天、来自口头汇报,按当天通过数 ÷ 当天添加 10 人算,不是同一批申请的通过率,只作参考);6 月导入的 401 条留电线索只通过 1 位,7 月后没再跟进。默认:先加老客户转介绍、到店留过电话、近期主动咨询过的人;冷线索放最后。

3. 什么情况下不加?

现状:一部分手机号搜不到,或对方没开搜索。默认:搜不到的不反复尝试,改请客户主动加;明确拒绝过的不再加。

4. 加好友时的验证语怎么写?

现状:没有不同验证语的对照数据;前面卡点表里的做法是验证语不放活动话术。默认:验证语只写门店名和来由,活动介绍留到通过之后的首触里讲。

5. 什么时间段加?

现状:夜里通过的 3 位,首触都拖到第二天上午才发,且都没回话;原因是夜里逐行核对停了(其中两晚程序报过电脑锁屏)。默认:先试一周在白天加,我们同时查清夜里核对为什么停;夜里样本只有 3 位,一周后看数据再定。

6. 人和系统各管哪一段?

现状:加好友、发申请由销售人工做;首触、日常回复和召回由系统做;转人工后的跟进回到销售。默认:维持这个分工,加人不交给系统自动做。

7. 我们能看到的上限在哪?

现状:系统只看得到聊天列表里出现过的客户,看不到每个微信的好友总数,也看不到每天发出了多少条申请。默认:销售每天在登记入口记一笔加了谁,好友总数每月在手机上看一次告诉我们。