她在湖北。在灿哥聊装修的开工准备视频底下,她留了九个字 — 「求手册,麻烦给发一下」。一个「求」、一个「麻烦」,是这批客户里姿态最低、诉求最干脆的一条。
系统 3 分 50 秒内评分、起草、送达。她 1 小时后回了「三室一厅」,AI 1 分钟内跟上 — 但跟上的那句话是「你报个vx号给我」。她从此没再出现。
这条案例的价值在于它把一个共性病灶摆到了台面上:她付出了两次,一份资料都没拿到。整条案例按 6 个模块复盘 — 做到位的与 还能拧紧的。
下面三块是这条案例的原始信号:她留评论的开工准备视频、那句客客气气的九字索取、以及一个多小时里三条来回的完整对话。全部三条消息 DB 均已入库,与手机截图逐字一致 — 这条案例没有任何回写缺口,看到的就是全部。
messages.role = ai,右侧紫色气泡);#2 来自 DB(role = customer,左侧灰色气泡)。三条全部入库,无截图补录、无回写缺口,sender 按 DB role 字段判定而非启发式推断。sent_at / created_at。抖音客户端截图上显示的时间戳与落库时间存在数分钟偏移(客户端只在间隔较大时插入时间标签),以 DB 为准。
时效性是本案表现最干净的一环:09:53:56 她敲下评论,09:57:46 破冰已经进了她的私信 — 3 分 50 秒。她 11:01 回「三室一厅」,AI 11:02 就跟上,间隔 1 分 6 秒。
这一点必须先说清楚,因为本案最终没成 — 但失败的原因不在响应速度上。采集侧、调度侧、发送侧全部达标,问题出在话术内容,别把账算到链路头上。
📌 三段时延全部达标(触达 <4 分、跟进 <2 分),这是本案唯一无可挑剔的模块。但请注意:快,只保证了消息在正确的时间到达,不保证消息里装的是正确的内容。本案恰恰是"链路满分、内容失分"的典型样本 — 下一个模块会解释为什么这条 1 分钟内跟上的回复,反而把人跟丢了。
内容侧是评分模型 + 破冰话术生成共同决定的:客户留了什么、系统看到了什么、AI 写了什么。本案在称呼处理上有一个值得单独拎出来讲的正面细节,也在索要微信的时机上暴露了全批共性的病灶。
在灿哥聊装修的开工准备视频底下,她写下 「求手册,麻烦给发一下」。这九个字里有三件事值得注意:①一个「求」字 — 索取意愿明确到不加掩饰,不是「有吗」「怎么领」这种试探;②一个「麻烦」 — 态度客气、零讨价还价,不带任何对抗性;③诉求单一且封闭 — 她要的就是那份手册,没有附加问题、没有比价、没有质疑。
这类客户是「资料换微信」打法的理想目标:动机纯粹、门槛低、只要东西到手就愿意继续。但硬币的另一面是 — 正因为诉求单一,一旦资料迟迟不到手,她也走得最快。她要的是手册,不是聊天。给不了手册,这段关系就没有别的支点。
intent_reason = 「问购·一般·在调研」,comment_type_reason = 「求手册是极简购买信号」):产品型 · medium specificity · active。首条 AI DM 在 transcript(#1)。她要手册,破冰就顺着她的诉求答应给、再加码、最后反问一个最容易答的问题:
唯一一条跟进(#3)在结构上其实写得不差,它做了三件事:接住户型 → 抛专业钩子 → 解释为什么要微信 → 索要微信。前两步是加分项,后两步是本案的转折点。
本案对信任度的要求比一般案例更高 — 因为 #3 直接开口要微信号。客户在决定要不要给微信之前,几乎一定会点头像看主页。触达账号是「小星·全屋定制」(DB 内部账号名「零星」,聊天气泡右上角带金色「小星·全屋定制」徽章)。她最后没给微信,主页这一层能不能排除嫌疑,目前没有数据可以回答。
accounts.following_count(同步于 6-25)accounts 无粉丝字段 · 需运营主页截图补数Akke 的地区信号分三层:客户 IP 属地(省)、自报现居(市)、号源服务市。本案三层里只拿到最粗的一层 — 湖北,而且对话从头到尾一个字都没提地区。
comments.ip_location · 抖音 IP 反查comments.city = null · 客户全程未提所在城市source_accounts.city · 「灿哥聊装修」为知识号、市字段未入 → is_same_city = nullcity 本来就难标。这意味着从知识号进来的 lead,结构性地拿不到同城信任锚,话术必须靠专业度而不是地缘来立信任。本案的「见光板单收」钩子恰好走的就是这条路,方向是对的。
本案对话未涉及任何具体报价 — 没有单价、没有总价、没有活动价。唯一沾到"钱"的表述是 #3 里那句「见光板和封边这两项很多家是单收的」。这不是价格模块跳过,而是一次刻意且正确的价格回避。
"评论入库 → 评分 → 起草 → 发送"在 DB 里是几行行变化,物理世界对应的是一台阿里无影云电脑上常驻的抖音客户端。本案是 Akke 通道演进后的样本:账号 channel_pref = cloud_pc,不再依赖运营本机的手机和 ADB 线。而且 — 三条消息全部回写成功,与截图逐字一致。
抖音 web DM 在 Fly Tokyo 出口被风控屏蔽,Akke 现阶段靠云电脑常驻 GUI 自动化触达:cron 派单进队列,云电脑上的 poll agent 拉单,用模板匹配 + SendInput 在抖音 PC 客户端里完成搜人、开会话、粘贴、发送。通道判定有硬证据 — accounts.channel_pref = "cloud_pc"。
channel_pref = cloud_pcmin_send_interval_seconds = 30
对话共 3 条(AI 2 + 客户 1),全部进了 messages 表,内容与手机截图逐字一致。对照同批出现过"客户连发短消息被漏捕"的案例,本案的回写是干净的 — 这也让本页的分析不需要任何截图补录,看到的就是 DB 里的全部。
queue_attempts 为空handed_off_at、无 next_followup_at。
给上面 6 个分析模块各打一个评价。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 是这条链路的明显短板。
本案的分布很说明问题:工程侧几乎满分,内容侧是唯一的失分点 — 这不是系统跑不动,是话术策略把一个客气、低姿态、动机纯粹的客户推走了。
next_followup_at 为空,没有任何自动补触达兜底。@℘₁̶₃̶₁̶₄̶এᰔᩚ傻丫 里只抠出可读的「傻丫」,既躲开了乱码入话术的尴尬,又叫中了她自己认的那个名。可固化成规则:符号昵称抽可读中文片段,抽不出就不带称呼。comments.city = null、号源「灿哥聊装修」city 未标记 → is_same_city = null。city 天然难标,这类 lead 要靠专业度立信任的路径应固化下来。channel_pref = cloud_pc,不再依赖运营本机手机和 ADB 线。queue_attempts 为空、无重试无报错。handed_off_at / next_followup_at 均为空 — 客户静默后没有任何自动兜底动作,链路"跑通"但没有"跑完"。76859092-…-1049db9fc92ddc7d2d04-…-8286a43004e0 · stage ice_breakMS4wLjABAAAA7k0Q…RzTao7642675465907391759 · 开工准备 5 样 · 号源「灿哥聊装修」(知识号)channel_pref = cloud_pc)· ≥30s/条