# APAC PLG Digest — 新註冊 ICP 發現區塊修訂提案 **日期：**2026-07-28 **對象：**APAC Tenants Monitor／PLG digest owner（謝玉潔、劉昉）及 APAC Marketing／RevOps **狀態：**待確認；建議先以兩週、可回滾的試行執行 **本文件：**原 `not decided-PLG-Scoring-Change-Request-2026-07-27.md` 的修訂草案；不取代既有 P0／P1 定義，也不代表已核准的產品或路由決策。 --- ## 一、要解決的問題 現行 daily digest 的主列表以既有分數排序，分數主要受累積使用訊號影響。這對已活躍租戶是合理的，但對剛註冊、尚未累積 QPS 或 cluster 的企業帳號，會造成固定盲點：它們通常無法在最需要早期接觸的 72 小時內出現在 digest。 這不是要把「新註冊」等同於「高產品意圖」，也不是要降低既有高使用量帳號的優先級。要補的是一個小而獨立的 **新註冊 ICP 發現入口**，讓 Marketing／SDR 能看見值得人工判斷的企業帳號。 --- ## 二、設計原則與邊界 1. **既有主評分、P0／P1 規則與 Target Account 覆蓋規則維持不變。** Target Account 若已依現行流程升為 P0，不能在新區塊中重複計分或重複建立任務。 2. **新區塊是 discovery queue，不是 PQL 升級機制。** 入選不代表 P0、P1、sales-qualified，也不自動指派 AE 或建立 HubSpot task。 3. **先小量、可人工消化、可回滾。** 不在沒有結果資料前重寫整個分數模型。 4. **使用已被執行流程讀取的欄位優先。** 不把收入、融資、產業等 enrichment 視為已可用的 scoring input；只有在覆蓋率、時效與置信度被驗證後，才可作為次要排序資訊。 5. **避免重複觸達。** 已在主 action list、已連線／已處理，或已由銷售擁有的帳號，均不得因新區塊再產生平行動作。 --- ## 三、Phase 1：新增「New ICP Discovery」區塊 ### 3.1 Digest 輸出 保留現有主列表，不降低既有行動帳號的曝光；在其後增加一個最多 3 筆的區塊： | 區塊 | 每日數量 | 用途 | 既有分數／優先級是否改動 | |---|---:|---|---| | 現有 Action list | 維持目前輸出（Top 10） | P0／P1 或既有高分行動帳號 | 否 | | **New ICP Discovery** | **最多 3** | Marketing／SDR 人工判斷新企業帳號 | 否 | 選擇「最多 3」而非一次保留 5 個名額，是因為目前沒有已確認的每日人工處理容量。試行期間不將此區塊寫入 CRM，不產生自動銷售任務；因此增加的工作量應可控制在每日 10–15 分鐘的初步判讀。 若當日沒有合格候選人，可少於 3 筆，不以較低品質帳號補滿。 ### 3.2 候選資格 候選人必須同時符合： - 註冊時間在 digest 產生前 **72 小時內**； - 位於目前 APAC monitor 的有效市場範圍； - 為非個人／公司網域，且可取得公司名稱或既有 domain intelligence 判斷； - enrichment 置信度不是 low，或至少可由企業網域明確識別； - 不在當日既有 Action list 中； - 未被標記為已連線／已處理；若此狀態目前不可用，必須在卡片中明確標示為「未驗證」，不得假設未處理； - 不屬於已由銷售擁有且被現行 Summary 排除的帳號；如業務希望保留可見性，僅顯示 owner，不新增動作。 以下帳號不進入人工 discovery 區塊： - 個人／免費信箱，或無法識別公司的低置信度帳號； - 已由既有 Target Account 規則升級並出現在 Action list 的帳號； - 資料時間戳過期或關鍵欄位缺失、無法判讀的帳號。 這些被排除的筆數應以簡短 tally 呈現（例如：`個人信箱 8／低置信度 2／已在 action list 1`），作為資料品質觀察；不是要把 APAC 的個人信箱使用者永久壓制。若後續出現 import、card 或明顯產品行為，仍由既有 PQL 規則處理。 ### 3.3 排序與卡片內容 候選人以以下順序排序： 1. 現行流程中可驗證的公司／domain intelligence fit 與置信度； 2. 註冊新鮮度（較新優先）； 3. 若可用且高置信度，再以 Target Account 標記、公司規模／融資／垂直等 enrichment 作為同級 tie-breaker，**不作為硬分數加成**。 每筆卡片至少輸出：公司名稱、網域、國家／市場、註冊時間、可驗證的入選原因、Target Account 標記、既有 owner／處理狀態，以及建議下一步。 建議下一步固定為二選一，避免把 discovery 卡變成未定義的工作： - `Research only`：補齊公司／用例資訊，暫不觸達； - `Marketing/SDR review`：人工確認後，依既有流程進 welcome、nurture 或 PQL 路徑。 ### 3.4 實作範圍 工程工作應限定為：在 Summary／digest 產生流程增加一段候選選取、去重與格式化邏輯，並記錄選取原因與產生時間。 不要先承諾「一條 SELECT + UNION」即可完成。現行 APAC 流程包含 monitor、scoring 與 summary 層；實作方式應由 owner 依實際資料表、排除條件與卡片格式決定。Phase 1 不更動 scorer、優先級寫入、HubSpot 權限或 owner-routing 設定。 --- ## 四、試行方式與停止條件 ### 試行設定 - **期間：**連續 10 個工作日（兩週）。 - **容量：**每日最多 3 筆；僅在 digest 顯示，無自動 HubSpot write-back、無自動指派。 - **人工 owner：**APAC Marketing 指定一位每日查看者；若未指定，僅收集卡片資料，不宣告 SLA。 - **可回滾：**以 feature flag／設定開關控制；若造成 digest 失敗、重複曝光或明顯錯誤，可關閉新區塊而不影響主列表。 ### 每日記錄欄位 - 候選總數、顯示數、各類排除數與資料新鮮度； - 每筆的 `selection_reason`、是否與主列表重複、人工判斷結果； - 7／14 天內是否出現 query、import、card 或被人工確認為目標帳號； - digest 發送是否準時，以及資料讀取／enrichment 失敗數。 ### 試行後的決策門檻 第 10 個工作日只回答三個現實問題： 1. 每日 3 筆是否有足夠可讀、可判斷的候選，還是資料品質不足？ 2. 人工是否能穩定處理，且沒有與既有 sales owner／P0/P1 重複？ 3. 被人工保留的候選，是否比隨機新註冊帳號更常在 7／14 天內出現有效產品或商業訊號？ 只有三項都有正向證據，才考慮擴至 5 筆或把部分 enrichment 納入正式排序。若沒有，關閉此區塊或維持為純市場觀察，不修改主評分。 --- ## 五、Phase 2：暫不排期的主分數調整 目前不採用收入、融資、垂直、註冊天數與 Target Account 的加分表。原因不是否定 ICP，而是正式分數會影響 P0／P1 的相對順序與銷售工作量，必須先釐清資料與規則。 Phase 2 只有在下列條件全數成立後才可重新提案： - 收入、融資、垂直、公司識別等欄位的覆蓋率、資料來源、最後更新時間與置信度均有可重現的檢查結果； - 已釐清 Target Account 在現行流程中是「P0 覆蓋」還是一般排序訊號，且不會雙重計算； - 有至少兩週 Phase 1 的人工採納與後續行為資料； - 有完整的 before／after 分數分布、P0/P1 容量影響、重複觸達檢查與 rollback 設計； - 任一 bonus 的 cap、最高分與範例計算完全一致，並經 owner 以實際資料驗證。 若進入 Phase 2，應優先考慮把資料品質良好的 fit 作為「人工隊列排序／最低優先級 guard」；不要讓零使用的新帳號僅靠 firmographic 分數直接獲得 P0 或同等銷售處理。 --- ## 六、需獨立處理的營運事項 ### Owner routing 「所有 PLG leads 均路由至 Kenneth Lee」必須由 RevOps／routing owner 以目前正式設定確認後，才可改 upstream mapping。這項變更與 Phase 1 分開發布、分開驗證；不得僅依 digest 顯示的舊 owner 推定設定已失效。 ### Daily Summary 的自動化與資料新鮮度 新 discovery 區塊依賴當日可讀資料，因此 Summary 應在送卡前顯示 `data_as_of`／產生時間與失敗狀態。若現行 daily cadence 尚未真正自動化，先修正排程與失敗告警，再承諾每日新增候選卡；否則只會把過期 enrichment 更快地發送出去。 --- ## 七、這週需要的確認 - [ ] 同意以「保留既有 Top 10 + New ICP Discovery 最多 3 筆」進行 10 個工作日試行。 - [ ] 指定 Phase 1 的 engineering owner 與人工 daily reviewer。 - [ ] 確認現行 Target Account、sales-owned 與 connected／已處理狀態的可讀欄位及排除規則。 - [ ] 確認 digest 的實際自動發送排程、資料新鮮度欄位與失敗告警責任人。 - [ ] 由 RevOps 獨立確認 PLG owner routing；確認後再排入設定變更。