L1、L2、L3 支援分級詳解：各級做什麼，工單怎麼交接

先說結論： L1（一級、tier 1）支援是第一線：登記工單、判斷問題，並解決常規問題。L2 處理需要更深技術工作或更大權限的問題。L3 是專家層，處理最難的故障，常常要和廠商或研發工程師一起工作。好的分級模型有明確的轉入規則、書面的交接記錄和規定的時限，所以工單能很快往上走，而不是在各級之間踢來踢去。

如果你提過 IT 工單，又看著它在幾個人之間流轉，每個人對同一份工作有不同叫法，那你就接觸過分級支援。L1、L2、L3（或 tier 1、tier 2、tier 3）這些標籤，是 IT 服務管理裡最古老的概念之一，現在大多數服務台依然用它們來說明「誰做什麼」。標籤很簡單，做法卻不簡單，因為真正的工作在交接上：每一級在升級之前承諾做什麼，又把什麼交給下一級？

本文說明每一級做什麼，工單怎樣從一級轉到下一級，以及把部分 IT 支援外判的企業，通常怎樣在自己與服務商之間劃分各級。凡是講通行模型的地方，我們都引用公開來源並註明閱讀日期。凡是講「應該向服務商問什麼」的地方，我們也會說明，因為各家服務商的人員分級方式不同，我們不能替別人下斷言。

L1、L2、L3 在 IT 支援裡是什麼意思？

它們是三個技術深度的層級。用戶的問題從能合理解決它的最低一級進入，只有當這一級解決不了時才往上轉。

維基百科的「Technical support」條目（我們在 2026 年 10 月 28 日讀過）這樣描述三級模型：Tier I（一級，簡稱 T1 或 L1）是第一技術支援層，首要工作是收集客戶資訊並找出根本問題。Tier II（二級）比一級更深入，成本也更高，因為技術人員經驗更豐富。Tier III（三級）是三級模型裡最高的一層，負責最困難或最高階的問題，由領域專家組成，支援低層級，併為新問題或未解決的問題開發解決辦法。

不同組織對同樣的層級用不同的名字。你還會看到「第一線、第二線、第三線」，「前線、後端、專家」，或者「服務台、桌面支援、工程」。名字不重要，重要的是層級之間如何轉移的規則。

有些組織會在兩端再加層：

1. 0 級（自助服務）：知識庫、密碼重置門戶、自動助手。用戶不用人工就能解決常規問題。
2. 4 級（廠商或產品研發）：軟硬件廠商，或內部開發團隊，他們能修改產品本身。

L1 支援做什麼？

L1 是前門。它是用戶接觸到的第一個人或第一個系統，工作重在廣度，而不是深度。

L1 的典型職責：

1. 接收並登記每一次聯絡，無論電話、電郵、聊天還是門戶，使每一次聯絡都變成一張有編號的工單。
2. 識別用戶和受影響的服務，並用用戶自己的話記錄現象，附上報錯資訊或截圖。
3. 設定優先級，按約定的影響度和緊急度規則來做。想了解具體做法，可以讀我們的文章：嚴重程度和優先級的區別。
4. 按腳本或知識庫文章解決已知的常規問題：密碼重置和帳號解鎖、郵箱和打印機問題、基本的連通性檢查、標準軟件安裝，以及操作諮詢。
5. 查看問題是否已知，比如一個正在進行的故障，這樣重複工單就能關聯起來，而不是各自處理。
6. 按約定的間隔向用戶通報進展。
7. 在問題超出 L1 範圍或時限時，帶著一份好的交接記錄升級。

L1 最重要的能力不是很深的技術知識，而是診斷和溝通：問對問題，識別模式，寫出下一個人不必再回訪用戶就能接手的工單。

L2 支援做什麼？

L2 接手 L1 關不掉的工單。它有更深的技術知識、更大的權限，每張工單也有更多時間。

L2 的典型職責：

1. 先看 L1 的記錄，這樣就不會讓用戶回答兩遍同樣的問題。
2. 排查超出腳本的問題：伺服器和網絡問題、應用故障、組策略和設備管理問題、權限問題，以及需要遠程訪問用戶設備或後端系統的問題。
3. 在批准的範圍內做變更，例如已有標準變更涵蓋的配置修改。
4. 處理上門或需要動手的工作，遠程辦法不夠時調派現場工程師。
5. 跨工單識別模式，當多起事件有共同原因時，創建問題記錄。
6. 更新知識庫，讓 L2 今天學到的東西，明天變成 L1 的解決辦法。
7. 當故障需要深入的產品、架構或代碼知識時，升級到 L3。

維基百科的描述還提到，L2 同時負責協助 L1 人員處理基本技術問題，所以很多團隊會在兩級之間開一個簡短的「求助」渠道。

L3 支援做什麼？

L3 是專家層。這些工程師、架構師或專家深入了解某個平台，被期望去解決在該環境中還沒人解決過的問題。

L3 的典型職責：

1. 分析複雜、反覆發生或高影響事件的根本原因。
2. 設計並實施修復，這類修復需要改動架構、代碼、集成或安全控制。
3. 與廠商和製造商合作，包括在廠商提供的最高支援層級開立並跟進案例。
4. 為 L1 和 L2 提供建議，併為沒有已知解決辦法的問題制定新的操作流程。
5. 作為技術負責人蔘與重大事件。這一流程的做法，請看我們的重大事件管理指南。
6. 把經驗反饋到知識庫和變更計劃中，避免明年又重新發現同一個故障。

L3 的時間是模型裡最貴的時間。所以健康的分級體系要保證 L3 騰得出手，去做只有 L3 才能做的事。

工單怎樣從一級交接到下一級？

分級支援的大多數失敗，都是交接的失敗。一張帶著「用戶登入不了，請查看」這一句備註到達 L2 的工單，已經丟掉了 L1 做過的工作。好的交接遵循固定的格式。

每一份升級記錄都應包含：

1. 誰受影響：用戶、所在地點和設備，以及還有多少人受影響。
2. 現象是什麼：用戶的原話、準確的報錯文字和開始時間。
3. 已經試過什麼：每一步及其結果，避免有人重複。
4. 優先級是多少、為什麼：所選的影響度和緊急度。
5. 需要下一級做什麼：一個具體的問題或動作，而不是籠統的「請看看」。
6. 用戶那邊進展到哪裡：已經告訴用戶什麼，下一次更新應在何時。

讓工單保持流動的交接規則：

1. 按能力升級：問題不在 L1 腳本或知識庫裡，就升級，不要猜。
2. 按時間升級：為每個優先級設定時限，超時未解決的工單自動上移。P1 可能只有幾分鐘，P4 可能有幾天。
3. 按風險升級：一旦出現安全事件、數據丟失或更大範圍故障的跡象，不管時限，立即上報。
4. 工單責任人始終可見：工單任何時候都在某個明確的人或團隊名下，用戶始終有一個聯絡人。
5. 允許退回：如果 L2 發現這是用戶權限或流程問題，可以帶著備註退回 L1，知識庫就是這樣長大的。

時限來自 SLA。博迅（Brocent）在 SLA 頁面上按優先級公佈響應目標（我們在 2026 年 10 月 28 日核對）：P1 和 P2 首次響應為 15 分鐘，P3 為 30 分鐘，P4 和 P5 為 60 分鐘。這是在標準 8×5 或高級 24×7 服務時段下的首次響應目標，頁面也註明以合約條款為準。想用大白話了解各個級別，請讀 IT 支援 SLA 裡的 P1 到 P4 優先級。我們的 P1 響應時間是公開的，在管理型IT外判服務方案與按用戶收費上也能看到。

以上規則講的是在各級之間向上轉。至於 L3 之後的聯絡人、時限和通知步驟，比如 P1 超過一定時間未解決時通知誰，請讀配套的 IT 升級矩陣模板。

外判時怎樣劃分 L1、L2、L3？

外判不必是「全有或全無」。企業通常在幾種常見的劃分裡選一種，哪種合適，取決於你自己保留多少 IT 知識。

方案一：只外判 L1

1. 服務商負責：登記、分流、常規修復，以及向你的內部團隊升級。
2. 你的團隊負責：L2 和 L3，也就是它最熟悉的系統。
3. 適合：有能幹的內部 IT 團隊、但花了太多時間在重置密碼和操作諮詢上的公司。
4. 留意：交接記錄寫得差，以及內部團隊被本該由 L1 解決的升級打斷。

方案二：外判 L1 和 L2，L3 留在內部或交給廠商

1. 服務商負責：整個服務台，以及它背後的桌面、網絡和伺服器工作。
2. 你的團隊負責：架構決策、業務應用和廠商關係。
3. 適合：希望把日常 IT 交出去，但保留一個小團隊或一位技術負責人的公司。
4. 留意：誰可以改什麼的邊界不清，以及服務商不熟悉的應用交接緩慢。

方案三：標準環境的 L1 到 L3 全部外判

1. 服務商負責：它所管理的基礎設施和工具的全部三級，包括向廠商升級。
2. 你的團隊負責：業務專用的應用，以及與服務商的關係。
3. 適合：沒有內部 IT 人員的組織。
4. 留意：約定範圍之外的應用，應在合約裡點名，免得掉在雙方之間。

無論選哪種，都要寫下這些

1. 一頁範圍清單，列出系統和服務，以及每一項在哪一級由哪一方負責。
2. 各級可用的時段，因為 24×7 的服務台，其 L2 和 L3 可能只是隨叫隨到。
3. 雙向的升級路徑，包括你方對接服務商 L3 的聯絡人。
4. 誰可以做變更，誰必須批准。
5. 你將收到的報告：各級的工單數、解決時間、L1 解決的數量，以及在各級之間來回的數量。

想了解服務商的服務台如何全天候運作，可以看我們的 24×7 服務台 IT 支援概述。如果想一起討論哪種劃分適合你，歡迎聯絡我們。

哪一級處理哪一類工單？

下面的例子僅為示意，真正的邊界由你自己的範圍清單決定，但它們能說明各級在實際中的差別。

1. 用戶忘了密碼：L1，按重置流程，一次聯絡解決。
2. 某個辦公點的一台筆記本連不上 Wi-Fi：L1 檢查基本項和用戶設定；如果問題出在接入點、網絡策略或設備配置上，則由 L2 接手。
3. 整個團隊的共享郵箱權限不對：L2，因為需要管理員權限，並理解組是怎樣設定的。
4. 廠商更新後業務應用出錯：L2 收集日誌並測試，如果原因在產品裡，L3 與廠商一起處理。
5. 幾個辦公點的雲服務中斷一小時：L1 把工單關聯起來並通知用戶；L2 和 L3 作為技術負責人加入，由重大事件流程接管。
6. 為新員工申請筆記本和帳號：這是服務請求，不是故障，由 L1 或 L2 按入職流程處理。

如果大多數被升級的工單都落到同一兩個人手裡，應當把它看作 L2 人手不足的信號，而不是這幾個人表現好的證明。

怎麼衡量分級是否有效？

四個指標就能說明大部分情況，都不需要特殊工具。

1. 首次聯絡解決率：在首次聯絡中就得到解決的工單比例，無論由哪一級解決。數值低，說明 L1 缺腳本、缺權限或缺培訓。計算方法見我們的首次呼叫解決率指南。
2. 各級升級率：往上轉的工單比例。L1 到 L2 的比例很高，說明 L1 把本該自己做的活傳了出去；比例很低，則可能是 L1 把工單扣得太久。
3. 各級解決時間：工單在每一級停留的時間。延誤常常藏在交接點上，而不是某一級內部。
4. 重開和回彈率：退回前一級或關閉後又被重開的工單。它們反映交接記錄薄弱，或修復沒有真正生效。相關指標請看 MTTR、MTBF 和 MTTA。

每月覆盤一次，每次問同一個問題：如果 L1 有更好的文章、更多的權限或更清楚的規則，哪些工單本來可以由它解決？

分級支援常見的錯誤有哪些？

1. 升級太晚，因為 L1 怕「失敗」。時限和風險觸發條件可以讓這個判斷不再靠個人。
2. 升級太早，因為 L1 沒有權限或腳本。表現為簡單故障的升級率偏高。
3. 只把 L1 當作呼叫中心。L1 還應負責知識庫文章，並發現規律。
4. 讓 L3 拿不到背景。L3 應當了解規律和計劃，而不是只在出緊急情況時才被叫到。
5. 讓用戶重複描述。每一個重複的問題，都說明交接上有缺口。
6. 讓一個「英雄」扛下一切。如果有一個人是非正式的 L2 和 L3，這套模型就存在單點故障。

常見問題

什麼是 L1 支援？

L1，即一級或 tier 1 支援，是 IT 支援的第一線。它登記工單、判斷問題、按腳本和知識庫文章解決常規問題，並把解決不了的問題升級。

L1、L2、L3 有什麼區別？

區別在於深度。L1 處理常規問題和分流，L2 處理需要更深技術工作或更大權限的問題，L3 則與專家和廠商一起處理最複雜的故障。

tier 1 和 level 1 是一回事嗎？

是。tier 1、level 1、T1、L1 和「第一線」說的都是同一個第一層。各組織用詞不同，請以你自己文件裡的定義為準。

小公司需要三級都有嗎？

不一定要作為三個獨立的團隊。小型 IT 團隊可以身兼數級。重要的是任務、交接和時限有定義，即使同一個人做不止一級。

哪些可以外判？

任何一級都可以。很多公司先外判 L1，等交接順暢後再加上 L2。合約裡應寫明哪一級的哪些系統由誰負責。

升級和 SLA 有什麼關係？

SLA 為每個優先級設定響應和解決目標，升級規則把這些目標當作觸發條件。如果一張工單快要違反目標，就往上轉。

升級工單和轉派工單有什麼區別？

升級是因為當前層級解決不了，把工單轉給能力更強或級別更高的一級；轉派是平級地轉給負責該系統的團隊。好的記錄會把兩者分開。

接下來讀什麼

先看優先級是怎麼設定的：嚴重程度和優先級的區別，再看 IT 升級矩陣模板了解聯絡人和時限。合約措辭方面，請看 IT 支援裡的 SLA 是什麼意思。

*2026 年 10 月 28 日核對的來源：維基百科「Technical support」條目（en.wikipedia.org/wiki/Technical_support）；博迅 SLA 頁面（brocent.com/sla）。*

想把這些指標寫進合約，而不是停留在簡報上？ 博迅的管理型IT外判服務方案把 SLA 和按用戶的月費並排公開，覆蓋香港、新加坡、中國大陸和美國。查看方案與收費，或聯絡顧問。