停止使用 SaaS 後要留什麼紀錄？核對帳戶關閉與資料處置

從匯出驗收、帳戶停用到相依工作與供應商資料處置，整理一份可查核的 SaaS 退場紀錄，讓未知事項也有負責人與回查證據。

停止 SaaS 的工作，不會在按下取消時結束。真正要收尾的是一條可回頭查核的紀錄：哪些資料已取出並驗收、帳戶何時失去使用能力、哪些自動化已改道，以及供應商對資料刪除或保留怎麼回覆。本文整理一套可供負責人逐項填寫的退場紀錄，讓接手同事能分辨已證實、已提出要求與仍未知的狀態。工具名稱和供應商政策不同，請依帳戶實際設定與書面回覆核對。

核對已完成匯出驗收

匯出完成的通知只表示檔案生成，不代表內容可接手。先把驗收範圍寫清楚：涵蓋哪些工作區、日期區間、資料類型、附件、留言、狀態欄位、建立與更新時間、使用者對應及關聯紀錄；也註明供應商不支援匯出的項目。範圍要對應實際工作，不要只用檔名或壓縮包數量當完成標準。若匯出分成多個檔案，逐一記錄檔名、格式、產生時間、存放位置、檔案大小及負責人，並保留下載成功或供應商回覆的證據。若加密或含敏感資料，另記存取限制和解密責任人，不要把密碼放在同一份索引中。

接著做可重複的抽查：檔案能否開啟、欄位是否亂碼、關聯是否仍可辨識、附件能否對到主紀錄，以及代表性紀錄能否在新環境搜尋。需要完整匯入驗證時，使用核准的測試位置，不要在正式系統覆蓋資料。以「假設某工作區匯出 120 筆，其中 118 筆通過抽查、2 筆因附件連結失效待查」為例，結論應寫成已收 120、已驗 118、未完成 2（118+2=120），並列出兩筆識別碼、影響和處理人，而不是寫匯出成功。若來源與匯出筆數不同，先查篩選條件、封存、重複或權限範圍，再判斷差異是否可接受。

驗收人要和下載人分開，至少由熟悉業務資料的人核對欄位含義；若無法雙人檢查，記錄由誰覆核、抽查了哪些樣本、用什麼方式確認。抽查條件宜在匯出前先定義，避免只挑最容易成功的資料。可用下表做最小驗收記錄；每格都填實際結果，不能以預設文字代替證據。

記錄帳戶關閉日期

把帳戶關閉拆成日期與狀態欄位，避免把提出取消、停止續約、權限停用和資料刪除寫成同一件事。至少登記申請提出時間、預計最後可用日、供應商確認的停用時間、確認時區、帳戶或租戶識別方式、承辦票號、提交人與覆核人。這些日期若不同，分別保留，不用一個「關閉日」掩蓋過程。若服務以工作區、子帳戶或不同登入方式分開管理，也要列出每個範圍的狀態，並附上能辨認對象的名稱或遮蔽後識別碼。

關閉前先比對仍需使用的功能與替代路徑，確認匯出已驗收、必要交接已完成、付款或續約安排有人跟進，再由有權限的人送出取消要求。不要單靠行事曆提醒推定服務已停；應留存供應商的確認訊息或管理畫面截圖，註明截取時間和來源。關閉後用既定監控方式確認舊登入、API 存取或排程不再成功；這只是功能停用的證據，不能自動證明資料已刪除。

若停止續約和停用時間不同，也把兩者分開，並記錄截至停用前誰可登入、哪些帳戶將被移除、如何核實無人再依賴舊入口。若確認來自帳務通知而非服務管理者，註明證據來源及限制；不同通知不得合併成單一結論。同一租戶若有多個管理入口，要逐一確認並記錄操作者。假設某訂閱於月初送出取消，供應商回覆月底停用，管理者月底看到登入被拒。紀錄要分別標成「取消已送出」、「停用日由供應商確認」、「登入測試已失敗」，並附各自證據；若仍有其他管理員帳戶、測試入口或可用金鑰，就將帳戶關閉標為未完成。若無法取得停用畫面，指定負責人向供應商索取可追溯的文字回覆，記下後續回查條件。

確認相依工作已移除

服務退場最容易漏掉的是仍在運作的連線。從目前系統清單、設定檔、密碼管理器、表單通知、排程工作與供應商整合頁面盤點所有相依點：API 金鑰、OAuth 授權、webhook、SSO、寄信服務、資料同步、嵌入元件、分享連結、網域記錄和定期匯出。每筆寫明使用情境、呼叫端、資料流向、目前負責人及最後一次成功執行的證據。只找到一個畫面不代表盤點完整；也詢問流程負責人該服務是否被其他團隊或外部合作方使用。

移除前先判斷替代路徑與相依順序：先切換仍必要的工作，再撤銷舊授權或排程，避免在無人注意時讓通知中斷或資料靜默漏接。每個改動都記錄執行者、時間、改了哪個設定、回復方式和結果；密碼、token 等秘密不應複製進退場表。若某連線無法辨認用途，不要直接刪除，先暫停變更並指定確認人，再用近期執行紀錄或系統擁有人辨認。

對每筆關係還可補上環境名稱、用途分類、最近檢查人和預定處置，並標記是否涉及正式資料。若替代服務測試使用的是假資料，請明示測試條件，避免把測試成功誤認為全部正式流程已切換。保留的每條連線都要寫明理由與下次覆核時點。可以用「發票資料由表單送入舊服務，再同步到會計工作區」作為假設例子：先確認新路徑能接收一筆測試資料且欄位對應，再切換表單目的地，確認舊排程停止並撤銷舊金鑰，最後查看執行紀錄是否仍呼叫舊端點。若一項變更影響多條流程，建立逐項清單而非一次全部停用。結案條件是每筆相依關係都有已移除、已替換或保留原因，並附實際觀察；待確認項不得填成已清除。

記下資料處置回覆

向供應商詢問資料處置時，問題要具體到可比較，不只問「資料刪了嗎」。請對方確認指定租戶與期間的正式資料是否已刪除、備份或歷史副本怎麼處理、操作紀錄是否仍保留、是否有其他處理方，以及尚未處置的內容、原因、預計條件或回覆方式。不同服務可能採不同保留方式；不要自行把帳戶停用、刪除使用者或收到自動回信當成全部資料已清除。若供應商只回覆「已收到要求」，就把狀態記為已提出要求，並列出待回答的範圍。

保存往來信件、工單編號、附件、回覆者身分或職務、回覆日期和所指服務範圍，並註明回覆是直接確認、政策說明還是尚待處理。避免在一般退場文件貼上個人資料樣本；以工單連結、受限文件位置或遮蔽後的識別碼指向證據。若供應商提供自助刪除流程，先記錄操作前狀態和所選範圍，再由授權管理者執行並保存完成畫面，但畫面文字仍應照實轉述，不能擴大解讀成其他備份、紀錄或處理方都已完成處置。

若對方回覆附帶條款或範圍限制，保留原文與連結並摘錄待確認點；摘要不可省掉「部分」「排除」等限定語。內部摘要還要標出追蹤人，不能只留一封無人追蹤的信。遇到模糊回覆，逐項追問「哪個資料範圍、何種處置、何時確認、是否仍有例外」，並記錄每次往返的結果。假設回覆只明確說明主要工作區已清除，卻沒有提到匯出檔、備份或系統記錄，表格就分列：主要工作區為供應商已回覆、匯出檔由本方保管待內部確認、其餘項目為未知待追問。這種拆分能避免把尚未說明的範圍誤標為完成。

保留必要交接索引

退場紀錄不是把所有匯出資料再複製一份，而是做一份讓接手人找得到、看得懂、也知道哪些內容不能隨意開啟的索引。索引至少列出服務名稱與租戶識別、負責部門、匯出清單與位置、驗收結果、帳戶關閉證據、已撤除相依點、供應商資料處置回覆，以及未結事項的負責人。每項連到經核准的文件或工單，記錄檔案版本、建立時間與存取權限；不要把所有人的權限都設為可查看。

另附一段交接說明，交代資料格式、欄位對照、時區、特殊篩選條件、未匯出項目、解讀限制，以及必要時如何找到原始證據。若附件或紀錄含個人資料、商業機密或憑證，索引只放安全位置的引用，不貼出內容或密鑰。指定文件保管人和覆核角色，依組織的保存政策安排權限檢查與到期處置；不要自行承諾永久保存，也不必把不需要繼續使用的原始資料長期複製到新位置。

文件移交時也確認接收者知道如何提出存取申請、誰核准、遇到失效連結向誰反映；索引不要依賴只有離職或單一帳號看得到的私人雲端路徑。先確認接手者能看見索引，再正式移交保管責任。以假設的退場資料夾為例，可設「00-索引」「01-匯出清單」「02-驗收證據」「03-供應商往來」「04-未結事項」等分類，但實際位置應符合團隊既有受控空間。索引頁要能從每一列找到證據，也能從證據回到負責人與狀態；如果交接人只能看到資料夾而不知道檔案用途，索引還不算完成。最後由接手者實際開啟一份允許的樣本及各項證據連結，確認權限可用且未額外暴露敏感內容。

標出未確認事項責任

把未確認事項單獨列出，狀態不要只分「完成／未完成」。可用「已由本方驗證」「供應商已書面回覆」「已提出、待回覆」「待內部盤點」「不適用並附理由」等描述，讓讀者知道證據來自哪裡。每一項配一位負責角色、一個下一步、一個預計回查時間或觸發條件、一個證據位置，以及完成判準；例如「舊報表是否仍呼叫 API」的完成判準可以是找到呼叫端並觀察停用結果，而非只有發信請系統人員確認。若責任人更換，交接時要更新接手者並要求其回讀未結事項。

未確認事項若沒有可行替代流程，標示為阻擋項並說明需要哪個角色做決定；若可暫行，註明限制、觀察訊號和何時停止暫行，以免交接後無人承擔風險。排定的日期只是回查點，不代表屆時會自動結案。到點仍無回覆，就保留原狀態，記下已追問時間、阻礙和需要升級給誰；若收到新證據，才更新狀態和結論。對每條未確認事項，寫清楚它可能影響的工作、可否先繼續使用替代流程，以及若遲遲無法確認應採取的保守處理。結案時由交接者逐項讀回：資料可用性、帳戶停用、相依工作、供應商回覆和索引位置都能找到證據，未知事項仍有明確責任人，不以一個總體勾選蓋過細節。

如果整理過程顯示不只是關閉帳戶，還需要盤點工作流程、資料與風險治理，或規劃網站、AI、自動化與系統整合，可先從 ZhenheAI 官網 描述一條目前卡住的流程，讓下一步從現況與交接需求開始。