客户服务分析软件：八个平台对比

客户服务分析软件回答三个问题：团队响应速度有多快、解决问题的效果如何，以及流量来自何处。在这三者之一发生变化之前，看板上的其他一切都只是装饰。

下文覆盖了八个平台，以及值得追踪的指标和那些悄悄浪费注意力的指标。文中不会重现竞品的价格信息。

这一类别衡量什么

有两类产品共用同一个标签。

第一类是内置于支持平台中的报告功能：对话量、响应与解决时间、工作量和满意度，这些数据均取自平台已有的信息。

第二类是专门的联络中心分析软件，专注于语音领域：通话录音分析、语音分析、情绪评分，以及针对大量通话的交互分析。

大多数团队需要第一类，却以为自己需要第二类。这些专业工具的价值，体现在通话量大到平均处理时长每提升一个百分点就相当于一份薪水的场景中，而这样的公司数量远比宣传所说的要少。

实际的分界线在于：语音是众多渠道之一，还是唯一的主渠道。在每月通话量为几千通以下的情况下，支持平台内置的报告功能已经足够。

能改变决策的指标

有四个数字会改变人员配置或流程，值得围绕它们搭建报告。

按小时统计的通话量决定了排班模式。这是支持报告中最具可操作性的单一数字，也是最常被一周平均值抹平到失去意义的数字。

按原因分类的量决定了该自动化什么、该记录什么。一个被一致应用的原因代码，比任何情绪模型都更有价值。

重开率衡量问题解决是否真实有效。解决数量上升的同时重开率也在上升，意味着工单是被关闭而非被真正解决，而只有同时追踪这两者才能发现这一点。

客服人员之间的工作量差异，能区分出是人员配置问题还是分配路由问题。队列均衡但平均时长偏长，需要增加人手；队列不均衡，则需要更好的分配机制。

几乎不起作用的数字

有几个数字出现在每一个看板上，却几乎不会改变任何事情。

工单总数是一个没有分母的量。它会随着客户群增长而上升，也会在业务清淡的月份下降，而这两种变化都不会带来任何决策。

跨所有渠道的平均首次响应时间，会把以秒计的聊天与以小时计的邮件混为一谈。要么按渠道拆分，要么就不要衡量它。

客服排行榜按最容易统计的指标（通常是已关闭工单数）对人进行排名，而这类排行榜必然会诱发它所衡量的那种行为。

在整个周期内笼统评分的情绪指标，不附带原因，只能告诉管理者情绪如何，而无法说明原因。

八个平台一览

RolChat

RolChat将对话、工单、通话、交易和团队绩效的报告统一在一处，因为这五者都存在于同一个平台，而非分散在各个独立产品中。

标准指标集涵盖首次响应时间、解决时间、重开率、CSAT和工作量，可按队列、渠道、客服人员和小时进行切分。

由于语音功能是原生集成的，通话指标与文字指标并列展示，并且AI通话评分会覆盖每一通录音，而非抽样部分。这让质量审查从零散的个案观察，变成对整个周期的完整覆盖。

导出功能遵循权限设置，团队负责人可以只调取自己队列的数据，而无需访问整个公司的信息。报告功能已包含在方案中，而不是作为单独定价的分析层级出售。

最适合：希望在一份报告中同时获得文字和语音报告、而不必在支持平台之外另购分析产品的团队。

Zendesk

在传统帮助台产品中，Zendesk拥有最深入的报告层级，背后有专门的分析产品支持，并且在自定义报告构建方面有着悠久的历史。

对于有分析师专门负责搭建和维护看板的机构来说，其上限相当高。

各项能力分布在不同方案层级中，因此团队设想中的报告功能，可能位于其正在比价的方案之上。

最适合：拥有分析师和明确报告需求的机构。请在Zendesk官网确认各层级具体包含的功能。

Freshdesk

Freshdesk在工单指标方面的报告能力扎实可靠，并且在配合使用更广泛的Freshworks产品套件时会显著提升，因为客户旅程的更多环节会纳入同一数据模型。

单独使用时，它覆盖了基本需求，无需分析师介入。

语音分析通过配套产品提供，而非帮助台本身。

最适合：无需配置即可获得的工单报告。请在Freshdesk官网确认各层级具体内容。

Intercom

Intercom是按对话而非工单进行报告，这适合以消息为核心的运营模式，与帮助台看板的呈现方式有所不同。

其AI报告的细致程度不同寻常，这源于一种商业模式：已解决问题是计费单位。

比较时应留意“解决”一词的具体定义，因为这一定义既决定了报告结果，也决定了账单金额。

最适合：以消息沟通为主、关注自动化覆盖率的运营团队。请在Intercom官网确认具体方案。

HubSpot Service Hub

Service Hub的报告嵌入在更广泛的CRM之中，这是它的独特优势：客服活动数据与营销、销售数据同处于同一条记录之下。

这使得关于营收影响的问题能够得到独立帮助台无法企及的解答。

其权衡也很常见：价值取决于是否采用周边整个平台，报告深度也随方案层级而不同。

最适合：已经在使用该CRM、需要将服务与营收数据整合在一个视图中的团队。请在HubSpot官网确认各层级方案。

Zoho Desk

Zoho Desk提供称职的工单报告，背后有庞大的产品家族支撑，对于已经身处该生态系统的机构而言，其分析功能的覆盖范围远超支持领域本身。

所需的配置投入要高于其价格档位所暗示的水平。

对于使用多个Zoho应用的公司而言，共享的数据模型才是真正的价值所在。

最适合：现有Zoho用户。请在Zoho官网确认具体方案。

Help Scout

Help Scout报告聚焦于一套精简的指标集合，而非面面俱到，这与产品整体风格一致。

对话量、响应时间、满意度和帮助中心表现都清晰呈现，且无需任何设置。

自定义报告构建和语音分析不属于产品功能。

最适合：希望在无需配置的情况下获得清晰数据的以邮件为主的团队。请在Help Scout官网确认具体方案。

Front

Front报告对话数据以及团队活动情况（包括内部协作）,这一点比较少见，在需要共同起草回复的场景中十分实用。

账户级别的视图适合有专属负责人的B2B服务场景。

电话分析功能不在该产品范围内。

最适合：既衡量协作又衡量响应情况的B2B团队。请在Front官网确认具体方案。

呼叫中心与语音分析

呼叫中心分析软件是一个独立的领域，相关术语也值得加以区分。

呼叫中心报告软件覆盖运营层面：通话量、排队时长、放弃率、平均处理时长、占用率和排班遵守情况。这些是人员配置方面的数字，从每天数百通电话起就开始发挥作用。

呼叫中心看板软件是同一数据的实时呈现方式，是为监控现场的主管而非阅读周报的经理设计的。

语音分析则是更上一层：分析的是说了什么，而不是花了多长时间。

对于语音只是众多渠道之一的团队来说，这一层应该内置于支持平台中。购买专门的控制台会拆分报告数据，并产生两个版本的真相。

语音与交互分析

呼叫中心语音分析软件会转录通话内容，然后在转录文本中搜寻规律：关键词、沉默、抢话、升级用语和合规相关措辞。

交互分析则将同一思路扩展到各个渠道，把一次聊天和一通电话视为同一次交互的两种形式，并对两者同时评分。

其实际价值在于覆盖面。人工审查只能抽样覆盖某一时间段的一小部分，而自动化评分则能覆盖全部，这让辅导从依赖零散证据转变为依赖完整证据。

其实际风险在于评分脱离原因代码。知道情绪在周二下降却不知道客户来电的原因，这样的信息毫无用处。

RolChat将转录和AI通话评分作为平台功能，应用于每一通录音，这一层能力对于不需要专门语音分析控制台的团队来说已经足够。

CSAT、NPS与调查工具

CSAT调查工具是当下最廉价的分析投资，也是最常被误读的一种。

支持类调查的回复率往往偏向两极，因此一个分数其实是一种分布，而非单一数字。一个看似稳定的平均分，可能掩盖着不断增长的一星差评比例，这是一种正在恶化、却被报告呈现为平稳的服务。

时机比措辞更重要。在问题解决时发送的调查衡量的是解决本身；一周后才发送的调查，衡量的则是对这次解决的记忆。

按渠道拆分至关重要。聊天渠道和电话渠道的满意度很少同步变化，而混合评分会掩盖究竟是哪一个渠道需要改进。

自由文本评论所承载的信息比分数本身更丰富。阅读五十条评论所获得的信息，比一个季度的平均分还要多，而客户反馈分析软件的存在，主要就是为了让这种阅读变得系统化。

实时看板与周期性报告的对比

这两者服务于不同的人群，混为一谈只会产生一个没人使用的屏幕。

实时看板回答一个问题：现在是否需要介入。队列深度、最长等待时间、可用客服人数。四个数字，字号很大，在房间另一头都能看清。

周期性报告回答的是另一个问题：下个月应该做出什么改变。它需要与往期数据对比、按原因分类，并配有足够的背景信息以支撑招聘论证。

试图兼顾两者的客户服务指标追踪软件，通常会把第二项做得很差，因为实时数字难以支撑起使报告具有说服力所需的历史对比。

为什么一份报告胜过两套控制台

支持领域最常见的分析失败，不是缺少某个指标，而是两套系统各自只掌握答案的一半。

当聊天在一个产品中报告、通话在另一个产品中报告时，响应时间会按不同定义被计算两次，没有人能说清客户端到端的实际体验是怎样的。

同样的割裂也出现在支持报告和销售报告之间。一次由账单工单引发、最终演变成流失风险的对话，如果工单系统和CRM各自保留独立记录，就会变得无从察觉。

整合平台正是让报告变得可信的关键，而这通常也比购买一个用来调和两套系统的分析层更省钱。

这正是支持“报告随平台内置、而非另行外挂”这一主张的理由：不在于它更深入，而在于它更完整。

导出、权限与数据访问

有三个访问相关的问题，决定了报告在支持团队之外是否可用。

导出是否遵循权限设置，让团队负责人能够只调取自己队列的数据，而不会看到整个公司的信息。原始数据是否能以可用的格式导出，而不仅仅是渲染好的图表。以及是否有API可以让这些数字接入全公司范围的看板。

数据保留设置决定了对比可以追溯多远。一个只保留九十天数据的平台，无法回答关于去年的问题，而这一限制通常是在问题被提出的那一刻才被发现。

定时邮件报告仍然是让数字真正被查看的最可靠方式，因为看板需要有人记得主动打开它。

在签约之前，还值得问一个访问相关的问题：导出内容是否包含平台后来新增的字段，而不仅仅是最初就有的字段。承载原因代码的自定义字段，通常是文件中最有价值的一列，却也是最常被遗漏的一列。

搭建真正会被查看的报告体系

大多数支持类报告都是配置一次之后就被搁置不理。有几个习惯可以避免这种情况。

从决策出发，而非从指标出发。如果一个数字不会改变排班、规则或招聘决定，它就不需要一张图表。

在搭建其他任何内容之前，先统一应用原因代码。所有后续分析都依赖于此，而在一年的历史数据上再补充原因代码是不可能实现的。

初期每周复盘，规律稳定后改为每月复盘。每周复盘正是能捕捉到某条路由规则悄悄失效的关键。

迁移后的第一个月，与旧工具进行对比。不同平台的定义各不相同，响应时间的下降有时只是计时起点发生了变化。

预测与产能规划

报告解释的是过去；而预测，是把过去转化为排班表的关键。

所需的输入包括：数周内按小时统计的通话量、按渠道划分的平均处理时长，以及一名客服人员能够持续承受的并发量。聊天可同时支撑三到五段对话，语音只能支撑一段，把二者平均计算，得到的排班表在两方面都会失灵。

季节性规律需要一整年的历史数据才能看清。保留期短于此，会让年度高峰在到来之前一直隐而不见，而这是支持领域中代价最高昂的一种意外。

损耗率是大多数计划都会遗漏的一个数字：培训、休息、会议和缺勤，通常合计占到有薪工时的四分之一，仅按原始人头数搭建的排班表，从一开始就不够用。

工作时长和排班遵守情况需要与队列纳入同一系统，否则计划与现实会在一个月内就出现偏差。

归因：支持部门的价值

支持类报告通常止步于效率指标，这会让该部门显得像一个成本中心，因为效率是唯一被统计的内容。

有三种关联能够改变这种论调。与交易关联的对话，展示了支持部门挽回或推动了什么。与流失关联的对话，展示了它未能挽回什么。而与原因代码关联的对话，则揭示了是哪种产品问题在制造这些流量。

如果客户记录和对话记录分处不同系统，这三者都无法实现，因为关联要么靠人工完成，要么根本无法完成。

这正是支持“CRM与客服共用同一条记录的平台”这一主张最有力的实际论据：不在于便利性，而在于能够回答这项工作到底价值几何。

分析中的人工智能

AI驱动的对话分析平台承诺能读取每一次交互，而它们在很大程度上确实能做到这一点。问题在于它们是为了读出什么。

分类是最可靠的用途：无需客服人员打标签，就能按原因对对话进行分组。这消除了每一条报告链中最薄弱的一环，在时间压力下进行的人工打标签。

摘要生成是第二个可靠用途：把一段冗长的会话浓缩为实际发生的内容，让大批量审查成为可能。

情绪分析是宣传最多、单独使用时最缺乏可操作性的一项，因为没有原因的情绪无法支撑任何决策。与原因代码搭配使用时，它才变得有用。

依据评分标准打分是第四种用途，也是把质量保证从抽样变成全面普查的关键。RolChat将这一能力作为平台功能，应用于每一通通话录音。

基准值及其真正价值

已发布的支持行业基准值，是这一领域中被引用最多、却也最没有用的数字。

它们把预期各不相同的行业平均在一起，把计时方式不同的渠道平均在一起，把对“解决”定义不同的公司也平均在一起。以这种方式得出的数字，描述的其实是谁都不是的对象。

唯一站得住脚的基准，是你自己的历史数据。上个季度、去年同期，以及某次变更前的那一周，这三种对比才真正有意义。

在确实需要外部数字的场合，把它当作方向参考而非目标：了解到聊天响应在整个市场普遍以秒计算是有价值的，但把某个具体数字奉为目标就没有意义了。

唯一的例外是合同约定的情形。写入客户协议的SLA,无论任何基准值怎么说，都是必须达成的目标，报告必须依据合同自身的定义来衡量，而不是平台的默认定义。

常见问题

Ruslan Nazarov

RolChat SEO 负责人

撰写关于客户支持运营、在线聊天、AI 辅助服务，以及支撑优质客户体验的工具。

LinkedIn