IT 升級矩陣模板：職能升級、層級升級、聯絡人和時限怎麼寫

先說結論： 升級矩陣是一份文件，寫明什麼時候事件必須升級，以及每一級由誰處理。它結合了兩個概念：職能升級（把工單交給技能更強或專業不同的人）和層級升級（通知權限更高的人）。下面的模板給出需要填寫的字段，全部用編號列表表示，所以可以放進任何文檔或工單工具。

IT 事件拖下去的時候，最糟的問題就是「我該告訴誰？」升級矩陣提前回答了它：每個階段由誰負責，工單在轉走前有多少時間，哪些人必須被告知。沒有矩陣，升級就要看當班的是誰，而且往往很晚才發生。

本文說明什麼是升級矩陣，職能升級和層級升級的區別，以及文件裡應寫什麼。隨後給出一份可複製的編號列表模板，一個使用虛構人名的實例，和讓矩陣保持有效的簡短清單。我們還會講，向管理型IT外判服務供應商了解他們的矩陣時該問什麼。

什麼是升級矩陣？

升級矩陣是一份文件或一套系統，規定什麼時候應該升級，以及在每個升級層級由誰處理事件。這是 Atlassian 在事件管理指南「升級策略」一頁的說法（我們在 2026 年 10 月 28 日讀過）。同一頁還指出，各組織的詳細程度差別很大：有的用簡單的層級圖，每個人向技能更高的人升級；有的則維護針對具體情境的矩陣，說明不同類型事件或嚴重等級應聯絡哪個團隊。它還說沒有放之四海而皆準的做法，並建議把升級策略當作指導原則，而不是死板的規則。

在 IT 支援中，矩陣通常要為每個優先級回答五個問題：

1. 誰最先負責這張工單？
2. 他們有多長時間，工單必須轉走？
3. 下一個接手的是誰？
4. 哪些人即使不參與處理，也必須被告知？
5. 怎樣聯絡到每個人，包括下班時間？

它與支援分級模型不同。分級（L1、L2、L3）描述技能的層次；矩陣規定何時、如何在各級之間移動，以及誰位於它們之上。如果你想先看分級模型，請讀我們的 L1、L2、L3 支援分級指南。

職能升級和層級升級有什麼區別？

這兩個詞用於 ITIL 風格的服務管理。我們這次沒有重新閱讀 ITIL 的付費出版物，所以下面的解釋是我們對通行做法的描述，不是原文引用。

職能升級

職能升級把工單轉給有更專業知識或不同技能的人或團隊。它在技能上是橫向或向上，而不是職級上的向上。

1. 觸發條件：當前層級解決不了，或者工單需要專家，例如網絡、安全或某個應用團隊。
2. 方向：從 L1 到 L2，從 L2 到 L3，從 L3 到廠商。
3. 告知對象：接手工單的專家；除非正式轉移，工單責任人保持不變。
4. 例子：服務台人員把防火牆故障升級給網絡工程師。

層級升級

層級升級把資訊，有時還有決定權，交給權限更高的人。它是職級上的向上，而不是技能上的。

1. 觸發條件：事件嚴重、耗時過長，或需要超出當前人員權限的決定，例如花錢、請外部方介入或通知客戶。
2. 方向：從團隊主管到服務經理，到 IT 負責人，到總監。
3. 告知對象：需要知情、可能需要決策的經理和業務負責人。
4. 例子：服務經理告訴 IT 負責人，某個 P1 在約定時間後還沒修好，而且廠商上門會產生額外費用。

大多數真實的升級會兩者同時使用。一個 P1 故障一邊橫向交給專業團隊，一邊向上讓經理知情並幫忙清除障礙。好的矩陣在頁面上把這兩條路徑分開，讓人看得出自己走的是哪一條。

升級矩陣應包含哪些字段？

不管用什麼格式，每份矩陣都應記錄相同的基本字段。

1. 優先級或嚴重等級，按你的 SLA 定義。如需幫助，請看我們的嚴重程度和優先級的區別指南。
2. 服務或系統，因為合適的專業團隊取決於什麼出了問題。
3. 層級編號，從第一線到最終層級。
4. 角色和姓名，每個角色都有指定的代理人。
5. 聯絡方式，按應嘗試的順序排列：電話、即時通訊、電郵。
6. 可聯絡的時段，以及時段之外的值班安排。
7. 本層級的時限，超過後工單自動上移。
8. 通知名單，工單到達本層級時必須通知誰。
9. 決策權，本層級無需請示就能決定什麼。
10. 最近一次複核日期，以及文件的負責人。

升級矩陣模板

這是可複製、可填寫的模板。方括號裡的內容由你自己選定。不要把示例時間當成標準，要根據你自己的 SLA、人手和業務風險來設定。

第 1 部分：文件控制

1. 矩陣名稱：[公司或服務名稱] IT 升級矩陣。
2. 負責人：[角色，例如 IT 負責人或服務交付經理]。
3. 版本和日期：[版本號和日期]。
4. 複核週期：[例如每季度一次，以及每次重大事件之後]。
5. 適用範圍：[所涵蓋的服務、辦公點或客戶清單]。

第 2 部分：按優先級設定的時間觸發條件

為每個優先級記錄首次響應目標、第一次升級前的時限，以及下一次升級前的時限。使用你 SLA 裡的目標。

P1，危急

1. 在 [分鐘數，取自你的 SLA] 內首次響應。
2. 如果 [分鐘數] 內未解決，升級到下一層級，並通知服務經理。
3. 如果 [分鐘數] 內仍未解決，通知 IT 負責人和業務負責人。
4. 每隔 [分鐘數] 向受影響用戶更新一次，直到解決。

P2，高

1. 在 [分鐘數，取自你的 SLA] 內首次響應。
2. 如果 [小時數] 內未解決，升級到下一層級。
3. 如果 [小時數] 內仍未解決，通知服務經理。
4. 每隔 [小時數] 向受影響用戶更新一次。

P3，中

1. 在 [分鐘數，取自你的 SLA] 內首次響應。
2. 如果 [工作日數] 內未解決，升級到下一層級。
3. 至少每 [工作日數] 向用戶更新一次。

P4，低

1. 在 [分鐘數，取自你的 SLA] 內首次響應。
2. 如果 [工作日數] 內未解決，在每週服務例會上覆核。

第 3 部分：職能升級路徑

為每個服務領域，按介入順序列出相關人員。每個領域重複一個區塊。

服務領域：[例如終端設備]

1. 第 1 級：[角色和姓名]，[聯絡方式]，[時段]。
2. 第 2 級：[角色和姓名]，[聯絡方式]，[時段]。
3. 第 3 級：[角色和姓名]，[聯絡方式]，[時段]。
4. 廠商或外部方：[公司、合約或案例編號、支援熱線、支援級別]。

服務領域：[例如網絡與安全]

1. 第 1 級：[角色和姓名]。
2. 第 2 級：[角色和姓名]。
3. 第 3 級：[角色和姓名]。
4. 廠商或外部方：[詳情]。

服務領域：[例如業務應用]

1. 應用負責人：[角色和姓名]。
2. 技術負責人：[角色和姓名]。
3. 廠商支援：[詳情]。

第 4 部分：層級升級路徑

按職級從低到高，列出隨著事件擴大必須被告知的人。

1. 團隊主管：[角色和姓名]，在 [條件，例如任何 P1，或超時的 P2] 時被告知。
2. 服務交付經理：[角色和姓名]，在 [條件] 時被告知。
3. IT 負責人或技術總監：[角色和姓名]，在 [條件，例如 P1 超過第二個時限] 時被告知。
4. 受影響服務的業務負責人：[角色和姓名]，在 [條件，例如服務對客戶不可用] 時被告知。
5. 高層贊助人：[角色和姓名]，在 [條件，例如發生數據丟失或安全事件，或停機帶來法律或合約風險] 時被告知。

第 5 部分：與時間無關的自動觸發條件

1. 疑似安全事件：立即通知 [安全負責人]，並按安全事件流程處理。
2. 確認的數據丟失或數據泄露：立即通知 [高層贊助人和數據保護聯絡人]。
3. 同一故障被 [人數] 名或以上用戶報告：按重大事件處理，並啓用重大事件經理。
4. 人身安全或場地的實體風險：先聯絡 [設施或緊急聯絡人]。

第 6 部分：非工作時間的安排

1. 服務時段：[例如 8×5 或 24×7，取自你的合約]。
2. 值班表：[存放在哪裡、由誰更新、怎樣確認交接]。
3. 非工作時間聯絡方式：[電話號碼或呼叫工具，不能只用電郵]。
4. 哪些情況可以在非工作時間呼叫：[例如僅 P1 和 P2]。
5. 值班人員在 [分鐘數] 內沒有回應時的後備：[代理人，然後是經理]。

第 7 部分：溝通規則

1. 誰負責與受影響用戶溝通：[角色]。
2. 誰負責與高層管理者溝通：[角色]。
3. 誰負責與客戶或第三方溝通：[角色，需經誰批准]。
4. 更新渠道：[例如狀態頁、聊天頻道或電郵列表]。
5. 更新格式：我們已知什麼，我們正在做什麼，下一次更新在何時。
6. 結案通知：寫明已知的原因、採取的修復措施和後續事項。

第 8 部分：事件之後

1. 在工單中記錄所有升級，並寫明時間。
2. 在下一次服務例會上覆核所有到達 [層級] 的事件。
3. 如果原因不明或反覆出現，創建問題記錄。
4. 如果聯絡人有誤、時限不現實或缺了某個步驟，更新本矩陣。

一個使用虛構人名的實例

這個例子純屬虛構，只用來說明各部分如何銜接。

1. 09:02：服務台的 Sam 登記了一張工單：總部沒有人能打開財務應用。Sam 按矩陣把優先級設為 P1，並按第 4 部分的要求通知團隊主管 Priya。
2. 09:15：Sam 檢查了基本項，發現用戶端沒有問題。按第 3 部分，該應用屬於業務應用領域，於是 Sam 做職能升級，交給技術負責人 Dev，並附上一份列明已嘗試步驟的交接記錄。
3. 09:40：Dev 發現該應用的數據庫伺服器沒有響應，便撥打第 3 部分列出的廠商支援熱線。
4. 09:45：P1 的第一個時限到了。按第 4 部分，服務交付經理 Maria 被通知，Priya 向用戶發出第一次更新。
5. 10:30：第二個時限到了。Maria 通知 IT 負責人和該應用的負責人、財務總監。財務總監決定批准廠商的緊急服務費，這個決定超出了 Dev 的權限。
6. 11:20：廠商恢復了服務。工單關閉，備註裡記錄了每一次升級及其時間。同時創建問題記錄，追查原因。

注意矩陣在每一步的作用：Sam 不用猜該打給誰，Dev 不必等批准就能聯絡廠商，財務總監也及時得知問題並作出了決定。

怎樣讓升級矩陣一直有用？

寫好後就再沒人碰的矩陣是有害的，因為人們相信它，它卻把人指向一個已經離職的人。用一套簡短的例行做法保持它的有效。

1. 每季度複核一次，每次重大事件之後也複核。
2. 核對每一位聯絡人，複核時給每個人打電話或發消息。
3. 測試非工作時間的路徑，做一次包含值班電話的計劃內演練。
4. 只發布一份最新副本，放在即使主系統宕機，所有人員也能訪問的地方。
5. 記錄沒有按矩陣執行的情況，並問為什麼。原因通常是矩陣裡有缺口。
6. 與你的服務商共享，並請他們提供他們的矩陣。

常見的錯誤有哪些？

1. 寫人名而不寫角色。人會換崗。用角色加指定的擔任者，並配一名代理人。
2. 只有一種聯絡方式。給一個正在飛機上的人發電郵，什麼也升級不了。
3. 沒人能達到的時限。一個總是被錯過的時限，只會教大家無視它。
4. 沒有層級升級路徑。技術團隊橫向升級，經理卻是從用戶那裡才得知事件。
5. 沒有降級的辦法。要寫明服務恢復後，矩陣怎樣解除。
6. 矩陣只放在服務台工具裡。如果出問題的恰恰是這個工具，就沒人能讀到它。

向管理型IT外判服務供應商了解升級時該問什麼？

如果由服務商負責你的一部分 IT 支援，他們的升級矩陣就成為你的矩陣的一部分。簽約前值得問的問題：

1. 我們能看到矩陣以及每個優先級的時限嗎？
2. 我們自己的哪些人在其中，被呼叫時要做什麼？
3. 服務商團隊裡，每個層級升級對應的經理是誰？
4. 非工作時間怎樣聯絡服務商，什麼情況算非工作時間升級？
5. 服務商什麼時候向廠商升級，額外費用由誰授權？
6. 我們怎樣在月度報告裡看到升級記錄？

博迅（Brocent）在 SLA 頁面上公佈了響應目標（我們在 2026 年 10 月 28 日核對）：P1 和 P2 首次響應 15 分鐘，P3 為 30 分鐘，P4 和 P5 為 60 分鐘，適用於標準 8×5 或高級 24×7 服務時段，並以合約條款為準。我們的 P1 響應時間是公開的，管理型IT外判服務方案與按用戶收費上也能看到。想了解各個優先級的含義，請讀 IT 支援 SLA 裡的 P1 到 P4 優先級，或看 24×7 服務台 IT 支援概述。想聊聊升級機制怎樣適合你自己的團隊，歡迎聯絡我們。

常見問題

什麼是升級矩陣？

它是一份文件，規定事件什麼時候必須升級、每一級由誰處理、每一級有多少時間、誰必須被告知，以及怎樣聯絡到他們。

職能升級和層級升級有什麼區別？

職能升級把工單交給技能更專業的人；層級升級則通知權限更高的人，讓他們決策或幫助清除障礙。嚴重事件通常需要兩者同時進行。

升級矩陣應該有幾層？

IT 裡常見的是三到五層：第一線、第二線、第三線或廠商，再加上管理層。層級太多會拖慢決策，太少則可能在工程師和高層之間留下空檔。

應該用什麼時限？

根據你自己的 SLA 和能力來定。任何模板裡的數字，包括本文的，都只是佔位。從你公佈的響應目標出發，為每次交接加一點餘量。

誰應該負責升級矩陣？

一個明確的角色，通常是服務交付經理或 IT 負責人，負責複核矩陣，並確保每個聯絡人都是最新的。

升級矩陣和值班表有什麼不同？

值班表說明某個時間誰可以聯絡到。矩陣說明按什麼順序、什麼時候介入哪些人。兩者應相互引用。

安全事件需要單獨的矩陣嗎？

通常需要，至少要有單獨的一部分，因為安全事件涉及不同的人，比如安全負責人和數據保護聯絡人，通知義務也不同。

矩陣可以做成表格嗎？

可以，在電子表格或文檔裡它常常顯示為網格。兩種做法結構相同；本文用編號列表，是為了方便複製到任何工具中。

接下來讀什麼

優先級怎麼定，請讀嚴重程度和優先級的區別。矩陣所連接的技能層級，請看 L1、L2、L3 支援分級。當 P1 演變成大範圍故障時，下一步是重大事件管理流程。如果你在考慮怎樣在自己的團隊和服務商之間劃分責任，請看 SLA 與 OLA 的區別。

*2026 年 10 月 28 日核對的來源：Atlassian 事件管理指南「升級策略」一頁（atlassian.com/incident-management/on-call/escalation-policies）；博迅 SLA 頁面（brocent.com/sla）。*

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