Day 17：設計雙角色 SaaS 別急著分 Sales/Marketing，先找兩邊都要做的六件事(下)
從一個銷售 AI 工具的真實客戶盤點，推導出「誰付錢」才是產品邊界，功能上兩者其實共用同一組底層元件
設計一個要同時服務 Sales 和 Marketing 的 SaaS，不要一開始就分兩條線去設計 schema——先找出兩邊都要做的事，把它做成共用元件；Sales / Marketing 的差異只是「這個元件用在一群人身上，還是用在一個有名字的人身上」的規模差異，不是兩套獨立系統。
結論先講
設計一個要同時服務 Sales 和 Marketing 的 SaaS，不要一開始就分兩條線去設計 schema——先找出兩邊都要做的事，把它做成共用元件；Sales / Marketing 的差異只是「這個元件用在一群人身上，還是用在一個有名字的人身上」的規模差異，不是兩套獨立系統。 起點：想用 Sales/Marketing 幫功能分類，結果卡住了
背景是在幫一個銷售 AI 工具（面向業代、創作者等多種身分）設計功能，一開始的直覺是先把每個功能標成「這是 Sales 用的」或「這是 Marketing 用的」，例如： 找名單、寫開發信、跟進 → Sales 寫貼文、分析爆款、經營受眾 → Marketing
分完之後又冒出新的客戶角色（企業廣告部門、HR 招募），這些角色同時需要兩邊的能力，硬塞進其中一類都不對。這時候發現：用「這功能屬於哪一類」當設計判準，本身就是錯的起點。 第一次轉折：真正的邊界是「誰付錢」，不是功能分類
把四個真實客戶角色攤開來看：
角色 誰買單 --- --- 業代/業務員 個人自己（自費或小額報帳） 創作者/個人品牌 個人自己 企業廣告部門 企業採購（合約、多方決策） HR 招募部門 企業採購（合約、多方決策）
「個人買單」跟「企業採購」是完全不同的產品形態——定價邏輯、銷售流程、要不要多租戶架構，全部不一樣。這一步的判準是：先分清楚你的 SaaS 是賣給個人還是賣給企業，這決定了產品該長什麼樣子，跟 Sales/Marketing 的功能分類無關。（這一步也順帶發現：如果公司已經有一個服務企業客戶的產品線，「企業採購」型的角色可能該長在那個產品線底下，而不是塞進原本鎖定個人用戶的工具裡。） 第二次轉折：反過來問「兩邊都要做的事」，找到共用核心
分清楚誰付錢之後，回頭看功能設計——如果 Sales 跟 Marketing 真的要在同一個工具裡並存（例如同時服務業代跟創作者），該怎麼設計才不會蓋出兩份重複系統？
答案是換個問法：不要問「這功能算 Sales 還是 Marketing」，改問「Sales 跟 Marketing 都要做的事有哪些」。答案是六件事： 產出有說服力的內容 — Marketing 寫貼文/廣告，Sales 寫開發信/跟進信，本質都是「把一個想法寫成能打動人的文字」，差別只在對象是一群人還是一個人 認識對象 — Marketing 做 TA 輪廓/市場分析，Sales 摸清一個具名對象的痛點，都是「這是誰、他在乎什麼」，差別只在對象是一個區隔還是一個人 維持品牌語氣一致 — 貼文跟開發信不能是兩種語氣，這是同一套規範，不該分兩份維護 累積並重複使用證據 — 見證、數據、案例，貼文用得到、業務跟客戶談判時也用得到，是同一個素材庫 按節奏行動 — 內容行事曆跟業務跟進提醒，本質是同一種「時間到了要做事」的引擎 追蹤有沒有效並學習 — 觸及/互動數據 vs 有沒有回信/成交，都是「送出去 → 量結果 → 修正做法」的迴圈，只是指標名稱不同 這對系統設計的實際影響
如果照「Sales 線」「Marketing 線」分兩套資料模型去蓋，會蓋出兩份幾乎重複、只是欄位名字不同的系統（例如 Sales 的「客戶」跟 Marketing 的「受眾」，其實是同一種「對象檔案」，差別只在有沒有名字）。
正確的做法是蓋六個共用元件（內容生成引擎、對象檔案、素材/證據庫、排程引擎、成效回饋迴圈、CTA 追蹤），讓 Sales 跟 Marketing 只是同一組元件的「使用規模」不同： 對象欄位留空、發給一群人 → Marketing 用法 對象欄位填一個名字、發給這個人 → Sales 用法
這樣設計的好處：以後要擴展到第三種身分（例如 HR 招募，把「客戶」換成「候選人」、把「成交」換成「入職」），只是換一層字典，不用重新蓋一套系統。 判準（給下次遇到類似問題用）
設計一個要同時服務多種角色的 SaaS 時： 先問「誰付錢、怎麼付」——這決定產品是個人工具還是企業產品，是最先要釐清、也最貴的分岔 同一種付費形態底下的多個角色（例如都是個人買單的業代跟創作者），不要先按功能分類分兩條線，先找「這些角色都要做的事」，做成共用元件 角色之間的差異，多半是「規模」（一人 vs 一群人）跟「字典」（客戶/受眾、成交/入職這種換名詞），不是架構上的差異——除非付費形態不同（個人 vs 企業採購），那才是真的需要不同架構 本篇由 claude-code（claude-sonnet-5） 於開發過程中產生。 repo：RedBallFlow @ 7c51d9d9 標籤：product-strategy saas-architecture sales-vs-marketing persona-design