老闆把 CRM 接上 AI 之後，系統確實變勤勞了——客戶填完表單、回了一句話、下單一次，CRM 裡的客戶階段、owner、同意狀態就自動跳動。但「自動更新」跟「更新得對」是兩件事：客戶可能同時跟兩個業務在聊、填過舊版表單又填了新的、同意收行銷訊息之後又在客服抱怨被打擾太多次。CRM 資料一直在變動，不代表每一次變動都是對的。
如果 AI 直接依照 CRM 當下的欄位值去分眾、排下一封訊息、安排跟單順序，等於把「資料本身可能是錯的」這個風險，原封不動外包給自動化流程去放大。這篇要談的不是該不該讓 AI 跟單，而是在放手之前，老闆要先訂出一套「客戶上下文修正規則」——誰能改、什麼情況該改、改了要留下什麼紀錄。
「資料新」不代表「資料對」
CRM 裡最常被 AI 拿來做決策的幾個欄位，恰好也是最容易悄悄出錯、卻沒人發現的欄位：
- 客戶階段：報價單一寄出，系統就自動把客戶從「接洽中」跳到「待成交」，但客戶根本還沒回覆，AI 卻已經依「快成交」的邏輯排了催促訊息。
- owner 歸屬：原本的業務離職或客戶轉單，owner 欄位沒人記得改，AI 自動發出的訊息還掛著舊業務的名字和聯絡方式。
- 同意狀態：客戶半年前勾選同意行銷訊息，這兩週卻在客服反覆抱怨「訊息太多」，同意狀態欄位卻還停在「同意」，沒人把這個訊號寫回去。
- 產品需求：客戶原本詢問 A 產品，後來在對話裡改問 B 產品，CRM 的需求標籤卻還是舊的，AI 分眾時仍把他歸進 A 產品的名單。
- 最近互動：客戶同時有 LINE、Email、電話三個管道，系統只看單一管道的最後互動時間，就判斷「已失聯 30 天」，實際上客戶上週還在另一個管道回過話。
- 誰能改：每個欄位指定可以修正的角色或窗口——不是人人都能改，但也不能卡在只有一個人能改、他不在就沒人能處理。業務可以改自己客戶的階段，但同意狀態這種合規相關欄位，建議收斂到固定一兩人。
- 什麼情況該改：列出會觸發修正的具體情境，例如業務異動、客戶主動反饋、連續 N 天沒有任何管道回應、客服接到抱怨。情境列得越具體，越不會變成「大家憑感覺改」。
- 怎麼留紀錄：修正時間、修正人、修正前後的值、修正理由，至少留最基本的版本紀錄。之後客戶投訴「為什麼一直收到不該收的訊息」，才有東西可以回溯，不是只能說「系統自動的」。
- 可以自動跑：欄位異動有明確、單一來源可追——例如客戶親自在表單勾選新需求、業務在系統裡手動把階段往前推一格，且來源與修正紀錄一致。
- 該跳回人工：同一位客戶的資料在短時間內被多個來源同時修改；同意狀態在短期內「同意→拒絕→同意」反覆跳動；owner 變更的同一時間點，客服系統剛好有一筆該客戶的投訴紀錄。
- 先盤點 AI 跟單會讀的幾個關鍵欄位，逐一寫下「誰能改」。不用一次盤點整張 CRM，先抓客戶階段、owner、同意狀態這三個 AI 最常拿來做決策的欄位開始。
- 針對同意狀態與 owner 這兩個最容易出錯的欄位，先訂一條「異動要留言」的基本規則。不用複雜系統，先要求改動時必須填一句理由，就能擋掉大部分「順手改一下」造成的問題。
- 設一個低成本的人工複核點，而不是一次建完整系統。例如每週花 10 分鐘，看一次「被多次修改」或「短期內同意狀態跳動」的客戶名單，比起追求一次到位的自動化稽核機制，更容易真的被落實執行。
這五個欄位的共同問題不是「資料太舊」，而是「沒有人固定負責確認它現在是不是真的對」。AI 跟單跑得越快，這個缺口被放大的速度也越快。
客戶上下文修正規則：至少要寫清楚這三件事
不需要一次蓋出一套完整的資料治理系統，但「客戶上下文修正規則」至少要白紙黑字寫清楚三件事，而不是靠誰想到就順手改一下。
這三件事沒有先寫清楚，AI 跟單只是把「資料錯了沒人追」的老問題，換成「AI 自動依錯誤資料做事」的新問題，速度更快、影響面更廣。
什麼情況可以自動跑，什麼情況要跳回人工
不是每一次欄位異動都值得驚動真人。區分的關鍵不是「欄位重不重要」，而是「異動訊號本身是否可疑」。
這跟行銷自動化先做名單分流：中小企業 CRM 自動化該從哪裡下手談的是不同層次的問題——那篇解決的是「名單一進來該先分到哪裡」，是第一步的分流規則；這篇談的是分流之後，客戶資料在往來過程中持續變動時，誰該負責確認它還是對的，是分流之後接著要補的治理層。沒有這一層，分流規則訂得再漂亮，AI 跟單用的還是一份會悄悄走偏的名單。
用 RACAE 把修正規則變成能持續調整的機制
修正規則訂出來的第一版，大概率不會剛好合用——訂太鬆，錯誤資料照樣溜進 AI 的跟單流程；訂太緊，一堆正常異動都被攔下來等人工確認，業務反而嫌麻煩不想用。比較務實的做法是把它放進固定週期，用 RACAE 跑：先把每週出現的欄位異動與修正紀錄記下來（Record），比對哪一類異動最常被判斷錯、哪一類又真的抓到問題（Analysis），判斷目前「誰能改、什麼情況要改」的門檻是訂得太鬆還是太緊（Conclusion），針對下一週該調整哪一條規則先做假設（Assumption），再用下一輪實際資料驗證調整後的誤判率是不是真的下降（Experiment）。
重點不是一次做到完美，而是讓「修正規則的門檻」變成每週會被重新檢視一次的活規則，而不是上線當天訂死、半年都沒人動過的舊設定。
很多老闆聽到「修正規則」「版本紀錄」就以為要先換一套更貴的 CRM 系統或額外買稽核工具，其實不必。第一版規則完全可以先用一張共用表格撐著：欄位、修正人、修正時間、修正前後值、理由，五欄位就夠開始。等這套規則跑過幾週、確認「誰能改、什麼情況要改」這兩條真的訂對了，再決定要不要把它搬進 CRM 系統裡變成正式流程。先把規則本身想清楚，比急著買工具更重要——工具只是把已經想清楚的規則執行得更快，想不清楚的規則裝再多自動化也沒用。
老闆現在可以做的 3 件事
CRM 自動化會不會讓跟單更有效率，現在已經很難說不會。但不管答案是什麼，「這筆資料現在是不是真的對、改錯了算誰的」這個風險，不會因為你還沒讓 AI 自動跟單就不存在——事實上，資料出錯、沒人負責確認，從 CRM 剛導入的那天就一直在發生，只是現在多了一層「AI 會依照這份資料自動做事」的放大鏡。延伸閱讀可參考企業 AI 陪跑是什麼，了解陪跑如何陪老闆把 AI 自動化風險一關一關盤清楚。
客戶上下文修正規則常見問題
CRM 資料都是系統自動帶的，為什麼還需要人工修正規則？
系統自動帶入的是「最新一次異動」，不代表那次異動本身是對的。客戶階段、同意狀態這類欄位常常因為單一事件（例如報價單寄出、一次性抱怨）就被自動改動，如果沒有人固定確認，AI 之後的分眾與跟單就會建立在這個沒被檢查過的資料上。
修正規則會不會拖慢 AI 跟單的速度？
不會拖慢大部分情況，只會拖慢真正可疑的那一小部分。規則設計的重點是分流：來源明確、單一的異動照常自動跑；只有短時間內多來源同時改動、或同意狀態反覆跳動這類可疑訊號，才需要多一道人工確認，大部分客戶完全不會感覺到流程變慢。
小公司資源有限，要從哪個欄位先做修正規則？
建議先從 AI 跟單最常拿來做決策、而且出錯代價最高的欄位開始，通常是客戶階段、owner 歸屬、同意狀態這三個。不用一次盤點整套 CRM 欄位，從這三個先訂出「誰能改、改了留什麼紀錄」就能擋掉大部分問題。
這跟判斷 AI 代理人下單是不是本人、是不是盜用帳號是同一件事嗎？
是同一個大問題的不同層面，但關卡不同。代理人身分風控談的是「下單那一刻」要不要信這個動作；客戶上下文修正規則談的是 CRM 裡的客戶資料本身在平時就要有人固定確認是不是還準確，兩者都是 AI 自動化之前要先補的治理工作，但處理的時間點與對象不一樣。
