Salesforce 在 2026 年 9 月 15 日的 Dreamforce 上发布 AIforce，提出把 Salesforce 的数据、业务逻辑与受控动作带到 Claude、Slack 等界面。其中 Salesforce in Claude 当时以 beta 形式开放，各入口需要分别核对使用资格和功能范围。多入口设计可以让员工从熟悉的界面发起工作，正式记录仍由业务系统维护。Salesforce 官方公告
对已经使用 CRM 的企业，讨论重点可以具体到“哪些工作需要打开完整系统，哪些工作适合在对话中完成”。以下设计方法适用于评估多入口需求，不代表任意 CRM 已具备相同产品能力。
可以拆出的常用工作
高频查询、拜访准备、活动记录整理和跟进任务创建，通常具有明确对象与结果。复杂批量维护、权限配置和经营规则调整，则可能仍需要完整管理页面。
| 工作 | 对话入口的作用 | 正式记录所在位置 |
|---|---|---|
| 拜访准备 | 汇总联系人、历史沟通和事项 | CRM 与资料库 |
| 活动记录 | 整理事实并生成记录草稿 | CRM 活动记录 |
| 跟进安排 | 提取动作、负责人和时间 | 待办或CRM任务 |
| 商机更新 | 展示拟修改字段供确认 | CRM 商机对象 |
入口的简化应减少查找和录入步骤，同时保留必要字段和业务规则。
同一对象的识别
不同入口必须使用稳定对象编号。聊天中的简称、联系人姓名和群名称可以帮助搜索，但不能直接替代企业、商机或订单编号。
示例：销售在手机对话中说“把这个项目改成已签约”，系统应先确认具体商机，并检查是否已经形成满足阶段规则的有效依据。不能仅依据聊天语句，把多个相似项目一起改动。
身份与规则的一致
员工从浏览器、移动端或团队聊天发起动作时，都应关联其真实身份和当前权限。不能因为入口换成 AI，就跳过原系统的字段校验、审批条件或数据范围。
服务账号可以承担技术连接，但业务授权应继续按请求者计算。管理员看到的数据与普通销售看到的数据不同，生成摘要也应遵守同样的边界。
写入与结果反馈
用户确认后，入口应提交明确的字段修改，并返回正式记录的编号和当前状态。若执行失败，应说明未完成部分，保留草稿供修正。
网络超时后，先查询原系统是否已经更新，再决定重试。多入口同时处理同一商机时，需要检查版本变化；后提交的动作不能不加判断地覆盖前一个入口的新内容。
逐步接入的业务依据
可从一个岗位的一组高频工作开始，比较原流程与新流程中实际减少的步骤。记录查找时间、人工补录和错误修正，使用同一任务样本核对收益。
正式验收应由员工完成完整业务过程，并从 CRM 回读结果。对话顺畅、页面好看只能说明入口体验，是否真正减少工作还要看记录质量与后续使用。
员工在一个入口更正记录后，应从另一个入口重新查询同一对象。若仍显示旧值，需要检查缓存和同步时点，并明确提示资料时间。把跨入口回读列为验收样本，才能发现单入口演示中看不到的状态差异。
相关设计可参考现有系统嵌入 AI 助手和面向 Agent 的事实源。业务系统定制可围绕现有 CRM 补齐必要接口与身份衔接。
