首次呼叫解决率FCR：定义、公式与提升方法

一句话版本： 首次呼叫解决率（FCR）是指在第一次联系中就被彻底解决的支持请求所占的比例，不需要再次来电、重新打开工单或转交他人。在IT支持中，FCR = 首次联系即解决的请求数 ÷ 同期处理的全部请求数。在报出数字之前先约定统计口径，因为口径对结果的影响比团队本身还大。

问一位IT服务台经理，哪个指标最能说明服务台是否运转良好，许多人会回答首次呼叫解决率。它容易解释，符合用户的期待（一次就修好），而且会随着培训、工具和知识库的改善而变化。但它也很容易被量错。本文说明FCR的含义、FCR怎么计算、哪些因素在驱动它，以及怎样在不“做数字”的前提下提高它。

外部定义我们在2026年10月28日查阅过：维基百科“First call resolution”词条（2026-10-28查证）。涉及博迅（Brocent）如何公布承诺的内容，取自我们的SLA页面。

什么是首次呼叫解决率？

维基百科该词条（2026-10-28查证）把首次呼叫解决率，即首次联系解决率（FCR），描述为衡量呼叫中心能否在第一次来电或联系中就解决客户问题、从而不需要后续联系的指标。词条还指出，理想的FCR是从客户的角度看，不需要重复来电或联系。

词条区分了同一个概念的两个名称：

首次呼叫解决率（first call resolution）： 针对呼叫中心，也就是语音来电来衡量。
首次联系解决率（first contact resolution）： 针对任何渠道来衡量，如在线聊天、电邮、门户或电话。

对IT服务台来说，第二种理解更有用。用户通过电话、在线聊天、电邮、工单门户，有时还有到场柜台联系服务台，所以我们用“FCR”指任意渠道的首次联系解决，只有渠道确实是语音时才说“呼叫”。

有三个相近的词容易与它混淆：

一线解决率： 工单由第一支持级别（L1）解决，没有转给L2或L3。工单可能经过三次沟通才在L1解决，所以这与FCR不是一回事。我们的L1、L2、L3支持级别一文说明了各级别。
平均解决时间： 从登记到解决所经过的平均时间，见MTTR、MTBF与MTTA解读。它衡量速度；FCR衡量是否一次联系就够。
重开率： 已解决的工单又被重新打开的比例。它是FCR的镜像，两者应一起解读。

FCR怎么计算？

公式很简单：

FCR = （首次联系即解决的请求数 ÷ 同期处理的全部请求数）× 100

举一个演示算术的例子（数字为虚构）：某月服务台处理了200个请求。其中130个，用户没有就同一问题再次联系服务台，工单也没有被重开。FCR就是130 ÷ 200 = 65%。

难点在于判定什么算“首次联系即解决”。这些点要一次定下来，写下来，并保持稳定。

什么算请求？ 是事件和服务请求都算，还是只算事件？密码重置和服务器故障都是工单，但表现很不一样。许多服务台会把两者的FCR分开报告。
重复窗口多长？ 如果同一用户在比如两个工作日内就同一问题再次联系服务台，算不算重复？维基百科词条指出，“在给定时间范围内没有重复来电”是最常用的方法之一；窗口多长由你定，但必须事先固定。
谁来判断是同一个问题？ 除非系统能自动匹配，把后续联系关联到原工单就需要人工判断。要定好由谁来做、怎么做。
转交算不算失败？ 如果L1把工单转给L2，用户再也不用来电，这算首次联系即解决吗？多数定义认为不算，因为第一次联系并没有解决它。请明确你的立场。
哪些工单要排除？ 计划内的工作、主动监控告警，以及代别人登记的工单，通常不应计入。把排除项列出来。

FCR怎么衡量：看系统数据，还是看客户的感受？

维基百科词条（2026-10-28查证）介绍了两类方法。内部方法衡量运营表现：坐席记录、语音分析、质检、被重开的问题，以及统计重复来电量。外部方法则询问客户，例如通话后调查。词条还指出，FCR最好从客户的角度判断，因为只有客户才知道问题是否真的解决了。

对IT服务台来说，务实的做法是两者结合：

系统信号： 在重复窗口内，同一用户没有就同一主题重开或新建工单。成本低，覆盖每张工单。
客户信号： 关单后问一个问题，例如“您的问题在这次联系中是否已彻底解决？”要抽样，因为每次都问每个用户会让人厌烦。
对账： 每季度对比两者。如果系统显示70%而用户反馈55%，说明服务台在关闭实际上没修好的工单。

IT支持的FCR达到多少算好？

没有放之四海皆准的数字，我们也不会给出一个。公开的基准常把不同类型的呼叫中心混在一起，而主要处理密码重置的IT服务台，得分会高于支持复杂业务系统的服务台。判断一个数字，更好的办法是：

与自己的历史比较， 用相同的统计口径。
按类别比较。 密码重置、权限申请和软件安装，多数应在首次联系解决。网络故障和应用报错往往做不到。
与重开率和用户满意度一起看， 且针对同一批工单。FCR高而重开率也高，说明工单被关得太早。

FCR是衡量服务台及其改进工作的指标，通常不是合同承诺。维基百科的SLA词条确实把首次呼叫解决率列为SLA常用的指标之一，但大多数IT支持SLA承诺的是响应时间和解决时间，见我们的IT支持中的SLA是什么。FCR通常作为质量指标，出现在这些目标旁边的月报里。

哪些因素影响首次呼叫解决率？

有七件事对FCR的影响最大。多数都关乎如何装备第一个接手请求的人。

1. 第一线坐席用得上的知识

如果常见问题的解法只在某个人的脑子里，就只有那个人能在首次联系中解决。有人维护的知识库、写给一线坐席的简短步骤，能让任何人解决常见问题。过期的文章和没有文章一样，会拉低FCR。

2. 权限与访问

坐席能诊断问题，却不能重置密码、解锁账号或修改权限，就只能把工单转出去。梳理一线被允许执行的日常操作，把能够安全委托的权限开放出来，并保留日志。

3. 远程工具

能（在用户同意下）看到用户屏幕或接管设备，会把许多“请描述您看到了什么”的对话变成几分钟内的修复。对分散办公的团队来说，这往往是单项最大的因素。

4. 培训和技能覆盖

一线坐席应该对最常见的二十类问题了然于胸。与L2工程师结对工作、每次重大变更后的简短复训，以及一张清楚的“谁懂什么”的图，能让首次联系更有成效。

5. 第一次沟通的质量

在对的时机问对的问题，能省掉第二次来电。为常见类别准备一份简短的话术，涵盖什么变了、何时开始、还有谁受影响、用户已经试过什么，可避免后续再把同样的问题问一遍。

6. 分类和路由

工单分类错了，就会落到解决不了的人手里。清晰的分类与路由规则，最好链接到优先级定义（参见严重程度与优先级的区别一文），能让合适的人在首次联系时就介入。

7. 请求的构成

支持标准设备、受管理应用的服务台，在首次联系中解决的会比支持一堆老旧系统的更多。这不是忽视FCR的理由，而是要拿同类比较、把这个数字当作“复杂度在哪里”的地图的理由。

哪些请求通常能在首次联系解决，哪些不能？

请求的构成解释了FCR的大部分差异，所以在设定任何改进目标之前，先把工单按类型分一分。

通常能在首次联系解决： 密码重置和账号解锁、遵循标准审批的权限申请、从批准清单安装软件、已有固定解法的打印机和网络驱动器问题，以及操作咨询。
有时能在首次联系解决： 邮件和Microsoft 365问题、设备变慢、VPN问题和应用报错。这取决于知识库和远程工具的质量。
很少能在首次联系解决： 需要更换部件的硬件故障、运营商网络内部的故障、厂商软件的缺陷，以及任何需要变更窗口的事项。

对第一类而言，FCR偏低说明存在流程或权限问题，是可以解决的。对最后一类而言，FCR偏低是预料之中的事，更好的问题是工单多快带着正确的信息到达正确的人手里，这正是L1、L2、L3支持级别和升级矩阵模板要解决的。

如何提高首次呼叫解决率？

按顺序逐步做。每一步都比招人便宜。

量出基线。 先按前面一节定好统计口径，在改动任何东西之前量一个月。
找出重复联系最多的前十个类别。 把需要多次联系的工单按类别排序，最大的几类通常占了大部分差距。
为每一类写出或修订知识库文章。 保持简短：症状、快速检查、修复方法，以及何时升级。指定负责人和复审日期。
开放安全的操作。 对每个类别，列出L1目前不能做的操作及原因。清除出于习惯而存在的障碍，对其余的设计成有脚本的转交。
给一线配备远程工具和设备信息。 让资产和用户信息直接显示在工单上，坐席不必再去询问。
加一份简短的首次联系检查清单。 要问的问题、要收集的证据，以及升级前要试什么。并加一条规则：升级的工单必须带上下一位工程师需要的全部信息。
和用户确认后再收尾。 关单前确认修复，并与用户约定重复窗口，使再次联系被记录在原工单上。
每月复盘。 看按类别的FCR、重开率，以及本可在首次联系解决的升级。把心得写回知识库。

需要升级时，要干净利落。我们的升级矩阵模板说明了联系谁、何时联系，让无法在首次联系解决的工单，也能不再重复提问就继续推进。

追求FCR有哪些陷阱？

一个可以用错误手段轻松达成的目标，就会被错误手段达成。要留意：

提前关单。 如果只奖励FCR，坐席会在用户确认之前就把工单标为已解决。把FCR与重开率、客户确认搭配使用。
挑软柿子。 回避复杂来电的坐席会抬高自己的FCR，把难做的活推给同事。要按类别报告FCR，而不是只报一个数字。
与通话时长对着干。 缩短通话的压力和首次联系即解决的要求，方向相反。多花十分钟但免去第二次来电的通话，整体上更便宜。
把转交算作成功。 匆匆看一眼就转出去的工单，不是首次联系解决。要定义清楚，并抽样检查。
忽略用户。 工单系统里修好了，用户那边却不行，用户只能再次来电，于是系统显示一张已解决的工单，用户却觉得失败。
把FCR当成质量的替身。 服务台可以FCR很高，却一直在处理错误的事情，例如每周都修同一个问题而不消除根因。那属于问题管理，见我们关于重大事件管理流程的文章。

FCR与SLA、外包是什么关系？

FCR和SLA目标衡量的是不同的东西。响应和解决目标按优先级承诺速度；FCR描述的是首次联系够用的频率。两者都重要，而且相互影响：首次联系解决得更多的服务台，需要升级的更少，这就保护了那些确实要升级的工单的解决目标。各个优先级分别承诺什么，见IT 支持 SLA 里的 P1 到 P4 优先级。

IT支持外包时，问服务商怎样衡量FCR、用什么统计口径、这个数字是否出现在月报里。答案会告诉你，服务商把服务台当作一项服务，还是一个工单队列。还值得问的是，服务商把哪些日常请求从头到尾处理完。我们的SLA页面把密码重置和用户管理列为日常（P5）请求，24×7服务台支持介绍了处理它们的服务台。服务如何融入更大的合同，见管理型IT外包服务方案。我们的管理型IT外包服务方案与按人头定价把公布的响应承诺与各档套餐价格放在一起。这些页面上我们没有公布FCR数字，本文的任何内容也不应被理解为这样的数字。