Escalation Path

升級路徑是什麼，跟備援指令有什麼不同？

升級路徑是自動化流程裡，明確定義問題超出目前這一層處理能力時，該往哪裡送、送給誰的規則，通常會設計成好幾個等級，例如輕微問題留在原地處理、中度問題轉交特定負責人、嚴重問題立即通知決策者。這個機制解決的是「處理不了該送給誰」的問題，讓不同嚴重程度的事情，走到對應層級的人手上，而不是全部堆在同一個人的待辦清單裡。

跟備援指令的差別在於處理的問題性質不同。備援指令處理的是「判斷不了怎麼辦」，也就是 Claude 對某個案例沒有把握該怎麼分類或判斷，需要標記出來；升級路徑處理的是「處理不了該送給誰」，也就是問題本身已經清楚是什麼，但這一層的權限或能力不足以解決，需要往上一層轉送。前者是判斷問題，後者是分派問題，兩者經常搭配使用——先用備援指令標記出不確定的案例，再用升級路徑決定這個案例該送到哪一層去。

升級路徑有哪些風險，哪個最容易被忽略？

最容易被忽略的風險是「等級之間的判斷標準寫得不夠具體，導致該不該往上送變成臨時判斷」。如果只寫「輕微問題自行處理、嚴重問題往上送」，卻沒有具體定義什麼算輕微、什麼算嚴重，實際運作時每個人對「嚴重」的認定可能不一樣，有些人偏向謹慎、稍微有點狀況就往上送，有些人偏向大而化之、真正該往上送的也留在原地處理，升級路徑本該提供的一致性反而消失了。

第二個容易被忽略的風險是等級設計得太多層。理論上等級越細，分類越精確，但每多一層轉送，就多一次等待和確認的時間成本，如果升級路徑設計成四五層以上，真正緊急的事項反而會因為要一層層往上走，處理速度比原本更慢。升級路徑存在的目的是加快重要事項被正確處理的速度，如果因為層級設計過度反而拖慢速度，就違背了原本的設計初衷。

什麼情況該設計升級路徑，什麼情況不需要？

適合設計升級路徑的核心判斷標準是「這個流程會處理到嚴重程度差異很大的事，而且不同嚴重程度需要不同權限或能力的人來處理」。例如客服工單系統，一般詢問跟客戶威脅要提告，嚴重程度天差地遠，需要的處理權限也完全不同，這種情況適合設計清楚的升級路徑，確保真正緊急的事能立刻找到有權限處理的人。

不需要的情況是流程本身處理的事情嚴重程度都差不多、或是本來就只有一個人負責處理，沒有分層轉送的必要。例如一個人獨自管理的小型專案，所有問題本來就是同一個人在看，設計升級路徑反而是多此一舉，增加不必要的流程複雜度。簡單判斷法：問自己「這個流程處理的事情，有沒有可能出現『這件事我沒有權限或能力處理，得轉給別人』的情況」，有可能才需要升級路徑。

進階使用者怎麼設計升級路徑，讓層級判斷更精確、轉送更即時？

進階使用者的關鍵做法是「每個等級的進入標準都寫成可以直接判斷的具體條件，而不是抽象的形容詞」。與其寫「情況嚴重就往上送」，不如寫「客戶明確提到要投訴、要求退款超過某個金額、或使用威脅性字眼，符合任一條件就升級到第二層」。具體條件讓判斷不再依賴個人主觀認定，也讓 Claude 在自動化流程裡可以直接依照條件執行分級，不需要每次都由人工重新判斷。

另一個進階技巧，是在升級路徑裡加入「跳級」機制，而不是強制每個案例都要一層一層往上走。例如設計「如果符合最高嚴重等級的條件，直接跳過中間層級，第一時間通知最高權限的人」，避免真正緊急的事項因為要按規定逐層轉送而被拖慢。跳級機制的判斷條件應該設得比一般升級更嚴格，確保只有真正需要立即處理的案例才會觸發，不會因為跳級機制的存在，反而讓大量案例都跳過中間層級，失去分級的意義。