開店平台、WordPress 購物車還是客製電商？判斷點不只是預算

文章導讀

「開店平台、WordPress 購物車，還是乾脆做客製電商？」這是我們在電商諮詢裡最常被問到的一題。多數人會先比月費和建置費，但只看這兩個數字，很容易選到「現在能上線、半年後開始繞路」的方案。參考的做法是先把商品、價格和客戶身分攤開，再看庫存、配送、退款和資料怎麼流動。正常流程之外有多少例外，哪些規則正是你們的商業模式，答案通常就藏在這裡。

先別從預算問起，先看營運有多少例外

每個電商都有商品和購物車，也都有結帳、付款和訂單。系統之間的差異，多半出現在這條基本路徑旁邊的條件，像是這些：

• 不同客戶看到不同價格
• 某些商品不能一起配送
• 訂單要經過業務確認才成立
• 庫存分散在門市和倉庫
• 退款時要同步調整發票
• 訂單完成後，要回寫 CRM 或 ERP

例外很少時，標準化工具能把成熟的流程直接帶進來。例外很多時，硬把營運塞進固定欄位，最後就是同事在試算表、通訊軟體和好幾個後台之間補工作。選電商架構，看的是它能不能自然接住你們每天真的在做的事。功能清單長不長，反而是其次。

三種電商架構，差別在控制範圍

這三種名稱，可以看成控制範圍一步步變大。開店平台由服務商提供主機、系統和既定功能。WordPress 購物車以 WordPress 和 WooCommerce 這類成熟核心為基礎，網站、內容和外掛都能依專案配置。客製電商，則把你們公司特有的資料和流程做得更深。

架構	主要優勢	常見限制	比較適合
開店平台	基本流程整合完整，環境與更新由平台處理	欄位、結帳與資料交換多依平台提供範圍	商品與流程標準、希望先快速驗證市場
WordPress 購物車	內容、SEO、品牌頁面與購物功能能在同一站整合	需要專業維護主機、版本、備份與相容性	內容與交易都重要，且預期持續擴充
客製電商	可依價格、權限、訂單與資料流建立專用規則	前期盤點、測試與長期維護深度更高	營運例外多，系統本身會形成競爭力

客製電商不一定從零開發。多數企業可以用成熟核心加上客製外掛，把資源集中在真正不同的流程。

什麼情況適合開店平台

商品規格好整理，價格對所有顧客都一樣，庫存來源也單純。促銷和配送如果也屬於常見情境，開店平台通常就能提供完整的基本能力。帳號、主機、結帳和付款，連同後台，都由同一個服務串起來，你們不用先處理太多技術決策。

還在驗證商品和通路的階段，也適合開店平台。這時候要確認的是客群、商品組合、客單價和回購，想像中的功能可以晚一點再做。平台既有的規則，反而能幫你們把流程收斂，避免還沒開始營運，就先投入大量客製。

選了平台，未來的需求還是要先想過。上線前，先列出你們最可能增加的會員、促銷、物流和資料需求。再看平台有沒有對應的方案、應用程式或匯出方式。關鍵流程如果一開始就超出平台的範圍，之後用人工補洞的成本，會一個月一個月累積。

WordPress 購物車的優勢在哪裡

WordPress 購物車的一個特色，是內容網站和交易網站可以用同一套架構規劃。品牌故事和服務頁、知識文章和案例，連同公開的商品資訊，都在同一個網域持續累積。搜尋引擎也比較容易看懂它們之間的主題關係。會員和訂單資料，則留在網站後台支撐營運。

WooCommerce 官方把自己定位成建立在 WordPress 上、可以擴充的開源電商平台。實務上的好處是：成熟的功能直接用，特殊的需求有清楚的外掛與開發邊界。例如標準的商品和訂單，沿用既有結構。會員分級、結帳欄位和特殊運費，還有付款後的動作與後台報表，再依你們的流程擴充。

另一個優勢，是整個網站環境能由維護團隊統一配置。主機、快取和資料庫，加上圖片處理、備份與 SEO，都在同一個環境裡調整。活動流量或商品量變大時，也能從實際的瓶頸下手。相對地，這份控制力需要一組團隊持續負責，內部人力或委外維護都算。核心、外掛、主機和客製功能，都要持續更新與測試。

哪些訊號代表需要客製電商流程

這是我們檢查電商網站時很常看到的狀況：客製需求早就藏在同事的人工作業裡。業務登入後台改價格，客服另外打電話問配送。倉庫把訂單再輸入一次，會計月底重新對帳。這些動作，其實就是網站還沒接住的規則。

• 客戶身分會改變交易條件

  經銷商、企業客戶、會員等級或合約客戶，看到的價格、最低量和付款方式都不同。

• 訂單成立前需要判斷

  商品要先報價或審核資格，或要確認服務區域、選擇時段；也有的要業務核准後才能付款。

• 交付方式不是一張運費表

  常溫和冷藏要分單，大材積要另外報價；也有門市自取、分批出貨，或依地區換不同物流。

• 付款後還有後續動作

  開立電子發票、建立服務資格、通知特定部門；有時還要產生預約，或把訂單送到其他系統。

• 售後會改變原始訂單

  部分退貨、換貨或取消服務時，退款和發票要跟著一致調整，各自用人工處理很容易對不上。

出現其中一項，也不代表要整站重做。WordPress 的做法，可以是保留現有的購物車，再用客製外掛擴充特定環節的功能。資料結構和流程已經互相衝突時，才需要重新規劃。判斷的重點，在於問題發生在哪一層。

三個常見情境，會落在不同架構

剛建立線上通路的品牌，商品規格固定、單一倉庫出貨，促銷規則也常見。現階段要驗證的是商品和客群，開店平台通常就能接住。

已經有穩定內容和自然搜尋流量的品牌，希望文章、案例和商品共用同一個官網，還要依活動調整頁面和結帳。這時 WordPress 購物車的整合空間比較合適。

企業客戶要先登入才看得到合約價，訂單要經業務審核，出貨後還要回寫內部系統。這種情境的關鍵，在資料、權限和狀態怎麼流動，版型是次要的。可以用 WordPress 和 WooCommerce 當成熟的核心，再用客製外掛承接差異；也可能需要重新規劃更深的電商架構。

客製設計、功能客製與系統串接是三件事

很多電商需求，會被一句「想做客製網站」包在一起，拆開來其實至少有三種。客製設計處理品牌、商品呈現和購買動線。功能客製處理價格、權限和促銷，以及訂單與售後的規則。系統串接處理的，是網站和其他系統之間的資料交換，例如 CRM、ERP、庫存，或物流、金流與發票服務。

需求層次	常見問題	主要交付
客製設計	品牌與商品怎麼被理解，購買路徑是否清楚	資訊架構、頁型、視覺系統、手機版與互動
功能客製	價格、資格、結帳、訂單與售後怎麼運作	客製外掛、欄位、狀態、權限與後台操作
系統串接	資料由誰建立，要送到哪裡，失敗怎麼補	API、Webhook、排程交換、對應表與例外流程

三層可以分階段進行。先確定是哪一層在限制營運，才不會換了畫面，問題還留在原地。

資料能否延續使用、接到其他系統，會影響長期營運

商品、會員和訂單，會隨著時間變成營運資產。評估架構時，要先確認這些資料能不能延續使用。例如能匯出哪些欄位、歷史訂單和狀態是否完整、圖片和網址能不能對應。新產生的資料，也要能持續送到其他系統。

開店平台通常有既定的匯出和介接方式，範圍依方案與服務而定。WordPress 和 WooCommerce 的資料保存在網站環境裡，需要時由維護團隊以通用格式匯出，備份和串接也由維護團隊規劃。高度客製的架構，能更精確地定義資料模型，維護團隊也要持續保管與更新更嚴謹的內部維運紀錄。

客服、業務、倉庫和會計都要用同一筆訂單時，網站不一定要取代所有系統。比較好的分工，是先決定哪一套是主要的資料來源。其他系統再透過批次匯入匯出、Webhook、API 或客製外掛，交換必要的資料。這樣就不會每一套系統，都各有一個「看起來最新」的版本。

總成本要看改動與維護，不只看上線費

開店平台常把主機和基本更新含在固定方案裡。額外的成本，可能來自升級方案、加購應用程式、交易相關服務或特殊調整。WordPress 購物車的費用，常見會包含下面幾類，實際項目依網站架構與專案階段而定：

• 網站建置
• 主機
• 付費外掛的授權
• 客製開發
• 年度維護

高度客製的電商，還需要更多盤點、測試和版本管理。比較方案時，要把三個時間點放在一起看。上線前要投入什麼？每年固定要維持什麼？流程改變時，新增一條規則又要怎麼處理？初期看起來精簡的方案，如果每個例外都靠人工補，營運成本就藏在同事的時間裡。彈性高的方案少了持續維護，技術風險也會一點一點累積。

比較之前，先在你們公司內部把這幾件事問清楚，成本才估得準：

• 你們預計多常調整價格、促銷或配送規則？
• 現在有哪些工作要靠同事在系統外補做，每個月大約花掉多少人力？
• 旺季時，商品、會員和訂單量大約會變成平常的幾倍？
• 訂單資料還要提供給哪些部門或系統使用？

不論選哪一種架構，備份、版本更新、異常處理和資安都要持續有人負責，內部人力或委外維護都算。開店平台由平台處理系統這一層；選了 WordPress 購物車或客製電商，這些就是年度維護代管要接住的工作。

用現在與未來兩年的流程做選擇

先把你們每天真的在跑的流程畫出來，再加上未來兩年很可能發生的變化。「也許有一天」的需求，不必都放進第一期；已經確定會發生的會員、通路、庫存或系統整合，則要一開始就算進去。

• 列出商品與客戶類型

  商品是否標準化、價格是否一致、個人與企業客戶的購買方式是否相同。

• 畫出一筆訂單的完整路徑

  從進站、結帳到付款，再到開票、出貨和退換貨，標出所有人工轉交與例外。

• 找出不能妥協的規則

  哪些規則直接支撐利潤、客戶關係或交付品質，不能為了配合工具而取消。

• 把需求分成現在、下一階段與想像

  第一期只做營運必需，但資料與權限要為已知的下一階段保留空間。

• 再比較架構與總成本

  此時才評估平台、WordPress 模組與客製外掛各自承接哪些部分。

從平台搬到 WordPress，也要先設計遷移路徑

已經在開店平台營運，也不必因為一個新需求就立刻搬家。先確認平台有沒有合適的擴充方式；關鍵流程長期受限，再開始規劃遷移。要盤點的資料有三大類：

• 商品、分類與圖片
• 會員與歷史訂單
• 網址與 SEO 設定

資料搬完只是第一步。舊網址轉向、付款與發票測試、會員通知，以及營運切換的時間，都要一起規劃，再分批進行。

我們怎麼協助企業選擇電商架構

談電商架構時，可以先問一題：你們的同事除了網站後台，還開著哪些工具？試算表、通訊軟體、另一套進銷存，每多一個，就代表有一條規則網站還沒接住。接著把這些規則一條一條列出來，再分出哪些是你們的商業模式，哪些只是做事的習慣。

分完之後，內容和常見的交易流程，用成熟的架構承接；只有影響商業模式的規則，才另外開發。會員與訂單規則、付款與發票、物流或資料回寫，都依必要程度擴充。網站上線後，主機、備份和速度，連同 SEO、版本相容與關鍵流程測試，都放進年度維護代管。這些工作不論你們這個月有沒有新活動，都持續在進行。

常見問題