外包IT服务台的首次接触解决率

要点：“首次接触解决率达到90%”并不是一个数字，而是至少三个：取决于什么算“接触”、什么算“解决”、哪些工单算“符合条件”。招标之前，先把定义、分母和审计权写清楚，并让重开率、应答时间与它并列。服务台能在首次接触解决的，只能是它被允许、也有工具去处理的那部分问题。

设想一家总部在香港、约几百名员工的集团，在新加坡和中国内地设有办事处，打算把整个IT服务台对外招标。招标文件写得很细，但分量最重的只有一行：“一线解决率不低于90%，7×24小时，中英双语”。三家投标方都回答“可以”。信息部负责人手里有三份承诺，却不知道这三个“可以”是不是同一回事。

这家集团是说明性的综合场景，并非具体客户，本文也无意讲它的故事。本文是一份围绕这个数字本身的实操指南：首次接触解决率到底在量什么、怎样被做高、真正能提升它的因素是什么、哪些指标必须与它并列、怎样写进合同、月报应当展示什么。如果您正在比较几家外包服务台，读完之后应当能分辨什么是诚实的90%，什么是方便的90%。

为什么招标书要写“一线解决率90%”，为什么每家投标方都答“可以”？

买方把首次接触解决率写进招标书，理由很充分。它一句话就能说清，听上去又像是能力的体现：接电话的人把问题解决了，没有人需要等待。它还像是成本的替身，因为每一张在不同层级之间来回传递的工单，都会占用更多昂贵工程师的时间，也消耗您自己同事的耐心。

投标方答“可以”，原因却不一样。这个说法没有唯一的出处。ITIL没有规定唯一的定义，各种工具的统计口径也各不相同，而回应招标的销售团队自然会选一种自己能够满足的解释。回答“可以”的投标方通常并没有说谎，只是回答了一个与您心里所想略有差别的问题。

所以三个“可以”至少可能在四个地方不一样：什么算一次“接触”，什么算“已解决”，哪些工单进入统计，以及由谁来判定这一切。本文后面依次讨论这四点。在这个说明性的集团里，买方第一件有用的事，不是挑数字最大的投标方，而是请每家投标方把定义这个数字的那句话写下来。

首次接触解决率到底在衡量什么？

最简单的说法是一个分数：在首次接触中解决的工单数，除以本可以被解决的工单数。这句话里的每个词都是一个决定。目前常见的定义有三种，彼此差异足够大，同一个服务台、同一个月的工单，按不同定义算出来的结果可以明显不同。

定义A：在第一次交互中解决

这是最严格的理解。用户联系服务台，坐席在这一次对话里把问题解决，没有转接，没有回电，也没有“我们稍后回复您”。通话中完成的密码重置算数。需要坐席先去查证再答复的问题不算，即使二十分钟后坐席把它解决了。

这个定义最接近终端用户听到这个词时的想象，也最难达到。它同时最能反映用户的实际体验，因为用户的计时是在对话结束时停止的，而不是在之后某个时间点。

定义B：由一线解决，不限时间和次数

这种说法更准确的名称是一线解决率，或第一级解决率。工单由一线解决，没有转给二线或三线，但可以有多次接触：一次电话、一条跟进消息、第二天早上的一次远程会话。它衡量的是一线能承担多大比例的工作量，而不是用户多快被解放出来。

这是一个正当的指标，往往也是衡量成本的合适指标，但它与“首次接触”并不相同。如果投标方把它冠以更严格的指标名称来汇报，数字看上去会比实际表现好。

定义C：没有升级到更高层级或第三方

这是最宽泛的理解。凡是没有离开一线团队的工单都算，包括坐席向同一层楼的资深同事请教的工单，也包括一线等了用户三天才得到回复的工单。它几乎说明不了速度，却能说明团队结构：它奖励的是由资深人员组成、并被标注为“一线”的团队。

哪些工单算数？

即使定义相同，统计范围也很关键。只算故障，还是连服务请求也算？密码重置和账号解锁这类又快又多的工单是否计入，还是被当作“不算真正的故障”而剔除？“怎么操作”的咨询是否计入？由监控系统而不是由人发起的工单是否计入？每一种选择都会改变数字，原则上没有一种是错的。它们只在没有被明说的时候才是错的。

分母是什么？

差异最大的地方往往藏在这里。一种选择是服务台处理的全部接触。另一种是“符合首次接触解决条件”的接触，也就是供应商自己判断有可能在首次接触解决的那部分。后一种做法通过剔除难题工单来缩小分母，而分母变小，百分比就会升高，哪怕没有多解决一张工单。买方应当把“范围内全部接触”之外的任何分母，都视为必须配上书面符合条件清单的事项。

由谁来分类？

最后一个问题是，谁来判定什么算已解决、什么算符合条件、什么算一次接触。如果供应商的坐席在供应商自己的系统里给自己的工单分类，又没有任何第三方抽查，那么这个数字既反映供应商的表现，也反映供应商的裁量。这并不是针对某一家供应商的批评，而是一个结构性事实，合同必须处理它。

举个说明性的例子：想象这个综合场景集团的服务台，同一个月的工单。按定义A算出一个数字，按定义B算出更高的数字，按定义C算出还要更高的数字，再在分母上加一道“符合条件”的筛选，数字又会上升。这里有意不给出具体数值，因为任何数值都只是为这个综合场景编出来的，不具备市场意义。重点只在于：在这四个选择被写下来之前，招标书里的三个“可以”无法相互比较。

首次接触解决率是怎样被做高的？

大多数“做高”并不是欺诈，而是一套指标体系在忙碌的团队身上，自然而然地朝着目标漂移。买方了解这些模式，评标时就能问出对的问题。

重新分类为“不符合条件” — 难题工单在登记时被标记为项目、变更或“复杂故障”，因此不进入分母。百分比提高了，其他一切都没变。
过早关闭再重开 — 工单在第一次答复后就被关闭，理由是问题如果还在，用户自己会重开。如果重开被记成一张新工单，第一张算成功，第二张又是一次新的成功尝试。
把一个问题拆成几张工单 — 一次故障，例如笔记本既连不上网络也收不了邮件，被拆成三张工单，其中两张很快就能处理。工单量上升，快速解决的占比也跟着上升。
“已解决”其实是“给了临时办法” — 坐席提供一个临时处理方式，工单按已解决关闭，根本原因无人跟进。用户满意了一天。
排除渠道 — 只统计电话，不统计在线聊天、邮件和到访请求，或者反过来。哪个渠道最容易解决，就把哪个渠道算进去。
把一线自己的升级也算成一线 — 一线坐席请同一个团队里的资深同事帮忙。工单在系统里没有换负责人，因此仍然是“一线”，尽管答案来自更资深的人。

这些做法都不需要恶意。只要您索取正确的证据，它们全部可以被看见，这也是本文后面的部分把更多篇幅花在审计和报告上，而不是目标本身。

什么才能真正提高首次接触解决率？

目标本身不会解决工单，解决工单的是有工具、有权限的人。能够推动首次接触解决率的因素大多是结构性的，买方在签约前可以逐项发问。

知识库与一线可以执行的脚本

一线坐席只能解决他们知道怎么解决的问题。这意味着需要一个有人维护、可以检索、以步骤而不是长篇议论来书写的知识库，以及坐席凭现有权限真正能执行的脚本或操作手册。需要索取的衡量不是知识库有多大，而是上个月新增或修订了多少篇文章，由哪些工单类别触发。

一线的管理权限

这是一线无法关闭工单最常见的单一原因。如果坐席不能重置密码、重新登记多重身份验证、分配许可证、修改邮箱权限，也不能在用户同意的前提下远程控制设备，这些工单就必须转给其他层级，无论坐席多么熟练都改变不了。问投标方的问题不是“您有多少坐席”，而是“这些操作中，哪些您的一线在我的租户里第一天就能做，经过什么审批，留下什么审计记录”。

语言匹配

同一班次里同时能处理粤语、普通话和英语的服务台，首次接触解决的比例会高于把粤语来电转入回电队列的服务台。对于一家在香港、新加坡和中国内地都有办事处的集团，语言不是客套，而是决定坐席第一次就能不能听懂症状。要问的是哪个班次配备了哪些语言，而不是公司“支持”哪些语言。

终端可见性与远程支持工具

坐席如果能看到设备的状态，包括磁盘、补丁级别、安全状态和最近的变更，几分钟内就能诊断出本来需要向用户连问许多问题才能得到的结论。坐席如果能在用户在场的前提下发起征得同意的远程会话，一次对话就能修复本来需要上门或者长时间电话指导才能完成的问题。这一块工具的影响最大，下文的衔接部分会更详细地讨论。

工单系统集成，让坐席看得到历史

如果坐席能看到同一位用户上个月已经两次报过同样的故障，对话就会变化：跳过基础步骤，直奔原因。这要求服务台在一套正规的ITSM平台里工作，或与之集成。如果供应商用自己的系统、您的内部团队用您的系统，历史对话的一方就是看不见的。

哪些指标应该与首次接触解决率并列？

单独看首次接触解决率是危险的，因为可以通过让其他一切变差来改善它。它需要方向相反的搭档指标。

重开率 — 这是诚实性检验。关闭得快、重开率又高的服务台，并没有真正解决任何东西，只是把工作挪了个地方。要求在同一份报告里、同一个期间、按明确的重开窗口给出重开率。
应答时间与放弃率 — 服务台可以让难接的电话被放弃，来换取一个好看的解决率。应答时间告诉您人们等了多久，放弃率告诉您有多少人放弃了。博迅有一个数据点，需要说明它是什么：其7×24多语种服务台90%的来电在40秒内接听。这是应答时间指标，不是解决率指标，两者不能混为一谈。
按优先级的解决时间 — 平均值会掩盖长尾。按优先级拆分解决时间的报告，能看出紧急故障是否被区别对待。优先级阶梯本身可参阅我们关于P1至P4优先级的文章。
每张工单的客户满意度 — 关闭后一个简短的问题，与工单关联，让较差的评分可以追溯到具体的某次处理。工单级别的满意度，比月度平均值难以修饰得多。
升级率 — 它是一线解决率的互补，但值得按类别单独汇报。它显示一线承担不了哪几类问题，而那正是下一篇知识库文章或下一项权限调整应该出现的地方。
积压工单的年龄 — 最老的未关闭工单有多老，超过约定期限的有多少张？只在已关闭工单上计算的解决率，对未关闭的工单什么也说明不了。

这些指标放在一起，90%这样的数字就更难被操纵，因为以牺牲一项换取另一项的改善，会在同一张表里显现出来。

怎样把首次接触解决率写进合同？

招标书里的目标只是期望，合同里的条款才是义务，而条款的质量取决于定义。评标时，请投标方就下列每一项给出合同措辞草案，因为供应商愿不愿意为措辞作出承诺，比那个数字更能说明问题。

定义条款 — 用一句话写明采用上述三种定义中的哪一种。如果供应商提出另一种，这个提议本身就是信息。
事先约定的符合条件清单 — 列出范围内的工单类别，并单独列出被排除的类别及理由。清单的变更需要双方同意，而不是单方通知。
分母 — 除非符合条件清单另有说明，分母为所有渠道上范围内的全部接触。
数据来源 — 数字是依据供应商的ITSM还是您的ITSM计算？如果是供应商的，客户是否对原始工单数据有只读权限？基于您可以检查的数据计算出来的结果，比PDF里的一个数字有价值得多。
对工单样本的审计权 — 客户每月可以随机抽取一批已关闭的工单，对照定义进行检验。没有审计权，定义只是装饰。
重开窗口 — 工单只有在规定期限内（例如五个工作日）没有被重开，才算在首次接触解决。仅这一条就能去掉大部分过早关闭的动机。
爬坡期 — 在最初的90天里，服务台正在了解您的环境、应用和人员。合理的合同会允许爬坡期：目标照常报告但不强制执行，之后再强制执行。
服务抵扣应该与什么挂钩，不应该与什么挂钩 — 把抵扣挂在首要百分比上很诱人，但那也正是做高数字的动机最强的地方。抵扣通常更适合挂在难以操纵的指标上，例如应答时间，而对依赖分类的数字则要慎重。我们另有专文讨论SLA服务抵扣与履约保证金如何落实，本文不再重复。

招标期间有一个好用的测试：把同一份条款草案发给三家投标方，不仅比较他们的答复，也比较各自用了多久回复、想改多少内容。

月报应该展示什么？

合同定义数字，月报则证明数字。只展示一个首要百分比的报告，应当视为警示信号；能让您自己重新算出这个百分比的报告，才是有底气的表现。至少应要求以下内容：

按渠道和语言划分的工单量 — 电话、在线聊天、邮件、门户，以及任何到访或驻场请求，并按语言拆分。这能告诉您被统计的人群是否就是全部人群。
按约定定义计算的首次接触解决率 — 旁边列出被排除的类别及各自的工单数，让排除项一目了然，而不是被掩盖。
重开率 — 与合同中相同的期间和相同的窗口。
应答时间 — 包括放弃率。如果引用了来电接听数据，就要注明它是应答时间指标。
前十大工单类别 — 这是报告里最实用的一页，因为它显示下一步改进该从哪里来：一篇知识库文章、一项权限、一个自助流程，或一个根治办法。
新增或修订的知识库文章 — 证明服务台在学习您的环境，而不只是在其中回答问题。
被审计的工单样本 — 一份由客户或按明示的随机方法选出的工单清单，附带处理历史，让数字能够对应到真实的对话。

这样的报告需要花工夫来做。这正是重点：能够例行产出它的供应商，已经养成了诚实度量的习惯。

买哪一种定义？三种定义逐项对照

各自统计什么、隐藏什么、什么时候适合

A. 在第一次交互中解决 — 统计一次对话内、没有转接或回电就关闭的工单。它对一线跨多次接触能承担多少工作量说得很少。当您最关心用户体验和损失的时间，并且工单中有相当一部分是可以当场处理的常规问题时，选这一种。
B. 由一线解决，不限时间 — 统计一线关闭的工单，无论经过几次接触。它隐藏了解决得慢的情况，因为拖了一周的工单照样算，也隐藏了接触之间的返工。当您最关心成本和高层级工程师的负荷时，选这一种，并搭配解决时间和重开率一起看。
C. 没有升级到更高层级或第三方 — 统计所有没有离开一线团队的工单。它隐藏了一线内部的资深协助、用户的长时间等待，以及真正有专业能力的团队与仅仅被标注为一线的团队之间的区别。只有在同时拿到一线人员配置的清楚说明时才选这一种，单独使用时它是三者中最弱的。

如果综合场景招标中的三家投标方按三种不同的定义汇报，诚实的比较方式是请每一家在一套共同的工单类别上，按A和B重新给出结果，并写明分母。

服务台能在首次接触解决的，是否只限于它被允许处理的？

是的，这是指标与服务构建方式之间的衔接点。服务台能在首次接触解决的，只能是它被允许、也有工具去处理的那部分。如果管理权限、设备可见性和工单历史分散在三个地方、由三个不同的负责方掌握，一线即使能力很强，也关不掉工单。

在按用户计费的管理型IT外包服务方案里，这些环节是一起设计的。博迅的7×24多语种服务台是基于ITIL的全球服务台，从中国内地、香港和马来西亚的中心运营，每年处理约15,000起IT故障和服务请求。它使用普通话、粤语和英语，配备一线至四线工程师，拥有150多名服务台人员，持有涵盖70多个领域的认证。服务范围包括故障与问题管理、变更管理、入职与离职办理、Mac和Windows的远程工作站管理、供应商协调以及月度SLA指标报告，并可与ServiceNow、ManageEngine ServiceDesk Plus和Jira集成。如果无法远程解决，会升级为上门派单。也提供外包和白标服务台。

博迅没有公布任何首次接触解决率的百分比，本文也不会编造一个。博迅公布的服务水平数字是应答时间：90%的来电在40秒内接听。如果您问现实的首次接触解决率是多少，我们自己的专业看法是：这完全取决于定义和工单构成，这就是为什么条款比数字更重要。

在终端一侧，BCS Beam是一个经过签名的代理程序，提供先征得同意、全程可审计的远程支持：屏幕协助、后台维护、桌面内聊天，以及一键生成、限时有效的邀请。每一次会话都会显示在系统托盘里，并与对应工单绑定。同一个代理程序持续进行只读的安全与健康审计，涵盖磁盘加密、防病毒、防火墙和补丁状态，因此电话另一端的坐席在问第一个问题之前，就能看到设备的状态。连接审计台账记录谁在何时、以何种模式、为哪张工单连接了哪台设备，服务运行在博迅位于香港的自有基础设施上。这份台账也让合同里的审计权在实际中可行。

合在一起，服务台、终端代理、管理权限和月报是一台发动机，而不是四项各自采购的东西。这就是为什么一个管理型的安排能够对一线的可衡量解决作出承诺，而一个被硬接到自己碰不到的环境上的外包服务台做不到。

常见问题

现实中的首次接触解决率是多少？

没有定义，就没有诚实的答案。同一个服务台、同一个月，按是只统计第一次交互、统计一线关闭的全部工单，还是统计未升级的全部工单，以及密码重置和操作咨询是否在分母里，报出的数字可以相差很大。博迅没有公布首次接触解决率。我们自己的专业看法是：请每家投标方在指明的定义和约定的工单清单下给出数字，再与重开率一起判断。

密码重置算不算？

如果它在约定的工单范围内就应该算，合同也应该写明。密码重置和账号解锁又快又多，几乎都在首次接触中解决，因此会把百分比拉高。这并没有错，但意味着包含它们的数字，与排除它们的数字无法比较。请要求提供包含和不包含它们两种结果，并约定合同采用哪一种。

语言对首次接触解决率有什么影响？

影响很大，尤其对一家业务横跨香港、新加坡和中国内地的集团。如果坐席听不懂用户描述的症状，工单就会进入回电队列或转给另一位坐席，这次接触就不再是首次接触。请问清楚每个班次配备哪些语言。博迅的服务台使用普通话、粤语和英语，但对任何投标方都应当问的是：您的用户实际来电的那个钟点，值班的是谁。

首次接触解决率应该挂服务抵扣吗？

要谨慎。挂在依赖分类的百分比上，会给供应商最强的动机去宽松地分类。如果确实要挂，应与约定的定义、固定的符合条件清单、重开窗口以及您抽查样本的权利绑在一起。更难操纵的指标，例如应答时间，往往是更安全的抵扣触发条件。抵扣与履约保证金的具体机制，请参阅有关SLA落实的相关文章。

首次接触解决率如何审计？

靠抽样。每月，客户随机抽取一批已关闭工单，或按约定方法选取一批，逐张对照合同定义检查：是否在第一次交互中解决，是否在窗口内被重开，分类是否正确。这需要对工单数据的只读权限，对于远程会话，还需要有谁连接、为什么连接的记录。与工单绑定的连接审计台账有帮助，因为它显示设备上实际发生了什么。

首次接触解决率和一线解决率有什么区别？

首次接触解决率讲的是时刻：问题在第一次交互中解决。一线解决率讲的是层级：问题由一线解决，不管需要几次交互。它们回答不同的问题，一个关于用户体验，一个关于一线能承担多少工作；招标书把两个词混用，就给数字出现差异留了空间。请写明您指的是哪一个。

7×24小时覆盖会改变首次接触解决率吗？

它改变的是什么可以被合理地比较。一个全天候有人值守、但只有办公时间才有资深工程师的服务台，凌晨三点和上午十一点的解决情况会不同。请要求按班次或时段给出数字，并确认夜间的语言配置和管理权限安排与白天相同。全天候覆盖扩大了接触的人群，它本身并不会提高解决的占比。

在线聊天的工单可以统计首次接触解决率吗？

可以，而且如果在线聊天是您的用户会用的渠道，就应该统计。聊天让定义更难，因为一场对话可以中断几个小时仍然是同一张工单。请在合同里约定，中断后恢复的聊天算一次接触还是两次，并确保聊天在分母里。把最容易解决的渠道或最难解决的渠道排除在外，是数字悄悄漂移的最隐蔽的方式之一。

下一步怎么做

如果您正在起草招标书，实际的步骤很短：把定义写进招标文件，列出符合条件的工单类别，写明分母，要求上文的报告格式，并保留抽查样本的审计权。然后比较投标方对这些措辞的反应，而不是他们报出的数字。

如果您更希望服务台、终端代理、管理权限和月报以一项服务的形态交付，这正是按用户计费的管理型IT外包服务方案的用途，7×24服务台和BCS Beam包含在其中，或作为该方案的附加项提供。您可以在价格页面了解定价，也可以联系我们，带上您目前的工单类别，我们会先和您一起把定义问题梳理清楚，再谈任何百分比。