跨國賣家的倉儲難題：如何在 eBay, Amazon, Newegg 之間完美同步美國倉庫存？(從 ERP 到自動化腳本的全解析)

對於台灣的跨境賣家來說，「物流速度」往往是決勝關鍵。

初期量少利潤高時，我們或許還能奢侈地使用 UPS, FedEx, DHL 從台灣直發北美，讓客戶在 3-5 天內收到貨。但隨著訂單量增長，或者當你開始販售體積較大、利潤較薄的產品時，「建立美國倉庫」（或是使用第三方海外倉 3PL）就成了必經之路。

然而，當你的貨物躺在美國倉庫，而你同時在 eBay, Amazon.com, Newegg 三個平台開賣時，一個致命的問題就出現了：「庫存同步」。

如果 eBay 賣出了一個最後庫存，Amazon 沒有即時扣掉，導致 Amazon 客戶下單後你無貨可發（Overselling），這對帳號績效（Account Health）是毀滅性的打擊。

本文將探討三種管理美國倉庫存的主流解法，並針對技術型賣家深入分析 Google Sheet + 自動化工具 (n8n vs. Make) 的實作細節與成本陷阱。

方案一：使用第三方 ERP / 庫存管理系統 (最常見)

如果你的預算充足，不想碰任何技術細節，市面上已經有許多成熟的 SaaS 服務整合好了各大電商平台的 API。

典型的系統有：

Linnworks（英國老牌，多平台支援極佳）
ChannelAdvisor（大型企業首選，費用高昂）
SkuVault / Skubana（專注於庫存管理）
Zoho Inventory / Cin7

優點：

開箱即用，不需要寫程式。
支援訂單同步、揀貨、出貨貼標等完整流程。

缺點：

費用不便宜（通常是月費 + 訂單抽成）。
客製化彈性低，如果你的商業邏輯比較特殊（例如：保留 10% 安全庫存），可能很難設定。

方案二：自家開發後台 (Enterprise 級別)

許多具有規模的品牌商或擁有工程團隊的跨境賣家，會選擇自建系統。

典型技術架構：

前端： React / Vue / Angular (Web 介面)
後端 API： Node.js, Python, Java
資料庫： MySQL / PostgreSQL

優點：

完全對接公司內部的 ERP 或財務系統。
可以實作極度複雜的邏輯（例如：根據不同平台的費率動態調整售價）。

缺點：

開發週期長，維護成本高（API 改版時工程師要跟著改）。

方案三：輕量級自動化 —— Google Sheet + API (靈活且強大)

對於中小型賣家，或是 SKU 在 50~100 個以內的團隊，Google Sheet 其實是最好的 CMS (內容管理系統)。它免費、協作容易，且大家都沒上手門檻。

核心流程如下：

資料源頭： 使用 Google Sheet 管理 SKU Master（庫存量、價格、標題）。
自動化引擎： 使用 n8n 或 Make (原 Integromat) 監聽表格變化。
執行動作： 呼叫 eBay / Amazon / Newegg 的 Inventory API 進行更新。

這個方案既能省下昂貴的 ERP 月費，又能保有極高的客製化彈性。但在工具選擇上，Make.com 與 n8n 該怎麼選？ 這是一個巨大的坑，選錯了成本會差非常多。

深度解析：n8n vs. Make.com —— 誰才是庫存同步的王者？

在庫存管理的場景中，我們通常需要做的是 「批次處理」（例如：每 30 分鐘同步一次所有 SKU 的庫存）。

1. 計費邏輯的差異

這是決定性因素。

Make.com： 按 「操作數 (Operations)」 計費。流程中的每一個步驟（讀取、判斷、迴圈、呼叫 API）都算一次。
n8n (Cloud 或自架)： 按 「執行次數 (Executions)」 計費。不管流程多複雜、有多少步驟，跑完一次流程只算一次。

2. 為什麼 eBay/Amazon API 對 Make.com 是場災難？

假設你有 50 個 SKU 需要更新庫存。

在 Make.com 的場景：

讀取 Sheet (1 op)
進入 Iterator 迴圈 (1 op)
迴圈 50 次：呼叫 API (50 ops) + 錯誤處理/寫回 Log (50 ops)

單次同步消耗： 超過 100 Operations。
如果你每小時同步一次，一天同步 24 次：100 * 24 = 2,400 Operations / 天。
一個月就是 72,000 Operations。
結果： 你很快就會把 Make 的 US$9 (10,000 ops) 方案用爆，甚至 US$29 方案都不夠用。

在 n8n 的場景：

讀取 Sheet -> 迴圈處理 -> 批次呼叫 API -> 寫回 Log。
整個流程跑完。

單次同步消耗： 1 Execution。
一天同步 24 次 = 24 Executions。
一個月 = 720 Executions。
結果： 即便是 n8n Cloud 最便宜的方案 (2,500 executions)，也只用了不到 30% 的額度。如果你是自架 n8n，成本更是趨近於零（只付主機費）。

進階選擇：Python 自架 (PythonAnywhere / GCP)

如果你的規模更大，或者希望成本壓到最低，Python 是終極解法。

雖然 n8n 很好用，但長期來看，自架 Python 腳本（使用 requests 庫呼叫 API）擁有絕對的優勢：

成本固定： 使用 PythonAnywhere ($5/月) 或 Google Cloud Run (低流量免費)，無論你每天 call 幾萬次 API，費用幾乎不會變。
批次處理能力： eBay Inventory API 支援 bulkUpdatePriceQuantity，用 Python 處理大數據陣列比圖形化介面更直覺、更穩定。
無平台風險： 不用擔心 Make 或 n8n 漲價或改變規則。

總結與建議

如何管理美國倉庫存？根據你的發展階段，我有以下具體建議：

階段一：驗證期 (SKU < 50, 每日訂單少)

推薦工具： Make.com
理由： 視覺化最強，設定最簡單。在量少的時候，Operations 的費用還能接受。適合用來快速驗證流程（MVP）。

階段二：成長期 (SKU > 50, 需要頻繁同步)

推薦工具： n8n (自架或 Cloud)
理由： 你的同步頻率變高，Make 的費用會開始變得不合理。n8n 的「執行次數」計費模式對「批次同步」非常友善。且 n8n 對於多平台（Shopify, WooCommerce）的支援性也很強。

階段三：成熟期 (長期穩定營運)

推薦工具： Python (PythonAnywhere / GCP)
理由： 當流程已經固化，不再需要頻繁修改邏輯時，將 n8n 的流程改寫成 Python 腳本。這是成本最低、穩定性最高、且完全掌握數據主權的長久之計。

實務小提醒：
不管你選哪個工具，串接 eBay/Amazon API 時請務必注意 OAuth Token 的自動刷新 (Refresh Token) 機制，以及做好 錯誤處理 (Error Handling)。你絕對不想發生「系統顯示同步成功，但其實 Token 過期導致 API 呼叫失敗，最後大賣空」的悲劇。