销售拜访录音可以自动写进 CRM，但正确做法不是“转成文字后整段粘贴”。应让 Agent 先识别客户和商机，再抽取事实、对照 CRM 现值、拦截冲突字段，等销售确认后写回，最后独立回读。适合已有 CRM、客户与商机对象较清楚的团队；如果录音采集边界未明确、客户档案长期重复，先别自动写。
一条可靠的落库链要走完八步
- 触发：拜访结束或销售主动提交录音，同时带上日程、客户 ID、商机 ID 和参与人。
- 转写：生成带时间位置的文本，保留原录音引用，方便复核上下文。
- 绑定对象：按客户编码、联系人、日程和当前负责人匹配 CRM，不只靠公司简称猜测。
- 抽取事实：识别客户问题、当前阶段、决策角色、预算线索、竞品、下一步和日期。
- 冲突校验：把抽取结果与 CRM、有效报价、合同和现行规则逐字段比较。
- 人工确认：向销售展示“新增、修改、存疑、不写”四组内容，关键变化由主管复核。
- 写回：分别写入跟进记录、联系人、商机字段和待办，而不是塞进一段无法统计的备注。
- 终态回读：重新查询这些对象，核对实际值、记录 ID、负责人、截止日和审计来源。
如果团队连客户、商机、跟进记录分别由哪个系统负责都说不清，可以先读什么是 CRM；通用落地顺序则可对照销售 AI 助手指南。
哪些字段能写，哪些必须停下来
| 信息类型 | Agent 动作 | 人审要求 | 最终写到哪里 |
|---|---|---|---|
| 拜访时间、地点、已确认参与人 | 生成结构化草稿 | 销售快速确认 | 跟进记录 |
| 客户明确提出的问题与下一步 | 附原文位置和责任人 | 销售确认 | 跟进结果、待办 |
| 新联系人或决策角色 | 与现有联系人去重 | 销售确认身份 | 联系人对象 |
| 金额、折扣、交期与对外承诺 | 与报价、合同和现值对照 | 冲突时必须复核 | 商机字段或待核事项 |
| “可能、好像、记不清”等存疑表达 | 不转成事实 | 生成核实待办 | 不覆盖正式字段 |
| 商机阶段、赢率等经营判断 | 给出证据与建议 | 主管按规则确认 | 商机对象 |
最危险的错误，是把“客户提到某个金额”直接改成“商机金额”，或者把“销售准备下周答复”写成“已经对客户承诺”。Agent 要做的是保留证据、暴露冲突，不是替人消灭不确定性。
角色、事实源和规则要先定清
销售是本次拜访事实的确认人，销售主管负责关键商机变化，CRM 管理员维护字段与去重规则，IT 负责连接、权限和日志。Agent 只在发起人原本有权访问的客户范围内工作，不能因“自动整理”扩大数据权限。
事实源也要分层：录音证明“现场说过什么”；CRM 保存客户、联系人、商机和正式跟进；报价、合同证明已批准的金额与条款；知识库只提供现行销售规则。录音不能反向覆盖合同，历史聊天也不能代替当前 CRM 状态。
录音留存、转写范围和访问权限，应按企业制度和适用规则明确告知。若不能保存原音，可只留受控文本和必要证据位置，但仍要能让确认人知道结论从哪里来。
写回协议要比提示词更具体
上线前最好把每个目标字段做成一张协议表：字段名称、目标对象、允许来源、冲突处理、确认角色、是否允许为空、写入接口和回读条件。例如“下次行动日期”只能来自客户明确约定或销售确认；“商机金额”还要与有效报价核对；“客户关注点”可以保留为跟进摘要，但不能因此自动修改商机阶段。
每次执行还应保存来源证据、提取文本、原值、建议值、确认结果和写入对象。这样销售发现纪要有误时，可以纠正单个字段，而不是删掉整篇记录重填。管理员也能区分问题到底来自转写、对象匹配、抽取规则还是接口写入，后续优化才有依据。
建议先挑一个拜访类型试运行，限定一组销售和少量字段。连续检查对象绑定正确率、存疑拦截、确认修改、重复写入和回读不一致，再决定是否增加联系人、商机阶段等高影响字段。自动化范围应随着证据增加，而不是随着演示效果扩大。
销售拒绝本次建议时，也应记录是转写错误、客户对象不对、字段规则不合适还是业务事实尚未确认。这些原因会成为下一轮优化依据，比只统计“确认率”更有用。
验收看终态，不看纪要写得像不像
“纪要已生成”“已创建待办”“接口调用成功”都只是过程。真正的终态是：CRM 中出现了可查询的跟进记录；经确认的联系人或商机字段与预期一致；存疑信息没有覆盖正式值；下一步有负责人和日期；每次写入能追溯到录音、确认人和执行记录。
上线前至少覆盖正常录音、对象匹配失败、金额冲突、无权客户、重复提交和写入超时。完整检查方法可参考AI Agent 项目验收清单。如果希望从岗位视角继续拆解，可看销售岗位 Agent 场景；要把录音、CRM 与其他系统串成可执行流程，可从企业 AI 落地工程开始。
