首次呼叫解決率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數字，本文的任何內容也不應被理解為這樣的數字。