Genesys第五版《2026 State of Customer Experience》调查了5811名消费者和1560名企业及客户体验负责人,覆盖20多个国家、14个行业。不能完全代表中国,但服务接受方和建设方两头都问了,能看出两边的认知差距。

数据最值得看的是:76%的消费者不在意问题最后是人工还是AI解决的,前提是解决得够快够完整。

但耐心没有跟着变多。84%的人最多只给虚拟客服三次机会。95%希望已经给过的信息能跟着渠道和服务人员一起走,但48%的企业做不到把虚拟客服收集的数据自动交接给人工。

不能简单解释成"客户已经喜欢上AI了"。更准确的说法是:客户越来越不在意谁在服务,越来越在意问题有没有真的解决。


2.jpg

客户评价的是结果丨企业统计的是一个节点


消费者不会按一次对话、一个渠道或某个工具评价服务。客户查物流是想知道包裹什么时候到,报修是想让设备恢复,退款是想确认钱能不能回来。

电话、在线客服、机器人、人工坐席、工单系统,这些只是企业内部的划分方式。

但很多企业建AI客服时,优化对象还是一个接待节点:机器人接了多少咨询、自助率提了多少、转人工降了多少、省了多少人工接待量。

这些指标能看出AI承担了多少量,但说明不了客户的问题有没有解决。转人工率低,可能是Agent处理能力强,也可能只是客户找不到人工入口。自助率高,可能是问题被快速处理了,也可能只是客户被留在机器人端,后面还得再打一次。

当项目目标变成“尽量把客户留在AI端”,系统自然会围绕一次交互做优化。只有把目标改成“推动客户问题解决”,企业才会追问:AI什么时候该继续、什么时候该退出?信息怎么交给人?一次咨询怎么进到查询、工单和业务流程?

这可能是当前AI客服建设里更根本的错位:企业优化一次接待,客户评价的是从提问到拿结果的整个链路。


投入了AI,客户还是觉得割裂


最直白的解释是系统没打通。不同渠道的会话记录各存各的,人工看不到机器人阶段的信息,订单、工单和客户资料散在多个系统里。报告自己也说,企业要提供连续体验,AI得带着上下文走,在渠道和人机之间持续推动问题解决。

但系统割裂只是表面。更深的问题是,很多AI客服项目从一开始就把边界划在"前端问答自动化"。项目止于机器人能不能识别问题、给答案、分流咨询。答案之后的事,即业务办理、跨部门处理、责任承接,还是留在原来的流程里。

结果企业多了个AI入口,没重新设计客户问题怎么向后流动。客户跟在线Agent说了订单和故障,转到电话坐席还要重新说。机器人采集了信息,人工还是逐项复制到工单。AI告诉客户要补材料,没说交到哪、谁处理、怎么查进度。

这类体验不一定说明模型不行。很多时候,企业只是自动化了一次对话,没有自动化问题继续流动的过程。


3.jpg

先查四类断点


问题出在四个位置。它们不是AI效果的全部条件,知识准不准、规则合不合理、人工有没有权限,也会影响结果。但能帮企业看清自己建的到底是一个问答入口,还是一条能继续往后跑的服务链路。

・表达断点

客户很少用一句完整、标准的话说事。可能连着发几条,中途补个订单号,突然从物流改问退款,也可能直接在电话里把一句话拆成两段。还有图片、文件、表单。

如果系统逐条理解消息,或者只认固定问法,知识里答案再多也可能答非所问。要看的不是模型能不能识别关键词,是它能不能结合前后文理解连续表达、识别问题改变、把后续补充的东西纳入同一次服务。

・处理断点

报修、预约、投诉、物流异常,很少回答一句话就完。通常还要采集身份、订单、型号、地址、附件,建工单,通知客户补材料,再由业务部门继续处理。

如果AI只能回答“应该怎么办”,后续人工还是要重新问、重新填字段、跨系统录入。AI减掉的只是部分问答时间。要检查的是:AI获取的信息能不能继续进表单、查询、工单和业务接口;客户拿到答案之后,有没有明确的下一步。

・交接断点

转人工不该等于重新开始。坐席需要的不是聊天记录,还有客户已经填的字段、当前诉求、之前做了什么、下一步该做什么。

转人工本身不是AI失败。无效交接才是。坐席接手后是在继续处理,还是又重新问一遍,决定了交接质量。

・运营断点

Agent上线时好用,业务变了不一定还行。政策、规则、流程在变,新的表达和异常情况持续出现。有些问题是知识过期,有些是特殊场景的判断方法和服务经验没被沉淀下来。

Badcase出现后能不能定位原因、修改后有没有持续评测、接口和服务有没有异常,这些应该在大量客户受影响之前就被发现。AI客服不是配置好就能一直用的工具,更接近一项需要持续运营的服务岗位。


4.jpg

从一次回答,到一条能继续跑的链路


四类断点在不同位置,核心问题是一个:客户给过的信息、Agent做过的活、后续处理责任,没有沿着服务链路继续往后走。

合力亿捷对Agent的设计不是把这四类问题拆成孤立功能,而是让它们发生在同一条服务过程里。

拿一次售后报修来说。客户先发一句“设备坏了”,再补型号、订单号和故障现象,再上传现场图片。Agent需要结合连续表达理解诉求,不是逐条回答。图片、文件可以按场景配置识别、摘要或回填,跟客户已提供的字段一起进到后续流程。

信息多的时候,Agent用表单集中采集。完成之后,根据企业规则进工单、通知或业务系统。缺材料就继续提醒客户补。要其他部门介入,已采集的信息不用重新录,跟着任务走。

如果超出Agent的处理边界,人工接手时不只是一个转接请求。对话、已采集信息和服务记录继续交给坐席,还可以结合配置提供画像、SOP节点、话术建议和风险提示。人工面对的不是一个“刚进系统的客户”,而是一项已经完成部分理解和准备的服务任务。

服务结束也不代表链路走完了。运营人员对错误回答和异常处理的纠正可以沉淀为后续可调用的经验。业务变化后,通过评测和记录检查Agent表现。质检不只是给总分,还能拆分规则和扣分原因,供复核和调整。接口超时、节点卡住这些问题也要进监控,不是等客户投诉了才发现。

MPaaS做的事就是这种底层连接和编排:把对话、知识、表单、工单、人工工作台、业务接口、评测和日志放在同一条链路里。前一个环节产生的信息和结果,能继续被后一个环节用。需要结合企业实际流程配置的环节(自动通知、材料回写、接口重试等),不是默认全开,但核心逻辑是让信息和动作不中断。


5.png

衡量指标也要跟着变


优化目标变了,评价指标也得换。

机器人接待率、自助率、转人工率、平均响应时间,这些是“节点效率”。

一次解决率、重复咨询率、有效交接率、业务闭环率,这些是“问题结果”。

节点指标不是没用,但不能替代结果指标。一个项目完全可能接待率做得漂亮,客户问题解决上却失败了。也可能因为合理转人工,转人工率没明显降,但客户重复描述减少,复杂问题处理反而更顺。

企业要问的不只是“AI接了多少”,而是:AI独立处理了哪些问题?处理不了的及时退出了吗?已经拿到的信息被继续用了吗?客户的问题最后有没有进到对的人和流程?

这些问题比单一的自助率,更接近AI客服的真实业务价值。


终点不该是"没转人工"


《2026 State of Customer Experience》说得很直白:客户没要求所有服务回到人工。他们愿意用AI,也相信AI能改善效率,但有前提,问题得被快速、完整地处理。

企业要改的不只是模型、知识库或话术。还有AI客服项目的终点。终点不该是“这次没转人工”,而应该是客户拿到了答案、完成了办理,或者AI处理不了时被顺畅交到了合适的人和流程。

客户从来说的不是谁接的电话,而是问题有没有解决。衡量AI客服,也应该从这里开始。