Gemini Live 让语音 Agent 更自然：销售通话后什么该进 CRM？

实时交谈越顺畅，事后核对越不能省

Google 在 2026 年 9 月 15 日推出 Gemini 3.8 Live 系列，强调实时对话、多步推理与工具调用；同日的开发者说明面向语音应用构建者。Google 对企业渠道仍使用 private preview 等不同可用性表述。

技术进展容易让销售团队想象一个流程：AI 听完客户电话，自动总结并写入 CRM。但通话里有试探、玩笑、转述、条件句和临时想法。“客户说过”与“双方确认”可能只差半句话。把语音整理得漂亮，不等于把事实分对了层。

通话结束后的四层记录

原始证据层。 录音、经授权的转写、会议笔记及附件，保留时间、参会者和来源。若没有原始资料，就如实标“人工回忆”，不要伪造逐字引文。

单次事件层。 本次谁提出了什么、我方如何回应、下一步约定为何。这些属于带日期的 activity。对“客户计划付款”“可能采购”等说法，保留原话中的不确定性。

稳定画像层。 公司主体、长期经营领域、固定联系人等相对稳定事实，经过核实才进入 profile。一次电话里提到“我们也可能做欧洲市场”，通常不应改写为“该客户主营欧洲市场”。

可复用知识层。 产品适用条件、常见问题或新异议模式，须脱离客户隐私并经过产品或业务 owner 复核，才可能成为通用知识。单个客户的折扣和付款安排始终是客户私有事实。

这四层先分清，AI 写入才有边界。另见CRM 数据卫生指南。

一个合成通话的写入判断

假设「示例客户 A 公司」在电话里说：“如果样料测试通过，我们可能在十月下单两台；付款条件还要财务确认。”合格的 activity 应写成“客户提出有条件的采购意向；样料测试与付款条件待确认”。它不应成为“十月确认采购两台”的画像事实，更不应自动推动预测收入。

如果我方工程师当场确认某配置的适用范围，也要留下具体型号、条件与确认人。客户提出的适用猜想与工程师确认的参数应分列。若有人在通话里引用旧报价，写入时还要标记报价版本和有效期。

从语音到 CRM 的六步流程

1. 核对录音或笔记是否有收集与使用权限；
2. 用公司名加邮箱、电话等硬标识匹配唯一客户；
3. 把金额、型号、交期、付款、安装、服务与渠道冲突逐项提取或明确“未涉及”；
4. 标注每项是客户提出、我方确认、历史记录还是待澄清；
5. 先生成候选 activity 和下一步行动，由销售审核；
6. 写入后按记录 ID 读回，检查客户、时间与正文。

KnowSales 的客户 profile、activity 和客户跟进看板可承接整理后的销售记录；本文没有声称 KnowSales 已内建 Gemini Live、实时录音或自动转写。语音工具负责产生候选证据，CRM 负责长期保存获核事实。

管理者该看哪些指标

不要只看“自动生成纪要数量”。更有意义的是：身份匹配错误率、关键商业字段漏项率、待确认项被误写成已确认的比例、写后读回成功率，以及销售实际采用或修改建议的比例。先抽查小样本，尤其是金额、交期和产品适配；质量稳定后再扩大范围。

常见问题

AI 转写能直接作为客户承诺吗？

不能。转写可能识别错人或遗漏条件句，关键承诺要对照原始证据与人工确认。

一次通话里的新信息都要更新 profile 吗？

不用。大多数通话内容是一次性事件，先进入 activity；稳定背景经核实后再更新 profile。

客户说“可能下单”应怎样记录？

保留条件和不确定性，写成有条件的意向，并列出未完成的测试、审批或付款确认。

可以用什么标准验收自动写入？

可用12 项销售 Agent 业务门禁检查身份、来源、权限、确认和读回。

先选三通已获授权且客户身份明确的历史通话，人工对照 AI 候选记录，再考虑把流程连接到KnowSales 客户工作台。