銷售預測不必靠通靈：WordPress + CRM 數據打造 AI 業績預測模型

「去年加 10%」不是預測，是抄作業；業務的直覺也不是模型，是心理安慰。可被驗證的業績預測，得把 WordPress／WooCommerce 的交易事實與 CRM 的客戶行為紀錄串成同一條數據流，再交給合適的機器學習模型（時間序列、回歸、分類）去跑。本文拆解整套架構與特徵工程重點，並附一段可實際運行的 WooCommerce 資料匯出範例。

核心觀念只有一句：預測模型不是裝個外掛就有，而是「乾淨的數據 + 對的模型 + 持續驗證」三者的結果。缺一不可。

每到月底或季末，我看過太多企業主和業務主管的臉色比伺服器掛掉還難看。為什麼？因為又要面對那張該死的 Excel 報表，填寫下個月的「業績預測」。

通常這個過程是這樣的：業務 A 憑直覺說「我覺得這個客戶會成」，業務 B 為了不想被釘，保守填了個數字，最後老闆再根據「經驗法則」加權一下。結果呢？往往跟擲筊差不多準。不是庫存備太多積壓資金，就是產能不足錯失商機。

都 2025 年了，我們寫程式的都要用 AI 輔助了，為什麼你的業績預測還在用「通靈」的？今天這篇不談虛無縹緲的概念，我們直接聊硬核的技術實作。

為什麼 Excel 算命法會失靈？

在進入技術架構之前，身為一個對數據有點潔癖的工程師，我必須先點出傳統預測方式的幾個結構性問題。這些不是「再認真填一點」就能解決的，而是方法本身的缺陷。

• 數據孤島（Data Silos）：你的訂單在 WordPress／WooCommerce，客戶互動紀錄在 LINE 或 Email，而業務進度在 Excel 或 CRM。這些數據沒有串連，預測模型就缺少了「上下文」，只能看到片面的事實。
• 主觀偏差：人類天生過度樂觀或過度悲觀。業務為了達標獎金，可能會隱瞞案子的真實風險；主管則容易被最近一兩個大案影響判斷（近期偏誤）。
• 忽視變數：傳統 Excel 很難同時考慮季節性、行銷活動 ROI、總體經濟指標等多重變數，更不用說量化它們之間的交互作用。
• 無法被驗證：憑感覺的預測，事後對不準也說不清是哪裡錯了。模型化的好處之一，就是每次都能回頭比對「預測值 vs 實際值」，持續修正。

這就是為什麼我們需要引入 AI 銷售預測模型。它不帶感情，只看數據；而且它的錯誤是可以被量化、被改進的。

技術架構：WordPress × CRM × AI 的黃金三角

要打造一個能用的預測模型，我們需要建立一條完整的數據流水線（Data Pipeline）。這不是裝個外掛就能解決的，這需要系統思維。整條流水線大致分成四個階段：數據源整合 → 清洗與特徵工程 → 模型訓練 → 部署與回饋。

第一步：數據源整合（The Source of Truth）

首先，WordPress（特別是 WooCommerce）是你的「交易事實」來源。這裡有最準確的歷史訂單數據、客單價（AOV）和購買頻率——這些是已經發生、不會騙人的硬數據。

但光有交易數據不夠，我們還需要「行為數據」。這時候 CRM（如 HubSpot、Salesforce，或自建 CRM）就進場了。我們需要將 WordPress 的數據同步到 CRM，讓兩邊的紀錄能對得上同一個客戶。

這部分可以參考 將 WordPress 會員資料無縫同步至企業 CRM 的實戰。只有當「訂單金額」與「客戶互動頻率」、「開信率」結合在同一個客戶身上時，AI 才有足夠的特徵值（Features）可以學習。否則模型看到的永遠只是半張臉。

第二步：數據清洗與特徵工程（Data Cleaning & Feature Engineering）

這是工程師最痛苦但也最重要的環節。Garbage In, Garbage Out（垃圾進，垃圾出）是資料科學的鐵律。如果你的 CRM 裡充滿重複名單、錯誤標籤、空白欄位，那預測出來的結果還不如丟銅板。

實務上，特徵工程比「選哪個模型」更決定成敗。一個被廣泛採用的入門框架是 RFM，它把每個客戶量化成三個維度：

• 近因性（Recency）：上次購買／互動距今幾天？越近通常代表越熱。
• 頻率（Frequency）：一段期間內互動／購買幾次？反映黏著度。
• 金額（Monetary）：累積貢獻金額？反映客戶價值。

在 RFM 之上，你還可以疊加「互動深度」類的特徵，例如網站停留時間、Email 開信次數（這需要事前埋設 Event Tracking 才收得到）。這幾類特徵之所以好用，是因為它們把「一個人的行為」壓縮成模型看得懂的數字。

清洗時要特別留意幾個常見地雷：

• 去重與身分對齊：同一個客戶在 WooCommerce 和 CRM 可能是兩筆資料，要先用 Email 或會員 ID 對齊，否則 RFM 會被算錯。
• 時間切點要一致：計算「過去一年」時，所有特徵都要以同一個基準日往回推，避免資料洩漏（用到了預測當下還不該知道的未來資訊）。
• 處理極端值與缺值：一筆異常的大額退款訂單，可能把整個 Monetary 分佈拉歪。

第三步：模型選擇與訓練（AI Modeling）

這裡稍微硬核一點。針對「銷售預測」這個題目，常見的做法不是只用一種模型，而是看你要回答什麼問題來選工具：

1. 時間序列分析（Time Series Forecasting）：例如 ARIMA 或 Prophet。它把「時間」本身當成主軸，適合預測整體營收趨勢，能納入季節性因素（例如年度大檔）與長期趨勢。問的是「下個月大盤會落在哪」。
2. 回歸模型（Regression）：用來預測連續數值，例如某個 Lead 下個月可能的成交金額。輸出是一個數字。
3. 分類模型（Classification）：例如 Random Forest 或 XGBoost，用來預測成交機率（Lead Scoring），判斷這個客戶會買（1）還是不會買（0）。輸出是一個機率，很適合拿來排優先順序。

挑選的直覺很簡單：要「總量趨勢」找時間序列，要「某個值是多少」找回歸，要「會不會發生／機率多高」找分類。三者常常並用，而不是二選一。

另外提醒一個容易被忽略的工程紀律——驗證。模型不能拿訓練用過的資料來自誇準確，要切出獨立的測試資料；做時間序列時更要按時間順序切分（用過去預測未來），而不是隨機打散。沒有誠實的驗證，再漂亮的數字都只是自我安慰。

雖然現在有不少 No-Code AI 工具，但在企業級應用中，我們通常會寫一段 Python 腳本，或透過 API 把整理好的 JSON 數據丟給 AI 引擎來訓練與推論。

實戰程式碼：從 WordPress 提取訓練數據

為了讓大家更有感，這裡提供一個簡單的 PHP 範例。它的功能是從 WooCommerce 提取歷史訂單，並格式化成適合訓練機器學習模型的 JSON 結構。你可以用 WP-CLI 或排程任務（Cron）來跑這段程式碼。

這段 Code 是給經典編輯器用的，所以我刻意保持精簡，方便你照著改：

function export_orders_for_prediction() {
    // 檢查權限，別讓路人甲撈你的數據
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }

    $args = array(
        'limit'  => -1,
        'status' => array('wc-completed'),
        'return' => 'ids',
    );

    $order_ids = wc_get_orders( $args );
    $data = array();

    foreach ( $order_ids as $order_id ) {
        $order = wc_get_order( $order_id );
        $user_id = $order->get_user_id();

        // 這裡我們提取「特徵值」
        $data[] = array(
            'order_id'    => $order_id,
            'user_id'     => $user_id,
            'order_total' => $order->get_total(),
            'date'        => $order->get_date_created()->date('Y-m-d H:i:s'),
            // 這裡可以加入更多 CRM 整合的數據，例如該客戶的標籤分數
            'items_count' => $order->get_item_count(),
            'payment_method' => $order->get_payment_method(),
        );
    }

    // 輸出 JSON，這就可以丟給 Python 或 AI API 了
    header('Content-Type: application/json');
    echo json_encode($data);
    exit;
}

// 掛載到一個自訂的 API 端點或 admin-ajax
add_action('wp_ajax_get_sales_training_data', 'export_orders_for_prediction');

幾個值得注意的實作重點：

• 權限檢查不能省：範例開頭的 current_user_can( 'manage_options' ) 是底線。訂單資料屬於敏感個資，端點若沒有保護，等於把客戶名單攤在網路上。
• 大量訂單要分批：範例用 'limit' => -1 一次撈全部，資料量大時可能吃光記憶體。正式環境建議改成分頁（paged）逐批匯出，或直接走 WP-CLI 在背景跑。
• 這只是「事實層」：這段只取了交易數字。真正的特徵工程（RFM、互動深度）通常在拿到資料之後，於 Python 端依 user_id 聚合計算，而不是塞在這支匯出腳本裡。

拿到這份 JSON 後，你就可以餵給雲端的機器學習服務（例如 Google Vertex AI、AWS SageMaker），或是直接用本機的 Python Scikit-learn 腳本做初步的回歸／分類分析。

AI 預測模型能回答的三個關鍵問題

部署了這套系統後，它能解決哪些實際的商業問題？對應前面講的三類模型，剛好是三個最常見的提問。

1. 下個月我的業績低標在哪裡？

透過時間序列模型，結合過去多年的 WordPress 訂單數據，AI 可以畫出一條已經考慮淡旺季的基準線。這讓你設定 KPI 時，不再是「去年業績 + 10%」這種無腦算法，而是基於統計推估的合理區間。模型甚至能給你一個「預測區間」，告訴你最壞與最好分別大概落在哪。

2. 哪些潛在客戶（Leads）最快會成交？

這是 CRM 結合 AI 最強大的地方。如果你的 WordPress 有串接 CRM，分類模型可以學到類似這樣的規律：「過去成交的客戶，通常在註冊後幾天內瀏覽了定價頁面，並且開信率偏高」。

系統會自動為現在線上的每個潛在客戶打分（Lead Scoring）。業務早上打開電腦，系統直接幫他排好優先順序：「先打給這幾個人，他們的成交機率最高。」這就是把有限的業務時間花在刀口上。

3. 誰準備要流失了？（Churn Prediction）

挽回一個舊客的成本，通常遠低於開發一個新客。同樣是分類模型，換個標籤（流失／未流失）就能偵測異常行為，例如：「這個大戶過去每個月都下單，但最近一段時間沒登入，且上次客訴單處理時間偏長」。

偵測到風險後，可以利用自動化工具（如 n8n）觸發挽回流程，自動發送關懷訊息或請專人聯繫。前提一樣是資料夠乾淨——這也是為什麼特徵工程那一步省不得。

從「預測」到「處方」：再往前一步

AI 在這個題目上的價值，正從「預測會發生什麼」（Predictive）往「建議該做什麼」（Prescriptive）延伸。

理想狀態下，未來的 WordPress 官網不只是展示中心，而是一個會思考的營運大腦。當模型預測下個月業績可能未達標時，它不只是亮紅燈，而是能進一步建議行動方向：例如鎖定「購物車未結帳」的客群做再行銷。當然，這類「處方」本身也需要經過實際投放、再回頭驗證效果，才能持續變準——這又回到那條「預測 → 行動 → 回饋」的閉環。

結論：數據是石油，AI 是引擎

身為工程師，我常說代碼不會說謊，數據也是。建立銷售預測模型聽起來很遙遠，但其實從你的 WordPress 資料庫開始，只需要正確的架構（整合 → 清洗 → 建模 → 驗證）和工具就能逐步實現。

別再讓你的企業像無頭蒼蠅一樣亂撞。把直覺留給創意，把預測交給數據。

如果你想把 WordPress 網站改造成具備 AI 預測能力的數據中樞，或在串接 CRM 與 AI 模型上遇到技術瓶頸，歡迎隨時找浪花科技聊聊。

延伸閱讀

• 2026 企業 CRM 選型指南：HubSpot、Salesforce 與客製化系統完整比較
• 業績不是靠拜拜！2026 自建「AI 銷售預測模型」實戰：結合 CRM 數據與 Python 演算法的技術指南
• 拒絕資料孤島！將 WordPress 會員資料「無縫同步」至企業 CRM 的實戰
• 你的頂尖業務正在 CRM 裡睡覺！喚醒 AI 銷售教練，用數據提煉成交 SOP