官網、CRM、ERP 到底差在哪裡？資料該放哪裡，真的要串接時怎麼做

文章導讀

業務每天早上的第一件事，是把官網表單的詢問，一筆一筆貼進 CRM。成交之後，同一位客戶的資料，還要在 ERP 裡再打一次。公司規模變大後，資料常常就是這樣散著。客戶資料在官網、業務的試算表和 CRM 裡，商品、訂單和庫存又分在購物車和 ERP 兩邊。這時最直覺的想法，是「全部串在一起」。可是有三件事得先講好：哪個系統負責什麼、同一位客戶怎麼辨認、兩邊狀態衝突時聽誰的。沒講好就串接，只會讓原本的混亂傳得更快。所以規劃要從商業流程和資料責任開始，API 是之後拿來交換資料的工具。

先談商業流程，再談要買哪個系統

系統名稱很容易讓討論失焦。需求訪談時，我們很常被問到這類問題：官網的會員能不能直接當 CRM 用？CRM 能不能順便管庫存？ERP 能不能直接做前台頁面？這些工具的功能確實有部分重疊，但設計的重心不同。只比功能清單，很容易買到一堆能力，資料怎麼流動的問題卻還在。

規劃時，先畫出一條真實的流程。例如潛在客戶從服務頁送出需求，業務確認資格、持續跟進。成交後建立訂單，倉庫安排出貨，最後把交付狀態回寫到客戶查得到的頁面。每一步由誰負責、產生什麼資料、下一步需要什麼資訊，決定了官網、CRM 和 ERP 各自的位置。

系統整合的目的，是讓對的人在對的時間，拿到完成工作需要的正確資訊。一個欄位如果沒有明確的用途，技術上能同步，也不必同步。錯誤如果會影響價格、庫存、客戶權益或帳務，驗證和異常處理就要更嚴格。

官網、CRM、ERP 的角色差在哪裡

系統	主要面向	典型資料	核心問題
企業官網	市場、訪客、會員與買家	公開內容、表單、會員、購物車與付款入口	外部使用者如何理解、互動與完成行動
CRM	行銷、業務與客服團隊	客戶、互動、商機、跟進、案件與關係歷程	公司如何持續經營潛在與既有客戶
ERP	採購、營運、倉儲、財務等內部部門	品項、採購、庫存、訂單、出貨與帳務	公司如何配置資源並完成日常營運

官網站在公司的邊界上，把外部的需求帶進來，也把可以公開的資訊送出去。CRM 以人和關係為中心，追蹤每一次接觸後來怎麼發展。ERP 以資源和交易為中心，讓商品數量、成本、交付和財務，在內部流程裡保持一致。這是理解分工的起點，並不表示每套產品只能做一件事。

同一件事，會在三個系統留下不同的紀錄。官網保存最初的資料，CRM 建立商機，ERP 則在成交後建立正式訂單和出貨。每套系統只留自己工作需要的狀態，不必整份複製。

官網是對外內容、互動與交易入口

企業官網首先是一個對外公開的內容系統。品牌、服務和產品介紹在這裡，案例、知識文章、徵才資訊和聯絡方式也在這裡。它要讓搜尋和 AI 功能找得到內容，也要讓不同裝置上的訪客看得懂。這類資訊的更新頻率和呈現方式，通常不適合交給 ERP 的內部畫面。

官網也是互動的入口。表單、預約和報名，會員申請、文件下載和客服需求，都從外部使用者開始。WordPress 可以先保存最初的資料、做必要的驗證，再把符合條件的資訊送往 CRM 或其他系統。沒填完的、垃圾的或重複的請求，就不一定要進到內部的主資料。

電商網站還多一層交易的責任。從商品瀏覽、客戶身分到價格呈現，從購物車、付款到訂單狀態，都在官網上發生。一般流程可以交給成熟的購物車；特殊的會員價、審核、配送或 ERP 回寫，則透過客製外掛畫出整合的邊界。前台體驗和內部資料要連起來，但不需要由同一套系統包辦所有畫面。

公開頁面、網址、媒體和搜尋內容，通常由官網主導。商品名稱和描述要由官網還是 ERP 負責，依內容和管理需求決定。決定之後，同一個欄位就不能兩邊各自修改。

CRM 管理客戶關係與跟進狀態

CRM 是 Customer Relationship Management 的縮寫，管的是公司和潛在客戶、既有客戶之間的關係與互動。它通常保存個人和公司的基本資料、來源與聯絡紀錄。商機走到哪個階段、由哪位業務負責、下一步要做什麼，以及行銷或客服的歷程，也都記在這裡。

官網表單送進 CRM，後面還有一連串判斷。這是既有客戶還是新名單？由哪個團隊負責？符合商機的條件嗎？同一個人再次詢問時，要合併還是另開新案件？這些都是業務規則，欄位搬過去只是第一步。

CRM 擅長回答的是：「這位客戶之前談過什麼？現在誰在跟？走到哪個階段？下一步要做什麼？」庫存或會計的最後正確版本，通常不在 CRM。CRM 上看到客戶想買某個商品，實際能賣多少、成本多少、什麼時候正式出貨，仍可能由 ERP 判定。

所以你們公司內部要先定義清楚：什麼算客戶、聯絡人、商機和案件，成交、失敗和重新開啟又各代表什麼狀態。維護團隊再依這些定義，把官網資料轉成 CRM 接受的格式，並記下重複或缺漏的資料。

ERP 管理商品、庫存、交付與帳務

ERP 是 Enterprise Resource Planning 的縮寫，通常把日常營運裡的財務、採購和供應鏈，以及庫存、生產、專案等資源流程整合在一起。不同產業、不同產品用到的模組差很多。共同點是用一致的資料結構，串起跨部門的交易和內部作業。

在電商的情境裡，正式品號、可用庫存和倉別，以及客戶條件、訂單、出貨和發票，可能都由 ERP 負責。官網負責的，是顧客看到的圖片、內容、商品組合和購買互動。兩邊要先講好每個欄位歸誰管。例如庫存以 ERP 為準，網站只拿可銷售的結果；行銷文案以官網為準，不必回寫 ERP。

B2B 的流程，還可能牽涉報價核准、合約價和信用條件，以及最低訂購量和不同的交付方式。網站如果要在客戶登入後顯示這些結果，只傳一張價目表是不夠的。客戶身分、規則版本、有效期限，以及查詢失敗時網站該怎麼反應，都要先確認。否則 ERP 暫時沒回應，網站就可能顯示錯的價格。

ERP 的資料會直接影響履約和帳務。下面這些問題，要先有營運上的答案，才能轉成技術規格：

• 哪些資訊可以公開
• 多久更新一次
• 訂單取消後，庫存怎麼釋放
• 同一筆訂單重送時，要怎麼認定

每種資料都要有單一真實來源

「單一真實來源」，意思是同一種資料，由一個系統負責最後的正確版本。其他系統可以取得工作需要的副本或結果，但沒有規則的話，彼此不能互相改寫。例如服務文章以官網為主，商機階段以 CRM 為主，庫存和出貨以 ERP 為主。

決定主來源，要看誰建立這筆資料、誰最能驗證、哪個流程正式使用，以及出錯時由哪個部門負責。客戶的公司名稱，可能是在官網第一次填寫，經業務確認後改由 CRM 維護，成交後再以正式的客戶代碼送進 ERP。不同階段可以換系統負責，但轉換的條件要講清楚。

辨認資料，靠的是識別碼，名稱靠不住。這是我們規劃串接時很常看到的狀況。同一家公司有簡稱和正式名稱，同一個人會用不同的信箱來詢問。同一個商品，在網站和 ERP 上的顯示名稱也可能不一樣。所以客戶、聯絡人、商品和訂單都要有穩定的識別碼，兩邊也要保留對照，不能因為文字一樣就當成同一筆。

時間和衝突，也要事先定義。ERP 和官網在差不多的時間改了同一個欄位，要採用哪一邊？資料多久沒更新就算過期？同步失敗的期間，網站要保留上一次的結果、暫停特定動作，還是轉人工確認？這些選擇，會直接影響客戶體驗和營運風險。

資料類型	常見主來源	其他系統取得的內容
公開服務、案例與知識內容	企業官網	CRM 可保存來源頁面與關注主題
潛在客戶、互動與商機階段	CRM	官網送入初始詢問，ERP 接收成交後必要資料
正式品號、庫存、訂單與出貨	ERP	官網取得可售資訊與客戶可見狀態
前台購物車與付款互動	官網／電商系統	ERP 接收已成立訂單與後續狀態

選擇串接方式，要考量即時性與風險

排程匯入匯出，適合變動不頻繁、能容許延遲、資料量也方便核對的情境。例如定期更新產品清單，或同步不需要即時的報表。它的邊界清楚，也方便人工檢查。缺點是兩次交換之間有時間差，檔案格式和重複資料都要有人管。

現成連接器，能處理兩套常見產品之間的標準欄位和事件。你們的流程如果符合它預設的模型，可以省下從零開發的工夫。價格、身分、審核或狀態的規則比較特殊時，要先確認連接器表達得了這些例外，出錯時也查得到。還要看它是不是還有人持續維護。

Webhook，適合在事件發生時主動通知另一個系統，例如表單成立、付款完成或訂單狀態改變。它通常是單向傳送。接收端可能暫時連不上，所以要有驗證、重試和去重的機制；請求送出去了，也不能當作對方已經處理完成。

API，適合需要查詢、建立、更新或雙向交換資料的整合。WordPress REST API 本身就提供用 JSON 存取網站資料的介面，也區分公開和私有資料的權限。實際專案裡，還可能用到 CRM、ERP 或中介服務提供的 API。能呼叫端點只是開始，資料和流程的規則，還是要靠客製功能承接。

即時整合會增加相依，任何一端變慢，都可能拖到另一端。參考的做法是看能等多久、失敗的影響、資料量和維護成本，把排程、事件和即時查詢搭配著用。所有工作綁在同一條同步線上，風險反而集中。

API 接上之後，真正的串接工作才開始

欄位對應：兩邊的欄位名稱、格式、單位和必填規則，可能都不一樣。姓名、地址和稅籍資料，品號、金額和日期，都要明確轉換，也要記得哪一份是原始值。少一個必填欄位，整筆資料就可能被拒收。

唯一識別：前面提到的識別碼和對照，要在每一次重送和回寫時沿用。只靠信箱或名稱比對，遇到資料修改、共用信箱或格式差異，就容易合併錯。

身分驗證與權限：串接只讀寫任務需要的資料。憑證要安全保存，測試和正式環境分開。API 憑證和技術操作不需要你們公司內部經手，由維護團隊依正式的機制實作。

狀態轉換：網站、ERP 和物流的狀態，不一定一對一。例如網站上一個「處理中」，在 ERP 可能對應「已接單」和「揀貨中」兩個狀態。每個狀態的商業意義、允許怎麼轉換、轉換時觸發什麼動作，都要先定義。否則狀態倒退或重送時，就可能產生錯誤的結果。

重試與去重：網路和外部服務難免暫時失敗。系統要分得出哪些錯誤可以重試、哪些事件是重複送來的，避免重複建立客戶、訂單或付款紀錄。已完成和待處理的項目，也要分開記錄。

異常紀錄與監看：失敗的資料不能無聲無息地消失。紀錄要寫出是哪筆資料、在哪個環節失敗、原因是什麼、要怎麼重新處理。影響大的流程，出錯時也要通知維護團隊。

哪些訊號代表值得開始整合

同一筆資料反覆輸入。就像開頭說的，業務把詢問貼進 CRM，成交後再把客戶和訂單輸入 ERP。量一多，花掉的時間和打錯的機會會一起累積。這時可以先找出最穩定、重複最多的那一段，不必一開始就串接所有系統。

狀態經常對不起來。網站顯示有庫存，倉庫其實已經缺貨。CRM 上已經成交，ERP 卻還沒建立訂單。貨都出了，客戶頁面還停在「處理中」。這些落差如果會影響客戶權益或內部決策，就值得把主來源和回寫的事件定義清楚。

人工等待開始卡住下一步。表單要等人轉寄，報價要等資料彙整，訂單要等人工核對完才能出貨。自動化適合接手已經確認、會重複發生的規則；真正需要判斷的例外，還是留給人處理。

錯誤會沿著流程放大。一個客戶識別錯了，可能連帶影響價格和訂單，再擴及庫存、發票和交付。遇到這類流程，技術設計、測試和監看的層級都要跟著提高。只靠一次性的資料搬移，或沒有留下紀錄的自動操作，風險太高。

決定要開始之後，大致會照這個順序進行：

1. 盤點流程：列出角色、事件、正常路徑與真實例外。
2. 分配資料責任：決定每種資料的主來源、使用者與可接受延遲。
3. 選擇第一段整合：優先處理重複高、規則穩定且商業影響明確的流程。
4. 定義失敗行為：建立驗證、去重與重試機制，留下紀錄，並畫出人工處理的邊界。
5. 分階段驗收：從正常與例外情境核對兩端資料和實際營運結果。
6. 持續維護：追蹤版本、憑證與 API 的變動，也留意資料量與商業規則的改變。

這個過程裡，你們公司內部提供流程、資料用途、負責的部門和期待的商業結果。我們把這些規則轉成 WordPress 網站、客製外掛和資料交換的設計，接著做測試和後續維運。API、驗證和系統層的實作，都在代管架構裡由我們完成。

我們怎麼規劃官網與內部系統串接

談串接時，可以先問一題：「同一筆資料，兩邊不一樣的時候，要聽誰的？」這題答得出來，主來源就定了一半。接著和你們的同事，拿一筆真實的詢問或訂單走一遍：從官網送出，一路追到 ERP 開單。看它在每一站用什麼編號、狀態叫什麼名字。紙上的流程圖，很少把這些細節畫出來。

也要先確認 ERP 或 CRM 有沒有可以測試的環境。沒有的話，測試時就得另外設計隔離的做法，避免動到真實的庫存和帳務。

串接不會在 API 第一次成功回應後就結束。版本和憑證會更新，欄位和業務狀態會調整，外部服務也會改版。所以備份、更新和相容測試，連同紀錄與監看，我們都放進年度維護一起處理。這條資料管線上線之後，也一直有人照顧。

常見問題