他在江西。07-03 中午,他在一支业主日记视频底下留了四个字:「我准备装这个」 —— 系统读成 85 分高意向、urgent。
6 分钟内破冰打回,个性化叫他「雷声哥」、接住了「胡桃色平板门」。可其中一条用了成都的社会证明,客户隔了两天回一句「四川的啊」,AI 顺势承诺「我们四川都有门店、本地上门」—— 但他的 IP 在江西。球在客户方。
下面三块是这条案例的原始信号:客户留评论的业主日记视频、那句「我准备装这个」、以及由「有大有小」账号发出的两条破冰 + 一轮往返。先看全貌,再进入每个模块的拆解 —— 尤其注意破冰里那句"成都"埋下的地理伏笔。
下方各分析模块在拆解时用 #1–#4 引用回这里。全部来自 DB messages,但有两处状态异常在气泡下如实标注。
时效性是 Akke 链路最先体现的工程指标。本案评论到入库只用 47 秒,入库到首触达约 5 分钟,全链路 6m05s(按 DB 确认 sent 的 #2 计;#1 若按 13:00 算约 2 分钟)。系统侧没问题。真正拖节奏的是两处人/流程侧:3 分钟内双发两条破冰,以及客户回后我方隔 5 小时才接。
📌 系统侧时效在本案是达标的(47s 入库、6 分钟触达)。两个非系统污点值得记:① 双发 —— #1#2 3 分钟内连发两条近乎重复的破冰,观感像"刷屏";② 晚回 —— 客户 17:46 回,我方 #4 拖到 22:58 才接,5 小时的空窗对一个高意向客户偏久。
这条 lead 的内容看点是一次个性化做得不错、但社会证明选错了地方的破冰。opener 叫对了「雷声哥」、接住了「胡桃色平板门」和业主日记场景,本该顺;但「成都很多客户选」这句地域性社会证明,成了客户两天后唯一回应的那句「四川的啊」的引子 —— 本该拉近距离的社会证明,反而把话题引向了"你们在哪、离我远不远"。
在大橘的家🏠(软装中)(号源池里一个"业主日记"类目的装修记录号)的胡桃色平板门视频底下,雷声只留了四个字:「我准备装这个」。别看短,这是阶段词 + 明确意图的组合 —— "准备装"直接暴露了他正处在临下单的决策窗口,而"这个"锁定了具体品类(视频里的胡桃色平板门)。信息量不大,但意图纯度极高,所以系统给了 urgent。
customer_profile.decoration_stage 却被另一路分类器标成 non_decoration(置信度 1),和"准备装"直接冲突 —— 两个模型对同一个人给了相反的装修阶段判断,是个待对齐的内部信号矛盾。
opener(#1)前半段做得很好:叫「雷声哥」拉近称呼、复述「准备装胡桃色平板门」证明真看了视频、点出"显大又耐看"的卖点、再用"新房还是翻新"引导。问题出在中间那句 "现在成都很多客户选" —— 这是一句地域性社会证明,对一个 IP 在江西的客户,既不拉近距离、还凭空引入了"成都/四川"的地理设定。
面对客户 #3「四川的啊」,跟进 #4 选择顺势确认:"我们四川都有门店的,本地都能上门量尺~",再连问新房/翻新、几室几厅,并承诺"给你估个价"。方向感对(接住地理话题 + 推进量尺 + 抛估价钩子),但有个隐患:它默认了客户在四川 —— 而 DB 里客户 IP 是江西,"本地上门量尺"这个承诺是押在一个没被确认的前提上的。
DM 进来后,客户的第一反应是点头像验证身份。本案触达账号是「有大有小」,它能不能扛住"主页一眼信任检查",直接决定客户愿不愿意往下聊 #2。本案主页详细资产尚未截图抓取,以下据 DB 账号记录填,缺数处明确标注。
Akke 的地区信号分三层:客户 IP 属地(省)、自报现居(市)、号源服务市。本案三层里唯一入库的省级是江西,可整段对话却因为破冰那句"成都"、全程围绕四川打转。这是本案最需要点破的问题:系统信号(江西)和对话设定(四川)互相打架,且没有任何一方被确认。
comments.ip_location · 抖音 IP 反查comments.city · 客户未自填;对话也未确认在四川source_accounts.city · 业主日记号,无服务市 → is_same_city = null整段对话没有出现任何具体报价 —— 单价、总价、计价方式都没提,#4 只在结尾承诺"顺便给你估个价"。对一条 85 分高意向 + urgent(准备装) 的 product 型 lead,这偏保守:客户已经站在下单窗口、又是问"准备装这个",一个具体的价格锚(哪怕是范围)本可以更快把他从"看看"推向"聊聊"。
本案账号「有大有小」走云电脑浏览器 DOM web 私信通道(网页版专用)。这条通道在本案暴露了一连串回写/去重问题:#1(含成都、真实发出)在 DB 里却是 draft;#2 3 分钟后重发构成双发;客户回复 #3 有行但 sent_at/last_inbound_at 空。DB 里这条 lead 的状态和真实对话严重脱节。
cloud_pcdouyin_dm_web_capture_dom.py · 发送 douyin_dm_web_send_dom.pydraft、sent_at 空 —— 实发未回写;② #1#2 3 分钟内近乎重复地双发,观感差、还可能是"draft 没标 sent → 系统以为没发 → 重发一条"这条 bug 链的结果;③ 客户回复 #3 的 last_inbound_at 仍为 null,统计上这条高意向 lead"看起来没回应"。建议:查 DOM web 通道的 sent 回写为什么漏,堵住"draft 实发 → 重发"的双发链;跑 writeback 把 #1 的 sent 和 #3 的 inbound 补上。
本案已经在云电脑上跑,暴露的缺口正好构成这条通道下一步要加固的清单:让发送状态、去重、客户回复都可追可回写。
给上面 6 个分析模块各打一个评价:做到位的沉淀成 SOP,不足的列成下一周 punch list。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 这条链路的明显短板。
075db5bd-…-dc1e54869b1cice_break(DB;真实已一轮往返)c46f080a-…-a04562e57c12MS4wLjABAAAAIkJSkrwZ…VL0