週二早上9:15，營運組三個人同時打開5個 TikTok Shop 後台和2個 Temu 商店，選品組在跑第三輪數據回篩，物流組剛處理完一批 FBA 退貨工單。12個人、11家跨境電商商店、5個平台——這不是理想化的演示，是我們上週二的實際節奏。下面按角色拆工具棧，重點說每個環節的工具之間怎麼接力、多商店登入怎麼隔離，以及哪些地方最容易踩坑。
週二早會：12個人、11家店、5個平台的分工
團隊構成固定為四組：選品組3人（負責數據採集、競品監控和趨勢判斷），營運組4人（管多商店登入、上架和廣告），物流組3人（國內倉、頭程、海外倉對接），數據組2人（匯總全鏈路報表）。11家店分佈在 Amazon、TikTok Shop、Temu、Shopee 和獨立站，其中 TikTok Shop 佔4家、Amazon 3家、Temu 2家，其餘各1家。早會15分鐘，只過異常：退貨率突增的SKU、被限流的商店、頭程延誤批次。正常節點不進議程。
選品端：3個人各自盯的工具池
選品不是一個人拉全量數據再分，而是三個人按平台切分，工具之間靠觸發條件接力：
- 數據採集員（1人）：每天9:00前跑完 Amazon 和 TikTok 的類目榜單抓取，用固定腳本導出到共享表格。觸發下一人的條件是榜單出現連續3天排名上升超過20位的SKU，而不是單純看絕對值。
- 競品監控員（1人）：盯目標SKU的競品價格變動、評價增速和廣告位占比。工具按平台不同——Amazon 側重搜尋意圖鏈的變化，TikTok 看內容勢能（短影片帶鏈結的轉換率），Temu 看平台定價鏈的波動。三條決策鏈的輸入條件完全不同，不能共用一張評分表，具體拆解邏輯見亞馬遜、TikTok、Temu 選品邏輯對比。
- 趨勢判斷員（1人）：每週二和週五各做一輪回篩，把前兩人的輸出合併，砍掉生命週期過短的品。回篩標準不是單指標閾值，而是看品類競爭密度和物流適配度（能不能走現有頭程線路）。
三人的工具池不重疊：採集員用爬蟲和 API，監控員用各平台後台加第三方排名工具，趨勢員主要看合併後的表格和物流商報價。一個人最多同時盯3個平台，超過就切給下一個人，避免多店鋪營運工具的選擇變成"誰都能用但誰都不精"。
多店鋪層：11家店怎麼分到5個瀏覽器實例
11家店不會開11個瀏覽器視窗。我們的分配原則是按風控檢測維度分環境：同一平台、同一法人主體、同一代理出口IP池下的店鋪可以共享一個指紋瀏覽器實例；跨平台或不同法人主體的必須獨立實例。實際操作下來是5個實例——TikTok 4家店分2個實例（按市場站拆），Amazon 3家店1個實例，Temu 2家店1個實例，獨立站1個實例。每個實例配獨立代理出口，Cookie 域和本地儲存完全隔離。
權限管理上，營運組4人各對應2-3個實例，登入密碼和代理設定寫在內部文件裡，不讓一個人管全部。多店鋪登入的切換成本靠多帳號隔離配置和團隊協作權限方案來控制，核心是共享變量（裝置指紋、IP段、登入行為節奏）的管控，而不是帳號數量本身。具體配置標準可參考Temu 多店鋪合規邊界與隔離配置。
多店鋪運營工具解決的是環境隔離效率，不替代合規資質、真實經營數據和穩定的網路出口。兩個高頻踩坑點：一是代理IP池複用週期太短，同一出口IP在冷卻期內被兩個實例輪詢，觸發平台環境異常標記；二是團隊誤把「指紋不同」等同於「風控通過」，實際平台檢測維度遠不止指紋，還包括行為節奏和資金鏈路。團隊自查建議每兩週跑一次全實例環境比對，重點看代理出口是否有重疊窗口。
物流與售後：從ERP到FBA退貨的4個節點
物流組3人管全鏈路，每個節點的工具和對接方式不同，數據回傳和異常觸發規則是協作的關鍵：
- 國內倉：用ERP統一管庫存和揀貨，觸發條件是訂單量超過日處理上限的80%時自動預警，物流組提前48小時安排加倉。異常規則：SKU缺貨率連續2天超5%時，選品組同步降權該SKU。
- 頭程：按目的國分2-3條線路（快船/空運/鐵路），工具是物流商各自的追蹤系統加一個統一導出表。觸發規則：任何批次延誤超72小時，運營組暫停該平台新上架，避免庫存斷檔。
- 海外倉 / FBA：Amazon 走 FBA，其餘平台用第三方海外倉。FBA 退貨走 Amazon 後台的退貨管理模組，第三方倉走工單系統。節點間數據靠每日一次的庫存快照同步到共享表，數據組據此出報表。
- 尾程與售後：尾程追蹤用各平台自帶物流追蹤，售後工單集中在一個看板裡按優先級排序。觸發規則：同一SKU 7天內退貨率超15%時自動標紅，選品組48小時內給出處置建議（改詳情、換供應商或下架）。
多平台訂單不在各平台後台分散看，而是靠ERP聚合到同一個面板，物流組只看一個介面。帳號矩陣層面的投放數據和物流數據怎麼打通，可以參考多帳號矩陣管理中的批次操作與數據匯總方案。
月支出結構與協作天花板
12人團隊的工具月支出大致分三塊：SaaS 類（ERP、海外倉系統、廣告管理）約佔總工具支出的一半；代理IP和指紋瀏覽器環境（含多店鋪登入的實例維護）佔約三成；物流追蹤和客服工具佔剩餘兩成。具體數字隨平台數量和SKU數浮動，這裡不給出固定金額，因為擴店時支出曲線不是線性的。
判斷什麼時候該換工具或加人：不是看"預算夠不夠"，而是看協作瓶頸。當前12人管11家店，運營組每人同時管2-3個實例已經接近行為節奏管理極限——多店鋪登入的切換頻率越高，單個實例的在線時長越短，平台對"異常活躍"的標記機率上升。如果擴到20人管20家店，最先撞牆的通常不是工具本身，而是代理IP池的出口數量和冷卻週期。建議擴編前先把多店鋪管理工具的環境隔離配置重新審一輪，而不是直接加實例。
常見問題
12人團隊管11家店，瀏覽器執行個體數怎麼定？
不是按店數定，而是按風控偵測面向分：同平台同主體的店可共用執行個體，跨平台或不同法人必須獨立。我們11家店最終是5個執行個體，關鍵是代理出口不重疊、登入行為節奏各自獨立。
選品組三個人各管什麼，會不會重複抓數據？
按接力而非重疊設計：採集員只出原始榜單，監控員只在採集員觸發條件滿足後介入，趨勢員做最終回篩。三人工具池不交叉，一人最多盯3個平台，超過就切人。
多店營運工具能保證不封店嗎？
不能。商店管理工具解決的是環境隔離效率，降低 Cookie、裝置參數共享造成的關聯風險，但不替代合規資質、真實經營和穩定網路。平台偵測面向遠不止指紋，具體處置以帳號通知和官方政策為準。
物流節點數據怎麼做到一個儀表板看全？
用ERP做訂單聚合，各物流商追蹤數據每日匯出到統一表格，海外倉和FBA退貨走各自系統但庫存快照每天同步。物流組只看聚合儀表板，異常靠閾值自動標紅，不逐單排查。
