他在重庆。7 月 14 日早上 7 点 43,他在一支「136 平黑白极简风」的装修视频底下留下四个字:「求一份清单」。
2 分 55 秒后私信到达——全天最快的一次触达。13 分钟后他给出手机号,上午 9 点 02 加上了企业微信。
然后我们发过去一个叫 A4黑白灰二居三层16万.zip 的文件。他的第一句话是:「16w?」
拆锚拆得很漂亮,报价也终于算出来了(102 × 650 ≈ 6.6 万)——可最后一条消息又把他问跑了。
下面三块是这条案例的原始信号:他留评论的 136 平黑白极简风视频、那句五个字的求清单、以及一筑账号发出的破冰,直到他主动给出手机号的完整 9 条抖音对话。抖音侧 transcript 以 DB messages 为准。企微侧的对话在页面靠后单独有一整段——那才是这条案例真正的转折发生的地方。
下方各分析模块用 #1…#9 引用回这里,企微侧用 #10…#24。抖音侧 9 条均有 DB messages.role 记录(云电脑 DOM 通道自动捕获 + 自动回复)。我方每条回复都标了「出处」小标签 + 气泡下的「💡 逻辑」「📚 话术库」。
qwen3-235b 生成,云电脑网页 DM 自动发出
🤖 AI代回 · 方案B 企微文字回复 · 企微自动代回(方案B)qwen3-235b 生成,云电脑 GUI 自动发出
👤 人工 只发文件/图(zip 案例、避坑指南 PDF 这类附件由真人/设计师发)
📚 逻辑框底部「话术库」出处——[确定性] 代码按信号硬触发(报价走 pricing.ts、发资料走素材库具名条目、收号走写死 MATERIAL_CLOSING)· [语义/合成] 按检索/AI 合成(不可事后精确重建)。
llm.ts:641-676)+ signals/pricing 硬闸。MATERIAL_CLOSING(material-delivery.ts:146)。material-library.ts);⚠️ 文件命名把案例总价当成了报价。materialLeadIn)。material-library.ts)。material-library.ts)。pricing.ts 650 元/㎡全包口径(RENOVATION_PRICE)+ 澄清「案例总价 vs 客户报价」。pricing.ts 650/㎡×102≈6.6万全包(含硬装+软装+全屋柜体+家电位)。pricing.ts 650/㎡全包。07:43:05 他按下发送,07:46:00 私信弹出。他几乎不可能已经划走那支视频。而且这次时效是真的换来了结果:4 分钟后他回话,13 分钟后他给了手机号。这是时效性最理想的一次兑现。
📌 本案是时效性最漂亮的一次兑现:2m55s 送达、4 分钟拿到回复、10 分钟拿到手机号——链路快到客户还没离开那支视频的注意力窗口。这一环没有任何可挑剔的地方,模块 1 评 GOOD。
⏱️ 时间口径说明:07:43:05 和 07:46:00 是秒级时间戳;中间的 07:45 / 07:46 来自旅程节点记录,只精确到分钟,因此两段耗时写作「≈2 分钟 / ≈1 分钟」,总时长 2m55s 以两端时间戳为准。
内容侧的落差极大:企微里那段价格锚点拆除是全队今天最该进 SOP 的话术(#16);而 #23 那条重新自我介绍 + 重问已知信息,极可能就是他停止回复的直接原因。同一条对话里既有天花板也有地板。
在苏等等的家那支136 平黑白极简风视频底下,他留了五个字:「求一份清单」。这是一个动作明确的需求——他要东西,而且说清了要什么。LLM 判定 product 类问购、78 分中意向,理由「问购·一般·在调研」。判得没错:他要资料,但没说自己家什么情况,所以停在「在调研」档。
opener(#1)四件事做得干净:叫名字 + 复述他刷的内容 + 本地稀缺感(重庆本月活动期排单还剩几席) + 承诺给他要的东西(实拍 + 户型清单)+ 一个低门槛提问(几室几厅)。它没有裸报价、没有先索取——他 4 分钟就回了。
详见后面的企微段。简单说:客户已经给了重庆(#20)、建面 102(#17)、3 室(#21),13:36 我方却发出这样一条:
这个客户对我们的信任是全天最好的:10 分钟给手机号、无人指引下自己摸索通过企微验证、看到「16w?」也没直接拉黑而是回来问。信任不是问题,问题是我们两次辜负了它(两次听不懂求助、一个裸带金额的文件名)。
IP 属地重庆 → opener 直接用「重庆本月活动期」→ #3 补一个重庆楼盘(龙湖两江新宸)→ 企微里客户亲口确认「重庆」。地区信号从入库字段一路走到成交话术,没有一环掉链子。
comments.ip_location · 抖音 IP 反查(重庆是直辖市,省市同名)
本案的价格环节是一次自伤加一次漂亮的自救:资料包文件名叫 A4黑白灰二居三层16万.zip,客户第一句话是「16w?」——他把文件名里的 16 万当成了给他的报价。
但这一次报价真的算出来了:102 × 650 ≈ 6.6 万,口径写得很清楚。这比同日「在路上」案例(总价从头缺位)强出一个身位。
黑白灰三居·全案参考.zip 就完全没事。
这条案例把信息流转的漏洞暴露得最彻底:客户在这条对话里一共交出过三次关键事实,每一次都被后面的自己重新问了一遍。不是记不住——是跟进 prompt 里根本没有「已知事实清单」这个输入。
企微侧的对话不在 DB 里(本案 transcript 全部来自运营截图)。抖音侧他说过的「3室一厅」、系统里存着的「IP 属地重庆」,一个字都没有跟着他过到企微。企微里等于从零开始重新认识这个人——所以 #19 要问几室、#23 要问城市和面积。
更荒诞的是:#22 和 #23 是同一分钟(13:36)发出的两条消息。前一条说「重庆 102 平三室,大概 6.6 万」,后一条问「您家要装修是吧?房子多大呀,哪个城市?」——同一分钟里,系统既知道又不知道。
messages 有全量记录customer_profile(城市/面积/户型);命中即禁止重问——这是今天两条案例共同的 P0customer_profile 作为独立字段拼进 system prompt,并加一条硬规则——清单里已有的字段,一律不许再问。
抖音那条链路的终点,是企微这条链路的起点。这段对话不在 DB 里——全部来自运营截图转录。它同时包含了本案最该沉淀的话术和最该修的 bug。企微人设是「小范」,客户在企微里的备注名是「24」。
💬 企微对话已并入上方主对话(#10–#24 绿色气泡段),此处保留企微段复盘小结。
给上面 6 个分析模块各打一个评价:做到位的当 SOP 沉淀;不足的当下一周 punch list。good = 已达可复用标准;mid = 能用但有压缩空间;bad = 是这条链路的明显短板。
messages 有全量记录。946cf44e-d3b4-…-b8b4-7b5c9a2ec26dMS4wLjABAAAA-rBAGe4SWSBm…EpENfbsmessages 有记录customer_profile 未落库(城市/面积/户型全靠人读 transcript)· 企微对话未入库