分类： 全渠道

客户在 WhatsApp 上开始一段对话。两天后，他们就同一个问题致电支持热线。那一周晚些时候，他们又发来一封邮件追问。在大多数企业中，三位不同的客服坐席分别处理这三个接触点，而他们中没有一个人了解另外两人讨论过什么。

这正是全渠道联络中心旨在解决的问题。它将来自各个渠道的语音和文本消息路由到同一个客服坐席工作台，因此接听的人员无论每条消息来自哪里，都能在面前看到完整的对话历史。

这个术语常与“多渠道”混用，但两者存在实质性差异。本指南将介绍全渠道联络中心的真正含义、它如何路由消息，以及与多渠道的区别在何处至关重要。

主要优势

• 统一的客户视图： 客服坐席可以在同一个会话线程中看到与客户过去的每一次互动——聊天、通话、邮件、表单——而不是分散在各自独立的工具中。
• 一致的交接： 当工单在客服坐席之间或渠道之间流转时，上下文会自动跟随。
• 更快的解决： 客服坐席不再需要让客户重复说明，而这是 CSAT 偏低的最大来源之一。
• 更清晰的报表： 咨询量、响应时间和解决指标按跨渠道统计，而非各自为政。

“全渠道联络中心”的真正含义

全渠道联络中心是一种系统，其中每个客户渠道——语音、WhatsApp、在线聊天、邮件、社交媒体私信、应用内消息——都汇入同一个客服坐席工作台和同一份客户记录。

关键在于“同一个”。客服坐席在同一个队列和同一个界面中工作。客户历史在各渠道之间统一。无论消息来自哪个渠道，路由规则都应用相同的逻辑。

这与“支持多个渠道”的联络中心不同。支持与统一并不是一回事。

多渠道与全渠道：差异的关键所在

多渠道联络中心为客户提供多种联系企业的方式。每个渠道通常有自己的收件箱、自己的团队和自己的报表。

全渠道联络中心提供相同的渠道，但将它们全部路由到同一个工作台和同一份客户记录。

实际差异体现在三个方面：

客户体验。 在多渠道环境中，从 WhatsApp 切换到电话的客户必须重新解释问题。在全渠道环境中，接听电话的客服坐席已经看到了 WhatsApp 的历史记录。

客服坐席工作量。 在多渠道环境中，客服坐席按渠道专业化——一个团队负责聊天，一个团队负责通话。当某个渠道出现高峰时，其他客服坐席无法轻松支援。在全渠道环境中，由于界面相同，客服坐席可以跨渠道调配。

报表。 在多渠道环境中，“我们响应需要多长时间”每个渠道各有一个答案。在全渠道环境中，只有一个答案。

多渠道并没有错。对于渠道切换较少的企业来说，它可能已经足够。当同一位客户经常出现在多个渠道上时，全渠道才变得必要。

消息路由的工作方式

一旦每个渠道都汇入同一个队列，路由规则就成为系统中最重要的部分。

常见规则：

• 基于技能的路由： 消息路由到在相关产品、语言或问题类型方面受过培训的客服坐席。
• 基于可用性的路由： 消息路由到当前在线且未满负荷的客服坐席。
• 基于历史的路由： 当之前处理过同一客户的客服坐席可用时，消息路由到该坐席。
• 基于优先级的路由： 高价值客户、紧急工单或违反 SLA 的工单可优先插队。

大多数联络中心会组合使用这些规则。一条典型的规则可能是：*如果客户有未结工单，路由到同一位客服坐席；否则，路由到下一位具备该产品线技能的可用客服坐席，并按 SLA 优先级排序。*

统一路由的目的不是让规则更复杂，而是在每个渠道上应用相同的逻辑，使同一位客户的 WhatsApp 消息和电话最终到达同一个地方。

一个实际示例

一位客户通过 Instagram 私信向一家零售商反映配送延迟。

消息路由到客服坐席 A，坐席 A 确认了延迟，并承诺第二天早上更新状态。工单保持未结状态。

第二天早上，在承诺的更新之前，同一位客户致电支持热线。电话并没有转给任何有空的人，而是路由系统先检查未结工单，发现坐席 A 正在处理该客户，于是将电话路由给坐席 A。

坐席 A 接起电话时已经知道客户是谁、问题是什么、承诺了什么。无需重复自我介绍，也无需第二次解释。

这一个流程就是全渠道联络中心带来的差异。听起来很小，却改变了客户对这次互动的感受。

采用前需要确认的事项

并非每家企业都需要全渠道路由。在采用之前，有三个问题值得回答。

客户切换渠道的频率有多高？ 如果大多数客户只使用一个渠道，统一的价值就有限。

你们有多少位客服坐席？ 只有一两位坐席时，靠纪律就能轻松实现统一。达到十位或更多时，纪律不再可扩展，系统必须强制实现。

重复提问的代价是什么？ 在高考虑度的购买或受监管的行业中，被要求重复说明比低风险的客服场景更糟糕。上下文跟随客户的价值更高。

如果其中两个答案指向统一，那么全渠道方案就值得改变。

全渠道如何融入你现有的技术栈

全渠道联络中心并不是要取代现有的工具，而是连接它们的层级。

渠道仍留在原处——WhatsApp 依然是 WhatsApp，电话系统依然是电话系统。变化在于，来自每个渠道的消息都会呈现在同一个工作台中，共用同一份客户记录和同一个路由引擎。

像 Cekat 这样的平台将语音和文本渠道整合到同一个客服坐席收件箱中，并配备统一的客户记录，因此处理 WhatsApp 会话的坐席可以在同一视图中看到客户的通话历史。这消除了使多渠道方案在实际中变慢的切换成本。

从哪里开始

如果你的团队已经在分别运营两三个渠道，第一步不是更换软件，而是弄清客户跨渠道的频率。

抽取最近 100 次客户互动的样本，统计其中有多少次涉及一个以上的渠道。如果这个数字有意义——比如超过 15%——那么全渠道的理由就是真实的，其 ROI 可以通过缩短处理时间和提高首次接触解决率来衡量。

关于客户服务、客户关怀和客户支持如何在统一团队中划分职责的相关观点，请参阅 客户服务、客户关怀与支持：有何不同？。

全渠道联络中心与其说关乎渠道，不如说关乎它们共同指向的那份记录。当这份记录统一后，下游的一切——客服坐席工作量、客户体验、报表——都会变得更容易管理。

客户发来一条 WhatsApp 消息：“我的订单有更新吗？”客服坐席看着这条消息。屏幕上没有其他内容。没有订单号，没有过往购买记录，也没有任何线索表明这位客户上周还有未解决的投诉。

客服坐席只能问出唯一能问的问题：“您好，可以告诉我订单号吗？”这位已经下过三单、还有一个未解决工单的老客户不耐烦地回复了。真正的处理还没开始，对话就已经有了一个糟糕的开端。

客户统一视图通过在客服坐席回复的同一个窗口中呈现客户的完整上下文，解决了这个问题。这是客户服务工具中最缺乏投入的改进之一，也是最可靠地改变首次回复质量的改进之一。

主要优势

• 首次回复即掌握完整上下文： 聊天一进来，客服坐席就能看到客户最近的订单、未解决的工单和客户档案。
• 不再重复提问： 客户不会再被问及企业已经掌握的信息。
• 更快的升级处理： 主管可以在同一视图中查看历史记录，而不必在多个工具之间来回查找。
• 更清晰的报表： 指标按每位客户一条记录统计，而不是按渠道或按会话统计。

客户统一视图究竟是什么

客户统一视图（SCV）是每位客户一条统一记录，将聊天线程、订单、投诉工单、付款、客户档案数据等所有触点串联起来，并在需要的那一刻呈现相关信息。

重要的不是数据存在于某处。大多数企业的订单数据在一个系统里，聊天记录在另一个系统里，投诉工单在第三个系统里。重要的是，当聊天进来时，客服坐席能在消息所在的同一窗口中看到其中真正重要的那部分数据。

SCV 不是数据仓库。仓库存储一切用于分析。SCV 只呈现那一小部分会改变客服坐席下一句话该怎么说的信息。

为什么接触点是关键所在

设想同一次互动的两个版本。

版本 A，没有 SCV。 WhatsApp 消息到达。客服坐席询问订单号。客户回复订单号。客服坐席打开另一个 WMS 标签页，粘贴订单号，等待加载。查看状态。输入回复。总耗时 4 到 6 分钟，而这个问题本应 30 秒就能回答。

版本 B，有 SCV。 WhatsApp 消息到达。客服坐席屏幕上已经显示：客户姓名、最近三笔订单及状态、上周的一张未解决投诉工单、LTV 层级。客服坐席给出具体的更新，并主动提及那张未解决的工单。总耗时不到 60 秒。

差别不在于版本 B 中客服坐席更努力。差别在于信息已经在那里了。客服坐席花在切换标签页、重新输入标识信息或反复询问客户上的每一秒，都是没有在解决实际问题的一秒。

哪些数据应纳入 SCV

人们总想展示一切。这是错误的本能。一个展示客户所有数据点的 SCV 会变成客服坐席必须筛选的噪音。

有用的 SCV 呈现五个类别：

• 身份信息： 姓名、联系电话、客户标签、语言偏好。
• 最近订单： 最近三到五笔订单，含状态和金额。
• 未解决工单和近期投诉： 所有未解决的事项，以及过去 30 天内已解决的案例。
• 沟通历史： 客户使用过哪些渠道，最后一次接触发生在何时。
• 偏好与授权： 语言、营销同意、产品兴趣。

经验法则是：如果某条信息会改变客服坐席的回应方式，它就应纳入 SCV。如果它只对月度报表有意义，它就应放在数据仓库里。

SCV 如何构建

要让这个视图发挥作用，必须满足三个条件。

一个身份标识键。 客户需要一个能在各系统之间串联记录的标识符。对于以 WhatsApp 为主的企业，这通常是经过规范化的电话号码格式。没有共享的键，一个系统中的订单和另一个系统中的聊天就无法合并为一条记录。

写入同一条记录的各系统。 如果订单系统用与 CRM 不同的 ID 创建自己的客户记录，SCV 就会显示部分或碎片化的数据。映射到共同身份的集成，是 SCV 能否真正发挥作用的分水岭。

内嵌呈现。 数据必须出现在处理聊天的同一窗口中。需要客服坐席点击进入的单独标签页不是 SCV，只是第二个应用。如果信息需要点一下才能看到，那么在时间压力下它就不会被持续使用。

常见的失败模式

大多数 SCV 的落地会以以下四种方式之一失败：

重复记录。 同一个客户出现两次，因为电话号码在一个系统中记录为 +62812…，在另一个系统中记录为 0812…。在采集环节进行规范化可以避免这种情况。

数据陈旧。 SCV 中的订单反映的是昨天的状态，而不是今早发出的货件。实时同步比大量历史数据更重要。

展示过多数据。 客服坐席看到 40 个字段，却找不到关键的那三个。渐进式展示——紧凑的默认视图加上可展开的选项——比一次性展示全部更有效。

没有回写闭环。 客服坐席在聊天中解决了问题，但没有任何内容记录到客户档案中。下一位客服坐席完全不知道发生了什么。只有当新信息能回流到 SCV 中时，它才有用。

这与 CRM 体系如何契合

客户统一视图是 CRM 搭建方式的一种属性，而不是一个独立产品。大多数 CRM 在技术上都能生成它；但很少有产品真正把它内嵌展示在实际工作发生的地方。

像 Cekat 这样的平台将全渠道收件箱与 CRM 整合在同一个工作区中，因此客户记录会出现在进行中的对话旁边，而不是单独的标签页里。订单历史、未解决工单和客户档案数据在客服坐席阅读消息的那一刻就可见，而无需先搜索。

从哪里开始

如果团队目前还没有 SCV，不要从数据项目开始。从诊断开始。

调取最近十次客户聊天。针对每一次，列出客服坐席在首次回复时需要的但没有的信息。如果同样三四项反复出现——订单状态、过往投诉、产品偏好——这些就是应纳入 SCV 第一版的字段。

从这些开始。之后只有在明确的模式证明有必要时才添加字段。一个包含五个精心选择且能可靠加载的字段的 SCV，比一个包含四十个加载不稳定的字段的 SCV 更有价值。

对于希望在设计 SCV 本身之前先思考如何组织联系数据的团队，请参阅如何构建 CRM 联系数据结构。

客户统一视图并不会为企业增加新的能力。它消除的是已经存在的能力之间的摩擦。服务质量最大的跃升，通常正来自于此。

一位客户上午9点在WhatsApp上给同一家企业发消息，五分钟内就收到了回复。同一位客户上午10点在Instagram DM上给这家企业发消息，却等了三个小时才收到回复。同样的团队，同样的产品，体验却截然不同。

客户看到的不是渠道。他们看到的是一家时而快速回复、时而消失不见的公司。而聊天响应SLA正是为了防止这种不一致而设计的。

本指南介绍什么是聊天响应SLA、为什么跨渠道的一致性比单渠道目标更重要，以及如何设定团队真正能够达成的数字。

主要优势

• 一致的客户体验： 响应速度成为企业本身的属性，而不是取决于客户选择了哪个渠道的运气。
• 切合实际的容量规划： 与真实业务量挂钩的SLA目标让您能够准确配置人力，而不是凭直觉。
• 清晰的升级触发条件： 当消息接近SLA时限时，路由系统知道需要升级——不再有悄无声息的拖延。
• 可衡量的问责机制： 每个层级只有一个数字，“我们很快”就变成了可以证明或推翻的事情。

聊天响应SLA究竟涵盖什么

聊天响应SLA不只是“在X分钟内回复”。一份有用的SLA会明确四件事：

• 首次响应时间： 客户的消息到达后，第一个真人（或机器人）回复送达客户的速度。
• 解决时间： 问题多快被彻底关闭，而不仅仅是得到确认。
• 覆盖时段： SLA适用的时间。在这些时间之外，适用不同的（或没有）承诺。
• 优先级层级： 不同的客户群体或问题类型可以有不同的SLA。VIP账户与首次购买者并不相同。

一个像“15分钟内回复”这样只有单一数字、缺少这些维度的SLA会留下漏洞。怎么回复？在什么时段？是否包括仅作确认的消息？具体性本身就是SLA。

为什么跨渠道一致性比单渠道速度更重要

大多数团队会无意中按渠道进行优化。WhatsApp因为醒目且容易关闭而受到关注。Instagram DM停留在一个小小的红色角标上，所有人都视而不见。网站上的在线聊天有自己单独的标签页，而现在没有人打开它。

结果是各渠道的SLA相差几个数量级。WhatsApp的p90首次响应时间是3分钟。Instagram DM的p90是4小时。在线聊天的p90是45分钟。

从客户的角度来看，他们记住的p90是最慢的那一个。在醒目的渠道上很快，并不能弥补在安静渠道上的缓慢。跨渠道SLA会迫使慢的渠道提升到快渠道的标准，而大部分改进工作实际上正存在于那里。

如何设定数字

设定SLA的错误方式是选一个理想化的数字。“5分钟内回复”听起来很好，直到每份SLA报告连续六个月都显示红色，团队学会了忽视这个指标。

正确的方式是先衡量当前表现，然后逐步收紧。

第1步：建立基线

提取过去30天的入站聊天记录。计算每个渠道的p50和p90首次响应时间。p50是一半消息所在的位置；p90是最慢的10%开始的位置。

第2步：选择可实现的最严格目标

将初始SLA设定为您最快渠道的p90。这样就得到了一个团队已经在某个地方证明可以实现的目标。

第3步：公布、监控、调整

第一个月每周跟踪合规率。未达SLA是诊断性的，而不是惩罚性的——它显示路由、人员配置或工具在哪里出了问题。

第4步：每季度收紧一次

一旦合规率连续四周保持在90%以上，就将目标缩短20%。SLA成为一个棘轮，而不是一个固定数字。

实践中是什么让SLA失效

当SLA失败时，原因往往集中在几个方面：

夜间和周末。 只在9-5适用的15分钟SLA是诚实的。24/7适用而团队只在9-5工作的SLA则不诚实。要么明确设定营业时间，要么投入资源保障覆盖。

高峰期。 闪购、产品发布和病毒式传播时刻会让业务量翻倍或增至三倍。静态SLA会失效；而感知业务量的路由和预先安排的备用人力则不会。

渠道孤岛。 如果WhatsApp客服坐席看不到IG DM，反之亦然，那么一个渠道的高峰就无法由另一个渠道的容量来支援。统一的队列可以解决这个问题。

技能不匹配。 SLA靠任何一个人回复就算达成，但由于接单的客服坐席不对，回复可能毫无帮助。首次响应SLA需要与首次响应质量检查相配合，否则团队就会以牺牲有用性为代价来优化速度。

如何跨渠道一致地执行

设定SLA之后，有三种机制让它在各渠道中保持诚实。

统一告警。 任何渠道的新消息都会触发相同的升级逻辑。一条已存在五分钟的IG DM应该与一条已存在五分钟的WhatsApp会话触发相同的警报。

一个队列，一套路由规则。 当每个渠道都汇入同一个队列时，任何渠道的容量都能帮助其他渠道。路由根据技能和负载决定每条消息的去向，而不是根据客服坐席碰巧打开了哪个渠道。

一个仪表板。 按渠道报告SLA合规率会引发相互指责。按团队跨所有渠道报告，则会迫使讨论围绕流程而不是工具展开。

这与工具栈如何配合

聊天响应SLA由负责将消息路由给客服坐席的工具来执行。如果该工具是按渠道划分的——一个用于WhatsApp，一个用于Instagram，一个用于在线聊天——那么跨渠道执行就需要额外叠加手动仪表板。

像Cekat这样的平台在一个队列和一个路由引擎中处理WhatsApp、Instagram DM、在线聊天及其他渠道，因此SLA规则可以统一适用，告警也集中管理。这消除了“今天谁负责这个渠道”的问题，而大多数跨渠道SLA失败都可追溯到这个问题。

从哪里开始

不要从SLA开始。从基线开始。如果不知道团队今天处在什么位置，任何目标都只是猜测。

提取上个月的数据。计算每个渠道的p50和p90首次响应时间。看看差距。如果某个渠道明显比其他渠道慢，那就是约束所在——在设定SLA之前，先弄清原因。通常它是上述四种模式之一。

有了基线数字之后，将初始SLA设定为您最快渠道的p90。公布它，每周跟踪，并每季度收紧。SLA不是目标——目标是让团队把每个渠道都视为同样值得回复。

关于SLA的定义、类型以及在客户服务合同中的结构方式的更深入参考，请参阅服务级别协议（SLA）：类型、指标与CS指南。

关于让更快响应成为可能的运营策略的配套文章，请参阅如何缩短CS响应时间。

聊天响应SLA不是文书工作。它是一种机制，把“我们尽量快速回复”变成团队在周一早上能够站得住脚的数字。

五人的客服团队每天可以轻松处理 300 次聊天。当聊天量增长到每天 3,000 次时，再增加 45 名客服坐席并不是答案：成本上不划算，培训体系跟不上，而且每招一批新人，质量就会下降。

大多数企业在这个节点上，要么接受服务质量下降，要么投资于客户服务自动化。第二种选择如果做得好，改变的是团队的结构，而不是人数。

本指南将说明”不增加人手也能扩展”在实践中究竟意味着什么，哪些聊天可以干净地实现自动化、哪些不能，以及在你知道业务量增长曲线即将到来时该从哪里开始。

主要优势

• 吸收流量高峰： 自动化可以处理 5 倍的业务量，而成本不会按比例增加。
• 释放人力从事高价值工作： 客服坐席把时间花在投诉和谈判上，而不是重置密码和更新物流信息上。
• 对重复性问题给出一致答案： 同一个产品问题，每次都能得到同样准确的回答。
• 更快响应占多数的普通客户： 占聊天量 70% 的简单问题在几秒内就能得到答复，而不是几分钟。

“不增加人手也能扩展”的真正含义

这句话常被误读。它并不意味着把人工从客户服务中移除，而是改变人所做的事情。

在典型的入站聊天构成中，大约 70% 的消息是重复性、低上下文的：订单状态、产品库存、营业时间、配送时间。这些不需要人工判断，只需要快速、准确的回答。

另外 30% 才是人工能够创造价值的领域：复杂投诉、高价值谈判、边缘情况、需要共情的场景。这些也是客户会记住的互动。把客服坐席从 70% 的工作中解放出来，才能让他们在 30% 的工作中表现出色。

不增加人手也能扩展，意味着由自动化吸收重复性业务量，让团队能够在真正重要的互动中保持质量。

按业务量划分的三类聊天

入站聊天分为三类：

交易型（约 40%）

订单状态、物流更新、付款确认、配送时间窗口。答案就是数据——从系统中提取，然后回复。不涉及判断。

信息型（约 30%）

产品规格、营业时间、退货政策、门店位置。答案存在于知识库中——检索、格式化、回复。判断成分极少。

例外型（约 30%）

投诉、定制请求、复杂问题、谈判、不满意的客户。答案需要上下文、判断，往往还需要共情。判断是核心。

前两类正是自动化发挥作用的领域。第三类则是人工仍然不可或缺的地方。

哪些能干净地自动化，哪些不能

一个有用的检验标准：如果答案可以从结构化数据或知识库中生成，不需要人工权衡选项，就交给自动化处理；如果答案需要判断语气、权衡取舍或做出自主决定，就留给人工。

可以干净地自动化： 订单状态查询、产品库存检查、配送时间预估、退货政策说明、营业时间查询、预约登记、投诉类型的初步分类处理、转接人工前收集身份信息。

不能干净地自动化： 退款例外处理、复杂投诉解决、向高价值客户追加销售、协商定制价格、处理情绪激烈的互动、处理账户欺诈疑虑，以及任何需要产品判断或自主决定的事项。

随着技术进步，这条界线会移动，但原则不变：自动化可复现的部分，把判断留给人。

自动化在哪些环节发挥作用

自动化应当吸收的业务量，大部分集中在四个具体工作流中：

订单状态。 客户询问后，机器人从订单系统获取信息，回复当前状态和下一次预计更新。如果答案不明确或系统出错，就升级给人工。仅这一项就能在电子商务中吸收 20-30% 的入站业务量。

FAQ 分类处理。 答案稳定的常见问题直接从知识库解决，不进入排队。只有新的或不清楚的问题才会转给人工。

初步信息收集。 在客服坐席接手之前，机器人先收集订单号、问题类型和相关标识信息。人工接手的是一个已经梳理清楚的对话，而不是从零开始。

预订与排程。 预约时段、服务预订和预订确认都是纯粹的数据流。这些绝不应当由人工来做。

人工仍然重要的地方

自动化不是目标，更好的客户服务才是目标。有两类场景在自动化后通常会变得更糟：

情绪激烈的互动。 订单到货时已损坏的愤怒客户，并不希望由机器人来认可他的不满。他需要一个人来解决问题。

高风险的商业决策。 正在协商年度合同条款的 B2B 客户，不会接受 AI 的还价。这种判断举足轻重。

设计良好的自动化方案会及早识别这些情况，并在客户不得不主动要求之前转接给人工。

需要避免的两个陷阱

大多数自动化推行都会在以下两个方向之一失败：

过度自动化。 所有请求都先经过机器人，包括情绪激烈的互动。客户会把这个系统体验成一道必须先突破的墙，才能获得帮助。即使响应时间改善，CSAT 也会下降。解决办法是设置积极的升级触发条件：愤怒用语、重复联系、高价值账户标记，让人工尽早介入。

自动化不足。 只有最琐碎的查询才转给机器人。人工仍然要处理全部订单状态业务量。单次互动成本居高不下，负载下响应时间被拉长，预算中的”自动化”项目看不到可衡量的回报。解决办法是诚实地衡量：如果扩大自动化范围，当前聊天中有多大比例可以干净地处理。

合适的平衡因企业而异。它来自测量，而不是猜测。

它与技术栈如何配合

客户服务自动化不是一个单一产品。它是能够读取上下文并作出回应的 AI 智能体、让机器人从订单和产品系统中获取数据的集成，以及决定何时升级给人工的路由层的组合。

像 Cekat 这样的平台将 AI 智能体构建器与全渠道收件箱和 CRM 结合在一起，因此自动化运行在人工客服坐席所使用的同一客户上下文之上。这意味着当机器人升级时，人工接手时拥有完整的历史记录——无需重复自我介绍，也不会丢失上下文。

从哪里开始

在增加任何自动化之前，先测量当前的分流情况。把最近 200 次聊天归入三种类型：交易型、信息型、例外型。这些百分比会告诉你业务量究竟集中在哪里。

如果超过 50% 属于交易型或信息型，自动化的理由就有了量化依据。从最常见的单一查询类型开始，通常是订单状态，把那一个工作流彻底自动化。衡量一个月的效果后，再增加下一个。

一次一个工作流地构建自动化，比一次性全面铺开要慢，但它能产生真正有效的自动化。全面铺开通常会在团队没有预料到的边缘情况下崩溃。

想具体了解 WhatsApp 聊天机器人如何吸收客服运营成本，请参阅 用 WhatsApp 聊天机器人将客服运营成本降低 60%。

想从更广阔的视角了解如何在业务规模上管理聊天量，请参阅 业务聊天管理：扩展支持与 SLA。

客户服务自动化如果做得好，并不会让客服团队变小。它会让团队在只有人类才能做的工作上表现得更好，同时让其他事情不再占用他们的一天。