營運離職帳號安全怎麼做：店鋪帳號交接、跨境電商權限交接與店鋪權限清單實操

離職交接的風險不在密碼，而在三條沒關上的通道

營運把主帳號密碼交回，交接並不算完成。

常見的情況是：兩週後有人發現子帳號仍能登入後台、ERP 的 API key 還掛在離職同事名下、他離職前用的瀏覽器 Profile 連同代理 IP 被新同事接著用來登入別的店鋪。

密碼只是主帳號的一個入口。要真正關掉存取能力，得同時收口三條線：權限層（平台官方角色、子帳號、廣告帳戶、ERP 與物流授權、支付與收款綁定）、環境層（瀏覽器 Profile、代理 IP、登入裝置、Cookie 與本機儲存）、留痕層（誰在什麼時間回收了什麼、誰複核、截圖存在哪）。

處理順序也來自這個框架：一項權限能改動的東西離錢和離主體越近，越先處理。

以下按交接前、交接當天、交接後三段時間展開。

交接前 48 小時：凍結順序與必須匯出的紀錄

凍結不等於刪除。凍結是先把「能改動」變成「只能看」，刪除留到資料都匯出之後再做。

1. 支付與收款：凍結提現、換綁收款帳戶、修改銀行資訊的權限。這類動作一旦發生，事後追回的成本最高。
2. 主帳號：改密碼，並檢查綁定信箱與手機號碼裡是否有一份屬於個人。
3. 廣告帳戶：暫停其廣告操作權限，但不要刪帳戶——投放歷史、像素與受眾資料要留給接手人。
4. ERP 與物流授權：標記對應的 API key 與授權項目，準備更換。
5. 子帳號：列出全部子帳號，而不是只處理最常用的那一個。
6. 電子信箱與手機號碼：核對平台通知信箱、驗證碼接收號碼是否指向個人。

凍結同步進行的是匯出。

平台後台能匯出的部分盡量匯出：訂單與結算記錄、廣告結構與花費、客服會話與未結工單、能查到的登入記錄、供應商與物流對接人清單。匯出的目的不是留檔給 HR，而是讓接手的人不必靠離職者回憶來還原業務上下文。

店鋪權限清單：一行一個「店鋪 + 帳號 + 環境 + 負責人」

跨三個以上平台的團隊，靠記憶做交接一定會漏。清單的粒度是一行對應一個「店鋪—帳號」組合，同一店鋪的主帳號和子帳號各佔一行。

最常被漏掉的一欄是環境編號，它記錄這個帳號平時在哪個瀏覽器 Profile、走哪個代理出口登入。

環境共用本身不會立刻出問題，但它會讓後續的異常提示難以定位——收到複核或限制提醒時，你無法判斷是哪個帳號的哪次登入引起的。

平台排查帳號關係時通常也不是看單一訊號，而是網路出口、裝置與瀏覽器指紋、身分與資金資訊、操作軌跡這幾層變數的重合度，具體原因以帳戶通知和平台官方說明為準。

權限分組的寫法可以直接套用現成做法，Shopify 多店鋪管理的分組、權限與隔離清單給出的三張表同樣適用於獨立站團隊。

權限清單的粒度是一行一個「店鋪—帳號」組合，主帳號與子帳號分開記錄。

交接當天：主帳號、子帳號與第三方授權的回收順序

交接當天的動作和凍結順序一致，差別是凍結只改狀態，這天要真正移除身分。

1. 支付與收款：更換收款帳戶的聯絡資訊，或至少移除其操作權限；確認收款主體是公司而不是個人。
2. 主帳號：改密碼後立刻用新密碼登入一次，看舊工作階段是否失效；把綁定電子郵件信箱換成公司電子郵件信箱並完成驗證。
3. 廣告帳戶：在廣告後台的成員管理裡移除其使用者身分，不要只依賴改密碼。
4. ERP 與物流：作廢舊 API key，產生新 key 交給接手人，然後確認訂單同步仍然正常。
5. 子帳號：逐一停用，重新整理成員清單並截圖。Amazon 的使用者權限層級、TikTok Shop 的店鋪角色、Shopify 的員工權限範圍要逐條核對，而不是只看帳號還在不在清單裡。
6. 內容與客服平台：達人合作後台、社群媒體帳號、客服工具裡的共用席位。

多人協作團隊最容易在這裡出錯：只改了密碼，成員清單沒動。TikTok Shop 團隊多帳號的環境隔離、登入權限與交接流程給出了按官方角色分配權限的欄位，可以對照著核對自己的成員表。

跨境權限交接的特殊項

• KYC 主體與聯絡人：主體屬於公司時，聯絡人和驗證信箱必須換成公司資源；屬於個人的，要在交接前就完成變更，而不是等到離職當天。
• 收款帳戶：帳戶名、綁定人、能修改帳戶的人，三件事分開確認。能登入後台不等於能改收款。
• VAT 與稅務代理：代理聯絡信箱、申報系統的登入權限，經常掛在某個營運的個人信箱上。
• 品牌備案：品牌註冊的帳號歸屬與授權管理，誰可以操作品牌工具。
• 廣告 BM 與廣告主：廣告帳戶的所有權與操作權是分開的，移除成員前先確認還有另一個管理員在。
• 達人合作與內容授權：寄樣紀錄、合作中的達人名單、綁定在個人社群上的店鋪授權。
• Shopify Payments 與 ERP API key：這類授權往往產生後就沒人再看，交接時要重新核對有效期與使用方。

這些項目有一條共同規則：先加新的管理員，再移除舊的成員。所有權轉移和成員移除不是同一個動作，如果先移除，可能連唯一的管理入口一起丟掉，帳號會短暫地無人能管。

交接後 7 天：驗證權限是否真的回收

回收動作做完不等於生效。有些平台的權限變更要重新登入才會更新，有些第三方授權在後台移除後仍保留一段存取能力，也有的會被自動化工具繼續呼叫。七天內的驗證順序如下。

1. 登入與操作紀錄：查是否還有該身分、該電子郵件或該裝置的登入，以及改價、改庫存、提領等動作。
2. 子帳號清單：重新打開成員清單，和交接當天的截圖逐行比對，不要憑印象。
3. API 與授權：在 ERP、物流、廣告後台的授權清單裡確認舊 key 已失效。
4. 瀏覽器 Profile 與代理：確認離職者用過的 Profile 是停用、重建，還是轉給了新人。若轉給新人，確認它只負責原來的那個店鋪。
5. 裝置與本機殘留：離職者用過的電腦上，是否還留有儲存的登入態、匯出的表格和本機儲存的金鑰檔案。

出現下面幾種情況，表示回收不完整，需要回到上一步補做：離職後仍有登入或操作紀錄（先確認不是自動化工具在用同一帳號）；收到環境異常或帳號複核提示；付款方式或收款帳戶被其他店鋪重複使用；子帳號顯示已刪除但仍然生效。

環境層的殘留不會自動顯露，往往要等到出問題時才會被翻出來，可以參照電商多帳號的環境隔離要點逐層核對網路出口、裝置指紋、行為節奏與本機儲存；帳號多到需要分組管理時，多店鋪多帳號的帳號分組、登入紀錄與異常處理流程給出了可直接沿用的欄位；判斷某個提示是否真的與歷史共用變數有關，則要回到平台判定多帳號是否屬於同一主體時所看的維度去對照。

回收動作做完不等於生效，七天內要用登入記錄、成員列表與授權列表逐項驗證。

交接留痕：一頁確認單結束責任

確認單的作用是把「我以為收回了」變成「有人複核過」。欄位不用多，但每一項都要能對應到一條可核查的證據。

• 時間：凍結時間、回收時間、複核時間分開記。
• 店鋪、帳號類型、平台官方角色。
• 回收項：支付與收款、主帳號、廣告、ERP 與物流、子帳號、內容平台，逐項打勾。
• 執行人與複核人：不能是同一個人。
• 證據：截圖或匯出檔案的存放位置。
• 雙方確認：離職者確認沒有遺留個人綁定，負責人確認權限已回收。

存放位置要寫進確認單本身，否則三個月後沒人找得到。查看範圍建議限定為團隊負責人、HR 與接手人，確認單裡含帳號與綁定資訊，不適合全員可見。

常見問題

離職當天沒做完，事後再補來得及嗎？

權限類動作可以補，環境類動作補起來成本更高。如果離職者已經用某個 Profile 登入過多個店鋪，事後能做的只是停用並重建，而不是回滾。所以改密碼和凍結盡量在離職當天完成，其餘七天收尾。

小團隊只有兩三個人，也要填環境編號嗎？

要。人少的時候帳號往往在幾個人的裝置之間來回登入，環境編號是唯一能說明「誰在哪個環境動過哪個店鋪」的記錄。哪怕只寫 Profile 編號和使用者兩欄，也比什麼都不記錄來得好。

離職者用過的電腦能不能直接給新人用？

可以，但要先清乾淨：刪掉瀏覽器儲存的登入狀態與密碼，清除與該帳號相關的 Cookie 與本機儲存，確認機器上沒有留存的金鑰檔案或匯出表格。如果這台機器原本承擔多個店鋪的登入，更穩妥的是重建獨立環境，而不是在舊環境上換人。

子帳號刪掉之後，這個店鋪還會被算作和以前的帳號有關聯嗎？

權限移除和平台內部的判定記錄不是一回事。刪掉子帳號只解除了存取能力，不代表歷史資料被同步清理。判定通常看多層變數的組合，具體認定標準以帳戶通知和平台官方說明為準。

交接確認單必須雙方簽名嗎？

至少要有執行人和覆核人兩個簽名。離職者簽名的意義是確認沒有遺留個人綁定，比如個人手機號碼、個人電子信箱、個人收款資訊；這一項少了，後續驗證碼收不到或資金歸屬有爭議時會很難處理。