228 lines
23 KiB
Markdown
228 lines
23 KiB
Markdown
# 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 與政策波動影響。
|
||
|
||
**已握有、本輪明確不重造的底座：**
|
||
|
||
1. **雙路徑抓取**：官方 API 路徑與 dev 模式下的瀏覽器工作階段路徑，已在既有海巡落地。
|
||
2. **貼文分類地基**：既有命中已能區分「求助／求推薦／同業叫賣／討論／提問／公告／雜訊」，並保留意圖片段與命中理由。意向分數是在這之上補地區、時效與服務匹配，**不是從零做分類器**。
|
||
3. **AI 供應商抽象與 BYOK 用量計量**、**Outbox 真發送與節流**、**成果歸因與 UTM 點擊**、**帳號健康分與送出閘**、**Stripe 訂閱與方案**、**站內通知**、**前端設計系統與 repository 契約**。
|
||
|
||
## 4. 目標（To-be）
|
||
|
||
### 4.1 必須達成（P0）— 每天有名單、回得出話、追得到錢
|
||
|
||
1. **服務檔案（ServiceProfile）**
|
||
使用者一次填好：服務項目、價格區間、代表案例、**不能說的內容**、常見問題、服務地區、可接案空檔。這份檔案同時餵給**商機判定**與**回覆生成**，是「AI 回覆助手不是單純改寫」的來源。
|
||
|
||
2. **雷達訂閱＋每日自動巡（RadarWatch）**
|
||
使用者設定關鍵字（例：「台北 婚攝推薦」「有人會做網站嗎」「求推薦寵物美容」「公司想導入 AI」）後，系統**每日自動巡**，不需手動按掃描。這是「每天幫你找客戶」的核心承諾，也是與既有 on-demand 海巡最關鍵的差異。
|
||
|
||
3. **商機判定五問與意向分數（Opportunity）**
|
||
每筆訊號由 AI 回答五問：**是不是真實需求**、**對方是否有購買意圖**、**地區是否符合**、**需求是否仍有效**、**是否值得放進潛在客戶名單**。輸出 0–100 意向分數與高／中／低分級，**必須附判定理由**且使用者可覆寫分級。
|
||
|
||
4. **今日商機頁**
|
||
一眼看完當日產出：「今日找到 18 筆 ／ 高意向 5 ・中意向 8 ・低意向 5」，以及每筆的原文摘要、意向分數、地區、發布距今時間、AI 建議回覆，與三個動作：**開啟原文**、**加入名單**、**產生其他回覆**。
|
||
|
||
5. **AI 回覆多版本**
|
||
同一筆需求可產出五種語氣版本：**公開留言版**、**私訊版**、**不帶銷售感版**、**專業版**、**幽默版**。回覆須讀得出品牌語氣與服務內容，且**不得違反服務檔案中「不能說的內容」**。
|
||
|
||
6. **超輕量 CRM 八狀態＋聯絡人聚合（Contact）**
|
||
狀態：**新發現 → 已互動 → 已私訊 → 對方回覆 → 已報價 → 已成交／未成交**，外加**待追蹤**。同一個人在同一平台多次發需求，收斂成同一個聯絡人，看得到完整接觸歷史。自媒體不會想維護複雜 CRM，因此欄位與操作必須極簡。
|
||
|
||
7. **追蹤提醒（FollowUp）**
|
||
幾天沒回覆自動提醒（走既有站內通知），並可 **AI 產生追蹤訊息**，避免名單躺著爛掉。
|
||
|
||
8. **轉換統計（讓產品從內容工具升級成營收工具）**
|
||
成交來源統計、**哪個關鍵字最容易成交**、**哪種回覆版本成功率最高**。統計掛在既有成果歸因之上，不另做一套帳。
|
||
|
||
9. **方案配額掛載**
|
||
每日雷達訂閱數、每日商機上限、AI 回覆生成額度，掛進**既有 Free／Starter／Pro 三階方案**。金流與訂閱流程已存在，本 run 只定義配額與超限行為，不重做付費流程。**這是 P0 而非 P1**：每日自動巡若無配額上限，AI 成本會失控。
|
||
|
||
### 4.2 應該有（P1）— 補來源與收錢
|
||
|
||
1. **手動匯入商機**：貼上 Threads／Facebook 社團貼文網址，或以 CSV 批次匯入。這是「不承諾全平台自動抓取」前提下的合規補位。
|
||
2. **報價與成交金額**：CRM 的「已報價／已成交」可填金額與備註，寫入既有成果歸因，讓 ROI 頁與轉換統計有金額維度。
|
||
3. **價格帶校準**：依 P0 實際使用量與 AI 成本，決定是否調整既有 Starter／Pro 價格（見決策 #9 的價格落差）。
|
||
|
||
### 4.3 以後再說（P2）
|
||
|
||
1. **LINE 官方帳號雙向**：以 Messaging API 把私訊收進同一條 pipeline。
|
||
2. **Google 商家評論**、**網站表單 webhook**（自帶名單入口，不碰第三方平台）。
|
||
3. **自有 IG／Threads 留言與私訊收斂**進聯絡人。
|
||
4. **可公開搜尋的論壇來源**。
|
||
5. **空檔媒合**：依服務檔案的可接案空檔，對高意向商機提示可約時段。
|
||
|
||
## 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. 開放問題
|
||
|
||
1. **關鍵字怎麼設才有效**——要不要提供「依服務類別自動建議關鍵字」的引導？（影響 P0 上手體驗，建議 spec 納入最小版）
|
||
2. 每日自動巡的**觸發時段**採 UTC 固定時點或會員時區早晨 → **spec 選一種寫死**。
|
||
3. 地區判定的**粒度**（縣市／區／可遠端）與「服務地區」的比對規則 → **spec**。
|
||
4. 意向分數五問的**權重公式與門檻校準方式**（是否需要人工標註樣本）→ **spec／plan**。
|
||
5. 既有海巡命中「升級為商機」是**複製**還是**共用同一筆資料** → **spec**。
|
||
6. 免費試用如何設計才能讓使用者在**第一天**就看到名單（否則無法驗證價值主張）→ **spec／plan**。
|
||
|
||
## 13. 批准
|
||
|
||
- [x] 需求已批准（2026-07-31／使用者「批准，進 spec」）
|