如何用 Claude 的排程任務和 Dispatch 讓銷售商機保持最新

一句話結論：Claude 的排程任務（Tasks）可以在沒人開對話的情況下週期性地重新檢查進行中的商機，而它的多代理調度（Dispatch）模式可以並行處理大量商機，而不是一條一條循序處理。這個組合對銷售管線的資料衛生確實有用——前提是代理只提出修改建議，由人來核准寫入。

每個業務主管都知道預測表裡的數字有一部分是虛的，也大致知道原因。有些案子最後一次接觸已經過去三週，狀態還停在「議價中」。三分之一的進行中商機「下一步」是空的。預計成交日期早就過了，沒人去改。沒有人在偷懶——管線資料維護是那種永遠沒有截止日期的工作，所以每週都輸給有截止日期的事。

常見的應對是週一提醒加季度集中清理。這撐不住，因為衰減是連續的，介入卻是週期性的。

這是本系列裡唯一一篇圍繞 Claude 自身代理能力、而不是「對話＋API 整合」來寫的題目，因為管線資料維護恰好需要這兩個能力提供的東西：一個在沒人打開對話視窗時也會跑起來的東西，以及一個能一次看完九十筆商機、而不需要來回九十輪的東西。

為什麼管線資料的衰減比業務手動修復更快

CRM 紀錄變舊的方式都很平常。打了通電話，筆記記在本子上。客戶說「等我們三月預算複核之後再聯絡」，沒人去改預計成交日期——因為在那個當下它感覺像行政雜事，而不是一個影響預測的事實。某位商機負責人離職，他的案子被批次轉給一位從沒跟這些客戶談過的主管。

每一件都是兩分鐘能修好的。但這樣的事有八十件，持續不斷地出現，而且在發生的當天沒有一件是緊急的。這就是問題的形態，也解釋了為什麼常規辦法沒用：把欄位設成必填，只會讓業務填點什麼，而不是填點真的；季度清理衝刺在跑的那天把積壓清掉，然後接下來八十九天繼續衰減。

真正有效的，是一個頻繁發生的、乏味的小檢查——每一兩天，涵蓋所有進行中商機——產出一份很短的「這十筆看起來不對，原因如下」。這活毫無光彩、重複度極高，恰恰是最適合交給無人值守代理的特徵。

Claude 的 Tasks 和 Dispatch 到底做什麼

這裡有兩個能力值得說清楚，因為價值取決於你用的是哪一個，而代理式 AI 的行銷話術常常把它們混為一談。兩者的可用範圍因訂閱方案而異，且都在快速演進——在圍繞任何一個做設計之前，請先查閱 Anthropic 的最新文件確認你的方案包含什麼。

排程任務（Tasks）——週期性的無人值守執行，而不是一次性提示

Task 是一條按排程自動執行、不需要任何人發起對話的指令。這聽起來微不足道，但這正是全部要點：管線資料維護失敗的原因，不是沒人知道該怎麼檢查一筆陳舊商機，而是在週二、另外四件事都在著火的時候，沒人記得去做。

無人值守改變的是風險樣貌，不是能力本身。你自己跑的提示詞，你會讀它的輸出；一條不管有沒有人看著都會在早上七點跑起來的提示詞，必須按照「沒人會仔細讀」來寫——這意味著範圍要窄、預設要保守、輸出要落在人真的會看到的地方，例如電子郵件或某個 Slack 頻道，而不是一份沒人打開的日誌。

Dispatch——跨多筆商機的並行子代理

第二個能力是編排：一個協調代理分派出若干子代理同時處理不同部分，再把結果收回來。用在管線複核上對應得很乾淨——每筆商機（或每個管線分段）一個子代理，各自讀取該紀錄的歷史並形成判斷，並行進行而不是排隊。

實際好處不只是快。只負責一筆商機的子代理，擁有這筆商機的完整脈絡而沒有別的干擾，判斷會比「一次把九十個案子都裝在腦子裡」更銳利。代價是每個子代理只看得見自己那一筆，所以任何需要跨管線比較的問題——「這一季真正重要的是哪三筆」——應該放在協調環節，而不是子代理裡。

成本是個現實問題。九十個並行子代理消耗的大致就是九十份 token，每天跑一次再乘以每月二十個工作天。要刻意收窄範圍：只涵蓋金額超過某個門檻的進行中商機，或超過十四天沒有動靜的，而不是每晚掃描系統裡的一切。

一套可落地的流程：從陳舊管線到每日更新

按這個順序搭建，不要跳過唯讀階段。

先唯讀，並且維持兩週。給代理 CRM 唯讀權限，完全不給寫入權限。讓排程任務每天早上執行，分派子代理掃過所有進行中商機，產出一份摘要：哪些案子看起來陳舊、具體哪裡不對、它會改什麼。用電子郵件寄給業務主管。

兩週之後你就知道了在授予任何寫入權限之前最需要知道的事——它標出來的東西對不對。如果三分之一是錯的，那要麼提示詞需要打磨，要麼 CRM 資料比你以為的更糟；而在唯讀摘要階段發現這件事，成本為零。

把判定標準明確寫下來。「陳舊」不是不言自明的，不該讓模型自己發明定義。寫清楚：21 天沒有活動紀錄、預計成交日期已過、停留在某階段的時間超過該階段平均值的兩倍、金額超過門檻但「下一步」為空。明確的標準會產出每次執行都一致的輸出，而這正是摘要值得據以行動的前提。

給它歷史，不只是欄位。語言模型在這裡的價值，是讀取紀錄上掛著的筆記、郵件和通話摘要，注意到最後一次溝通結束於「這個專案我們暫停到第三季」，而階段欄位還寫著「合約簽署中」。欄位層級的規則看不見這個。這也是你應該刻意決定「允許代理讀多少對話內容」的節點。

要放開寫入權限，就放得很窄——或者乾脆不放。當摘要連續兩週都可靠之後，可以考慮讓代理寫入，但把寫入面維持得很小。更新一個「AI 已標記」欄位、加一條備註、給負責人建一個待辦，與修改階段或預計成交日期完全是兩回事。餵給預測的那些欄位，永久保留給人。站得住腳的規則是：代理可以寫任何用來提醒人的東西，不能寫任何用來報數的東西。

把輸出送到有權限的人手上。寄到一個沒人認領的共用信箱，這個任務就會悄悄變得無關緊要。寄給業務主管，並且在既有例會裡給它一個五分鐘的、有名字的固定環節。

Claude Tasks + Dispatch vs CRM 原生工作流規則 vs Zapier 或 API 整合

• Claude Tasks 搭配 Dispatch 是三者中唯一能讀非結構化內容的——通話筆記、郵件往來、會議紀要——並對「紀錄是否與實際發生的事相符」形成判斷。這是它的全部價值，也是它的全部風險：判斷可能出錯，而錯誤判斷寫進真實紀錄，比漏更新更糟。適用於你需要的訊號存在於文字之中的場景。
• CRM 原生工作流規則（Salesforce Flow、HubSpot workflows）是確定性的、你已付的授權裡自帶的、可稽核的，在它的能力邊界內完全可靠。它能告訴你某筆案子 21 天沒有活動，但永遠不會告訴你最後一封郵件裡客戶說專案被擱置了。任何能用欄位條件表達的檢查，就用它——在同樣的活兒上，它嚴格優於 AI 代理。
• Zapier 或直連 API 整合處在中間：擅長在觸發時把資料從一個系統搬到另一個，不擅長判斷，而且會留下一份比建造者在職時間更長的維護負擔。把它當作 AI 複核下面的管道層是合理的——負責把摘要送進聊天工具，或把已核准的標記寫回去——而不是當複核者。

真正從中獲益的團隊通常三者都用：確定性檢查交給 CRM 規則，判斷題交給 AI 複核，簡單自動化作為兩者之間的傳送管道。

這件事會在哪裡出錯

把看似合理的猜測自動寫進真實紀錄。最快摧毀信任的失敗，是代理依據一條讀錯的筆記改了預計成交日期，被業務發現，然後整個團隊認定這工具不可靠。一次可見的錯誤寫入，損耗的信譽超過五十次正確寫入所累積的。這就是「先建議、後核准」的全部理由。

CRM 權限給得過寬。阻力最小的路徑是建一個對所有物件擁有完整讀寫權的整合帳號，五分鐘建好，之後再沒人回頭看。把它收窄到這項工作需要的物件和欄位，並且記住：代理也能讀到這個帳號能讀的一切——包括從來沒同意過這件事的業務線的商機、聯絡人和備註。

沒有稽核軌跡。三個月後有人問某筆案子的階段為什麼變了，「是 AI 改的」不是任何人能接受的答案。每一次自動變更都應可歸因：用專屬整合帳號而不是某個人的憑證、留一條記錄變更內容與依據的備註、並保留提出該變更的那份摘要。

靜默失效。排程任務停掉的時候通常不會聲張。管線慢慢退回原樣，一個月都沒人發現，因為「沒有摘要」看起來就像「這週比較安靜」。要對「任務沒有執行」告警，而不只是對「任務報錯」告警。

業務悄悄迎合它。如果摘要變成用來考核人的計分卡，得到的不會是更好的資料衛生，而是更好看的紀錄。把它定位成主管的待辦提示清單，不是法遵報告。

把這件事做對：CRM 權限範圍、寫入前的人工簽核，以及何時找 IT

一個對 CRM 擁有長期存取權的無人值守代理，與一次聊天工作階段是完全不同的安全物件，應該由以此為業的人來劃定範圍。有三個決定比其餘都重要。

限定的是權限，不是意圖。從唯讀開始，只涵蓋這項工作需要的物件和欄位，透過一個擁有獨立憑證的專屬整合身分。真正重要的是代理能碰到什麼，而不是今天這條提示詞讓它碰什麼——提示詞會變，權限會留下。

決定允許它讀什麼。商機紀錄裡有客戶組織中的具名個人、合約條款、價格，有時還有關於潛在客戶內部狀況的商業敏感資訊。把這些送給任何外部服務，都是一個資料處理決定，而你在 PDPO、PDPA、PIPL 或 GDPR 下的位置對此可能有話要說，取決於你的客戶在哪裡。這個問題屬於資料治理負責人，要在第一次排程執行之前解決，而不是之後。

寫入這一環必須留人。不是作為將來會放寬的臨時安全措施，而是作為設計本身。代理的職責是產出一份簡短、準確、值得人去看一眼的清單。人來決策在這裡不是瓶頸，而是讓整套安排站得住腳的那個控制點。

設計這個權限範圍、選擇代理能看到管線的哪些部分、把複核標準寫得讓輸出持續有用——這是 AI+ 支援服務的工作，屬於 AI 就緒度與使用情境梳理，而這正是業務組織裡比較清晰的一個使用情境。治理這一側——一個 AI 代理應該持有多少長期的、無人值守的、跨系統存取權，由誰複核，如何留痕——正是我們託管服務實踐所提供的那類常設決策建議，與其中的資安治理和虛擬 CTO 工作一脈相承。底下的身分、憑證與整合帳號衛生，屬於常規的託管 IT 支援。如果你想先邁一小步，我們關於 HubSpot 中 AI 輔助名單評分的文章講的是這件事的單次觸發版本，也歡迎找我們聊聊哪一種更適合你。

常見問題

排程任務可以在沒人複核的情況下直接寫入 CRM 嗎？

技術上可以，只要你給了寫入權限。但對任何餵給預測的欄位來說，這是個壞主意。從唯讀開始，至少維持兩週；等到確實開放寫入時，把它限制在提醒人的欄位上，而不是報數的欄位上。

這到底需要什麼 CRM 權限——唯讀還是讀寫？

唯讀就足以支撐有用的版本：讀取紀錄及其歷史、產出摘要。只有當你希望代理直接更新紀錄時才需要寫入權限，而多數團隊一開始不該這麼做。無論哪種，都要按物件和欄位收窄，並透過專屬整合帳號。

這和 HubSpot 或 Salesforce 自帶的 AI 功能有什麼區別？

CRM 原生 AI 內建於平台，不需要外部整合就能看到你的資料，通常在基於結構化訊號的評分與預測上最強。這裡說的模式在性質上不同：一個由你設定的代理，讀取非結構化歷史，按你設定的節奏報出具體的不一致之處。兩者是互補的；如果你 CRM 自帶的功能已經涵蓋了這件事，那才是更簡單的答案。

如果 Dispatch 讀錯了一筆案子、改錯了階段怎麼辦？

如果你遵循了「先建議、後核准」，什麼都不會發生——誤讀出現在摘要裡，人不同意，紀錄原封不動。如果你給了直接寫入權限，你會得到一個錯誤的階段和一份悄悄錯掉的預測。這個不對稱正是該模式存在的理由。

可以限定它只處理部分商機嗎？

可以，而且應該——出於成本考量不亞於安全考量。按金額門檻、管線、負責人或距上次活動的天數過濾。每天涵蓋真正重要的那五十筆案子，比每晚全量掃描所有歷史紀錄更有用，也便宜得多。

每天跑這個到底要花多少錢？

它隨複核的商機數量、每個子代理讀取的歷史量，以及執行頻率同步放大。價格會變，所以請按你自己的範圍估算，而不是相信文章裡的某個數字——但要先做的算術是「商機數 × 每月執行次數」，而這通常正是讓團隊從「每晚全量」轉向「每日篩選」的原因。

這會取代每週的管線檢討會嗎？

不會，它改變的是檢討會討論什麼。會議不再把前二十分鐘花在發現哪些紀錄是錯的，而是一開場就拿到那份清單，時間用在案子上，而不是資料上。