Anthropic 的 Claude Salesforce 插件将 CRM 工作带入 AI 对话

Anthropic 于 9 月 15 日推出处于测试阶段的 Claude Salesforce 插件，为销售人员提供 37 项技能，可通过 Claude 处理实时客户记录。这一发布让 Claude 成为账户调研、通话准备、销售管道审查、预测以及拟议 CRM 更新的操作界面。

这一转变的重要性不止于集成目录中新增了一个连接器。数十年来，Salesforce 一直致力于让自身界面成为销售工作的核心。如今，新插件让 Claude 能够置于 Salesforce 的数据、权限和业务规则之前。

Salesforce 通过与 Anthropic 扩展合作关系 Claudeforce 支持这一变化。这项安排也将 Claude 引入 Salesforce 产品，包括 Agentforce 和 Slack。但更具影响力的方向恰恰相反：Salesforce 现在可以作为 Claude 背后的受治理系统运行。

因此，眼下的竞争并非 Anthropic 对阵 Salesforce，而是 Claude 内的对话式工作方式，与在 CRM 应用中浏览记录、报表、仪表板和工作流这一既有模式之间的较量。

Claude Salesforce 插件从 37 项销售技能起步

Anthropic 和 Salesforce 正将常见销售任务转化为预定义的 Claude 工作流，而不只是通过对话开放原始 CRM 记录。

根据 Claude 发布文章，该测试版可在现有 Salesforce 权限框架下，将销售人员的账户、商机和销售管道带入 Claude。其 37 项技能涵盖账户调研、会议准备、销售管道检查和 CRM 管理等重复性工作。

技能是一组打包的指令和工具，用于完成一项明确任务。这种结构为 Claude 提供了可遵循的流程，以及访问相关 Salesforce 功能的权限。

一项技能可根据客户记录、通信内容和已连接的数据源汇总账户简报。另一项可检查未结商机，并识别看似停滞的交易。其他技能则支持续约准备、预测说明、活动记录和销售管道维护。

其实际目标是消除客户沟通前后所需的整合工作。销售人员通常需要分别查看联系人记录、商机历史、电子邮件、Slack 讨论串和会议笔记。当组织已将这些来源连接起来时，Claude 可以将它们汇集到一个工作上下文中。

该插件还可在 Claude 内生成交互式视图。Anthropic 表示，销售人员可以创建销售管道仪表板、审查预测信息以及查看账户计划，无需切换至单独的报表界面。

这并不是对 Salesforce 记录的替代。Claude 仍依赖 Salesforce 作为存储客户数据、访问控制和工作流逻辑的系统。改变的是人们提问、审查上下文和发起工作的地点。

Salesforce 将这一更广泛的合作称为 Claudeforce。其 合作公告最初称，Salesforce in Claude 将以插件形式于 2026 年 9 月进入公开测试。Anthropic 于 9 月 15 日的发布使该计划进入实际测试阶段。

访问仍有条件。Anthropic 表示，该测试版面向通过 Salesforce 加入流程获批的组织，并可通过付费 Claude 套餐使用。因此，不同公司、配置和地区的可用性可能有所不同。

测试版与正式发布之间的区别很重要。测试版表明，客户应在将该插件视为标准生产基础设施之前验证其行为、管理方式和可靠性。它并不能证明已实现广泛采用，也不能证明这些工作流能在所有 Salesforce 环境中节省时间。

不过，这一测试版带来了一个具体检验。销售人员如今可以将以 Claude 为中心的工作流，与打开 CRM 页面、调取报表和更新单个字段这一熟悉流程进行比较。

Salesforce 为何让 Claude 成为入口

Salesforce 正押注于：保留对企业数据和操作的控制权，比拥有每一个工作起始界面更重要。

该公司的公开解释异常直接。在其 Claudeforce 产品页面上，Salesforce 描述了从“软件即界面”转向“软件驱动多个界面”的变化。这一表述将传统应用界面视为一种选择，而非工作的永久中心。

对 Salesforce 而言，防御性风险显而易见。如果销售人员日益在 Claude、Slack 或其他 AI 助手中开始一天的工作，强迫他们返回独立的 CRM 界面会造成摩擦。能够广泛访问电子邮件、对话、文档和日历的助手，也可能比单独的 CRM 记录拥有更即时的工作上下文。

阻止这一转变，会给缺乏治理的集成留下空间。企业可能自行搭建连接器、使用通用自动化服务，或允许员工将客户数据复制到未受管理的对话中。

Claudeforce 为 Salesforce 提供了另一种定位。该公司可以在用户工作的任何位置开放受控数据和操作，同时保留其作为底层权威系统的角色。

这正是模型上下文协议（Model Context Protocol，MCP）进入架构的地方。MCP 是一项开放协议，使 AI 应用能够通过标准化接口连接外部工具和数据源。Salesforce 将 MCP 用作 Headless 360 的一部分；Headless 360 是其在不要求使用 Salesforce 用户界面的情况下提供平台能力的方法。

这一架构将推理与执行分开。Claude 解读请求、收集相关上下文，并提出响应或操作建议。Salesforce 提供记录、验证访问权限、应用业务逻辑并执行受支持的操作。

这种分工有利于 Anthropic，因为 Claude 获得了有用的企业上下文；也有利于 Salesforce，因为即使由另一款产品掌控对话，其数据模型和治理的价值仍可延续。

这一合作也双向运行。Claude 在 Agentforce 中充当推理模型，并支持 Salesforce 的部分 Slack 战略。Salesforce 表示，Claude 是多项内部和面向客户体验的默认模型，而 Anthropic 则将 Salesforce 用作其首选 CRM。

因此，两家公司在基础设施层面是合作伙伴，尽管其界面存在重叠。Salesforce 希望客户使用 Agentforce、Slack 及其自有应用；Anthropic 则希望 Claude 成为知识工作者跨这些系统协调任务的场所。

这种张力并不使合作关系自相矛盾。它反映了企业软件正在发生的变化。一个平台可以提供记录和控制，同时多种助手竞争成为日常工作空间。

对买方而言，重要的问题不是 Salesforce 是否会消失，而是 Salesforce 应用是否仍会是销售人员解读和处理 CRM 信息的默认场所。

对话式 CRM 必须胜过的不只是菜单导航

只有当对话能够比既有 CRM 视图、报表和工作流更快地产生可靠决策时，该插件才会成功。

最明确的使用场景发生在销售通话之前。销售代表可要求 Claude 生成一份简报，汇集近期账户活动、未结商机、联系人、过往对话和未解决问题。该响应可将分散的记录转化为一份聚焦的准备文档。

这一工作流有利于对话式界面，因为销售人员的问题很少对应某一个屏幕。准备续约可能需要商机历史、支持工单、决策者、产品使用情况和近期往来信息。

销售管道审查带来了更严苛的测试。经理可以询问哪些商机将在某个期间内成交、哪些缺少近期活动，以及哪些交易变更了阶段。Claude 可以汇总结果，并展示为该问题生成的仪表板。

传统报表仍然具有可预测性和可重复性。它们也提供可供团队检查的固定定义。当 Claude 将自然语言请求转化为销售管道分析时，必须保留这些定义。

“停滞交易”这样的表述说明了问题所在。一个组织可能将其定义为 14 天没有活动；另一个组织可能以缺少后续步骤、预计成交日期未变，或多种因素的组合来定义。Claude 需要采用公司的实际逻辑，而非看似合理的解释。

同样的问题也适用于预测。对话式摘要可以解释许多记录中的变化，但其效用取决于一致的源数据。缺失的联系人、过时的阶段和不完整的笔记，不会因为 AI 围绕它们生成流畅文字就变得准确。

Claude Salesforce 插件通过将请求锚定于实时 Salesforce 数据，并经由 Salesforce 路由受支持操作，解决了这一问题的一部分。在检索和执行过程中，现有权限和业务规则仍然有效。

锚定是指将模型响应连接到指定的组织数据源。它减少了对模型通用训练的依赖，但并不保证每项结论都正确。

用户仍需区分检索到的事实与 Claude 的解读。记录的预计成交日期是来自 Salesforce 的事实；一项交易看似存在风险的说法，则是取决于现有证据和插件流程的评估。

这使维护良好的客户数据变得更有价值，而非更不重要。对话式访问能够迅速暴露缺口，因为用户提出的问题比固定报表所能回答的更广泛。当数据质量较弱时，它也可能更快地传播错误解读。

评估该测试版的企业应从范围狭窄、可观察的任务开始。与开放式地要求运行整个销售流程相比，账户简报、商机摘要和销售管道检查能提供更清晰的比较。

企业应衡量该插件是否能检索正确记录、遵守字段定义、识别缺失上下文，并向用户展示结论来源。如果审查者必须手动重构每个答案，节省的时间几乎没有价值。

这种评估还需要真实的组织复杂性。一个干净的演示环境无法代表多年来积累的自定义对象、重复记录、例外情况和区域规则。这些细节决定了对话式 CRM 在最初的新鲜感消退后是否仍然有用。

权限有所帮助，但写入路径仍不明确

核心风险并不在于 Claude 能否读取 CRM 数据，而在于当对话转化为操作时，组织能否预测并控制会发生什么。

Anthropic 表示，该集成在既有 Salesforce 权限下运行。用户应只能查看与其在 Salesforce 内获得授权的同一身份可访问的记录和字段。

Salesforce 也表示，操作会经过其业务规则。这一设计十分重要，因为查看记录的权限并不会自动赋予修改每个字段或启动每个工作流的权限。

两家公司称，对于拟议的 CRM 变更，人工审批是默认机制。销售人员可能要求 Claude 调整预计成交日期或商机阶段，审查拟议编辑内容，并在 Salesforce 接收更新前予以批准。

不过，公开文档并未呈现完全一致的说法。Anthropic 的发布材料描述了记录更新功能，而一份 Salesforce 发布说明则将其 beta 功能描述为只读。

这些表述可能反映了不同的推出阶段、配置、产品或文档更新时间。但它们仍给管理员带来一个实际问题：其特定 beta 环境究竟启用了哪些写入功能？

组织应直接核实这一答案，而不应假定所有宣传的工作流都已可用。他们还应确定哪些操作需要确认、哪些字段可以更改，以及审计记录会显示在哪里。

身份验证并不能取代运营控制。员工可能拥有合法访问权限，却仍可能提出错误请求。Claude 也可能误解含糊的指令，而并未绕过任何权限边界。

例如，有人请求“把续约推到下个月”。这句话可能指成交日期、计费里程碑、预测周期或提醒事项。安全的工作流应在执行前显示拟修改字段、旧值、新值以及受影响的记录。

批量操作会进一步提高风险。经明确审查后更新一条商机记录，与依据生成的分类结果更改数十条记录，性质截然不同。管理员需要了解事务限制、错误处理、可逆性以及审批行为。

数据路径同样值得严格审查。Salesforce 表示该集成遵循既有控制机制，其 Claudeforce 材料也宣传支持的 Claude 模型实行零数据保留。买方应针对自身部署确认合同细节、区域处理、日志记录和保留要求。

接入的数据源会扩大审查范围。一份有用的客户简报可以结合 Salesforce、Slack、电子邮件、会议转录和文档。每一种连接都会引入独立的权限、保留政策，以及潜在的数据质量差异。

对于连接工具的助手而言，提示词注入也是另一项隐患。恶意或误导性的指令可能出现在模型读取的文档、消息或外部内容中。企业团队需要在不受信任的源文本与经授权的运营指令之间设置边界。

两家公司均未公布独立证据，证明该 beta 已消除这些风险。更负责任的表述应更为谨慎：该集成将既有 Salesforce 治理机制作为其控制层的一部分。

这种做法比向通用聊天机器人授予不受限制的 CRM 凭据更可靠。但其有效性仍取决于配置、准确的身份映射、清晰的确认界面，以及在真实工作流中的可靠执行。

Beta 客户应记录 Claude 能够读取、推断、建议和执行的内容。这四类能力并不能互相替代，将其视为同一种能力会掩盖最关键的控制问题。

Agentforce 面临的是界面问题，而非简单的模型之争

当 Claude 已能基于相同的受治理数据进行推理时，Salesforce 必须说明客户为何仍需要其自有的智能体体验。

Agentforce 仍是 Salesforce AI 战略的核心组成部分。它提供用于构建和部署智能体的工具，这些智能体可连接 Salesforce 数据、工作流和客户渠道。

Claude 集成并不会取代该产品。Salesforce 可以在 Agentforce 内使用 Claude 作为推理模型，而 Agentforce 则提供部署控制和面向具体应用的编排能力。

然而，Salesforce in Claude 改变了买方的比较方式。他们可以思考：一项任务究竟需要专门构建的 Salesforce 智能体、Claude 插件、在 Lightning 中工作的员工，还是三者的某种组合。

对于内部知识工作，Claude 具备界面优势。员工可以在一次对话中结合 CRM 信息、写作、分析、研究、文档以及已连接的工作场所数据源。

对于面向客户的自动化，Agentforce 则可以承担不同角色。企业可能需要一个嵌入支持渠道、受服务流程治理、可集中监控并与 Salesforce 运营体系集成的智能体。

这条边界并不总会保持清晰。Claude 可以调用工具并完成多步骤任务；Agentforce 可以使用 Claude 进行推理。因此，两种产品都可参与分析上下文并采取行动的工作流。

这种重叠将差异化竞争转向控制、分发和任务设计。胜出的系统未必拥有最强大的模型，而是能够在为用户提供足够上下文的同时，让操作保持可理解、可治理的系统。

Microsoft 和 OpenAI 带来了更广泛的竞争压力。它们的企业助手同样试图成为跨应用工作空间，并由生产力套件、连接器和智能体框架提供支持。Salesforce 不能假定其自有界面仍会是所有 CRM 任务的起点。

Salesforce 的回应，是让其平台能够从多个 AI 环境中使用。该公司正在保护界面之下的价值：客户记录、数据关系、工作流逻辑、权限和行业配置。

这一策略带来取舍。Salesforce 在 Salesforce 之外越强大，部分用户就越不需要打开其主应用。即使 Salesforce 依旧不可或缺，使用行为也可能转向 Claude。

反过来，若拒绝第三方界面，客户围绕 Salesforce 构建其他方案的风险将增加。该公司或许能保留自己的屏幕，却可能失去对新兴智能体层的影响力。

Anthropic 同样面临依赖关系。当 Claude 能够访问可信系统时，其企业价值会提升；但 Anthropic 不控制客户 CRM 数据的准确性或结构。它还依赖 Salesforce 提供可靠操作并执行规则。

因此，这项合作在划分职责的同时，并未消除竞争。Anthropic 提供推理界面，Salesforce 提供受治理的业务底层体系。两家公司都希望影响客户如何设计完整工作流。

企业买方不应将此简单视为模型基准测试。若权限失效、记录缺乏上下文，或助手无法完成相关操作，推理质量上的微小差异就不那么重要了。

真正的评估应覆盖完整任务流程。团队应测试初始请求、源数据检索、推理、拟议操作、审批步骤、Salesforce 执行以及最终审计轨迹。

这一过程将揭示 Claude Salesforce 插件究竟是一个运营界面，还是主要只是便捷的摘要层。

三个信号将显示该 Beta 是否改变销售工作

下一阶段取决于写入控制、复杂组织内部的采用情况，以及向初始销售工作流之外的扩展。

第一个信号是围绕操作功能的文档趋于一致。Anthropic 和 Salesforce 需要明确说明哪些 beta 配置支持读取、拟议更新、直接执行或批量更改。

如果两家公司发布一致的能力矩阵和细粒度的管理控制，生产环境使用的信心将增强。产品页面与发布说明之间若持续存在分歧，插件就会更接近评估工具。

第二个信号来自拥有成熟 Salesforce 环境的客户证据。Salesforce 表示，包括 Deloitte、GitLab 和 Legora 在内的组织参与了试点活动。有价值的证据应说明任务完成情况、错误率、审查要求以及数据治理结果。

关于准备工作更快的个例可以识别出有前景的工作流，但无法证明可重复的价值。买方需要知道，该插件能否适用于自定义字段、复杂角色、区域团队和不完美的记录。

如果有证据显示团队在试点后持续使用 Claude，将支持界面转移这一判断。大量人工核验或部署范围狭窄，则表明既有报告和 Salesforce 界面对于关键决策仍不可或缺。

第三个信号是承诺中超出销售领域的扩展。Salesforce 已将服务、营销、商业、收入、Tableau、MuleSoft、行业工作流及其他平台领域列为未来方向。

这些新增功能将使 Claudeforce 从销售插件转变为更广泛的界面战略。延迟推出或严格受限的发布，则表明受治理的对话式操作仍比发布愿景所暗示的更困难。

9 月的 beta 已经确立了一个重要事实：Salesforce 愿意让 Claude 成为员工直接处理客户信息的场所。尚未解决的问题是，有多少工作能够安全地转移到这里。

对于销售负责人而言，实际的下一步是开展受控比较。选择若干重复性任务，记录其当前耗时和错误模式，并使用相同的记录和权限角色测试该插件。

既要纳入常规记录，也要纳入混乱复杂的记录。测试含糊请求、缺失字段、受限账户、存在争议的预测以及拟议更新。审查 Claude 的表述、Salesforce 允许的操作，以及审计轨迹记录的内容。

知识工作者也应检视其余上下文是否准备就绪。CRM 数据与可靠的笔记、文档和对话连接后会更有价值。在增加更多自动化之前，结构化的销售知识工作流可以帮助团队整理这些周边上下文。

Claude Salesforce 插件并不证明 CRM 界面已经消失。它是一项实时测试：在受治理系统仍然存在的情况下，界面能否迁移。在接下来的几个月里，应关注用户信任 Claude 去更改什么，而不只是他们要求它总结什么。