售后工单系统要不要上加实时客服通道，这个话题在内部讨论的时候，经常会变成”邮件模式和Websocket模式哪个更好”的技术争论。但吵到最后我发现，很多团队争的根本不是技术问题，而是没想清楚客户真正要的是什么。
B2B场景下，客户提交售后工单的时候，心理预期本来就是”需要等一段时间”。他们不期待秒级回复，也不觉得邮件通知有什么问题。真正让他们焦虑的不是”回复慢”，而是”不知道工单被谁接了、不知道处理到哪一步了、不知道能不能解决”。如果这个信息透明度没有做好，加任何实时通道都解决不了问题。
邮件模式在这件事上其实够用了。提交后收到确认、工单状态变化时收到通知、问题解决后收到结案邮件——这套流程客户已经习惯了，也不存在额外负担。但邮件有个天然局限：它是”推”过去的，客户没有办法主动查询自己的工单状态，也没办法在不打开邮箱的情况下看到最新进展。如果售后团队处理一个工单需要两三天，客户在这期间就是完全的信息黑箱，什么都看不到。
Websocket的价值在于让这个信息黑箱变得透明。工单被谁接了、技术人员在处理哪个环节、大概什么时候能反馈，这些信息可以实时推送到客户界面，客户不需要主动刷新邮箱也不需要打电话催。但这套方案的前提是售后团队有足够的在线人力来支撑”实时响应”。如果技术团队有限，客户发来消息却长时间没人回，系统显示了”在线”却没有兑现承诺的响应速度，客户的失望感会比纯邮件模式强烈得多。
还有个问题是并发。售后工单量不是均匀分布的，产品发布、活动促销、系统故障的时候，短时间内会涌入大量请求。Websocket需要维持长连接，每个在线客户都占用一个连接资源。如果服务器配置不够或者负载均衡没做好，连接数激增可能导致系统变慢甚至崩溃。邮件模式是无状态的，触发事件才发送，不存在这个问题。对于业务还在增长阶段的企业，系统稳定性往往比功能炫酷度更重要。
所以这个决策的顺序应该是：先明确售后流程里客户真正的痛点是什么。如果核心问题是”信息不透明”，优化状态同步和主动推送机制比加实时聊天通道更直接。如果核心问题是”响应速度慢”，需要先看是人的问题（人力不足）还是流程的问题（工单分配机制），而不是直接跳到技术方案。