本周完整统计 10-15 00:00 至 10-21 24:00（北京时间），以上周 10-08..10-14 为背景：新加了多少客户、首触是否及时、客户有没有回话，以及前三个卡点的处理进度。
销售 A / B / C：门店三位销售各自的微信号，用三台 Windows 电脑由 AI 辅助接待。新客：好友通过记录一条算一位（同一人两条记录合并）。首触：客户通过好友后我们发出的第一条消息，现在是固定模板文字加 2 张海报。首触时延：通过到首触发出的分钟数。客户回话：通过之后客户发过的消息，剔除「我通过了你的朋友验证请求」等系统提示。转人工：系统停止自动回复，交给销售本人。端上版本：销售电脑上运行的程序版本，电脑端的修复要装上新版本才生效。
10-19、10-20 各确认 4 位，10-21 确认 1 位。10-15 至 10-18 没有通过记录，但销售逐日登记从 19 日才开始，不能据此断言前四天完全没有加人。截至 21 日结束，6 位有首触记录的客户（24、25、27、28、29、30）均已满 24 小时，系统记录回话为 0；样本小且人工聊天回传不全，不能直接认定客户都没说话，也不能与上周更长观察期的开口率作升降比较。
| 窗口 | 新客 | 有首触 | 首触时延 中位 / 最长（分钟） | 客户回话（记录） | 召回已发 | 召回后回话 |
|---|---|---|---|---|---|---|
| 上周 10-08..10-14（原页快照） | 21 | 13 | 39 / 773 | 10 | 14 | 6 |
| 本周 10-15..10-21 | 9 | 6 | 49 / 574 | 0 | 2 | 0 |
| 两批合计（观察期不同） | 30 | 19 | 43 / 773 | 10 | 16 | 6 |
首触时延只统计通过时刻和首触时刻都有精确记录的客户（上周 12 位、本周 5 位）。10-08 没有任何新客记录。本周记录截至 10-21 24:00；上周批次的回话和召回效果保留 10-21 下午原页快照，不能作为同等观察期对比。召回后回话不限 7 天，不等于成交。
| 日期 | 发起好友申请 | 通过好友 | 通过人数 A / B / C | 同期通过率 |
|---|---|---|---|---|
| 10-19 | 44 | 4 | 2 / 1 / 1 | 9.1% |
| 10-20 | 44 | 4 | 0 / 3 / 1 | 9.1% |
| 10-21 | 32 | 1 | 0 / 1 / 0 | 3.1% |
| 合计 | 120 | 9 | 2 / 5 / 2 | 7.5% |
通过率 = 同期通过好友人数 ÷ 实际发起好友申请次数。三天合计为 9 ÷ 120 = 7.5%，不取每日通过率的简单平均。客户可能跨日通过，因此这里展示同期通过率，不代表这 120 次申请的最终通过结果。数据按销售逐日汇总核对。
| 通过日 | 账号 | 新客 | 有首触 | 首触时延 中位 / 最长（分钟） | 回话（截至 21 日） | 召回已发 | 召回后回话 |
|---|---|---|---|---|---|---|---|
| 10-15..10-18 | 三台 | 0 | — | — | — | — | — |
| 10-19 | 销售 A | 2 | 1 | — | 0 | 0 | 0 |
| 销售 B | 1 | 1 | 574 / 574 | 0 | 0 | 0 | |
| 销售 C | 1 | 0 | — | 0 | 1 | 0 | |
| 10-20 | 销售 B | 3 | 3 | 49 / 272 | 0 | 0 | 0 |
| 销售 C | 1 | 1 | 28 / 28 | 0 | 0 | 0 | |
| 10-21 | 销售 B | 1 | 0 | — | 0 | 1 | 0 |
只列本周 10-15..10-21；10-14 及以前见上周汇总和 10-14 版。没列出的日期 × 账号均无通过记录。6 位有首触记录的客户均观察满首触后 24 小时，尚未满 72 小时；不把未满观察期写成 72 小时回话率 0%。定制安卓手机（APK）没有好友通过记录，新客数不在本页统计范围内。
验收建议：通过后自动登记、30 分钟内发首触；未回话客户按现行召回规则跟进（本页案例最早为首触后的第 2 个自然日），不把“24 小时未回”写成当前已执行的发送规则；人工与 AI 的发送记录均能核对。下面每位客户一行数据，下一行是标注：彩色标签是问题类别，后面写实际发生了什么、原因是什么。时间都是北京时间；客户消息、AI 回复按系统记录计数，发送与消息计数截至 10-21 24:00；逐条原因沿用原页 10-21 22:20 核查记录。
| 编号 | 客户标识 | 通过 | 账号 | 首触 | 客户消息 | AI 回复 | 召回 | 召回后回话 | 现在 |
|---|---|---|---|---|---|---|---|---|---|
| 客户23 | 匿名客户 | 10-19 22:18 | 销售 A | 销售手发 | 0 | 0 | 0 | — | 销售已接手 |
| 被当成老客户销售接手后看不到 程序自动记下了通过（10-19 22:18），但第二天 10:02 点开她时没有发首触，而是建了一条召回任务；运营核实销售已经手发过首触后，把召回取消了。10-20 13:35 销售手打了一句活动价，系统随即转人工。这句价格和首触模板里的价格不是同一组数字，待和销售核对。客户说过什么没进系统。原因：程序判断「是不是刚通过的新好友」，只看聊天最下面是不是系统灰字；销售先手发了首触，最下面变成我方消息，程序就按老客户处理（与客户31 同一个问题，推测，未逐条查日志）。销售在微信里的对话不回传系统。 | |||||||||
| 客户24 | 匿名客户 | 10-19（无时刻） | 销售 A | 17:45 已发 | 0 | 0 | 0 | — | 破冰 |
| 未见回话记录召回到期没发通过没自动记 程序 10-19 17:45 发了首触（模板 + 2 张海报），系统未见客户回话。通过时刻程序没记下，是按截图补录的日期，所以算不出首触时延。按规则 10-21 起可以召回，截至 21 日结束未发出；销售 A 电脑当天 13:27 后停止上报。最新进度：现场已确认升级至 1.25.51，自动登记通过的修复已包含在该版本中；截至 22 日 14:08，系统尚未收到新的状态上报，召回恢复和自动登记效果仍待回验。 | |||||||||
| 客户25 | 匿名客户 | 10-19 23:39 | 销售 B | +574 分钟 | 0 | 0 | 0 | — | 破冰 |
| 首触晚未见回话记录 夜里 23:39 通过，程序第二天 09:13 才发首触（+574 分钟），系统未见客户回话。按规则召回最早在首触后的第 2 个自然日，也就是 10-22 起才能发。原因（推测，未查日志）：首触已在 10-19 改成不限时段，但电脑夜里巡检只点有新动静的行，刚通过的好友这一行夜里没被点开，要等早上正常巡检。 | |||||||||
| 客户26 | 匿名客户 | 10-19（无时刻） | 销售 C | 无，发成了召回 | 0 | 0 | 1 | 否 | 破冰 |
| 被当成老客户没有首触通过没自动记 10-19 16:42 程序第一次点开这位，没认出是新好友，16:50 发了一条召回介绍（讲我们和传统定制的区别），没有首触，也没有记通过（之后按截图补录）。系统未见客户回话。10-21 14:07 程序又发了一条召回，发完微信显示红色感叹号（发送失败，或对方已不是好友、需要重新验证），这条不算送达，任务已作废；客户是否已删除好友待销售看一眼。原因同客户31。 | |||||||||
| 客户27 | 匿名客户 | 10-20 11:36 | 销售 C | +28 分钟 | 0 | 0 | 0 | — | 破冰 |
| 未见回话记录通过靠补录 11:36 通过，12:04 首触（模板 + 2 张海报），首触时延在本周最短，系统未见客户回话。通过和首触记录都是按截图补录的，程序当天有没有先记下待核实。召回 10-22 起才到时间。自动记通过的修复（1.25.48）销售 C 电脑 10-21 才装上，这位通过时还没有。 | |||||||||
| 客户28 | 匿名客户 | 10-20 16:41 | 销售 B | +49 分钟 | 0 | 0 | 0 | — | 破冰 |
| 程序没看到这位未见回话记录 16:41 通过，17:30 首触，系统未见客户回话。程序当天一直没有给她建会话，通过、首触都是 10-21 按截图手工建档补进系统的；首触大概率是销售手发，系统里分不出。原因：自动记通过的修复当时没装；程序没点开她的原因未查。 | |||||||||
| 客户29 | 匿名客户 | 10-20 16:49 | 销售 B | +41 分钟，销售手发 | 0 | 0 | 0 | — | 破冰 |
| 被当成老客户未见回话记录通过靠补录 16:49 通过，销售 17:30 手发首触。17:32 程序点开她，没认出新好友，建了一条召回任务；运营核实后取消，没有发出。系统未见客户回话。原因同客户23。 | |||||||||
| 客户30 | 匿名客户 | 10-20 18:22 | 销售 B | +272 分钟 | 0 | 0 | 0 | — | 破冰 |
| 首触晚未见回话记录通过靠补录 16:48 发出好友申请，18:22 客户通过，22:54 才首触（+272 分钟），系统未见客户回话。程序 22:55 才建会话，通过记录是按截图补录的（程序有没有先记下待核实）。原因：通过后 4 个半小时程序才点开这一行，这期间电脑在忙什么未查；首触是谁发的（程序还是销售）系统里分不出。 | |||||||||
| 客户31 | 匿名客户 | 10-21（无时刻） | 销售 B | 无，发成了召回 | 0 | 0 | 1 | 否 | 破冰 |
| 被当成老客户没有首触通过没自动记 10-21 通过，11:58 程序第一次点开她。聊天里只有我方的申请验证语和一行灰字「你已添加了…」，程序没认出新好友，12:00 发了一条召回介绍，没有首触，也没记通过（之后按截图补录）。原因（已查电脑日志）：程序判断新好友时，先看聊天最下面一块是不是居中的系统灰字；这次那一块像素没判出是居中，程序就跳过了，日志里没有读灰字的记录。原因已定位，编号 W-126，正在修，修好后出新版本。 | |||||||||
召回：首触后客户没回时补发的那条消息，按已发出计。客户24、26、31 的「通过」一列只有日期，是因为程序没记下通过时刻、按运营截图补录。「AI 回复」只算回复客户消息的条数，不含首触、召回和销售手打。9 位客户在系统里都没有客户消息；客户23 销售手打过一句报价，说明存在人工沟通，但不能据此证明客户一定回过话；需以微信原记录核对。
| 类别 | 人数 | 哪几位 | 原因与处理 |
|---|---|---|---|
| 新好友被当成老客户：发了召回或建了召回任务，没发首触 | 4 | 23、26、29、31 | 程序只靠聊天最下面是不是系统灰字来认新好友；最下面是我方的验证语或销售手发的首触时认不出。26、31 召回已经发出去了，23、29 是运营看到后取消的。原因已定位（W-126），正在修，修好后出新版本。 |
| 通过记录靠截图补录 | 7 | 24、26、27、28、29、30、31 | 程序自动记下的只有 23、25 两位；24、26、28、31 确定程序没记，27、29、30 程序有没有先记过待核实。自动记通过的修复（#2331，1.25.48）10-21 在销售 B、C 电脑装上；最新现场确认 A 已升级至包含该修复的 1.25.51，运行效果待回验；31 没记通过是因为没认出新好友，属于上一行的问题。 |
| 首触晚（超过 2 小时） | 2 | 25、30 | 25 夜里通过，夜里巡检没点开这一行；30 通过后 4 个半小时才被点开，原因未查。 |
| 首触后未见回话记录 | 6 | 24、25、27、28、29、30 | 系统里记的首触都是同一套模板文字 + 2 张海报。截至 21 日结束，这 6 位首触均已满 24 小时，系统回话 0/6；样本小且人工回传不全，仍不能与上周更长观察期直接比较。 |
| 召回到期没发 | 1 | 24 | 销售 A 电脑 10-21 13:27 后停止上报。最新已确认升级至 1.25.51，发送恢复待回验。25、27、28、29、30 的召回 10-22 起陆续到时间，不计入本周到期未发。 |
| 销售接手后看不到 | 1 | 23 | 销售在微信里的对话不回传系统，客户问了什么、销售怎么回的看不到。 |
一位客户可以同时落在几类里，所以各类人数相加大于 9。客户26、31 没有首触，算在「当成老客户」里，没再算进「首触后未见回话记录」。
下面每个卡点写现象、依据和处理进度。最新进度：销售 A 已升级至 1.25.51（现场确认）；截至 10-22 14:08，系统尚未收到 A 的新状态上报，最后一次仍停在 10-21 13:27，升级后的运行与发送恢复待回验。B、C 最新上报版本分别为 1.25.53、1.25.55。以上为本次补充的最新进度；本周业务数据仍统计到 10-21 24:00。
依据：本周确认新客 9 位，上周记录 21 位，记录量减少 57.1%。10-19..21 销售登记搜索 148 次、申请 120 次、通过 9 位；前四天缺少销售登记，不能据此认定无人加友。7 位的档案靠截图补录，自动登记完整性尚未验收。申请量、验证语和通过情况要按同一批申请持续跟踪，才能判断获客环节的具体原因。
| 已做 | 状态 |
|---|---|
| 销售加友每日汇总：按电脑按天统计搜索、申请、没搜到、通过，算申请率和通过率（#2255） | 已上线 |
| 销售加友登记接口 + 「是否通过」自动回填（#2224、#2227） | 已上线 |
| 添加好友记录只读接口，供看板查看每位的申请、通过、首触（#2303） | 已上线 |
| 程序自动记通过的窗口放宽到 3 天，与首触对齐（#2261，1.25.28） | 三台已装 |
| 「通过」系统提示被新消息顶出屏幕时往上翻找，按提示日期记通过（#2331，1.25.48） | B、C 已装 · A 已确认升级，待回验 |
验收（拟）：装上新版本后，程序自动记下的通过数和销售登记一致，不再需要补录。
依据：4 位新客曾被当成老客，2 条召回已发、另 2 条由运营取消。6 位有首触记录，5 位能精确计算时延，中位 49 分钟，最长 574 分钟，另有 272 分钟的一位。首触满 24 小时的 6 位系统回话为 0；目前仍是同一套模板加 2 张海报。原页历史参考（9-22..10-20）：模板首触 24 小时回话 7/45，先问城市版本 0/17，非随机分组，不能直接认定哪版更好。
| 已做 | 状态 |
|---|---|
| 首触补了三处缺口（#2226）；首触不再限制时段，凌晨通过也当场发（#2229） | 已合并 · 效果待核 |
| 会话建了超过 3 天还没有任何消息时，服务端不再发首触（#2266） | 已上线 |
| 召回在等发送名额时，电脑扫描会话列表时继续找该发首触的人（#2252） | 已合并 |
| 新好友误判为老客户（W-126，原页 10-21 22:20 记录） | 原因已定位 · 修复与实机验收待完成 |
| 模板首触和自由开场的效果对比 | 未开始 |
下一步：给每条首触打上模板、改写模板、自由开场三类标记，剔除客户先开口的会话，积累两周（拟）后按 24 小时和 72 小时回话率出对比。换开场白的实验（短问候 + 一个问题、海报放到第二条）要甲方先同意。
依据来自上周新客及存量会话（不是本周 9 位新客的失败人数；沿用 10-21 原页逐条核查）：有客户问了多个问题只被答了一个（客户08 首触后问见光板和柜门，AI 只答了柜体板材）、AI 回复被自动安全检查整条拦下（新客里 3 位：客户16、19、08）、到店意向没识别（客户03）；转人工以后销售在微信里手动回的消息不进系统，看不到客户是否被接住（客户03、04、06）。10-21 销售 C 一段会话里，销售手打的 4 条仍没进库。
| 已做 | 状态 |
|---|---|
| 见光板价格：跨句也认官方价，另算时补上官方价（#2158、#2337） | 已上线 |
| 客户说不打算过去、以后再到店时，不再判成已到店（#2176） | 已上线 |
| 销售在电脑上手发的消息（含图片）由程序扫描会话时补记入库（#2254） | 已装 · 10-21 有 4 条没进库，在查 |
| 转人工后客户在等回复，监控群推提示卡（#2277） | 已上线 |
| 转人工的客户再开口时提醒销售（#2228） | 已合并 · 开关默认关 |
| 销售让位后没人接，到点由 AI 接回（#2246） | 已装 |
| 客户正在聊的时候不插召回（#2225） | 已上线 |
转人工的对接：双方已经建了微信沟通群，转人工的客户直接在群里对接。验收（拟）：开口客户 30 分钟内有 AI 或销售回复，销售手发消息全部进库。
新客：好友通过记录一条算一位，按客户去重（客户07/09 合并）；通过日按北京时间，没有精确时刻的用人工补录的日期。首触：以好友生命周期表的首触发送时间记录计数，可能含销售手发和截图补录；客户23虽有人工首触证据，但缺少首触时间字段，未计入6位。客户回话：通过之后客户的消息，剔除系统提示整行；本次 24 小时观察统一从首触发送时间算；6 位均已满 24 小时，尚未满 72 小时。历史快照沿用原口径，不能与本次直接作同观察期对比。销售在手机上的回复无法单独识别，没有剔除，回话数可能略高。召回已发：召回任务状态为已发送的客户数。周：上周 10-08..10-14，本周 10-15 00:00 至 10-21 24:00（北京时间，等价于截至 10-22 00:00 之前）。
处理进度：PR 编号对应代码仓的合并记录；「已上线」指服务端改动已合并进主干（服务端合并后自动部署）；「已装」按客户端上报或现场确认标注；本次 A 为现场确认升级至 1.25.51，服务端仍无新上报，运行效果待验证；B、C 版本已按 10-22 14:08 查询结果更新。