AO2 FIELD GUIDE · N083 · 數據量測與成效判讀
商機品質回饋欄位先對齊詢問、聯絡人與商機的識別，再分開需求適配、確認進度、無效原因與下一步。附欄位字典與對照演練，讓網站改善有可用回饋，不把業務未回覆或缺資料自動判成無效。
行銷說帶來很多名單，業務只回「品質不好」，兩邊都無法改善。需要的不是再加一欄高、中、低，而是說清這次需求是否適合、目前知道什麼、缺什麼，以及下一步由誰確認。
商機品質回饋欄位，先區分在記哪一件事
一個人可以提出多次詢問，一家公司也可能同時有不同專案。網站事件、詢問紀錄、聯絡人與 CRM 商機不宜全部塞成同一筆。先約定穩定識別及關聯方式，再說明資料由哪個工作產生。電子郵件可以協助聯絡，但不應成為辨識所有需求的唯一方式，更不能用姓名相同就自動合併。
先把需求、處理狀態與品質分開，才知道該改內容還是改接手。本篇定義共用資料語言，不提供某個 CRM 的同步操作。以 HubSpot 為例，官方將生命週期階段與部分跟進狀態分開；這是平台示例，企業仍要按自己的服務及實際工作定義，不能照抄名詞就當成分工完成。
白話例子：掛號、看診進度與是否掛對科，是不同欄
假想電子材料網站收到一項選型詢問。資料已建立，不代表已有人確認，也不代表需求一定適合。這像掛號處記下資料、確認看診進度、判斷是否掛對科，各有不同工作；若只留「好病人、壞病人」一欄，既無助接續，也無法知道哪個入口讓人誤解。
掛號對應詢問建立，進度對應接手狀態，科別適配對應企業是否能服務。這只是一個資料分工比喻，不涉及醫療判斷。B2B 需求也可能暫時資訊不足，應保留待確認；不能因對方沒寫預算，就預設沒有價值，更不能用個人印象代替可查的需求證據。
共同欄位先保留最小可用的一組
起始欄位可有詢問 ID、接收時間、產品或服務、需求摘要、已知條件、缺少條件、負責窗口、目前處理狀態與下一次動作。來源另記可觀測的通路與活動資訊，標明取得方式及未知。業務回饋最好能指向哪個產品限制、內容缺口或服務誤解，讓行銷知道回到哪一頁修正。
適配、急迫性與資料完整度應分開，因為「很急但超出範圍」和「適合但尚待確認」需要不同處理。重複、測試、垃圾、不適用與暫緩也不相同。欄位字典寫名稱、定義、選項、填寫者、更新時點與空值意義；沒有確認就保留未知，不讓系統預設值把尚未跟進寫成已淘汰。
| 欄位組 | 要描述什麼 | 不要混在一起 |
|---|---|---|
| 識別及關聯 | 詢問、聯絡人與專案的關係 | 同人多筆需求不是必然重複 |
| 需求適配 | 產品、條件及可服務範圍 | 急迫不等於適合 |
| 處理進度 | 未接手、確認中及已回覆 | 未回覆不等於無效 |
| 缺口及下一步 | 缺什麼、誰確認、何時回查 | 空值不等於沒有需求 |
| 來源證據 | 可辨識通路及取得方式 | 未知不能猜成特定渠道 |
用同一組匿名示例核對不同人的判讀
挑幾筆已去除不必要個資的需求示例，讓行銷與業務各自填寫，再比較差異。若一人把「尚未回覆」當無效，另一人當處理中，就先改定義。重要選項應有可觀察條件與例子，而非只寫高、中、低。字典要讓沒參加會議的人也能使用，不能靠熟人私下知道哪個詞真正代表什麼。
接著檢查網站欄位是否能提供必要背景，業務是否仍能補充或修正。不要為了報表方便，把所有內部欄位都強迫訪客填完；某些資訊只有後續對話才知道。先確認每欄支援哪個判斷，沒有用途的欄位刪減，必要資料則說明為何需要，避免一開始就提高詢問負擔。
讓回饋形成內容與流程的改善單
定期將回饋按產品、頁面與缺口彙整：若很多人誤解供應範圍，修頁面；若需求適合但資訊不足，補問法或附件；若有完整資料卻無人處理，查接手。原始個案細節不必公開，報告可用類型與必要證據描述。欄位一致只是起點，仍要有人把發現轉成行動與回查。
未跟進是一個待處理狀態，不是名單沒有價值的證明。保留字典版本、選項調整與過渡規則，否則新舊月份的品質比例可能只是定義不同。開始同步資料前，再驗證識別、欄位對照與更新權責；不要以資料有進 CRM 就宣稱已完成跨部門回饋。
| 示例情況 | 較可用的紀錄 | 後續改善 |
|---|---|---|
| 型號已知、配置未知 | 適配待確認，缺配置 | 補問及來源入口 |
| 詢問不在供應範圍 | 不適用，附明確原因 | 核對頁面範圍表達 |
| 資料完整卻未回覆 | 待接手，不先評成無效 | 查責任及通知 |
| 同人有兩個專案 | 分別保留需求及關聯 | 核對識別及重複規則 |
常見問題
可以只用高、中、低三種品質嗎？
可以作彙總標籤，但前提是有清楚、可觀察的定義與原因。適配、急迫、資料完整度和處理進度仍應分開，否則標籤相同也不知道下一步怎麼做。先用同一組示例讓不同人判讀，修正分歧，再決定哪些欄位需要保留，不讓個人印象成為跨部門比較的唯一依據。
業務沒回覆的名單，要排除在有效詢問之外嗎？
先標記未接手或待確認，不直接當成無效。沒有回覆代表缺少確認證據，也可能反映通知、負責人或人力問題。回查必要背景與後續動作，再按明確原因分類。報告可分別呈現已確認適配、待確認與不適用，避免把跟進缺口包裝成網站帶來的需求品質差。
為了回饋完整，要讓訪客一次填完所有欄位嗎？
不必。先分哪些是開始處理所需、哪些可從核准資料取得，以及哪些需在後續對話確認。內部評估欄位通常由適合角色補上，不應全部轉成訪客負擔。每欄都有用途、責任及未知狀態，才能兼顧可用與填答成本；若沒有明確用途，新增欄位未必帶來更好的商機回饋。
白話總結：別用一個好壞標籤，代替整段工作
分清需求、適配、進度與下一步，用共同字典把業務回饋接回網站和內容。
- 定對象：區分詢問、聯絡人與專案，保留穩定識別。
- 對定義：用相同示例核對欄位、未知與填寫責任。
- 接改善：把重複缺口交回內容或流程，留下版本與回查。
完成條件：不同角色能一致判讀同一需求，知道缺什麼與交給誰，也能解釋該改善哪個入口。
來源與方法範圍
資料查核：2026 年 10 月 24 日。來源支持文中對應的準則與平台說明；工作表、判斷步驟及已標示的假想情境由 AO2 整理，實際使用時依產品資料與現行設定核對。
