187 lines
13 KiB
Markdown
187 lines
13 KiB
Markdown
|
# Requirements: 品牌 × 產品商機雷達
|
|||
|
|
|
|||
|
|
> Status: `approved`
|
|||
|
|
> Status note: 使用者 2026-08-10「批准」；同意 §11 的多產品合併與時效建議
|
|||
|
|
> Slug: `brand-product-radar`
|
|||
|
|
> Last updated: `2026-08-10`
|
|||
|
|
> Parent capability: `demand-radar`
|
|||
|
|
> 本文件將「找到這個產品的錢在使用者」理解為「找到這個產品的**潛在使用者**」。
|
|||
|
|
|
|||
|
|
## 1. 一句話
|
|||
|
|
|
|||
|
|
讓使用者選定自己的品牌與產品後，系統每天自動從公開需求訊號中，找出**正在遇到該產品可解決問題的人**，依商機價值排序，並清楚說明「他為什麼像這個產品的潛在使用者」。
|
|||
|
|
|
|||
|
|
## 2. 問題與現況
|
|||
|
|
|
|||
|
|
既有商機雷達已能每日巡邏、判斷購買意圖、產生回覆並把商機推進 CRM；Brand 與 Product 也已有自己的定位、受眾、痛點與匹配資料。但兩邊尚未形成正式關聯：
|
|||
|
|
|
|||
|
|
- 雷達訂閱目前只知道關鍵字、地區與排除詞，不知道是替哪個品牌、哪個產品找人。
|
|||
|
|
- 商機目前只能說「像一筆需求」，不能穩定回答「適合賣哪一個產品」與「憑什麼」。
|
|||
|
|
- 同一會員有多個品牌或產品時，共用服務檔案容易混入不相干的能力、案例與回覆語氣。
|
|||
|
|
- 只搜尋品牌名或產品名，通常找到的是品牌討論、同業與既有內容，不一定是尚未認識產品、但正在承受痛點的潛在使用者。
|
|||
|
|
- 同一篇貼文若同時命中多個產品訂閱，可能形成重複商機，造成重複聯絡。
|
|||
|
|
|
|||
|
|
因此本次重點不是增加更多關鍵字，而是把搜尋與判定改成以下鏈路：
|
|||
|
|
|
|||
|
|
**品牌定位 → 產品能解決的痛點 → 使用者正在表達的需求／情境 → 產品適配證據 → 可跟進商機**
|
|||
|
|
|
|||
|
|
## 3. 使用者與核心情境
|
|||
|
|
|
|||
|
|
| 角色 | 核心情境 |
|
|||
|
|
|------|----------|
|
|||
|
|
| 單一品牌、單一產品經營者 | 設定一次後，每天收到真正可能使用此產品的人 |
|
|||
|
|
| 單一品牌、多產品經營者 | 每筆商機知道最適合哪項產品，不把不同產品的受眾混在一起 |
|
|||
|
|
| 多品牌經營者／代理商 | 建立雷達時選清楚品牌與產品，結果、回覆、追蹤皆不串牌 |
|
|||
|
|
| 業務／行銷人員 | 看得懂對方的痛點、購買訊號與產品適配原因，再決定是否接觸 |
|
|||
|
|
| 既有商機雷達使用者 | 原有每日巡邏不中斷，可逐步把舊訂閱補上品牌與產品 |
|
|||
|
|
|
|||
|
|
## 4. 產品目標
|
|||
|
|
|
|||
|
|
### 4.1 P0：每天找到「適合這個產品的人」
|
|||
|
|
|
|||
|
|
1. **雷達訂閱綁定品牌與產品**
|
|||
|
|
- 新建產品型雷達時，必須先選一個自己擁有的品牌，再選該品牌底下的一個產品。
|
|||
|
|
- 一個雷達在 P0 只服務一個產品，避免判定、回覆與統計互相污染。
|
|||
|
|
- 不得選到其他會員的品牌／產品，也不得把產品綁到錯誤品牌。
|
|||
|
|
|
|||
|
|
2. **由品牌與產品產生需求語言**
|
|||
|
|
- 品牌提供目標受眾、品牌定位與目標。
|
|||
|
|
- 產品提供產品情境、痛點、匹配詞、可解決能力與排除詞。
|
|||
|
|
- 系統應優先找「使用者如何描述問題、需求與購買情境」，而不是只找品牌名或產品名。
|
|||
|
|
- 系統可提出建議搜尋詞與排除詞，但使用者在啟用每日巡邏前可檢查、修改。
|
|||
|
|
|
|||
|
|
3. **每日巡邏讀取最新產品資訊**
|
|||
|
|
- 每日自動巡邏與手動立即探索都使用同一套品牌／產品上下文。
|
|||
|
|
- 品牌或產品更新後，下一次巡邏使用新資料；過去商機保留當時判定依據，不被事後改寫。
|
|||
|
|
- 沿用既有排程、配額、錯誤提示與人工操作路徑，不重造另一套巡邏機制。
|
|||
|
|
|
|||
|
|
4. **潛在使用者判定**
|
|||
|
|
每筆候選訊號至少回答：
|
|||
|
|
- 對方是否在表達真實問題、需求、求推薦或購買情境？
|
|||
|
|
- 這個人是否接近品牌設定的目標受眾？只可依公開文字證據判斷，不得臆測個資或敏感屬性。
|
|||
|
|
- 貼文中的痛點是否與產品痛點、使用情境或解決能力吻合？
|
|||
|
|
- 對方是在找解法，還是同業叫賣、品牌公告、泛討論、徵才、已有供應商或其他雜訊？
|
|||
|
|
- 此需求是否仍值得現在跟進？
|
|||
|
|
|
|||
|
|
5. **分數與證據分開呈現**
|
|||
|
|
- 保留既有 0–100 商機分數與高／中／低分級，用來排序今天先看誰。
|
|||
|
|
- 另呈現產品適配程度，說明命中的痛點、使用情境、受眾線索與排除風險。
|
|||
|
|
- 單純命中一個關鍵字，不足以宣稱對方是潛在使用者。
|
|||
|
|
- 每個重要判定都必須能回指公開貼文中的文字證據；證據不足時明確標示不確定，不得補寫不存在的背景。
|
|||
|
|
|
|||
|
|
6. **今日商機以品牌／產品為核心瀏覽**
|
|||
|
|
- 今日商機可依品牌、產品、分數與適配程度篩選或排序。
|
|||
|
|
- 每張卡片清楚顯示品牌、主推產品、對方的問題、產品適配理由、風險與原文入口。
|
|||
|
|
- 空結果要說明是沒有候選、被排除、資料不足、配額或巡邏失敗，不得用成功空畫面掩蓋問題。
|
|||
|
|
|
|||
|
|
7. **跨產品去重**
|
|||
|
|
- 同一會員看到的同來源、同一篇公開內容，只形成一筆主要商機卡片。
|
|||
|
|
- 若同一內容同時適合多個產品，保留各產品的匹配結果與分數，指定一個主推產品並顯示其他可能產品。
|
|||
|
|
- 使用者可改選主推產品；不得因多個雷達命中而重複聯絡同一個人。
|
|||
|
|
|
|||
|
|
8. **回覆與跟進不串牌**
|
|||
|
|
- 產生回覆時使用該商機選定的品牌與產品資訊，並遵守既有禁止內容與人工送出規則。
|
|||
|
|
- 回覆應從對方公開表達的問題切入，不得假裝知道其未公開資訊，也不得強行硬銷。
|
|||
|
|
- 商機進入聯絡人、追蹤與成交後，持續保留來源品牌、主推產品及曾匹配的其他產品。
|
|||
|
|
|
|||
|
|
9. **品牌／產品生命週期安全**
|
|||
|
|
- 品牌或產品停用、刪除或失去可用條件時，相關產品型雷達不得繼續用過期上下文巡邏。
|
|||
|
|
- 系統應暫停受影響的雷達並說明原因；既有商機、聯絡與成交歷史保留。
|
|||
|
|
- 不得自動改綁到名稱相近的其他產品。
|
|||
|
|
|
|||
|
|
10. **舊資料平順過渡**
|
|||
|
|
- 既有未綁品牌／產品的雷達標示為「通用雷達」，不偷偷猜測歸屬。
|
|||
|
|
- 通用雷達原有每日巡邏先不中斷，並提供補選品牌／產品的明確入口。
|
|||
|
|
- 舊商機保持可查看與跟進；未綁定者顯示「未指定產品」，不偽造歷史關聯。
|
|||
|
|
|
|||
|
|
### 4.2 P1：讓產品資料越巡越準
|
|||
|
|
|
|||
|
|
1. 使用者對商機做「適合／不適合」、改主推產品、加入名單、未成交與成交等操作後，可形成產品層的調校訊號。
|
|||
|
|
2. 系統可建議新增或降低權重的痛點詞、需求句、排除詞；任何會改變後續巡邏的建議均由使用者確認。
|
|||
|
|
3. 產品維度可查看找到多少人、高意向比例、加入名單率、回覆率、成交率與成交金額；樣本不足時不下結論。
|
|||
|
|
4. 可比較同品牌不同產品的商機量與轉換，但不得把不同品牌的數據混成單一產品結論。
|
|||
|
|
|
|||
|
|
### 4.3 P2：跨產品推薦與更深受眾建模
|
|||
|
|
|
|||
|
|
1. 一個雷達同時探索多個產品，並替每個候選推薦最合適的產品。
|
|||
|
|
2. 產品可擁有自己的理想使用者、購買觸發、使用情境與不適合對象；空白時才繼承品牌受眾。
|
|||
|
|
3. 依已確認的成功／失敗商機產生產品受眾洞察，但不自動修改品牌或產品真相。
|
|||
|
|
4. 擴充至其他合規訊號來源，沿用同一套產品適配與去重規則。
|
|||
|
|
|
|||
|
|
## 5. 明確不做
|
|||
|
|
|
|||
|
|
- 不重做既有每日排程、Threads 訊號抓取、AI 供應商、用量計量、CRM、通知、Outbox 或成果歸因底座。
|
|||
|
|
- 不以品牌名／產品名命中數冒充潛在使用者數。
|
|||
|
|
- 不抓取私人帳號內容、不推測性別、年齡、疾病、財務狀況等未公開或敏感屬性。
|
|||
|
|
- 不自動大量留言、私訊或跨平台追蹤個人身分。
|
|||
|
|
- 不因高分直接認定成交，也不自動替使用者承諾價格、成效或交期。
|
|||
|
|
- P0 不做一個雷達跨多產品，也不重做完整產品資料管理。
|
|||
|
|
|
|||
|
|
## 6. 已採用的需求決策
|
|||
|
|
|
|||
|
|
| # | 議題 | 決策 |
|
|||
|
|
|---|------|------|
|
|||
|
|
| 1 | P0 關聯粒度 | 一個產品型雷達只綁一個品牌下的一個產品 |
|
|||
|
|
| 2 | 搜尋核心 | 以痛點、需求句、求推薦與使用情境為主；品牌名與產品名只能是輔助訊號 |
|
|||
|
|
| 3 | ServiceProfile 定位 | 保留為會員共用的服務區域、可接案狀態、禁止內容等營運預設；產品適配由 Brand／Product 提供，不再用共用服務項目替代產品 |
|
|||
|
|
| 4 | 產品修改 | 未來巡邏讀最新資料；既有商機保留判定當時的產品名稱與匹配證據 |
|
|||
|
|
| 5 | 重複訊號 | 同一內容對同一會員只顯示一筆商機，可攜帶多個產品匹配並選一個主推產品 |
|
|||
|
|
| 6 | 舊雷達 | 不自動猜品牌／產品，也不立即停巡；標為通用雷達並引導補綁 |
|
|||
|
|
| 7 | 刪除／停用 | 暫停相關雷達、保留歷史、禁止自動改綁 |
|
|||
|
|
| 8 | 判定可信度 | 關鍵字命中只是召回；必須同時有需求與產品適配證據，才可標成產品潛在使用者 |
|
|||
|
|
|
|||
|
|
## 7. 使用者故事與驗收
|
|||
|
|
|
|||
|
|
| ID | 作為… | 我想要… | 驗收要點 |
|
|||
|
|
|----|--------|---------|----------|
|
|||
|
|
| BP-01 | 多產品品牌主 | 新建雷達時選品牌與產品 | 只能選自己品牌下的產品；選錯關係無法啟用 |
|
|||
|
|
| BP-02 | 產品經營者 | 由產品痛點得到可編輯的需求詞 | 建議詞能對應來源資料；啟用前可增刪；不是只列產品名 |
|
|||
|
|
| BP-03 | 忙碌經營者 | 每天自動收到此產品的潛在使用者 | 無須每日手動操作；每筆結果帶品牌與產品歸屬 |
|
|||
|
|
| BP-04 | 業務 | 知道為何這個人適合這項產品 | 卡片顯示需求證據、痛點匹配、適配程度與風險，不以單一詞命中充當理由 |
|
|||
|
|
| BP-05 | 多產品品牌主 | 同一貼文適合兩產品時只處理一次 | 只出現一張商機卡；看得到兩組匹配；可更換主推產品 |
|
|||
|
|
| BP-06 | 多品牌經營者 | 產生不串牌的回覆 | 回覆使用正確品牌與產品，不引用另一品牌資料，並遵守禁止內容 |
|
|||
|
|
| BP-07 | 既有雷達使用者 | 升級後每日巡邏不中斷 | 舊雷達標成通用；可手動補綁；舊商機可繼續跟進 |
|
|||
|
|
| BP-08 | 產品管理者 | 停用產品後不再產生新商機 | 相關雷達被暫停並顯示原因；歷史資料仍在 |
|
|||
|
|
| BP-09 | 經營者 | 按品牌／產品看今日結果 | 篩選、排序、數量與卡片歸屬一致，空結果原因可辨識 |
|
|||
|
|
| BP-10 | 營運 | 確認排名真的比關鍵字搜尋有用 | 人工標註樣本中，高排名結果能說明需求與產品適配；同業叫賣與品牌公告不進高排名 |
|
|||
|
|
|
|||
|
|
## 8. 成功標準
|
|||
|
|
|
|||
|
|
- [ ] 新建的產品型雷達 100% 有合法品牌與產品歸屬。
|
|||
|
|
- [ ] 每筆被標為產品潛在使用者的商機，至少有一段需求證據與一段產品適配理由。
|
|||
|
|
- [ ] 同一篇內容被兩個產品雷達命中時，今日商機不產生重複卡片。
|
|||
|
|
- [ ] 使用者能在三分鐘內回答：「今天哪幾個人最可能需要哪個產品，以及為什麼？」
|
|||
|
|
- [ ] 品牌 A 的商機判定與回覆不引用品牌 B 的產品資料。
|
|||
|
|
- [ ] 更新產品只影響後續巡邏，不改寫過去商機的判定歷史。
|
|||
|
|
- [ ] 舊雷達與舊商機升級後仍可使用，且未綁資料不被假裝成已綁定。
|
|||
|
|
- [ ] 以人工標註的代表性樣本驗收時，高排名前十筆中至少八筆同時具備真實需求與產品適配證據；未達標不得宣稱已可自動找潛在使用者。
|
|||
|
|
|
|||
|
|
## 9. 約束與假設
|
|||
|
|
|
|||
|
|
- 沿用專案既有時間、回應格式、分頁、排程防重、會員權限、AI token 隔離與方案配額規則。
|
|||
|
|
- 前端沿用 Harbor Desk 與既有 repository 介面，不新增另一套 mock／live 行為。
|
|||
|
|
- 本 run 是既有 `demand-radar` 的產品化延伸，不應平行建立第二套商機、聯絡人或巡邏資料。
|
|||
|
|
- 品牌與產品資料品質會直接影響結果；資料不足時必須引導補齊或降低信心，不得讓模型自行腦補。
|
|||
|
|
- 公開貼文通常只能證明「此刻表達的需求」，不能證明對方完整身分或最終購買能力。
|
|||
|
|
|
|||
|
|
## 10. 主要風險
|
|||
|
|
|
|||
|
|
| 風險 | 影響 | 需求層緩解 |
|
|||
|
|
|------|------|------------|
|
|||
|
|
| 產品資料太空泛 | 建議詞與適配理由都會失真 | 啟用前顯示資料完整度與建議補充項目；證據不足降低信心 |
|
|||
|
|
| 多產品互相競爭 | 同一人被重複聯絡或推錯產品 | 單卡多產品匹配、主推產品唯一、人工可改 |
|
|||
|
|
| 過度依賴 AI 推測受眾 | 產生偏見與不可信判定 | 只引用公開文字證據；未知即未知；禁止敏感屬性推測 |
|
|||
|
|
| 舊資料遷移破壞每日價值 | 既有用戶突然沒有結果 | 通用雷達不中斷、不自動猜測、提供漸進補綁 |
|
|||
|
|
| 分數混合後難以理解 | 使用者只看到一個神祕總分 | 商機分數與產品適配分開，且都附理由 |
|
|||
|
|
| 只追求數量 | 結果退化成普通關鍵字搜尋 | 高排名必須同時具備需求與產品適配證據，以人工樣本驗收 |
|
|||
|
|
|
|||
|
|
## 11. 本次批准的兩個決策
|
|||
|
|
|
|||
|
|
1. **同一貼文匹配多產品：** 建議維持「一張商機卡＋多個產品匹配＋一個主推產品」，避免重複接觸；若你希望每個產品各自進不同業務流程，需改成可分拆但預設合併。
|
|||
|
|
2. **商機時效：** 建議「今日商機」保留既有時效門檻，確保可聯絡性；較舊但適配的內容不刪除，放在完整結果並以低時效分排序。這能同時兼顧你先前要求的「結果多一點」與商機必須及時。
|
|||
|
|
|
|||
|
|
## 12. 批准
|
|||
|
|
|
|||
|
|
- [x] requirements 已批准（2026-08-10／使用者「批准」）
|
|||
|
|
- 批准後下一步：補齊資料與互動契約的 `spec.md`；spec 再批准後才建立 `plan.md`，最後拆成可執行的 `tasks/`。
|