離職或轉調時怎麼交接帳號？檢查所有者、權限與自動化依賴
員工離職或轉調時，如何逐項盤點帳號所有權、登入方式、二階段驗證與自動化依賴，並安排權限移交、撤除和接手驗收。
人員離職或轉調時，交接的重點不是交出密碼，而是確認帳號所有權、操作權限、二階段驗證與復原方式都由適當的人接手，也找出持續運作的自動化是否依賴即將停用的個人身份。把人員、系統和流程放進同一份清單，才能先發現中斷點，再讓新負責人自己完成驗收。
清點帳號與登入方式
先從離職或轉調者常用的公司信箱、雲端檔案、網域與網站管理、客服或銷售系統、帳務入口、設計工具及自動化平台盤點。再查公司帳單、登入通知、流程文件和共享信箱；同一平台有多個工作區或品牌帳號要分開，避免只找到入口卻漏掉資料。
每筆記下資源用途、目前所有者、管理者與一般使用者、登入識別與方式、復原管道、付款責任人及流程依賴。所有者和操作者可能不同；先查管理頁面或組織紀錄，再按公司制度指定接手人。一般交接表不放密碼、一次性驗證碼或復原碼，只記它存放的受控位置及取用人。
登入方式需分清個人信箱、公司網域信箱、單一登入、第三方登入和硬體金鑰；再確認二階段驗證綁定哪支手機或哪個安全金鑰，備援信箱和電話是否仍有人管理。若員工離開後公司無法重設密碼，就代表復原控制仍綁在個人身上，應列為交接阻塞項目，而不是標成已完成。
以下是示意盤點列，實際欄位可依組織補充： | 資源（假設例） | 目前控制點 | 接手前核對 | | 公司信箱 | 個人復原電話 | 改由核准的公司復原管道 | | 網域管理 | 單一管理者 | 新增接手管理者並測登入 | | 自動化工作區 | 離職者建立流程 | 找出連線身份和下游用途 |
可依影響分成不能中斷、可短暫停用、待確認三類，標示負責人和完成證據；例如網域續費失敗可能影響網站與信箱，就要先完成所有權和付款權限交接，再撤掉原管理者。清單要讓接手者找到入口與復原責任；找不到所有者或復原路徑的項目應列為未驗收，直到有人承接。
排查自動化服務依賴
自動化會把單一帳號的權限延伸到多個步驟，因此要沿著流程查，而不是只核對登入頁面。先列出由排程、表單、郵件、檔案更新或外部通知觸發的工作；記錄執行身份、讀取來源、寫入目的地、通知對象、失敗通知接收者和流程修改者。建置者、流程所有者和授權人可能不同，流程仍顯示啟用不代表已完成交接。
逐條檢查個人連線、共享帳號、代表帳號呼叫服務的 API 授權字串、用來通知另一系統的 webhook，以及郵件轉寄或專供流程執行的服務帳號。確認授權由誰建立、範圍是否足夠、失效後如何更新、是否被多條流程共用；不要把可重用授權內容貼進交接文件，也不要未盤點就整批重設，否則可能同時中斷不相關工作。若無法看見授權內容，從權限紀錄、流程說明和最近一次成功執行的資訊確認身份線索。
假設一張表單收到詢問後，流程把內容寫入名單表，再通知業務信箱。核對表單管理人、寫入表格的連線、收件信箱及失敗通知；若任何一段依賴離職者個人帳號，就為該段指定新身份並重新授權，而非只把流程擁有人改名。若有排程任務，記下頻率、時區、最近一次成功和下一次應執行時段，以免交接時尚未到觸發時間而漏判。
把流程依賴畫成來源、身份、動作、結果四欄，優先處理沒有第二位維護者、直接寫入客戶資料或承擔對外回覆的流程。尚不清楚用途的自動化先找業務使用者和紀錄比對，不應擅自刪除；確認無人依賴後再依組織的停用程序處理。每個流程要有接手人、測試方式與失敗回報對象，否則完成帳號移交仍可能留下無人處理的工作。
移交所有者與驗證方式
所有權移交先確認平台是否支援正式轉移，以及新負責人是否已用自己的公司身份登入。能轉移時，由目前管理者依平台提供的流程指定新所有者，再讓對方確認資料、付款與管理權限都出現在自己的帳號；不能直接轉移時，先建立核准的公司管理者或第二位管理員，驗證其可維護資源後，才移除舊帳號。只把密碼交給同事，會讓操作仍顯示為離職者。
二階段驗證要逐項處理，不應把離職者的手機、個人信箱或安全金鑰當成長期共用設備。由有權管理的人員安排新負責人註冊自己的驗證方式，並確認備援方式可以由公司控制且有人實際保管；若平台只提供一次性復原碼，依內部保管規則存入受控位置，交接清單只標示位置和保管人。重設或新增驗證方式後，請接手人登出再用自己的帳號重新登入，確認復原路徑也有效。
權限採符合工作的最低範圍：需要日常編輯的人不一定要有付款或刪除權，需要處理帳務的人也不必取得客戶資料匯出權。先列出接手人的任務，再逐項核對所需角色；遇到平台把多項能力綁在同一角色，記下例外與核准者。假設網站工作區的舊管理員同時是唯一復原聯絡人，不能只新增編輯者便算移交，還要確認新管理者能調整復原資訊並處理權限變更。
若平台無法讓新帳號安全接手，先保留經核准的暫行管理者，寫明限制、負責人和處理期限，再聯絡平台支援或依公司程序安排替代控制。每一步完成後留下操作者、資源、角色、驗證方式更新結果和讀回證據；不要記錄可直接重用的密碼或驗證碼。
安排撤權時點紀錄
撤權要排進交接時序，而不是等離職當天才臨時決定。由主管、原負責人、接手人及帳號管理者共同列出每項資源的轉移時間、驗收條件、撤除時間和執行者；順序是先確認新身份、復原方式和流程，再做操作測試，最後才移除舊權限。撤權時點依公司政策與人員安排決定，沒有適用所有帳號的固定日期；帳號若仍是自動化唯一執行身份，應先完成替代身份和測試。
每次變更記錄資源識別、變更前後角色、操作者、時間、結果、證據位置及尚待處理事項。若因安全或人員安排必須先停用舊帳號，提前準備受控管理者、替代聯絡方式和流程暫停方案；先辨認哪些工作會受影響，安排窗口並告知使用者。若無法在撤權前完成移交，就明確標成未驗收，由主管指定風險承接人和下一步處理時間，不要用空白欄位暗示已完成。
可用一個假設時序檢查排序：週一由新負責人登入網站與自動化工作區，週二測試通知和資料寫入，確認結果後由管理者撤除舊角色。這只是說明順序的假設，不代表任何平台或公司都要採同樣天數；實際應依資源重要性、組織規定和人員可配合時間調整。若測試失敗，撤權前先停止該項變更並找出失敗步驟；已到必須撤除的時點時，依既定的替代控制與事故通報方式處理。
把交接紀錄存放在團隊可讀且有存取控管的位置，連同核准者和相關工單或會議紀錄索引。不要在一般紀錄保存密碼或完整復原碼。清楚區分已轉移、已驗收、已撤權、待平台處理等狀態，讓後續查核能看出誰在何時做了什麼，也能找出仍需要負責人的例外。
重新確認服務可用
權限移轉後要重新確認服務是否能從頭到尾使用，不能只看接手人已進入系統或流程頁面仍顯示啟用。先由新負責人用自己的帳號完成登入，核對可用功能符合職務、不能操作的高風險功能也沒有意外開放，再實際開啟需要的資料、修改一筆可安全回復的項目，確認儲存後能再次讀到。若有付款、刪除或對外發送等高影響操作，應先採用平台提供的測試或預覽方式，不要為了驗收製造真實交易或寄出未核准訊息。
自動化測試要覆蓋觸發、授權、處理、寫入和通知的路徑。選擇可辨識且不含真實客戶資料的測試輸入，先確認會寫到哪個目的地、誰會收到訊息，以及如何清除或標記測試結果；逐步比對預期與實際輸出。若系統沒有安全測試環境，先與流程使用者決定低風險窗口和回復方法，再用受控案例驗證，不要在未知影響下重複觸發。
排程或低頻流程則要檢查近期執行紀錄、失敗通知收件對象、下一次預定執行時間及執行身份；當下沒有觸發不等於沒有依賴。接手人還要知道錯誤通知送到哪裡、誰可更新連線授權、哪些情況需要先暫停流程。若一次測試成功但通知沒有送達，或資料寫入錯誤目的地，應記為失敗並修正後重測，不要以單一成功畫面推定整個服務正常。
每個服務留下驗收紀錄：測試人、時間、測試案例、觀察到的結果、證據位置及未解問題。敏感資料只放在核准的保管位置，紀錄中引用位置即可。發現問題時先界定影響範圍與可用的替代作法，指定處理人和重新驗收條件；在有可追蹤結果以前，服務狀態應維持待確認。
由新負責人驗收
新負責人要親自帶著清單驗收，因為能看見管理頁面不代表已具備日常處理能力。請對方從自己的公司身份登入每個資源，說明資料在哪裡、日常工作怎麼完成、何時需要更高權限，以及遇到登入失敗或流程中斷時要聯絡誰。由接手人實際完成一項低風險例行工作，並展示如何找到流程文件、失敗通知和權限申請方式；原負責人可補充背景，但不代替對方操作。
逐筆確認所有者、管理者、一般使用者、復原聯絡方式、二階段驗證、付款責任、資料位置、流程依賴、測試結果和撤權狀態。每一欄都由新負責人回讀，若資訊不一致就回到來源紀錄核實；不能只以交接會議有出席或收到文件當作驗收。把例外分為仍可工作但有明確風險、暫時無法使用、尚待外部平台處理等狀態，為每項指定承接人和下一步日期，並取得主管對未解風險的確認。
最後由新負責人確認：自己能登入且能復原、所需資料與操作權限到位、自動化的執行身份和通知路徑清楚、舊帳號已依時程撤除，並知道誰可批准後續變更。驗收紀錄可以用清單逐項勾選，但應保留未完成項目，不要把它們併入已完成數字。若職務再次調整，這份紀錄要能讓下一位接手者看懂前次交接的依據和限制，而非只能依賴口頭記憶。
下一步可先挑出最依賴個人帳號的三項系統，和接手人逐一完成登入、驗證方式與流程測試，再依結果安排撤權。若盤點後發現工作流程、網站與自動化交接互相牽動，可先整理依賴清單，必要時再到 ZhenheAI 官網 了解相關資訊。