CRM 有兩種：業務看的是生意，行銷看的是會員

我用過的 CRM，工作流程是這樣的：行銷說這一檔要推某個活動，開出名單條件，我請工程師寫 SQL 把會員撈出來，名單匯出來丟進 EDM 系統寄送。CRM 對我來說，就是「那個放會員資料、可以撈名單的地方」。

所以第一次打開一套 open source CRM 的 demo，我愣住了。首頁是一張看板，五個欄位寫著「接觸、確認需求、提案、議價、成交」，每張卡片是一筆幾千到幾萬美元的生意。這跟我認識的 CRM 完全對不上。

後來才搞懂：CRM 這個詞底下其實有兩種系統，中心完全不同。 一種圍著「生意」轉，一種圍著「人」轉。

不用 CRM 會痛在哪

兩種 CRM 要解的痛不一樣，但根源是同一個：跟客戶有關的資訊散在各個人身上。

業務那一側：客戶資料在業務的手機和 email 裡。業務離職，客戶就跟著走；主管問「這個月預計能進多少」，沒有人答得出來。
行銷那一側：會員資料散在 POS、官網、APP 各自的資料庫。每一檔活動要撈名單，就得有人去各處拼資料、寫 SQL。

CRM 把這些集中到一個地方，並且讓「下一步要做什麼」有紀錄。

兩種 CRM 並排看

	銷售型 CRM	會員型 CRM
常見於	B2B，賣給公司	B2C，賣給一般消費者
中心	一筆一筆的生意	一個一個的會員
主要使用者	業務、業務主管	行銷
核心畫面	銷售管線看板	名單條件與分群
典型問題	「這筆單卡在議價多久了？」	「近 90 天買過某類商品、生日在下個月的會員有幾個？」
一次工作的終點	成交	寄出 EDM、簡訊，回收開信與購買

銷售型：一筆生意怎麼往前走

以下截圖來自 EspoCRM 的官方公開 demo（AGPL-3.0），資料都是示範用的假資料。

銷售型 CRM 有四個核心東西：

Lead（潛在客戶）：還不確定會不會買的人，例如填了官網表單、在展覽遞了名片。狀態有新進、處理中、已轉換、已放棄。
Account（公司）：跟你做生意的公司。
Contact（聯絡人）：公司裡跟你對接的人，還會標角色，例如「評估者」「決策者」。
Opportunity（銷售機會）：一筆可能成交的生意，有金額、預計成交日、成交機率。

EspoCRM 的潛在客戶列表

業務確認一個潛在客戶真的有需求，就把它「轉換」成公司、聯絡人和一筆銷售機會。之後這筆生意在管線裡一格一格往右推：

EspoCRM 的銷售管線看板

點進一筆生意，看得到它的完整脈絡：金額、品項、成交機率，以及誰在什麼時候做了什麼。

一筆銷售機會的詳細頁

這裡有兩個設計值得注意：

成交機率跟著階段走。 在「接觸」階段預設是 10%，越往右越高。每筆生意的金額乘上機率加總起來，就是業績預測。主管要的「這個月預計能進多少」，答案就是這樣算出來的。
活動紀錄是給下一個人看的。 打過哪通電話、約過哪場會議、建了哪個待辦，全部掛在這筆生意底下。業務離職，接手的人讀這裡就知道進度。

會員型：一檔活動的名單怎麼來

會員型 CRM 的工作流程，就是我當年做的事：

會員資料（POS、官網、APP 各自進來）
  → 用條件分群：檔期、消費紀錄、生日、地區
  → 產生名單
  → 名單丟進 EDM／簡訊系統寄送
  → 回收開信、點擊、購買
  → 回寫到會員資料，下一檔再用

EspoCRM 也有這一塊，叫「目標名單」和「行銷活動」：

EspoCRM 的目標名單

EspoCRM 的行銷活動

不過它的名單偏向「整理好的固定名單」。真正以「用條件撈人」為核心的，是行銷自動化系統，例如 open source 的 Mautic（GPL-3.0）。Mautic 的分群可以設篩選條件，用「且」「或」組合，符合條件的聯絡人會由排程工作自動加入或移出（Mautic 文件：Segments）。換句話說，名單是活的：今天符合條件的人，下個月不符合了就會自己掉出去。

當會員資料來源很多，要先把同一個人在 POS、官網、APP 的資料合在一起，這一層通常叫 CDP（顧客資料平台）。

條件太複雜時：在 CRM 裡撈，還是在 ETL 那邊撈？

這是我當年真的碰到的問題。行銷開的條件常常不是 CRM 介面勾得出來的，例如「上一檔買過 A 但沒買 B、而且客單價在前 20%」。這時候有兩條路：

路線一：在 CRM 裡撈。 行銷自己勾條件，馬上有結果，不用等工程師。但 CRM 只看得到它自己有的資料。消費明細、商品分類、毛利這些，常常在 ERP 或交易資料庫裡，CRM 根本沒有。

路線二：在 ETL／資料倉儲那邊撈。 把各系統的資料定期整理進資料倉儲，在那裡用 SQL 算名單、順便產報表。條件想多複雜都可以，也能跨系統交叉比對。代價是：每次都要工程師寫，而且資料是批次更新的，看到的是昨天或上一次 ETL 的狀態。

我當年是走路線二。名單和報表都在 ETL 那邊產，CRM 比較像是「放結果的地方」。

但選路線二的主要原因，其實不是條件複雜，而是怕影響正式系統的穩定性。系統本身的排程、盤點都接在同一座資料庫上，撈名單的查詢直接打過去，就是在已經很忙的資料庫上再加一份壓力。所以名單和報表另外在 ETL 那邊算，正式系統的資料庫只負責跑交易。

這其實是一個很通用的原則：交易用的資料庫和分析用的查詢，存取模式完全不同，放在一起會互相拖累（見Analytical DB：OLAP 和 OLTP 為什麼不能用同一個資料庫）。撈行銷名單，就是一種分析查詢。

兩條路並不是只能選一條。常見的折衷是：在資料倉儲算好分群，再把結果推回 CRM 或 EDM 系統，讓行銷在熟悉的介面上用。這種「從倉儲往外推」的做法，有人叫它 reverse ETL。

AI 和 MCP 能接手哪一段

回頭看我當年的流程，最卡的一步是：行銷想到一個條件，要等工程師把它翻譯成 SQL。

這正好是 AI 擅長的事。如果 CRM 或資料倉儲有一個 MCP server，行銷可以直接用中文問：

「撈出近 90 天買過保養品、還沒用過這檔折價券的會員，有幾個？」

AI 把這句話翻成查詢，透過 MCP 去執行，回報人數和名單。行銷可以馬上改條件再問一次，不用排工程師的時間。

但這裡有四件事不能交給 AI 自己決定：

查的是哪一座資料庫。 前面那個穩定性問題不會因為換成 AI 就消失。MCP 背後接的應該是 ETL 或資料倉儲那邊的資料，不是正式系統的資料庫。行銷用 AI 問得越方便，查詢次數就越多，直接打正式系統只會更危險。
會員資料是個資。 MCP 給 AI 的權限要盡量小。能只回人數就不要回明細，要回明細就限制欄位，例如不回身分證字號和完整電話。每一次查詢都要留紀錄。
「寄出去」要人按。 撈名單是唯讀，錯了重撈就好。寄 EDM 寄錯人收不回來，這一步一定要人確認。
條件翻譯要能檢查。 AI 把「近 90 天」翻成什麼 SQL，要讓人看得到。翻錯一個日期範圍，名單就整批錯。

銷售型 CRM 也一樣能用：「列出卡在議價超過兩週、金額前十大的生意」「這個客戶上次聯絡是什麼時候、談到哪裡」。這些都是唯讀查詢，風險低、省時間明顯。

想看實作，可以讀這幾套

系統	類型	授權	AI／MCP 現況（2026-10）
EspoCRM	銷售型為主，也有名單和行銷活動	AGPL-3.0	有官方 MCP 擴充（2026-10 推出）
Twenty	銷售型	AGPL-3.0（部分功能要付費）	內建 MCP
SuiteCRM	銷售型	AGPL-3.0	只有小型社群版本
Mautic	會員型、行銷自動化	GPL-3.0	沒有官方 MCP，社群版本最多 1 顆星

Terry Yao's Blog

目錄