如何用 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 读错了一个单子、改错了阶段怎么办？

如果你遵循了"先建议、后批准"，什么都不会发生——误读出现在摘要里，人不同意，记录原封不动。如果你给了直接写权限，你会得到一个错误的阶段和一份悄悄错掉的预测。这个不对称正是该模式存在的理由。

可以限定它只处理部分商机吗？

可以，而且应该——出于成本考虑不亚于安全考虑。按金额门槛、管道、负责人或距上次活动的天数过滤。每天覆盖真正重要的那五十个单子，比每晚全量扫描所有历史记录更有用，也便宜得多。

每天跑这个到底要花多少钱？

它随复核的商机数量、每个子智能体读取的历史量，以及运行频率同步放大。价格会变，所以请按你自己的范围估算，而不是相信文章里的某个数字——但要先做的算术是"商机数 × 每月运行次数"，而这通常正是让团队从"每晚全量"转向"每日筛选"的原因。

这会取代每周的管道复盘会吗？

不会，它改变的是复盘会讨论什么。会议不再把前二十分钟花在发现哪些记录是错的，而是一开场就拿到那份清单，时间用在单子上，而不是数据上。