湖北,早上七点十九分。她在「苏等等的家」的视频底下留了一句最普通不过的话 — 「可以发一份清单吗?谢谢」,连户型都没提。
五分钟后系统把破冰送到她私信里,开头没有喊她的名字,而是一句 「你这条评论我看了几遍」 — 这是全批 11 条案例里唯一一条放弃称呼、改用情绪价值开场的破冰。她 18 分钟后回了「四室两厅」,这是本批最大的户型。整条案例按 6 个模块复盘 — 做到位的与 还能拧紧的。
下面三块是这条案例的原始信号:她留评论的那条视频、那句只求清单的九个字、以及 24 分钟里 3 条来回的完整对话。对话很短,但每一句都很有得聊 — 先看全貌,再进入每个模块的拆解。
messages.role = ai,右侧紫色气泡);#2 来自 DB(role = customer,左侧灰色气泡)。本案 DB 3 条与手机聊天截图逐条对齐、无遗漏,不需要任何截图补录 — 这在本批里是少数。sent_at / created_at。抖音客户端截图上显示的时间戳与落库时间存在数分钟偏移(客户端只在间隔较大时插入时间标签),以 DB 为准。
这条评论是在清晨七点多留下的 — 一个人还在被窝里刷手机的时间点。系统没有等到上班,4 分 54 秒后破冰就送达了。随后客户 18 分钟回应,AI 又在 48 秒内跟上:三段间隔全部压在分钟级,是本批较快的一档。
📌 值得记住的一点:这条对话发生在早上 7 点半前后,运营还没上班。整条链路(采集 → 评分 → 起草 → 云电脑真机发送 → 客户回复 → 48 秒内自动跟进)没有一个人工环节。无人值守通道最大的价值不是省人力,是覆盖了人不在的那些时段 — 清晨、深夜、周末,这些时段的评论如果靠人排队处理,等回过去客户早就忘了自己问过什么。
本案内容侧的看点高度集中在一处:破冰的第一句话。同批 11 条案例清一色是「你好,XXX,刷到你…」的模板,只有这一条放弃了称呼,改用一句情绪化的表达开场。这个选择既是本案最漂亮的地方,也藏着一处需要说清楚的风险。
在「苏等等的家」的视频底下,她写下 「可以发一份清单吗?谢谢」。这句话给出的东西极少:①购买信号成立但很浅 — 「要清单」说明她在收集资料,处在调研期而不是决策期;②礼貌 — 带「谢谢」的评论通常意味着这个人愿意好好说话,回复率会比命令式提问高;③三个决策变量全缺 — 户型、面积、预算一个没给,甚至没说是新房还是老房。这是一条标准的、没有任何抓手的求清单评论,全网每天有成千上万条。
intent_reason = 「问购·一般·在调研」,comment_type_reason = 「极简购买信号,要清单」):产品型 · 中 specificity · active。首条 AI DM 在 transcript(#1)。整条只有 32 个字,但结构完整:问候 → 情绪价值 → 承诺给东西 → 反问。特别之处在第 ② 段,它替换掉了本该出现的「昵称」。
.Xun — 一个点加三个字母。把它硬塞进话术会变成「你好,.Xun,刷到你…」,读起来非常别扭,客户一眼就知道是机器拼的。这条破冰的处理方式是:干脆不叫名字,换一句「你这条评论我看了几遍」。客户只回了四个字,AI 在 48 秒内推出 #3。这条跟进比同批其他「清单换微信」的版本多做了一件事 — 把清单里到底有什么讲清楚了:不是含糊的「一份清单」,而是「同户型整套的设计要点」「工厂直供价」「层板数抽屉数这些容易加价的项也标得清清楚楚」。
本案的加微请求出现在第 3 条消息 — 全对话最早的一次。这意味着账号主页承受的信任检查压力比其他案例都大:客户在几乎没有交流积累的情况下被索要联系方式,第一反应必然是点开头像看这个号靠不靠谱。本案触达账号是「小星·全屋定制」(DB 内部账号名「零星」,聊天气泡右侧带「小星·全屋定制」金色徽章)。
accounts.following_count(同步于 6-25)accounts 无粉丝字段 · 需运营主页截图补数Akke 的地区信号分三层:客户 IP 属地(省)、自报现居(市)、号源服务市。本案只拿到最粗的省级,两个市级字段都是空的。话术侧的处理是 — 干脆完全不碰地区。这是安全的做法,但也意味着一整类信任牌没打。
comments.ip_location · 抖音 IP 反查comments.city · 客户全程未提所在城市source_accounts.city · 「苏等等的家」标为本地号但市字段未入 → is_same_city = nullcity 未入库,无法判定是否同城,"本地仓 / 本地安装队 / 上门量房"这类最强的信任锚一张都打不出来。对一个四室两厅的大单来说,"能不能上门量房"几乎是必问项 — 这张牌打不出来,损失比小户型大得多。建议补录号源城市字段。
本案对话未涉及价格话术 — 模块跳过。3 条消息里没有出现任何具体数字:#3 提到的「工厂直供价都列了」指的是清单文件里有价格,不是在对话里报价。客户也没有问价。
"评论入库 → 评分 → 起草 → 发送"在 DB 里是几行行变化,物理世界对应的是一台阿里无影云电脑上常驻的抖音客户端。通道判定有硬证据 — 账号 channel_pref = cloud_pc,不依赖运营本机的手机和数据线。
抖音 web DM 在 Fly Tokyo 出口被风控屏蔽,Akke 现阶段靠云电脑常驻 GUI 自动化触达:cron 派单进队列,云电脑上的 poll agent 拉单,用模板匹配 + SendInput 在抖音 PC 客户端里完成搜人、开会话、粘贴、发送。本案早上 7 点 24 分的发送,正是这套无人值守机制的直接产物 — 没有云电脑,这条评论只能排到运营上班后再处理。
channel_pref = cloud_pcmin_send_interval_seconds = 30
本案回写零丢失:2 条 AI 消息 + 1 条客户回复全部落进 messages 表,与手机聊天截图逐条比对完全一致。这在本批里是值得单独指出的 — 同批有案例因为客户三分钟内连发短消息,DB 只捕到最后一条,直接导致 AI 漏接了最高价值信号。
给上面 6 个分析模块各打一个评价。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 是这条链路的明显短板。
.Xun 硬塞进话术必然别扭,改成「你这条评论我看了几遍」,客户读到的是"被认真对待"而不是"被系统识别"。city 未入库:无法判定同城,"本地仓 / 本地安装队 / 上门量房"一张牌都打不出。channel_pref = cloud_pc 上常驻的 GUI 自动化。1aa15269-…-00f3704dadb019ce6aaf-…-ee3eead484c4 · stage ice_breakMS4wLjABAAAANe87…xShc7655558671637079494 · 号源「苏等等的家」· 本地号channel_pref = cloud_pc)· ≥30s/条