周一早上客户发来一条使用问题咨询，周三下午他发来的是退款申请。中间隔的不是三天时间，是三条没人读的消息。我们复盘了这三天，把『响应时效』从口号变成了账本。
3 条被漏掉的后续消息
72 小时问题发酵的完整周期
读与回两个动作两种结局
1. 第一天：消息发出，进入『有人在吗』阶段
客户周一上午报了一个操作问题，还在耐性范围内。这个阶段的客户要的其实不是秒回，而是一个『收到了』的确认——自动回复加预计响应时间，成本几乎为零，却能稳住第一天的情绪。
2. 第二天：等待变成怀疑
没有确认、没有进度，客户开始换渠道：又发了一条、打了电话没打通、可能在社交平台上搜了搜你。第二天的沉默不是零成本，是客户在替你做负面宣传——他对自己的朋友、对平台上的陌生人，描述这次被晾着的经历。
3. 第三天：问题升级成决定
第三天客户不再问『怎么解决』，开始说『怎么退』。到这里，问题的性质变了：技术问题变成信任问题，服务成本变成挽留成本。回看这三天，最好的介入点在最便宜的第一天——确认收到，问题就停在问题。
4. 让『读与回』不依赖人的自觉
复盘的结论不是『大家要更用心』，而是把时效做成机制：消息进系统统一排队、超时自动提醒、当天未响应自动升级。9527CRM 的工单系统里，每条售后消息都有时限和归属，超时的会浮到主管面板上——那条消息的三天，从此不会再发生。
结语
响应时效不是服务指标，是成本变量：第一天回复是服务，第三天回复是公关。