由查詢到 CRM：建立有負責人跟進的 AI 流程

先定義收件記錄，再請 AI 填寫

保存原始電郵或提交內容、到達時間、渠道及穩定的收件識別碼，附件也沿用相同存取規則。把對方的說法與團隊的理解分開：「未提及預算」是有用資料，猜測預算範圍則是另一項主張。同事更正抽取欄位時，不應改寫原始查詢。

訂明負責人所需的最少欄位，清楚表示未知值。同一聯絡人可以有多項查詢，因此聯絡人與查詢要使用不同識別碼。公司名稱、電郵主旨或推測電話號碼，都不應代替有依據的身份核對。

• 對方提供的聯絡資料及來源位置。
• 所需服務與對方原本的範圍描述。
• 明確提及的時間、預算及附件；沒有提到就留空。
• 抽取狀態、驗證問題及覆核人。
• CRM 聯絡人編號、查詢編號、負責人及下一步時間。

把 AI 的理解限制在清楚約定的範圍

提供固定欄位清單，要求重要細節附上依據。電郵格式、可用服務分類及日期格式，用一般規則驗證。「下個月」應保留原來字句，直到參照日期及實際意思清楚。查詢內容不能成為匯出聯絡人、跳過覆核或改動確認範本的指令。

範圍含糊、服務分類不支援或聯絡資料矛盾時，交人覆核。若表格本身已收集結構化資料，就直接使用這些值，只讓 AI 處理自由文字描述。抽取的目的，是減少閱讀工夫，而非加入對方未說過的內容。

核對聯絡人，讓每次寫入可以安全重試

保留處理記錄，把收件識別碼與每次嘗試寫入 CRM 的動作連結。重試前，先查看該步驟是否已產生記錄。這樣可以恢復失敗流程，同時保留既有聯絡人的真正新查詢。身份配對不確定時交人核對，不要自動合併聯絡人。

HubSpot 的聯絡人 API 文件列出記錄編號、按電郵查找、自訂唯一識別欄位，以及更新和 upsert 操作；你選用的 CRM 是否提供相同功能，要逐項確認。即使支援 upsert，也要訂清楚哪些欄位可以更新，避免一封新電郵覆蓋負責人已核實的資料。

實例演練：記錄時間要求，不把它變成承諾

以下是假設例子，並非客戶項目：對方問可否「下個月前」改善網站查詢表格，並希望知道大概價錢。記錄這個時間要求及價格問題，預算留空，再交網站查詢清單。合適的收件確認只說已收到要求，團隊會查看；不代表已確認價格、開工日或交付日。

只有公司已批准而且能做到，才在回覆中承諾回應時間。負責人之後確認範圍及時間，再準備以 USD 列出的報價。CRM 記錄應把原文、抽取資料、待問問題及下一步放在一起。另訂後備負責人及升級處理規則，避免同事休假時無人接手。

分段恢復失敗，避免漏收或重發

把保存查詢、寫入 CRM、發出確認及分配責任分別記錄。CRM 暫時無法連線時，查詢仍應保存為待處理，並顯示給當值負責人。電郵發送逾時時，重試前先查發送服務可提供的證據；只有已提交的記錄，不應標示為已送達收件人。

Google 的 Gmail 推送文件指出，通知偶爾可能延誤或遺失，因此郵箱收件流程也需要補查核對。Microsoft 的流程指引建議用重試政策處理短暫故障。重試應有上限，之後轉入例外清單；無限重試無效資料或狀態不明的發送，反而令問題更難處理。

量度完整收件和責任交接，不只看流程成功次數

先量度現行人工流程由收件到負責人有可用任務的基準。收件完整率＝已記錄的唯一有效查詢數除以來源中的有效查詢數。責任完整率＝有負責人及下一步的已收查詢數除以已收查詢數。分開量度分配任務及首次實質回覆的中位時間，不要把自動收件確認當作已解答。

追蹤重複記錄、重要欄位更正、確認發送失敗及待處理項目年齡，把人工處理例外的工時算進比較。若身份配對損壞記錄、確認回覆自行加出條款、補查發現漏收，或清單超過議定覆核能力，就暫停自動發送或寫入。修復期間仍要透過人工路徑接收查詢。