她在安徽。在「我得装修日记」的视频底下,她只问了一句 「柜子那个胡桃木是什么颜色的」 — 一个模糊的产品问色。
系统 3 分 50 秒 就把破冰发到她手机,直接答清胡桃木色调、再反问全屋还是局部;她随后自曝电视柜/茶几/浴室柜/餐桌一套同色系、给了 100 平多层户型,几十分钟后 直接留下手机号当微信。这是一条中意向评分(68)却跑出强转化的案例 — 按 6 个模块复盘 做到位的 与 还能拧紧的。
下面三块是这条案例的原始信号:留评论的视频、那句问色的评论、以及当天下午 10 条来回的完整对话。先看全貌,再进入每个模块的拆解。
messages 2 条 AI + 2 条客户);中间 6 条 #2 / #3 / #6 / #7 / #8 / #9 均未入库 —— 包含最关键的加微钩子 #7 与客户给号 #8。这正是无影云电脑网页版 DM 通道 capture / 回写不完整的表现。完整 10 条以手机聊天截图为准。sender 按截图气泡侧判定(蓝色气泡带「有」头像在右 = akke「有大有小」,客户头像在左 = user),非启发式推断。
时效性是 Akke 链路最先体现的工程指标,本案是正面样本:评论 17:01:43 留下,触达 17:05:33 发出,全程 3 分 50 秒 —— 抓取、打分、生成话术、派单、发送全在 4 分钟内串完,达标线(评论→触达)轻松守住。破冰直接答清她问的胡桃木色调,客户 14 分钟后就自曝了一套同色柜需求,正是"评论还热着就被接住"的节奏在起作用。
📌 本案是时效达标的正面样本:评论→触达 3m50s 远快于达标线,说明采集→评分→派单→发送的自动链路在状态良好时能稳定做到分钟级。可复用经验 —— 把这条链路的稳定性常态化,是高转化的隐性地基。
内容侧是评分模型 + 破冰话术生成共同决定的:客户留了什么、系统看到了什么、AI 写了什么。本案有意思的点 —— 评分只有 68(中意向),实际转化力却跑赢了分数:一句模糊问色,被破冰答清 + 跟进钩子稳稳推到了留手机号。
在我得装修日记📔(号源池里类目「业主日记」的装修号)的视频底下,她写下 「柜子那个胡桃木是什么颜色的」。一句话暴露 2 件事:①已锁定材质 —— 盯着「胡桃木」问,材质方向明确;②在做柜子调研 —— 关心配色说明在为自家柜子做功课。但面积、房型、预算、买几件全没给,纯问一个颜色,所以系统给到 low specificity、68 分中意向 —— 信号真,但变量极少。
首条 AI DM 在 transcript(#1)。客户只问一个颜色、变量全无,破冰的任务是先把问的色答到位(接住问题、显专业)+ 反问缺失的关键变量,把对话往前推。
跟进链在 transcript(#3 / #5 / #7)。客户自曝一套同色柜后,AI 分三步推进:①顺需求做卖点「同一支胡桃木暖调整屋统一,比成品东拼西凑高级」+ 专业解答浴室柜防潮;②接住痛点抛钩子——客户说「客厅有点大」,AI 回「大客厅容易空、靠柜子和布局撑」再抛"发案例参考";③钩加微「抖音图会压缩看不清,把微信发我,今天就把整套案例和方案发过去」。
DM 进入之后,客户的第一反应是点头像验证身份。本案触达账号是内部 messaging 账号「有大有小」 —— 一个偏工具化、非品牌化命名的账号。能不能扛住"主页一眼信任检查",决定她愿不愿意继续往下聊。
Akke 的地区信号分三层:客户 IP 属地(省)、自报现居(市)、号源服务市。本案省级安徽在手,却全程没用上 —— opener 和跟进都没提省、没打方言、同城徽章也没触发。这是一处被浪费的信号。
comments.ip_location · 抖音 IP 反查comments.city · 客户未自填source_accounts.city · 号源 city 未入 → is_same_city = null本案对话全程没有任何数字报价、计价方式或预算话题 —— 客户问的是颜色和能不能看方案,AI 答的是"留微信我把整套案例发你"。价格 friction 被完全后置到加微之后,所以本模块按规范跳过价格拆解,只记录这条策略选择与其中的一个价值锚。
"评论入库 → 评分 → 起草 → 派单 → 发送"在 DB 里是几行行变化,但物理世界对应的是无影云电脑上的浏览器网页版 DM 自动化。本案前半段做得干净(评论→触达 3m50s 入库),教训在后半段:客户给手机号的关键链路(#7–#9)连同另外 3 条全部没回写 DB,reconcile 负担落到人工。
抖音 web DM 在 Fly Tokyo 出口被风控屏蔽,「有大有小」这类只在网页版操作的号,走的是无影云电脑上的浏览器(DOM)网页版 DM 通道。本案首条破冰(#1)走完整自动链路 —— 抓取→评分→生成→派单→触达全程入库、评论后 3m50s 发出,由账号「有大有小」承接。问题出在后半段:10 条对话 DB 只回写了 4 条(#1/#4/#5/#10),中间 6 条 —— 尤其加微钩子 #7 + 客户给号 #8 + 收尾 #9 —— 全丢,DB stage 失真为 ice_break,last_inbound_at 也为空。
本案通道已经在无影云电脑上常驻,速度也够(opener 3m50s),真正的短板是网页版 capture / 回写不完整。加固不是"换机器",而是把捕获→入库→回写这一段做原子、做全:
给上面 6 个分析模块各打一个评价。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 是这条链路的明显短板。
city 补录以备同城锚。last_inbound_at 空,可能被重复 claim 触达。71d1314b-…-4e8230f3cc0ca3d3614b-…-ef1c353b7e62 · stage ice_break(失真)MS4wLjABAAAA6cmv…apec7655285255800920314 · 号源「我得装修日记📔」业主日记