跨境團隊的分級權限怎麼設計：誰該看到什麼？

營運離職兩週後，主管才發現後台還有三個子帳號能登入，其中一個在凌晨改過兩次收款綁定；另一個團隊，店長同時握有店鋪設定和提現權限，一次誤操作把兩家店的回款提進了同一張卡。

這類事故的根因通常不是「人不可靠」，而是權限表只回答了「給他什麼角色」，沒回答「他能看到什麼、能改什麼、能把錢挪到哪裡」。多店、多平台、多主體的結構會把這個問題放大：同一個「營運主管」職級，A 可能在管三家跨境店，B 卻在管一家泰國本土店的收款主體。按職級切權限，等於按職級切風險。

下面按風險半徑重做一次權限設計：先分清三層權限，再分角色，最後用店鋪分組把平台子帳號、ERP、瀏覽器環境和資金權限對齊到同一張矩陣。

先拆權限的三層：看見、操作、轉移

把權限籠統寫成「管理員 / 營運 / 客服」，訂不出邊界。先按「能造成什麼損失」拆成三層：

• 資料可見層：訂單明細、客戶聯絡方式與地址、真實成本與毛利、廣告消耗與投產比、供應商與採購價。這一層主要造成資訊外洩和議價能力損失，不會直接動錢。
• 操作執行層：上架與改價、出貨與改地址、退款與補寄、優惠券與活動報名、客服回覆。損失有單次上限但會累積，一個錯誤折扣能吃掉一家店整月的毛利。
• 轉移與主體層：收款帳戶綁定與變更、提現與付款、稅務與法人資料、店鋪主體與授權、廣告付款方式。這一層沒有損失上限，而且平台端留下的紀錄追溯的是主體，不是操作人。

三層的授予順序和直覺相反：資料可見度可以放寬到職位需求，操作執行則按店鋪組收窄，轉移與主體層永遠保持最小集合，並加上覆核。多數團隊出問題，都是因為第三層被順手發給了第二層的人。

按風險半徑分角色，不按職級分角色

「主管看全部、營運看自己店」在多店團隊裡會立刻失效，因為風險半徑跟職級無關，跟這個角色能碰到什麼有關。同一個職級的人，可能一個只改標題，另一個能改收款。

一個夠用的判準是：假設這個角色判斷失誤或被惡意操作，最大損失是什麼？這個損失當天能不能被發現？答案決定他落在哪一類。

• 能碰金流鏈路和主體資料的，損失沒有上限——負責人、財務，通常不超過兩人，且不參與日常執行。
• 能改價格、庫存、活動、出貨的，損失以店鋪月毛利計——店長，權限綁定到店鋪組，不跨主體。
• 只處理訂單與客戶對話的，損失以單筆訂單計——營運、客服，權限限定在訂單層，看不到成本和收款。
• 沒有長期信任關係的，損失以資訊外洩和帳號外借計——外包設計、達人對接、臨時兼職，只給有期限的窄權限，任務結束即撤。

四類角色的最小可見集

下表是最小授權的起點，而不是標準答案。任何一個格子的例外都要有理由，並且寫進權限清單裡，否則半年後沒人說得清為什麼他能看。

店鋪分組是權限的第一層容器

逐店勾選在 3 家店時勉強可行，到 8 家、10 家必然出錯：新店開出來沒人記得配權限，於是直接複製上一個帳號的勾選，把不該給的範圍一起複製過去。把角色綁到「組」，新店只需歸組就自動繼承。

1. 第一層按平台分組：TikTok Shop、Shopee、Amazon、獨立站各自成組。跨平台的角色能力不通用，一個人同時管兩個平台的中控台，等於把兩套風險口徑混在一起。
2. 第二層按國家或站點分組：泰國、越南、馬來西亞分開。本土店的註冊資料、收款主體和售後規則按國別不同，混在一個組裡會出現「能看泰國店的利潤，就順帶看到越南店的」。一國多店的分組細節可參考TikTok Shop 東南亞本土店矩陣的分組與子帳號對映。
3. 第三層按註冊主體分組：同一營業執照下的店鋪歸一組，不同主體的店不允許出現在同一個角色範圍裡。角色一旦跨主體，離職交接時你無法判斷他帶走了哪些主體的資料。
4. 第四層按風險等級標註：主力店、測試店、待處置店分開。測試店可以給寬權限提速，主力店的改價、換主圖、改收款必須走複核。

組名要能自解釋，例如「TTS-TH-主體A-主力」，避免「組1」「新組」這類名字——半年後沒人知道它包含什麼，也沒人敢刪。

子帳號、ERP、瀏覽器環境必須對齊到同一張權限矩陣

只在平台後台設定子帳號，通常會被下面三個入口繞過，而且繞過時後台日誌看起來一切正常。

• 瀏覽器環境歸屬：一個 Profile 綁定了哪幾家店，這個環境的持有者就能登入其中任意一家。平台子帳號切得再乾淨，共用 Profile 依然讓權限形同虛設。Profile 與店鋪的一對一歸屬做法見一台電腦同時營運多個 TikTok Shop 的環境設定，也可以從多帳號管理的思路裡挑適合自己規模的隔離粒度。
• ERP 店鋪範圍與 API key：ERP 主帳號和開放的 API key 往往比平台子帳號權限更大，能一次性拉走全部店鋪的訂單和利潤資料。給營運開 ERP 子帳號時，店鋪範圍必須和平台側一致；凍結清單裡，API key 要排在子帳號前面吊銷。
• 共享收款與付款帳戶：多家店共用一個收款帳戶時，能進這個帳戶的角色實際上能影響所有店。幾個店鋪共用一個收款帳戶的連帶風險裡，最先暴露的往往就是這類交叉。

核對方法很笨但有效：拿一張表，列是角色，欄依次是平台角色、可見店鋪組、ERP 店鋪範圍、瀏覽器 Profile、API key 歸屬、收款與付款權限。每個角色填完之後，找一列出現「全部」的地方，問一句為什麼。

資金與合規權限：任何角色都不能一人閉環

如果團隊只有三個人，雙人複核做不到，退一步的替代方案是：資金類操作集中到一個主帳號，主帳號的登入環境單獨隔離，每次資金操作在團隊群組裡留一筆記錄，寫清時間、金額和去向。這不是合規方案，但它能把「沒人知道」變成「有人看到」。

入職、調職、離職的權限變更順序

1. 入職當天只給組和最小角色，不給單店逐項勾選。新人先跑一週訂單和客服，確認確實需要更多資料時再加。
2. 試用期結束按職務補資料可見層，比如成本和廣告消耗；操作執行層按店鋪組放開；轉移與主體層不開放。
3. 調職先減舊組、再加新組，順序不能反。先加後減會讓帳號在兩個組裡同時存在一段時間，日誌上無法區分他用哪個身分操作。
4. 離職前 48 小時依次凍結平台子帳號、吊銷 ERP API key、收回瀏覽器 Profile、移除收款與付款授權、移出廣告帳戶，最後才改主帳號密碼。只改主密碼是最常見的漏項，完整的項目清單見營運離職帳號交接的權限清單。
5. 交接確認表逐項簽字，包含店鋪組、資料範圍、未處理完的退款和未花完的廣告預算。

常見反模式與邊界條件

• 全員管理員：3 人團隊最容易這麼做，圖快，代價是任何一次誤操作都沒有邊界。
• 子帳號共用：兩人用一個帳號，日誌無法歸因，出了問題只能猜。
• 財務看全部店鋪利潤：本身合理，但如果同一個財務還有提現權限，資金鏈路就沒有第二道門。
• 外包用主帳號：最常見的帳號外借形式，通常以「就傳幾個檔案」開始。
• 離職只改主密碼：子帳號、API key、舊 Profile、收款授權都還開著。

三人以下的團隊不必照搬四類角色，但至少保留兩條線：資金操作與店鋪設定分開，執行帳號與主帳號分開。人再少也不建議把兩者合併在同一個人身上，因為合併之後沒有任何機制能發現問題。