Shopee 六國站點一起開的時候，帳號怎麼分組才不亂

六國站點一起開，最先亂的通常不是銷量，是後台：泰國站的營運在馬來店後台點了出貨，菲律賓站收到的卻是馬來收款帳戶的驗證提醒，新人接手時對著十多個帳號不知道哪個能改價。

這類事故的根源不是沒分組，而是分組維度互相打架——按國家分、按店型分、按人分，任意兩套都會覆蓋第三套。

先把結論放前面：Shopee 馬來、泰國、越南、菲律賓、印尼、新加坡六國站點同時開的時候，先別按國家分組，先確認每個帳號背後的控制變數是否一致。控制變數一致的一組帳號才是同一組，「國家」只是其中一個變數。

六國站點一起開，先別急著按國家分組

MY 組、TH 組、VN 組這種切法，在「一人管一國、一國一店」的階段完全夠用，因為國家剛好等於控制變數。問題出現在同一國家內部開始分層的時候：泰國有跨境店也有本土店，本土店還可能掛在兩張不同執照下，履約倉和收款主體都不一樣。

這時「泰國組」這個標籤會把這些差異蓋住。同一個組裡的帳號註冊主體不同、收款帳戶不同、出貨倉不同，但因為在同一張分組表上，日常操作就會預設它們可以互換——共用一套瀏覽器環境、共用一組子帳號、共用一份客服話術。

平台判斷多個帳號是否屬於同一主體時，看的不是單一訊號，而是網路出口、裝置與瀏覽器指紋、身分與支付資訊、行為軌跡這幾層變數的重合度（拆解見平台判斷幾個帳號是同一人的時候，通常看哪些維度）。按國家分組只對齊了站點欄位，其餘幾層仍是散的，真的被要求補充驗證時，你也說不清是哪一層先重疊。

先判斷你在哪個階段，再決定主分組軸

分組不是越細越好，團隊規模不同，主分組軸就該不同。先在下表裡找到自己那一列。

判斷標準只有一個：如果兩組帳號可以被同一個人用同一個瀏覽器視窗先後登入而沒人覺得奇怪，說明它們還沒真正分開，分組只停在表格上。

用「營運單元」做主分組軸，再掛站點、店型、履約和收款

營運單元指的是一組控制變數一致的帳號：同一註冊主體、同一收款歸屬、同一履約方式、同一套環境配置、同一負責人。它衡量的是風險半徑，不是資料夾層級——一個營運單元可能是 1 家店，也可能是同一執照下泰國的 2–3 家本土店。

確定單元之後，站點、店型、履約倉、收款帳戶、子帳號、ERP 綁定這些欄位全部掛在單元下面，而不是平行分組。這樣做的價值在於：任何一次調整都只動一個層級，新人入職只需要知道自己在哪個單元，不需要背六國站點的全部差異。

需要提醒的是，本土店和跨境店的差別不在後台按鈕，而在主體、履約、資金和多店環境這條鏈路上（Shopee 本土店和跨境店，營運上的九個差別）。把它們放進同一個單元，等於把兩條鏈路的變數混在一起，分組表後面怎麼維護都會出錯。

六國站點直接套用的分組表：4 類營運單元怎麼放

下面這張表是按「控制變數一致」排出來的常見型態，可以按自己的實際執照和收款情況增減列，但欄的判斷邏輯不要改。

表裡最重要的是最後一列。分組亂，通常不是分得不夠細，而是有人為了省事把「不能混」的帳號塞進同一組。本土店矩陣的帳號隔離順序、選品與合規流程可以配合Shopee 本土店矩陣與 Lazada 多店鋪的帳號隔離實操一起對照，但隔離順序不能反過來遷就分組習慣。

跨境店和本土店混營時，分組順序按這四步走

1. 先按收款主體分。錢歸誰，是平台與收款機構交叉比對的錨點，也是多店被歸到同一控制人的第一層線索（原因見幾個店鋪共用一個收款帳戶，會發生什麼）。收款主體不同的帳號，無論站點是否相同，都不能進同一單元。
2. 再按履約方式分。本土倉出貨、3PL 代發和跨境 SLS 是三條不同的鏈路，時效承諾、退貨地址、客服話術都不一樣。同一單元內履約方式必須統一，否則一個退貨地址填錯就是兩個站點的事故。
3. 再按站點和店型分。到這一步才輪到國家和跨境／本土標籤。前兩步已經保證了單元內部的資金和貨是一致的，國家只用來給單元起名。
4. 最後按營運人員權限分。人是最容易變的一層，放在最後。誰負責哪個單元，用子帳號授權表達，而不是把帳號密碼和環境一起交出去。

順序不能顛倒。先按人分，一次調職就會把兩個收款主體塞進同一套環境；先按國家分，一個「泰國」裡會同時出現本土店和跨境店，後面每一步都要打補丁。

一個營運單元對應一整套配置：獨立瀏覽器環境、代理出口、子帳號權限、收款帳戶和 ERP 綁定

分組之後，環境、子帳號和收款要落在同一張對應表上

分組只要停留在表格裡，最多三天就會失效。真正讓分組生效的，是每個營運單元都對應一整套設定，並且這套設定能被核對。

具體要落的是五項：獨立瀏覽器 Profile（店鋪指紋、Cookie 與登入狀態互不共用）、綁定到該 Profile 的代理出口（同一單元可以共用出口，不同單元不要混用）、該單元的子帳號權限範圍、收款帳戶與提現鏈路、ERP 或打單系統的店鋪綁定。五項裡任何一項跨了單元，這一組就不算乾淨。

把這張對應表放在團隊都能看到的地方，新店上線時先填表再開店，比事後排查省事得多。營運離職或調職時，按店鋪帳號交接與權限交接清單的順序凍結入口，對應表就是最直接的核對依據。

交接時先核對固定欄位，再交負責人和後綴；固定欄位一改就等於換組

命名規則：讓新人一眼看懂帳號屬於哪組

命名只需要表達四件事：站點、店型、單元號、負責人。常用範本是 站點_店型_單元號_序號_負責人，例如 TH_LOC_U03_02_Lin 表示泰國本土店、第 3 單元、該單元第 2 家店、負責人 Lin；跨境店把店型換成 CB 即可。

必須固定的欄位是站點代碼、店型代碼和單元號，這三個決定歸屬，改了就等於換組，必須同步對應表。可以變動的只有負責人和後綴。序號只在同一單元內遞增，不要跨單元連續編號，否則擴店時序號會互相插隊。

交接卡是命名的補充，用來記錄無法寫進名字的部分：店鋪 ID、註冊主體、收款帳戶、履約方式、瀏覽器 Profile 名、代理出口、子帳號列表、ERP 綁定、最後變更日期。交接時逐項過一遍，任何一項對不上就先停下來，不要靠「應該是這個」繼續操作。

三個最容易把分組搞亂的邊界條件

• 多店共用收款帳戶。如果兩家店必須共用一個收款主體，就把它們按同一個營運單元處理，別再拆成兩組；確實想拆開，先拆收款鏈路，再改分組表。
• 跨組臨時調人。讓臨時接手的營運人員用子帳號進入目標單元，不要把自己的帳號密碼、Profile 或代理給出去。人走了權限還在，是最難查的一類串組。
• 擴站時直接塞進舊環境。新開新加坡站或加一家越南本土店，先建獨立 Profile 和出口，再首次登入。已經用舊環境登過的帳號，不要靠「以後注意」補救，直接按新單元重配一輪並記錄變更日期。

常見問題

六國站點能不能放在同一個瀏覽器裡用不同分頁開？

能不能開和該不該開是兩件事。同一個人先後登入不同單元的帳號，會讓登入狀態、Cookie 和本機儲存在同一個環境裡累積，出問題時無法判斷是哪一層先重合。跨單元一律換 Profile，哪怕只是看一眼後台。

一名營運人員同時負責泰國和越南，分組要按人拆開嗎？

不需要。分組依控制變數走，人負責幾個單元就配幾個單元的權限，切換時換環境。按人分組會把人員變動直接變成帳號重組，成本遠高於多配一套 Profile。

子帳號可以跨營運單元共用嗎？

不建議。子帳號是登入入口，也是操作軌跡的歸屬標記。一個子帳號同時掛在兩個單元下，兩個單元的行為軌跡就會交叉，後續很難分清某次改價、改庫存是誰做的。

新開新加坡站，應該歸到哪個單元？

先看收款主體和履約方式，而不是看它和哪個國家「比較像」。走跨境鏈路、收款與原跨境主體一致，就併入單元 A 並在命名裡加 SG；如果是獨立主體或獨立收款，單獨建單元。

分組表和映射表多久更新一次？

按事件更新，不按時間更新：新店上線、收款帳戶變更、負責人變更、履約倉切換、擴站換環境，這五類事件發生當天就改。日常巡檢只核對命名與映射表是否一致，不要順手改結構。