他在贵州。凌晨 00:45,在「灿哥聊装修」的开工必备清单视频底下留了两个字:「跪求」。
破冰 3 分 44 秒后送达,他 5 分 27 秒后回了两个字:「新房」。AI 在 48 秒内接住,用一句「水电前定柜体能省后期改管钱」把清单的价值说清楚,然后要了微信。
4 分 25 秒后他就报出了号码。从评论到拿到联系方式,全程 14 分 24 秒,中间他只打了四个字。
但这四个字也意味着:户型、面积、城市、预算,我们一个都不知道 — 而跟进里已经承诺了「按你户型可直接套用」。
下面三块是这条案例的原始信号:他留评论的那条视频、凌晨敲下的两个字、以及十六分钟内跑完的完整对话。这条案例值得看的地方是「极低信息量下的高转化」 — 客户全程只输出了「跪求」「新房」和一串微信号,我们却在第二轮就把联系方式拿到了。效率极高,但也意味着我们对他家一无所知。
messages.role = ai;#2 / #4 来自 DB messages.role = customer。本案五条消息全部落库,没有靠截图补录、也没有靠气泡颜色或坐标猜归属,这是本批捕获质量最完整的一条。sent_at,客户两条取 created_at(入站消息无 sent_at),均已换算 CST。h863474134 原样展示 —— 本页是内部销售协同用,手机号/微信号按团队规则保留明文,方便销售直接取号加微。
评论 00:45:57 → 破冰 00:49:41,3 分 44 秒;破冰 → 首响 5 分 27 秒;首响 → AI 跟进 48 秒;要微信 → 客户给号 4 分 25 秒。四段全部在个位数分钟内完成,链路没有任何一处成为瓶颈 — 客户还在刷手机的那个时间窗里,我们把整件事跑完了。
📌 这条案例是「深夜在线窗口」价值的直接证据:客户 00:45 还在刷装修视频,说明他此刻正处在主动找信息的状态,而不是白天被工作切碎的碎片时间。凌晨触达的接通率不该被想当然地打折 — 本案 5 分 27 秒的首响比同批很多白天案例还快。真正需要注意的是另一端:客户 01:00 给完微信后,销售侧大概率已经下班,加微动作要等到早上,这中间的几个小时是这条链路目前唯一的空档。
客户只说了「新房」两个字,跟进(#3)却没有停在"好的那我发你",而是先讲了一条真实的工艺逻辑:新房开工阶段柜体要在水电之前定下来,否则管线预留不上、后期改管要花钱。这句话把"要一份清单"这件小事,变成了"再不定就来不及"的时间成本问题 — 而且它是真的,不是编出来的紧迫感。
「跪求」— 全部内容就这两个字。①意图极强:不是「不错」「学习了」这类围观,是明确的索取动作,而且用了很重的措辞;②指向明确:他求的是视频里那份开工必备清单,我们知道该给什么;③信息为零:户型、面积、城市、预算、进度,一个字都没有。这是一条典型的「意图满格、画像空白」评论 — 好接,但接住之后要靠对话把画像一点点问出来。而本案没有问。
intent_reason = 「问购·一般·在调研」,comment_type_reason = 「极简购买信号跪求」):产品型 · 中等 specificity · active。首条 AI DM 在 transcript(#1)。结构完整,最关键的是③ 兑现承诺这一段和他"跪求"的东西是同一样东西 — 他求清单,我们说发清单,中间没有偷换成"免费出方案""上门量房"这类他没要过的东西。
跟进(#3)是四段结构:工艺理由 → 承诺物具体化 → 要 vx → 摩擦解释。四段全部踩到点上,客户 4 分 25 秒就报了号。
本案触达账号是「小星·全屋定制」(DB 内部账号名「零星」,聊天气泡右侧带金色「小星·全屋定制」徽章,运营归属夏夏)。从收到「报个 vx 号」到报出号码,中间只有 4 分 25 秒,期间没有任何一句试探 — 没问是哪家公司、没问在不在贵州、没问要不要钱、也没点进主页问一句「你们做过什么案例」。
accounts.following_count(同步于 7-21)accounts 无粉丝 / 作品字段 · 需运营主页截图补数daily_limit = 30 · 节流 min_send_interval_seconds = 30Akke 的地区信号分三层:客户 IP 属地(省)、自报现居(市)、号源服务市。本案只拿到省级 — 贵州。市级两端全缺:客户没说城市,号源「灿哥聊装修」是知识号、没有服务市。整段对话里一个地名都没出现过。
comments.ip_location · 反映的是他发评论时人在哪comments.city · 客户全程未提城市source_accounts.city · 「灿哥聊装修」类目为知识号(全国流量)→ is_same_city = nullis_same_city 恒为空不是数据缺失、而是号源性质决定的。在这种情况下打「本地仓/本地安装队」牌是危险的 — 说错了直接暴露我们在猜。本案两条 AI 消息一个地名都没出现,避开了这个坑。
本案对话未涉及任何具体报价:客户没问价,AI 也没报。这是本案该有的处理 — 在只知道"新房"两个字、连户型都不清楚的情况下报数字,只会给后面留一个兑现不了的坑。但价格话题并非完全缺席:跟进里那句「能省后期改管钱」是一个省钱方向的锚,它把我们的价值定在了"帮你少花钱"这一侧。
"评论入库 → 评分 → 起草 → 发送"在 DB 里是几行行变化,物理世界对应的是一台阿里无影云电脑上常驻的抖音客户端。本案两侧都正常:发送侧 channel_pref = cloud_pc、队列零报错;回读侧五条消息全部落库,连微信号都抓进来了 — 这是本批捕获质量最好的一条。问题出在再下一层:消息进来了,字段没跟上。
抖音 web DM 在 Fly Tokyo 出口被风控屏蔽,Akke 现阶段靠云电脑常驻 GUI 自动化触达:cron 派单,云电脑上的 poll agent 拉单,在抖音 PC 客户端里完成搜人、开会话、粘贴、发送,并把捕获到的回复写回 DB。通道判定有硬证据 — accounts.channel_pref = "cloud_pc"(运营归属:夏夏)。
channel_pref = cloud_pcmin_send_interval_seconds = 30message_queue 无失败重试记录客户实际发了 2 条(「新房」+ 微信号),DB 落了 2 条,捕获率 100% — 对照同批那条把微信号漏抓、反而把抖音「可点亮火花」提示存成客户发言的案例,这次干净得多。但会话层的结构化字段一个都没有动。
messages.content 形式存在customer_profile 为 {},无联系方式字段stage = ice_break · handed_off_at = nullnext_followup_at / last_inbound_at 均为 nullstage = ice_break、handed_off_at = null —— 一个"聊过、没结果、可以再催"的对象。stage 推到 pending_handoff、停掉所有自动跟进;stage = ice_break,5 条消息(AI 3 / 客户 2)全部入库,客户微信号已随 messages 落库;handed_off_at、next_followup_at、customer_profile 均为空。h863474134(已随 DB messages 落库,销售可直接取号加微)给上面 6 个分析模块各打一个评价。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 是这条链路的明显短板。本案是本批转化最快的一条,成功点集中在"讲工艺不吓人"和"承诺物对得上";隐患则集中在"我们对他家一无所知,却已经承诺了按他家户型"。
is_same_city = null 是号源性质决定的,不是数据缺失。channel_pref = cloud_pc,云电脑 GUI 自动化,≥30 秒/条节流,队列零报错零重试。customer_profile = {},没有任何结构化字段承载联系方式,下游看不见。stage = ice_break、handed_off_at = null,自动跟进若命中,会对一个已经给过微信的人再催一次微信。pending_handoff、停自动跟进;②加一个"已交出联系方式"状态位,让派单侧一眼可见;③补加微结果回流。fcac3c71-…-aba6c4c7a1513d33c74b-…-a28228da4dad · stage ice_breakMS4wLjABAAAAzNvCUFFi8f…1neDo7642675465907391759 · 号源「灿哥聊装修」· 知识号channel_pref = cloud_pc)· ≥30s/条