他在江西。早上 07:45,在「苏等等的家」的视频底下留言「可以给我一份清单吗谢谢」,4 分 28 秒后破冰到达,6 分钟后他回了「三室一厅」— 开局非常顺。
然后对话撞上了一堵墙:他说「我微信现在用不了」,AI 回了一句漂亮的「vx 用不了咱就不折腾,我发你短信」,紧接着又要起了 vx。此后两个多小时里,他用六种说法重复同一件事 — 「微信用不了」「QQ 可以吗」「不是要我说多少遍」「过段时间」 — 而对面每一次都回同一段模板。
最后是运营看不下去,手动打了四个字「qq可以的」,他立刻给出 QQ 号 3499526727。而在那之后,AI 又自动发了两条「报个 vx 号给我」。
下面三块是这条案例的原始信号:他留评论的那条视频、七个字的诉求、以及两个半小时里 24 条来回的完整对话。这是本批最长、也是最难看的一条 transcript — 它完整记录了一个自动回复系统在遇到「客户提出替代方案」时会怎么失灵。
messages.role 显式判定,AI 10 / 客户 11)。截图补录 5 条:#14「?」、#15「不是要我说多少遍」、#21「行」为客户消息漏抓;#20「qq可以的🤗」与 #26「好」为运营手动发送,走的是人工操作、不经派单链路,因此不在 messages 表中。sent_at(已换算 CST);截图补录的 5 条无落库时间,按截图中的时间标签(08:08 / 09:57)与气泡顺序估算,页面已标注为约值。
纯看时效数字,这条案例是漂亮的:评论 07:45:07 → 破冰 07:49:35,4 分 28 秒;客户每次回复,AI 都在 90 秒左右接住,全程 12 次响应无一超过 2 分钟。但这条案例恰恰说明:当话术方向是错的,响应越快,伤害越大。
📌 本案的时效结论要反过来读:机器响应快不是好事,除非它响应得对。客户在 08:15 就问了「QQ 可以吗」,如果那一刻有人接手,这条对话 08:20 就能收尾;实际却是机器又快又准地复读了四遍,把客户逼出了「不是要我说多少遍」。真正该被压缩的时效指标不是「AI 多久回一句」,而是「AI 答不上来时,多久有人接手」 — 本案这个数字是 85 分钟。
这条对话可以从中间一刀切开。前半段(#1–#5)是本批质量最高的开局之一:破冰给户型钩子,跟进说见光板和封边,客户说微信用不了时立刻改口「咱就不折腾,我发你短信」。后半段(#9 起)则完全塌掉:同一段模板换着措辞发了 7 次,客户说什么都不影响它说什么。
「可以给我一份清单吗谢谢」— 索取动作明确,但没有任何房屋信息:不知道户型、面积、新旧、预算。句尾带「谢谢」,和同批「一个达不刘」一样,属于配合度高的类型。后来的事实也证明了这一点:他被机器复读了六轮都没有拉黑,还在耐着性子解释「微信用不了」。
intent_reason = 「问购·模糊·在调研」,comment_type_reason = 「索要清单,极简购买信号」):产品型 · 低 specificity · active。low — 两条评论其实几乎一样,说明这个维度的判定在极简评论上并不稳定。但从后续行为看,68 分低估了他:他不仅回了户型,还在被复读六轮后仍然愿意给联系方式。真正决定这条案例结局的不是评分,而是话术在遇到「客户提出替代通道」时完全没有分支。
#10 是整场对话的分水岭:「?微信用不了QQ可以吗」 — 客户不但重申了障碍,还主动提出了解决方案。这是一个高配合度信号:他想要这份资料,甚至愿意替我们想办法。此时只需要回两个字「可以」,对话就能立刻推进。
实际发生的是:#11、#13、#17、#19 连续四条,没有一个字提到 QQ,每条都以「报个 vx 号给我」结尾。
本案触达账号是「小星·全屋定制」(DB 内部账号名「零星」,聊天气泡右侧带金色「小星·全屋定制」徽章,运营归属夏夏)。截图顶部能看到抖音的「点关注,方便以后找到她」提示条,说明这是一次陌生人首触会话。本案的信任损耗不是发生在账号层,而是发生在对话层 — 复读把前面攒下的专业感一次性清零。
accounts.following_count(同步于 6-25)accounts 无粉丝 / 作品字段 · 需运营主页截图补数Akke 的地区信号分三层:客户 IP 属地(省)、自报现居(市)、号源服务市。本案只拿到省级 — 江西。但话术里「本地设计师」这四个字出现了整整六次,而我们既不知道他在江西哪个市,也没标记号源的服务城市。这是一句连自己都验证不了的承诺。
comments.ip_location · 抖音 IP 反查comments.city · 客户全程未提城市source_accounts.city · 「苏等等的家」标为本地号但市字段未入 → is_same_city = nullcity 字段是空的,导致 is_same_city 恒为 null,同城判定完全失效。同批的「誓水怜心」案例卡在同一个字段上。把号源城市补齐,是一次性解掉多条案例同一个问题的低成本动作。
两个多小时里没有出现任何单价或总价,价格信息全部是相对锚(工厂直供比门店低)+ 配置堆料(18mm 多层板、兔宝宝/莫干山/千年舟 ENF 板、悍高五金)。问题不在于说了什么,而在于同样这几句话被重复了四遍。
"评论入库 → 评分 → 起草 → 发送"在 DB 里是几行行变化,物理世界对应的是一台阿里无影云电脑上常驻的抖音客户端。发送侧正常:channel_pref = cloud_pc、队列零报错。但这条案例暴露了回读侧的两类缺口 — 客户情绪消息漏抓,运营手动消息完全不入库。
抖音 web DM 在 Fly Tokyo 出口被风控屏蔽,Akke 现阶段靠云电脑常驻 GUI 自动化触达:cron 派单进队列,云电脑上的 poll agent 拉单,用模板匹配 + SendInput 在抖音 PC 客户端里完成搜人、开会话、粘贴、发送。通道判定有硬证据 — accounts.channel_pref = "cloud_pc"(运营归属:夏夏)。但本案的两条关键消息(#20「qq可以的🤗」和 #26「好」)是运营在界面上手打的,不经这条链路,因此没有任何记录。
channel_pref = cloud_pcmin_send_interval_seconds = 30messagesstage = ice_break · handed_off_at = nullnext_followup_at / last_inbound_at 均为 null3499526727 虽然落进了 messages,但会话层没有任何「已获取联系方式」的标记,stage 仍是 ice_break。messages(标 role = human_operator),并进入 AI 上下文;②客户消息命中微信号 / 手机号 / QQ 号时写入会话联系方式字段并标 pending_handoff、停掉自动发送;③复核连发短消息场景的漏抓问题(本案客户在 08:24–08:25 连发三条,只抓到一条)。
3499526727 并在 10:08 确认「发你了QQ」。handed_off_at = null,而且自动流程在他给号之后还发了两条索要 vx 的消息。给上面 6 个分析模块各打一个评价。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 是这条链路的明显短板。本案是本批最有教学价值的一条 BAD 样本:开局质量很高,却因为「模板没有替代通道分支」把一个高配合度客户逼到了「不是要我说多少遍」。
city 未入库 → is_same_city = null,与同批「誓水怜心」卡在同一个字段上。channel_pref = cloud_pc,队列零报错零重试,21 条自动消息全部落库。3499526727 进了 messages,没有像同批案例那样丢掉联系方式。stage 仍是 ice_break、handed_off_at = null。role = human_operator)并进入 AI 上下文;②命中微信/手机/QQ 号即写会话联系方式字段 + 标 pending_handoff + 停自动发送;③复核连发短消息漏抓(本案 08:24–08:25 连发三条只抓到一条)。1491a244-…-a53ace72c7223b70a1-…-e086ab264e11 · stage ice_breakMS4wLjABAAAAnt6XMq…W3_vDu7655558671637079494 · 号源「苏等等的家」· 本地号 · tier 1(市未标记)channel_pref = cloud_pc)· ≥30s/条 · 含 2 条人工手发