Day 18：設計雙角色 SaaS 別急著分 Sales/Marketing，先找兩邊都要做的六件事(上)

先講清楚兩者的工作定義、服務對象、工作流、AI 工具開發上分別有什麼不同，再回頭找共同點，才推導出「誰付錢」才是產品邊界

設計一個要同時服務 Sales 和 Marketing 的 SaaS，不要一開始就分兩條線去設計 schema——先找出兩邊都要做的事，把它做成共用元件；Sales / Marketing 的差異只是「這個元件用在一群人身上，還是用在一個有名字的人身上」的規模差異，不是兩套獨立系統。

結論先講

設計一個要同時服務 Sales 和 Marketing 的 SaaS，不要一開始就分兩條線去設計 schema——先找出兩邊都要做的事，把它做成共用元件；Sales / Marketing 的差異只是「這個元件用在一群人身上，還是用在一個有名字的人身上」的規模差異，不是兩套獨立系統。

但要走到這個結論，得先把差異講清楚，不然「共同點」聽起來像和稀泥。 起點：想用 Sales/Marketing 幫功能分類，結果卡住了

背景是在幫一個銷售 AI 工具（面向業代、創作者等多種身分）設計功能，一開始的直覺是先把每個功能標成「這是 Sales 用的」或「這是 Marketing 用的」，例如： 找名單、寫開發信、跟進 → Sales 寫貼文、分析爆款、經營受眾 → Marketing

分完之後又冒出新的客戶角色（企業廣告部門、HR 招募），這些角色同時需要兩邊的能力，硬塞進其中一類都不對。這時候發現：用「這功能屬於哪一類」當設計判準，本身就是錯的起點——但在推翻它之前，得先把「這兩類到底哪裡不一樣」講清楚。 差異到底在哪：四個層面拆開看 工作定義不同 Marketing：對象是「一群還不認識你的人」，做的事是讓他們知道你、信任你、留下線索。一對多，對象一開始是不特定的 Sales：對象是「一個已經有名字的人」，做的事是把這個人從「知道你」推進到「付錢」。一對一（或一對少數），對象從一開始就是具體、可追蹤的個人

一句話：行銷是撒網，業務是拉魚上岸。 服務對象不同

Marketing 服務的是「受眾（audience）」——一個統計意義上的群體，用輪廓（TA profile）描述，不需要知道每一個人的名字。Sales 服務的是「對象（prospect）」——一個具體的人，需要知道他的背景、痛點、目前談到哪一步。

這個差異決定了資料要怎麼存：Marketing 的核心資料單位是「一個區隔」，Sales 的核心資料單位是「一個人」。 工作流不同

Marketing 的工作流是漏斗上層：發現受眾 → 產內容 → 養受眾 → 從中生出名單，是一個持續、不斷循環的養成過程，沒有明確的「結束點」。

Sales 的工作流是漏斗下層：拿到名單 → 個別接觸 → 跟進、推進 → 成交或放棄，是一個有明確起點（拿到這個名單）跟終點（成交/流失）的過程，中間每一步都要記錄「這個人現在卡在哪裡」。

這也是為什麼 Sales 天生需要 CRM 式的「狀態追蹤」，Marketing 天生需要「內容行事曆」——兩者的工作流形狀完全不同。 開發 AI 工具時的不同點

這是對「vibe coding 開發 AI 工具」最直接相關的差異： Marketing 的 AI 工具：核心是「內容生成 + 趨勢/受眾分析」。AI 生成一篇貼文，這篇貼文要能被很多人看到、不需要記得「這是誰」——AI 不用記狀態，只要一次生成得夠好、夠符合這群人的輪廓就好 Sales 的 AI 工具：核心是「客製化生成 + 狀態追蹤」。AI 每一次生成的開發信都要綁著一個具名對象，而且系統要記得「這個人上次寄了什麼、現在該不該再寄」——AI 沒有記憶不行，這是一個持續的、有狀態的互動，不是一次性的產出

結果就是：開發 Marketing 工具時，直覺上會去蓋一個「內容資料庫」；開發 Sales 工具時，直覺上會去蓋一個「名單/CRM 資料庫」。兩種直覺都對，但也正因為直覺不同，才會很自然地走向「分兩條線各自開發」——這正是一開始卡住的原因。 照差異走，會蓋出什麼問題

如果照上面四個差異，各自把 Sales 跟 Marketing 蓋成獨立系統，很快會發現一個矛盾：兩邊經常要共用同一批素材跟同一套語氣——同一份客戶見證，貼文用得到，業務跟客戶談判時也用得到；品牌語氣不能貼文一套、開發信又是另一套。分兩條線蓋，這些共用的東西會被迫複製兩份，維護一次要改兩邊。 岔路：先問「誰付錢」，才知道值不值得合併

在深入解決「怎麼共用」之前，有一個更前面的問題要先回答：這兩種角色，是不是本來就該做成同一個產品？

答案要看「誰付錢、怎麼付」：

角色 誰買單 --- --- 業代/業務員 個人自己（自費或小額報帳） 創作者/個人品牌 個人自己 企業廣告部門 企業採購（合約、多方決策） HR 招募部門 企業採購（合約、多方決策）

「個人買單」跟「企業採購」是完全不同的產品形態——定價邏輯、銷售流程、要不要多租戶架構，全部不一樣。業代跟創作者都是個人買單，值得合併進同一個工具；企業採購型的角色（廣告部門、HR）該長在另一個能處理多租戶的產品線底下，不該硬塞進來。這一步的判準，跟前面四個差異無關，是先決定「值不值得合併」，而不是「怎麼合併」。 轉折：確定值得合併之後，反過來問「兩邊都要做的事」

確定業代跟創作者這兩種角色值得做進同一個產品之後，回到功能設計——該怎麼設計才不會蓋出兩份重複系統？

答案是換個問法：不要問「這功能算 Sales 還是 Marketing」，改問「Sales 跟 Marketing 都要做的事有哪些」。答案是六件事： 產出有說服力的內容 — Marketing 寫貼文/廣告，Sales 寫開發信/跟進信，本質都是「把一個想法寫成能打動人的文字」，差別只在對象是一群人還是一個人 認識對象 — Marketing 做 TA 輪廓/市場分析，Sales 摸清一個具名對象的痛點，都是「這是誰、他在乎什麼」，差別只在對象是一個區隔還是一個人 維持品牌語氣一致 — 貼文跟開發信不能是兩種語氣，這是同一套規範，不該分兩份維護 累積並重複使用證據 — 見證、數據、案例，貼文用得到、業務跟客戶談判時也用得到，是同一個素材庫 按節奏行動 — 內容行事曆跟業務跟進提醒，本質是同一種「時間到了要做事」的引擎 追蹤有沒有效並學習 — 觸及/互動數據 vs 有沒有回信/成交，都是「送出去 → 量結果 → 修正做法」的迴圈，只是指標名稱不同 這對系統設計的實際影響

如果照「Sales 線」「Marketing 線」分兩套資料模型去蓋，會蓋出兩份幾乎重複、只是欄位名字不同的系統（例如 Sales 的「客戶」跟 Marketing 的「受眾」，其實是同一種「對象檔案」，差別只在有沒有名字）。

正確的做法是蓋六個共用元件（內容生成引擎、對象檔案、素材/證據庫、排程引擎、成效回饋迴圈、CTA 追蹤），讓 Sales 跟 Marketing 只是同一組元件的「使用規模」不同： 對象欄位留空、發給一群人 → Marketing 用法 對象欄位填一個名字、發給這個人 → Sales 用法

這樣設計的好處：以後要擴展到第三種身分（例如 HR 招募，把「客戶」換成「候選人」、把「成交」換成「入職」），只是換一層字典，不用重新蓋一套系統。 判準（給下次遇到類似問題用）

設計一個要同時服務多種角色的 SaaS 時： 先把差異講清楚（定義、服務對象、工作流、AI 工具開發上的不同），不要急著找共同點——差異沒講清楚，共同點會顯得像和稀泥 再問「誰付錢、怎麼付」——這決定產品是個人工具還是企業產品，是最先要釐清、也最貴的分岔，決定「值不值得合併」 確定值得合併之後，同一種付費形態底下的多個角色，不要先按功能分類分兩條線，先找「這些角色都要做的事」，做成共用元件 角色之間的差異，多半是「規模」（一人 vs 一群人）跟「字典」（客戶/受眾、成交/入職這種換名詞），不是架構上的差異——除非付費形態不同（個人 vs 企業採購），那才是真的需要不同架構 本篇由 claude-code（claude-sonnet-5） 於開發過程中產生。 repo：RedBallFlow @ 7c51d9d9 標籤：product-strategy saas-architecture sales-vs-marketing persona-design