异步服务

实时排队的终结

客户服务长期以来一直采用单一的设计模式：实时同步会话。客户打电话、等待、接通、解决——所有这些都在一个连续的时间块中完成，否则交互就被视为失败。这种假设现在正在瓦解。建立在持久消息通道基础上的异步服务正在取代实时排队，成为客户支持的默认模式。

其机制简单，但影响深远。客户在上午 9 点就延迟订单向商家发送消息，然后关闭应用程序，继续他们的一天，并在下午 3 点在同一条消息链中收到解决方案。没有等待音乐，没有排队位置，没有需要引用的案例编号，也无需从头开始重复问题。即使客户和客服都离开，该通道也会记住。WhatsApp Business 和 Apple Messages for Business 使这变得司空见惯而非新奇——对话被视为一个双方都可以返回的持久对象，而不是必须完成或丢失的实时通话。

为什么消息链优于电话

采用规模已不再是微不足道的。Meta 在 2022 年报告称，每天有超过 1.75 亿人通过 WhatsApp 向商家账户发送消息——这一数字表明持久消息服务已远远超出试点阶段，成为很大一部分面向消费者行业的默认基础设施。

值得注意的是，客户不仅大量向商家发送消息，而且排队本身正在作为一种设计概念而消失。Apple Messages for Business 和 WhatsApp Business API 都默认采用线程化、持久的对话，而不是实时排队——客户看到的是聊天记录，而不是等待时间。这种单一的界面变化悄然消除了等待的心理成本，因为等待不再可见或同步。没有什么可盯着看，也没有什么位置可刷新。

这种转变不是从慢速服务到快速服务。它是从需要现场的服务转向无需现场也能持续存在的服务。

围绕消息链重建后端

联络中心供应商——其中包括 Zendesk、Salesforce、Twilio——已经围绕消息链重建了核心工作流程，这些消息链会随着时间的推移路由到不同的客服，而不是单次会话的电话。这是一种比看起来更深层次的架构转变。实时电话需要一名客服在场，持续整个通话过程。持久消息链可以在客服、班次甚至几天之间传递，前提是上下文随之传递。这需要新的基础设施：共享历史记录、可见的先前交流以及将对话视为持续记录而非已结束事件的路由逻辑。

这也是为什么上下文持久性而非响应速度成为真正的差异化因素。因为消息链保留了历史记录，客户可以容忍更长的解决窗口——前提是他们不必从头开始重新解释问题。速度仍然很重要，但它已被降级。客户无法容忍的是被要求向一个显然已经忘记了他们已经描述过的问题的系统重新陈述问题。

客户和运营的变化

对于客户而言，好处是显而易见的：支持现在可以适应他们的一天，而不是要求他们实时等待。但这伴随着相应的期望——由商家而非客户来推进上下文。异步服务只有在消息链真正记住的情况下才能作为信任交换发挥作用；如果不能，该模型就会回到它旨在解决的精确重复问题。

对于商家而言，异步消息链减少了并发客服负载并降低了放弃率，因为客户不再坐在实时队列中，没有挂断的动机。但这需要围绕解决窗口而非通话时间建立新的人员配置和 SLA 模型。为同步、单次会话电话设计的模型无法干净地映射到可能跨越数小时或数天以及多个客服的对话。

特别是对于客户体验和运营团队而言，这迫使他们进行指标改革。当“通话”不再作为离散单元存在时，平均处理时间和首次响应时间等传统衡量标准就失去了大部分意义。运营必须转向消息链级别的解决跟踪——衡量问题是否真正关闭，以及整个过程花费了多长时间，而不是衡量某人接听电话的速度。

实际的前进道路

这种模式已经适用于零售和电子商务、电信、银行和金融服务、旅游和酒店以及物流和配送——任何高流量、低紧急度的服务查询目前不必要地堵塞实时渠道的地方。明智的做法是立即采用：针对那些低紧急度、高流量的案例试点持久消息通道，并围绕解决窗口而非响应时间重新设计 SLA。那些将其视为渠道互换的组织将错失要点。那些将其视为“解决”含义的重新设计的组织，将是客户不再害怕联系的组织。