13 KiB

Raw Permalink Blame History

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：每天找到「適合這個產品的人」

雷達訂閱綁定品牌與產品
- 新建產品型雷達時，必須先選一個自己擁有的品牌，再選該品牌底下的一個產品。
- 一個雷達在 P0 只服務一個產品，避免判定、回覆與統計互相污染。
- 不得選到其他會員的品牌／產品，也不得把產品綁到錯誤品牌。
由品牌與產品產生需求語言
- 品牌提供目標受眾、品牌定位與目標。
- 產品提供產品情境、痛點、匹配詞、可解決能力與排除詞。
- 系統應優先找「使用者如何描述問題、需求與購買情境」，而不是只找品牌名或產品名。
- 系統可提出建議搜尋詞與排除詞，但使用者在啟用每日巡邏前可檢查、修改。
每日巡邏讀取最新產品資訊
- 每日自動巡邏與手動立即探索都使用同一套品牌／產品上下文。
- 品牌或產品更新後，下一次巡邏使用新資料；過去商機保留當時判定依據，不被事後改寫。
- 沿用既有排程、配額、錯誤提示與人工操作路徑，不重造另一套巡邏機制。
潛在使用者判定 每筆候選訊號至少回答：
- 對方是否在表達真實問題、需求、求推薦或購買情境？
- 這個人是否接近品牌設定的目標受眾？只可依公開文字證據判斷，不得臆測個資或敏感屬性。
- 貼文中的痛點是否與產品痛點、使用情境或解決能力吻合？
- 對方是在找解法，還是同業叫賣、品牌公告、泛討論、徵才、已有供應商或其他雜訊？
- 此需求是否仍值得現在跟進？
分數與證據分開呈現
- 保留既有 0–100 商機分數與高／中／低分級，用來排序今天先看誰。
- 另呈現產品適配程度，說明命中的痛點、使用情境、受眾線索與排除風險。
- 單純命中一個關鍵字，不足以宣稱對方是潛在使用者。
- 每個重要判定都必須能回指公開貼文中的文字證據；證據不足時明確標示不確定，不得補寫不存在的背景。
今日商機以品牌／產品為核心瀏覽
- 今日商機可依品牌、產品、分數與適配程度篩選或排序。
- 每張卡片清楚顯示品牌、主推產品、對方的問題、產品適配理由、風險與原文入口。
- 空結果要說明是沒有候選、被排除、資料不足、配額或巡邏失敗，不得用成功空畫面掩蓋問題。
跨產品去重
- 同一會員看到的同來源、同一篇公開內容，只形成一筆主要商機卡片。
- 若同一內容同時適合多個產品，保留各產品的匹配結果與分數，指定一個主推產品並顯示其他可能產品。
- 使用者可改選主推產品；不得因多個雷達命中而重複聯絡同一個人。
回覆與跟進不串牌
- 產生回覆時使用該商機選定的品牌與產品資訊，並遵守既有禁止內容與人工送出規則。
- 回覆應從對方公開表達的問題切入，不得假裝知道其未公開資訊，也不得強行硬銷。
- 商機進入聯絡人、追蹤與成交後，持續保留來源品牌、主推產品及曾匹配的其他產品。
品牌／產品生命週期安全
- 品牌或產品停用、刪除或失去可用條件時，相關產品型雷達不得繼續用過期上下文巡邏。
- 系統應暫停受影響的雷達並說明原因；既有商機、聯絡與成交歷史保留。
- 不得自動改綁到名稱相近的其他產品。
舊資料平順過渡
- 既有未綁品牌／產品的雷達標示為「通用雷達」，不偷偷猜測歸屬。
- 通用雷達原有每日巡邏先不中斷，並提供補選品牌／產品的明確入口。
- 舊商機保持可查看與跟進；未綁定者顯示「未指定產品」，不偽造歷史關聯。

4.2 P1：讓產品資料越巡越準

使用者對商機做「適合／不適合」、改主推產品、加入名單、未成交與成交等操作後，可形成產品層的調校訊號。
系統可建議新增或降低權重的痛點詞、需求句、排除詞；任何會改變後續巡邏的建議均由使用者確認。
產品維度可查看找到多少人、高意向比例、加入名單率、回覆率、成交率與成交金額；樣本不足時不下結論。
可比較同品牌不同產品的商機量與轉換，但不得把不同品牌的數據混成單一產品結論。

4.3 P2：跨產品推薦與更深受眾建模

一個雷達同時探索多個產品，並替每個候選推薦最合適的產品。
產品可擁有自己的理想使用者、購買觸發、使用情境與不適合對象；空白時才繼承品牌受眾。
依已確認的成功／失敗商機產生產品受眾洞察，但不自動修改品牌或產品真相。
擴充至其他合規訊號來源，沿用同一套產品適配與去重規則。

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. 本次批准的兩個決策

同一貼文匹配多產品： 建議維持「一張商機卡＋多個產品匹配＋一個主推產品」，避免重複接觸；若你希望每個產品各自進不同業務流程，需改成可分拆但預設合併。
商機時效： 建議「今日商機」保留既有時效門檻，確保可聯絡性；較舊但適配的內容不刪除，放在完整結果並以低時效分排序。這能同時兼顧你先前要求的「結果多一點」與商機必須及時。

12. 批准

requirements 已批准（2026-08-10／使用者「批准」）
批准後下一步：補齊資料與互動契約的 spec.md；spec 再批准後才建立 plan.md，最後拆成可執行的 tasks/。

13 KiB Raw Permalink Blame History Unescape Escape