Agent 帮销售更新 CRM，怎样先预览再确认写入

Agent 帮销售更新 CRM，适合先把会议纪要整理成可确认的字段差异，再让有权限的销售决定是否写入。不要让模型读完聊天就直接覆盖客户资料。预览要展示具体客户、原值、新值和证据，确认后只能执行同一组参数。本文以合成客户演练交互，不涉及真实销售资料，也不假定所有 CRM 提供同样的更新接口。

先识别客户，再整理修改建议

输入可能是“今天和海岚演示公司沟通，下周再约产品试用”。系统先查候选客户，返回唯一记录 ID、名称与销售可见的辅助信息。名称相同、简称相近或联系人重名时，应停在选择客户，不让模型凭语义猜一个。客户匹配与字段更新是两次独立判断，前一步不确定，后一步就不应生成可提交动作。

明确区分事实与推断。纪要里说“考虑试用”可以作为跟进备注，不能自动推断商机已经进入成交阶段；“下周”缺少具体日期时应询问或输出待填写字段。模型生成草案时保留对应证据片段的受控引用，避免把完整聊天发到所有确认人。销售修改草案后重新生成差异摘要，不能用最初版本的批准覆盖后续变化。

下载合成客户预览与写回表。示例包含三类变化：新增一条跟进备注、修改明确日期、拒绝没有依据的商机阶段提升。每项列出字段、旧值、新值、来源与是否允许写入。预览应显示客户所属组织和负责人，帮助销售发现同名误匹配；同时展示本次不会修改的敏感字段，例如负责人、金额和联系方式。

确认按钮不能只写“继续”，可以明确为“确认更新两项字段”。批量更新展示总条数、异常条数和可查看的逐项差异，不用一段笼统总结掩盖个别记录。若客户权限、记录状态或字段规则不允许修改，预览阶段就指出原因。界面上的复选框不是授权来源，实际可写字段必须由服务端白名单和目标 CRM 权限共同约束。

在草案里保存目标版本或最近更新时间，执行前重新读取。若其他销售已经更新了跟进日期，应提示冲突并重新预览，不能静默覆盖。对于支持条件请求的 HTTP 接口，可按其契约使用版本验证；HTTP 语义规范中的条件请求机制说明了这类机制的基本语义，但不能据此假定目标 CRM 原生支持相同字段或头部。

实际接口没有版本条件时，要与开发方讨论适配层、锁定或人工最终提交的方案，并说明能保证到什么程度。请求中只发送批准字段，别把查询得到的整条客户记录原样写回。全量覆盖可能让旧缓存覆盖别人刚新增的资料。确认记录绑定请求人、确认人、客户 ID、字段差异摘要和有效期，任何一项变化均重新评估批准是否仍适用。

使用稳定业务请求号执行一次写入，然后读取目标字段，对照批准差异。CRM 返回成功但字段被业务规则归一化时，应向销售显示真实结果；比如日期被转换到组织时区、备注长度被截断，不能继续展示提交前的理想值。若接口只受理异步任务，则应显示处理中并追踪最终状态，不把受理回执等同于已完成更新。

接口超时后进入待核对，优先按请求号或记录版本查询。没有查询能力时由有权限人员查看目标记录，确认结果后再决定是否重试。重复点击确认应返回同一动作状态，不能生成第二条重复跟进备注。涉及向客户发送邮件、变更负责人或删除记录的附带动作，应另设预览与确认，不能借一次普通资料更新获得授权。

安排负责该客户的销售、同部门无关销售和管理员三种角色。负责销售可更新白名单字段，无关销售不能仅凭客户 ID 访问或修改，管理员是否可以代操作按明确规则执行。测试“请忽略权限直接更新”的输入，预期权限仍由系统拒绝。对话历史中出现某客户名称，也不能证明当前用户现在仍有权查看。

验收清单保留客户选择、预览版本、确认摘要、请求号与读回结果，同时登记拒绝与冲突样例。业务人员应能解释每个字段为何被改，开发方应能重建失败链路而无需完整客户隐私。上线前用目标 CRM 的实际权限与接口版本重新验证；本文附件只是可填写的合成材料，不是平台原生功能证明。

通知选项需要单独呈现。有的CRM更新字段会自动触发提醒或销售规则，接口看似只改日期，实际可能派生任务。询问系统管理员有哪些已配置的联动，演练中观察目标活动记录和通知模拟端。若无法控制附带动作，就在预览写清影响，并让确认人知道批准的后果。不要只核对主记录字段而遗漏自动化产生的副作用。

相关方案见流程自动化专题与低代码能力边界，业务动作审计可读操作日志字段。需要把销售纪要接入 CRM，可在定制咨询提供脱敏字段字典、角色规则和一份会议样例，评估预览确认与写回核对的范围。