外判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包含在其中，或作為該方案的附加項提供。您可以在價格頁面瞭解定價，也可以聯繫我們，帶上您目前的工單類別，我們會先和您一起把定義問題梳理清楚，再談任何百分比。