23 KiB
23 KiB
Requirements: 商機雷達＋成交 CRM（個人品牌的輕量 Growth OS）
Status:
approved
Status note: 使用者 2026-07-31「批准，進 spec」；金流已存在 → 方案配額改列 P0、價格校準改列 P1
Slug:demand-radar
Last updated:2026-07-31
輸入真相：2026-07-31 使用者產品構想（賣鏟子定位）；apps/web與apps/backend現況能力；docs/product/haixun-backend/（已交付底座）；docs/product/growth-loop/（成果歸因與健康分加值層）
已鎖定前置決策：本 run 為加值層，沿用既有前後端，不新開 app；第一版訊號來源只做 Threads ＋使用者手動匯入
1. 一句話
把巡樓從「品牌找正在抱怨痛點的買家」擴成「服務者與一人公司每天收到一份『正在找你的人』名單，並一路追到成交」：由 商機雷達（每日自動找需求）、AI 回覆助手（記得你的品牌與底線）、超輕量 CRM（八狀態追到錢）三個模組組成。
賣的不是「AI 幫你寫貼文」，而是「我幫你少花時間找客戶，並提高接到案子的機率」。
2. 誰用、在什麼情境
| 角色 | 目標 |
|---|---|
| 接案型服務者（攝影師、婚禮主持、剪輯師、網頁設計師） | 每天有人幫我把「正在詢價的人」整理好，我只要決定回不回 |
| 在地服務／一人店（美甲師、寵物美容、健身教練、營養師） | 只要地區對得上的需求，外縣市不要進我的名單 |
| 業務型自由工作者（保險、房仲、自媒體顧問） | 從第一次接觸到成交都在同一條線上，不靠記憶與截圖 |
| 團購主／小電商 | 把留言與私訊變成可追蹤的名單，知道哪個關鍵字最會成交 |
| 既有品牌島民（現在在用海巡） | 既有海巡命中也能收斂進同一條成交線，不用換工具 |
| 營運／管理員 | 看得到「關鍵字 → 回覆 → 成交」的轉換率，據此調整方案與定價 |
3. 背景與動機（As-is → 為什麼改）
市場判斷（本 run 的存在理由）：
- 創作者已經不缺生成文案的工具。 ChatGPT、Canva、Notion 在內容生成這格已經贏了，正面對撞不划算。真正缺的是把「發文、互動、私訊、名單、報價、成交、追蹤」串成一條線。
- 台灣市場的在地性是可守的優勢。 Threads 上「不懂就問脆」「求推薦」是既有的高頻行為，品牌與店家本來就會人工搜尋並回覆（俗稱海巡）。這是把既有人工行為工具化，不是憑空創造需求。LINE 有完整雙向 Messaging API，2026 年起台灣一般開發者也能發布 LINE MINI App，是後續的在地縱深。
- 使用者容易算帳。 一個攝影案 NT$10,000–30,000、一個網站案 NT$30,000–200,000、一名顧問客戶每月 NT$5,000–50,000；相對於既有 Starter NT$590／Pro NT$1,990 的月費，多成交一單就回本。收費遠低於一次成交價值，是好 SaaS 的特徵。
現況落差（既有系統已有什麼、還差什麼）：
- 既有海巡的語意是「找正在抱怨痛點的人」（品牌維護產品與痛點 → 命中貼文 → 外展）。服務者要的是「找正在公開發需求的人」：判定條件不同，需要的是明確需求、購買意圖、地區是否符合、需求是否仍有效。
- 掃描是使用者按一次跑一次。 要承諾「每天幫你找客戶」，就必須是常駐訂閱＋每日自動巡，而不是 on-demand。
- 命中的是「貼文」，不是「人」。 同一個人多次發需求無法收斂成一個聯絡人；沒有跟進生命週期、沒有「幾天沒回覆」的提醒，成交與否只能靠記憶。
- 成果歸因只證明 ROI，沒有回饋到打法。 既有歸因能回答「賺回多少」，但回答不了「哪個關鍵字最容易成交」「哪種回覆版本成功率最高」。
- 不改的後果： 產品停在「內容工具」象限，跟通用 AI 工具打價格戰；用戶算不出帳；只做 Threads 搜尋工具則護城河太薄，也容易受單一平台 API 與政策波動影響。
已握有、本輪明確不重造的底座：
- 雙路徑抓取：官方 API 路徑與 dev 模式下的瀏覽器工作階段路徑，已在既有海巡落地。
- 貼文分類地基：既有命中已能區分「求助／求推薦／同業叫賣／討論／提問／公告／雜訊」，並保留意圖片段與命中理由。意向分數是在這之上補地區、時效與服務匹配，不是從零做分類器。
- AI 供應商抽象與 BYOK 用量計量、Outbox 真發送與節流、成果歸因與 UTM 點擊、帳號健康分與送出閘、Stripe 訂閱與方案、站內通知、前端設計系統與 repository 契約。
4. 目標（To-be）
4.1 必須達成（P0）— 每天有名單、回得出話、追得到錢
-
服務檔案（ServiceProfile） 使用者一次填好：服務項目、價格區間、代表案例、不能說的內容、常見問題、服務地區、可接案空檔。這份檔案同時餵給商機判定與回覆生成，是「AI 回覆助手不是單純改寫」的來源。
-
雷達訂閱＋每日自動巡（RadarWatch） 使用者設定關鍵字（例：「台北 婚攝推薦」「有人會做網站嗎」「求推薦寵物美容」「公司想導入 AI」）後，系統每日自動巡，不需手動按掃描。這是「每天幫你找客戶」的核心承諾，也是與既有 on-demand 海巡最關鍵的差異。
-
商機判定五問與意向分數（Opportunity） 每筆訊號由 AI 回答五問：是不是真實需求、對方是否有購買意圖、地區是否符合、需求是否仍有效、是否值得放進潛在客戶名單。輸出 0–100 意向分數與高／中／低分級，必須附判定理由且使用者可覆寫分級。
-
今日商機頁 一眼看完當日產出：「今日找到 18 筆 ／ 高意向 5 ・中意向 8 ・低意向 5」，以及每筆的原文摘要、意向分數、地區、發布距今時間、AI 建議回覆，與三個動作：開啟原文、加入名單、產生其他回覆。
-
AI 回覆多版本 同一筆需求可產出五種語氣版本：公開留言版、私訊版、不帶銷售感版、專業版、幽默版。回覆須讀得出品牌語氣與服務內容，且不得違反服務檔案中「不能說的內容」。
-
超輕量 CRM 八狀態＋聯絡人聚合（Contact） 狀態：新發現 → 已互動 → 已私訊 → 對方回覆 → 已報價 → 已成交／未成交，外加待追蹤。同一個人在同一平台多次發需求，收斂成同一個聯絡人，看得到完整接觸歷史。自媒體不會想維護複雜 CRM，因此欄位與操作必須極簡。
-
追蹤提醒（FollowUp） 幾天沒回覆自動提醒（走既有站內通知），並可 AI 產生追蹤訊息，避免名單躺著爛掉。
-
轉換統計（讓產品從內容工具升級成營收工具） 成交來源統計、哪個關鍵字最容易成交、哪種回覆版本成功率最高。統計掛在既有成果歸因之上，不另做一套帳。
-
方案配額掛載 每日雷達訂閱數、每日商機上限、AI 回覆生成額度，掛進既有 Free／Starter／Pro 三階方案。金流與訂閱流程已存在，本 run 只定義配額與超限行為，不重做付費流程。這是 P0 而非 P1：每日自動巡若無配額上限，AI 成本會失控。
4.2 應該有（P1）— 補來源與收錢
- 手動匯入商機：貼上 Threads／Facebook 社團貼文網址，或以 CSV 批次匯入。這是「不承諾全平台自動抓取」前提下的合規補位。
- 報價與成交金額：CRM 的「已報價／已成交」可填金額與備註，寫入既有成果歸因，讓 ROI 頁與轉換統計有金額維度。
- 價格帶校準：依 P0 實際使用量與 AI 成本，決定是否調整既有 Starter／Pro 價格（見決策 #9 的價格落差）。
4.3 以後再說（P2）
- LINE 官方帳號雙向：以 Messaging API 把私訊收進同一條 pipeline。
- Google 商家評論、網站表單 webhook（自帶名單入口，不碰第三方平台）。
- 自有 IG／Threads 留言與私訊收斂進聯絡人。
- 可公開搜尋的論壇來源。
- 空檔媒合：依服務檔案的可接案空檔，對高意向商機提示可約時段。
5. 範圍
In scope
- 上述 P0／P1 的產品行為定義；前端
apps/web與後端apps/backend皆會異動（經 spec → plan → tasks 才動碼）。 - 加值層定位：復用既有雙路徑抓取、貼文分類、AI 與用量計量、Outbox 發送、成果歸因、帳號健康分、通知、訂閱計費、前端設計系統。
- 第一版訊號來源限 Threads（官方 API 路徑／dev 模式瀏覽器路徑）＋使用者手動匯入。
- 既有海巡命中可升級為商機，讓現有品牌用戶無痛接上同一條成交線。
Out of scope（明確不做）
- 不重做既有海巡抓取與發文主流程——本 run 是加值層，不是重構。既有品牌／產品／三種海巡模式（產品置入、主題接話、關鍵字活躍）保留不動。
- 不承諾全平台自動抓取。 第一版優先官方 API、公開搜尋結果與使用者主動匯入，避免帳號封鎖與平台合規風險。
- 不擴大爬蟲路徑：維持既有 dev 模式分流，不新增未經授權的模擬登入或規避手段。
- 不做自動大量發送：送出仍受既有帳號健康分送出閘與 Outbox 節流約束；所有自動化保留「複製文案 → 手動送出 → 標記完成」的人工路徑。
- 不做重量級 CRM：無自訂欄位、無自訂流程引擎、無團隊指派與業績目標、無 email 行銷序列。
- 第一版不做 LINE、不做 Google 評論、不做網站表單（P2）。
- 不自動判定成交：成交一律人工確認。
6. 命名決策（必須先鎖，否則契約會撞）
lead 一詞在既有後端規格中已被 ThreadPlay 的「主帳號」佔用（docs/product/haixun-backend/spec.md 的「lead／cast」「不可再當 lead 發送」）。本 run 一律不使用 lead 指稱銷售線索。
| 新名詞 | 中文 | 定義 | 與既有概念的關係 |
|---|---|---|---|
| Opportunity | 商機 | 一筆經判定、值得跟進的需求訊號，帶意向分數與判定理由 | 承接既有海巡命中，但獨立成可跨來源、可改狀態的物件 |
| Contact | 聯絡人 | 跨貼文聚合的「人」，擁有接觸歷史與目前狀態 | 既有系統完全沒有這層 |
| RadarWatch | 雷達訂閱 | 常駐關鍵字監控設定，含地區與排除條件 | 既有掃描詞是按一次跑一次，這是排程訂閱 |
| ServiceProfile | 服務檔案 | 服務項目、價格區間、案例、不能說的內容、常見問題、服務地區、空檔 | 既有品牌／產品是「賣產品」語意（痛點、匹配標籤），服務者欄位不同 |
| FollowUp | 追蹤 | 幾天沒回覆的提醒與 AI 追蹤訊息 | 既有系統完全沒有這層 |
7. 已鎖定決策（2026-07-31）
| # | 議題 | 決策 |
|---|---|---|
| 1 | 意向分數組成 | 由五問加權得出 0–100：需求真實性、購買意圖、地區符合、需求時效、服務匹配度。分級：高 ≥80／中 50–79／低 <50。必須附人話理由（為何判高、為何判低），使用者可手動覆寫分級並記錄覆寫紀錄——覆寫紀錄是後續調校判定的訓練素材。權重公式 → spec 定。 |
| 2 | 同業與雜訊處理 | 既有分類中的「同業叫賣」「公告」「雜訊」預設不進商機，但仍可在完整命中列表看到，避免誤殺。「求助」「求推薦」為主要來源。 |
| 3 | 每日巡的節奏與配額 | 每個雷達訂閱每日至少巡一次；每日商機有上限（防洗版與成本失控），超出部分依意向分數排序截斷並告知。每日訂閱數與商機上限依方案分級（見決策 #9）。巡的觸發時段 → spec 定一種寫死。 |
| 4 | 聯絡人收斂規則 | 同一來源平台＋同一作者帳號 → 同一聯絡人。跨平台不自動合併，但允許使用者手動合併與拆分。不做跨平台身分推測。 |
| 5 | CRM 狀態轉移 | 八狀態允許任意跳轉（自媒體實際流程不會照本走），但每次轉移記錄時間戳與操作者。「已成交／未成交」為終態，可重新開啟。「待追蹤」是可與其他狀態並存的標記，不是互斥狀態。 |
| 6 | 回覆版本與計費 | 五版本（公開留言／私訊／不帶銷售感／專業／幽默）。首次生成預設只產公開留言版，其餘按需生成，避免一次燒五倍點數。生成走既有 AI 用量計量與 BYOK 規則。「不能說的內容」為硬性過濾，違反時不得輸出。 |
| 7 | 追蹤提醒門檻 | 預設無回應 3 天提醒一次，最多提醒 2 次；仍無回應則建議轉為「未成交」，需人確認，系統不自動關閉。天數使用者可調。 |
| 8 | 與既有海巡並存 | 既有三種海巡模式原樣保留。商機雷達是新的使用情境，共用抓取與命中儲存，但商機是獨立實體。既有海巡命中提供「升級為商機」動作。既有品牌用戶不需重建資料即可使用。 |
| 9 | 定價與方案 | 金流與訂閱流程已存在（Stripe 訂閱、結帳、客戶入口、webhook）與既有 Free NT$0／Starter NT$590／Pro NT$1,990 三階方案，本 run 不重做付費流程，只把商機雷達的配額（每日雷達訂閱數、每日商機上限、AI 回覆生成額度）掛進既有方案並定義超限行為。價格落差待決： 產品構想的 NT$499／1,499 與既有 590／1,990 不一致；P0 沿用既有價格不動，待 P0 實際用量與成本數據出來再校準（P1），避免為了對齊一個未驗證的數字而破壞既有毛利模型（既有方案滿用毛利約 61%）。 |
| 10 | 成交回報 | 一律手動（從商機詳情或 CRM 卡片回報），金額與備註選填。寫入既有成果歸因，不另建一套成交帳。可事後修改／刪除，需留稽核精神。 |
| 11 | 交付順序 | 硬性： P0 內先做「服務檔案 → 雷達訂閱與每日巡 → 商機判定 → 今日商機頁」形成可展示的每日價值，再做「回覆多版本 → CRM → 追蹤提醒 → 轉換統計」閉環。配額掛載須與每日巡同批交付（成本閘）。P1 補來源與價格校準，P2 才碰 LINE 與其他平台。 |
| 12 | 訊號降級 | 平台拿不到某訊號時，仍交付其餘訊號＋手動路徑，禁止因缺訊號整段不做（沿用 growth-loop 既有降級原則）。 |
8. 使用者故事（可驗收）
P0
| ID | 作為… | 我想要… | 以便… | 驗收要點 |
|---|---|---|---|---|
| US-01 | 婚攝 | 填一次服務檔案（項目、價格帶、地區、不能說的內容） | 之後的判定與回覆都懂我 | 檔案可建可改；回覆生成明顯反映服務內容；違反「不能說的內容」的字句不出現 |
| US-02 | 網頁設計師 | 設定「有人會做網站嗎」等關鍵字後就不用再管 | 每天自動有名單 | 訂閱建立後次日無需人工操作即有當日結果；可暫停／恢復 |
| US-03 | 美甲師 | 每筆商機告訴我意向分數與理由，且分得出地區 | 只花時間在值得的人身上 | 每筆有 0–100 分與高／中／低；附人話理由；外縣市需求被標為地區不符 |
| US-04 | 一人公司 | 一頁看完「今日找到 N 筆／高中低各幾筆」 | 三分鐘決定今天回誰 | 今日頁含分級統計與卡片；卡片有原文、分數、地區、發布距今時間 |
| US-05 | 攝影師 | 對同一筆需求換不同語氣的回覆 | 公開留言與私訊要不一樣 | 可產出五種版本；預設先給公開留言版；其餘按需生成 |
| US-06 | 保險業務 | 把商機加進名單並推進狀態 | 不靠記憶追案子 | 八狀態可任意轉移並留時間戳；同一人的多筆需求收斂在同一聯絡人下 |
| US-07 | 健身教練 | 三天沒回覆時提醒我，並幫我想追蹤訊息 | 名單不會躺著爛掉 | 到期進站內通知；可一鍵產生追蹤訊息；最多提醒兩次後建議轉未成交且需人確認 |
| US-08 | 團購主 | 知道哪個關鍵字最會成交、哪種回覆最有效 | 把時間押在對的打法 | 統計頁可見關鍵字轉換率與回覆版本成功率；成交數據來自手動回報 |
| US-09 | 既有品牌島民 | 把既有海巡命中升級成商機 | 不用換工具、不用重建資料 | 命中列表有「升級為商機」；升級後進同一條 CRM |
| US-10 | 付費用戶 | 清楚知道我的方案每天能巡幾組、能出幾筆商機 | 用超了不會被無預警斷掉 | 配額掛在既有 Free／Starter／Pro；接近與超出上限都有明確提示；不靜默中斷每日巡 |
P1
| ID | 作為… | 我想要… | 以便… | 驗收要點 |
|---|---|---|---|---|
| US-20 | 寵物美容師 | 貼上一則 Facebook 社團貼文網址就能建商機 | 補上自動抓不到的來源 | 貼網址可建商機並跑判定；CSV 可批次匯入 |
| US-21 | 顧問 | 記錄報價金額與成交金額 | 算得出這工具幫我賺多少 | 金額寫入既有成果歸因；ROI 頁與轉換統計出現金額 |
| US-22 | 營運 | 依 P0 真實用量與 AI 成本檢視價格帶 | 毛利不被每日自動巡吃掉 | 有每會員每月雷達成本數據；價格調整與否有依據 |
P2
| ID | 作為… | 我想要… | 以便… | 驗收要點 |
|---|---|---|---|---|
| US-30 | 在地店家 | LINE 官方帳號的私訊也進同一條 pipeline | 不用在兩個地方追客人 | LINE 訊息建立／更新聯絡人；可在 CRM 看到 |
| US-31 | 服務業者 | 網站表單送出直接進名單 | 自有流量也被接住 | 表單 webhook 建立商機 |
9. 成功標準
- P0： 使用者設定關鍵字後，隔天不做任何操作即可看到「今日找到 N 筆／高中低分級」的商機清單。
- P0： 每筆商機都有意向分數、判定理由與地區判斷，且分級可被使用者覆寫。
- P0： 同一筆需求可產出至少五種語氣版本，且不出現服務檔案中「不能說的內容」。
- P0： 至少一條「關鍵字 → 商機 → 回覆 → 聯絡人 → 已成交」的完整鏈路可展示。
- P0： 追蹤提醒會在設定天數後進站內通知，並能一鍵產生追蹤訊息。
- P0： 統計頁能回答「哪個關鍵字最容易成交」與「哪種回覆版本成功率最高」。
- P0： 商機雷達配額掛進既有 Free／Starter／Pro，超限時明確提示且不靜默中斷每日巡。
- P1： 手動貼網址／CSV 可建立商機並跑同一套判定。
- 定性： 使用者能說出「這個月它幫我接到 N 個案子／省了幾小時找客戶」，而不是只描述功能。
- 商業： 月費遠低於一次成交價值的定位成立——使用者多成交一單即回本這句話在產品內可被數據佐證。
10. 約束與假設
- 約束：
AGENTS.md全部契約精神：UTC unix nanoseconds、JSON envelope 與成功碼、page／pageSize分頁、Job guarded 更新、後端一律 goctl 產生、會員 JWT 與 AI provider token 分離。- 禁止未實作 API 回成功空資料——本 run 新增大量頁面，此條特別容易被違反。
- 前端不引入新 UI 框架（不用 MUI／Ant／Chakra）；沿用既有設計 token 與元件庫；不用 emoji 當主 icon；TC 台灣語感。
- 平台合規紅線： 優先官方 API 與公開搜尋結果；爬蟲路徑維持既有 dev 模式分流不擴大；所有自動化保留人工路徑。
- 與
haixun-backend、growth-loop的關係：本 run 是加值層，不重構其已交付能力；成交歸因沿用growth-loop的成果事件，不另建帳。 - 交付順序遵守
AGENTS.md：既有前端已 live，本 run 前後端同步推進，但每個能力先有可驗收的產品行為定義才動碼。
- 假設（未驗證當真）：
- Threads 公開來源上「求推薦／不懂就問」類需求貼文的每日量體，足以讓單一使用者每天看到有意義的筆數。若量體不足，需以放寬關鍵字建議與手動匯入補足。
- AI 對「真實需求 vs 同業叫賣 vs 閒聊」的判定準確度，足以讓高意向分級可信。若不可信，名單價值歸零——這是本 run 的單點失敗風險。
- 使用者願意手動回報成交（沒有自動訊號可用）。
- 地區資訊可從貼文文字合理推斷；推斷不出時標為「未知」而非猜測。
11. 風險
| 風險 | 影響 | 緩解（需求層，非實作細節） |
|---|---|---|
| 意向判定不準（把閒聊當需求、把真需求判低） | 名單不可信＝產品價值歸零 | 強制附判定理由；使用者可覆寫並記錄；同業／雜訊預設排除；先求精準再求數量 |
| Threads 需求貼文量體不足 | 「今日 18 筆」變「今日 0 筆」 | 關鍵字建議機制；空結果時給明確建議而非空白頁；P1 手動匯入補位 |
| 平台 API 政策或搜尋能力變動 | 單一來源斷炊 | 定位為 Growth OS 而非 Threads 工具；來源可插拔；P2 擴 LINE 與自有表單分散風險 |
| 使用者被視為騷擾、帳號受罰 | 存亡級 | 沿用既有健康分送出閘與節流；回覆須「不像機器人推銷」；不做大量自動發送；保留人工路徑 |
| CRM 做太重，自媒體不想維護 | 功能無人使用 | 明確 out of scope（無自訂欄位／流程引擎）；八狀態任意跳轉；欄位極簡 |
| 成交靠手動回報，資料不完整 | 轉換統計失真 | 回報入口做在最自然的位置（商機詳情、CRM 卡片）；統計標示樣本數；不足時不顯示結論 |
| 與既有海巡概念混淆 | 現有用戶困惑、契約打架 | §6 命名決策；既有海巡原樣保留；提供「升級為商機」的單向橋接 |
| P0 範圍過大導致交付失焦 | 本 run 失去存在理由 | 決策 #11 交付順序硬性；先做出「每天有名單」再做閉環 |
| 每日自動巡造成 AI 成本失控 | 毛利被吃掉 | 決策 #3 每日商機上限與方案配額；低意向不生成回覆 |
12. 開放問題
- 關鍵字怎麼設才有效——要不要提供「依服務類別自動建議關鍵字」的引導？（影響 P0 上手體驗，建議 spec 納入最小版）
- 每日自動巡的觸發時段採 UTC 固定時點或會員時區早晨 → spec 選一種寫死。
- 地區判定的粒度（縣市／區／可遠端）與「服務地區」的比對規則 → spec。
- 意向分數五問的權重公式與門檻校準方式（是否需要人工標註樣本）→ spec／plan。
- 既有海巡命中「升級為商機」是複製還是共用同一筆資料 → spec。
- 免費試用如何設計才能讓使用者在第一天就看到名單（否則無法驗證價值主張）→ spec／plan。
13. 批准
- 需求已批准（2026-07-31／使用者「批准，進 spec」）