AI PM 面试精华：CRM 销售助手的上下文、写入与指标怎么答
本期用 AI 销售助手做主案例，拆解客户上下文、权限分级、建议核验、CRM 写入和业务指标，让你把「设计一个销售 Copilot」讲成可控、可落地的产品方案。
先把题目收窄
面试题可以这样问：
请你设计一个 AI 销售助手，帮助 B2B 销售代表更好地跟进商机。
这道题不要一上来回答「做一个能自动成交的 Agent」。先把用户和任务定清楚：用户是负责多个商机的销售代表，当前最费时间的环节是会前准备、会后整理和下一封跟进邮件；产品目标是减少准备和录入时间，同时让 CRM 里的关键信息保持可追溯。
AI 产品经理面试通常会追问 AI 是否适合这个问题、如何定义成功指标、模型出错时怎么发布，以及模型指标和产品结果如何区分。1
因此，比较稳的 MVP 是三个动作：
- 根据当前商机生成会前摘要和待确认问题。
- 根据已验证的客户上下文生成跟进邮件草稿。
- 把销售确认过的结果整理成 CRM 更新建议。
自动发送邮件、自动改变商机阶段、自动承诺交付时间，先不放进 MVP。它们一旦出错，影响的是客户关系和业务记录，不只是一次回答的好坏。
一套能落地的回答主线
可以这样开场：
我会把产品定位成「销售的准备和记录助手」，而不是自动替销售做决定。第一阶段只读 CRM 和用户有权限访问的资料，输出带来源的摘要、跟进草稿和待确认的 CRM 更新；涉及对外发送、商机阶段变化、报价或承诺时，必须由销售确认。上线评估同时看事实准确性、节省时间、建议采纳率和错误写入率。
1. 上下文要有边界，不是接得越多越聪明
销售助手最容易犯的错，是把客户的所有邮件、会议、文档都塞给模型。这样既增加成本，也让旧信息、无关信息和越权信息混在一起。
更好的做法是围绕一个明确的商机建立上下文包：当前账户和联系人、当前商机阶段、最近的客户沟通、最近一次会议记录、相关产品资料，以及销售提出问题时指定的时间范围。每条材料都显示来源、更新时间和访问权限。
微软 Dynamics 365 Sales 的摘要功能提供了一个很具体的参考：准备未来 24 小时内的会议时，系统会总结 stakeholder timeline 中最近 3 条 notes 和最近 1 封 email；对 SharePoint 文档的问答只会使用用户有权限访问的文件。2
面试里可以继续补一句：上下文策略要允许用户修正范围。例如销售问「这个客户为什么迟迟不签」，系统应先锁定当前商机和时间窗口；如果只有一封旧邮件或记录之间互相矛盾，就显示缺口，不要把猜测写成客户意图。
2. 把权限拆成五级，读和写不能混在一起
我会把能力分成五级：
| 层级 | AI 可以做什么 | 默认交互 |
|---|---|---|
| 读取 | 查看用户有权限的 CRM 记录和资料 | 自动执行 |
| 建议 | 提出下一步、风险点和待补字段 | 展示依据 |
| 草拟 | 生成邮件、会议纪要或 CRM 更新草稿 | 用户编辑 |
| 提议写入 | 生成待写入的字段变更 | 用户逐项确认 |
| 执行 | 发送邮件、改变阶段、创建报价或触发流程 | 明确确认后执行 |
这个分级要和既有系统权限一致。Microsoft Sales agent 的文档说明，它可以连接 Dynamics 365 Sales 或 Salesforce，把 CRM 洞察带到 Outlook 和 Teams，也支持邮件起草、跟进和下一步建议；使用前需要管理员和用户同意连接账号并共享数据，Dynamics 365 场景还要求相应的销售角色和权限。3
HubSpot Breeze Assistant 的文档也把「用户权限决定可执行操作」写得很清楚，相关动作包括创建记录、添加 note、生成数据可视化、创建销售邮件草稿和创建 workflow。4 这给面试回答一个提醒：动作越接近业务系统的真实写入，越应该单独设计权限、确认和审计，而不是把它们都包装成一个聊天按钮。
3. 每个建议都要能回到原始记录
销售不会因为模型语气自信就相信它。一个可用的回答应该包含验证闭环：
- 摘要旁边显示引用的 CRM 记录、邮件或文档，点击可以回到原文。
- 邮件草稿中的客户预算、上线时间、产品承诺，必须能逐句找到来源。
- 如果两条记录冲突，展示冲突，不替用户擅自合并。
- 如果客户、联系人或商机匹配不确定，先让销售选择对象。
- 写入前展示字段、旧值、新值和触发原因，支持逐项接受或撤销。
这里不要用一个看似精确的「置信度 92%」糊弄过去。对销售来说，「这句话来自哪封邮件」「这条记录是什么时候更新的」「还有哪些信息没有找到」通常比一个没有校准说明的分数更有用。
4. 指标要分模型质量、工作效率和业务结果
只报「使用率」不够。面试官想知道你能否判断 AI 到底帮了忙，还是只是让页面多了一个入口。
| 维度 | 可以观察的指标 | 主要回答什么问题 |
|---|---|---|
| 事实质量 | 关键字段准确率、引用覆盖率、错误实体匹配率、无来源断言率 | AI 说的话能不能核对 |
| 工作效率 | 会前准备耗时、会后录入耗时、草稿修改时长 | 是否真的减少重复劳动 |
| 建议质量 | 草稿采纳率、修改率、下一步建议完成率 | 建议是否能进入工作流 |
| CRM 质量 | 必填字段完整率、重复记录率、错误写入率、撤销率 | 系统记录有没有变得更可靠 |
| 业务结果 | 跟进及时率、qualified leads 数量、推进中的 opportunities 数量、客户回复率 | 产品是否改善销售流程 |
| 风险 | 越权读取、未经确认的写入、客户侧错误发送、权限变更后的延迟生效 | 上线后是否可控 |
Dynamics 365 的负责任 AI FAQ 也把 time saved、qualified leads 和 pursued opportunities 作为评估方向，同时提醒摘要质量依赖数据准确性、完整性、字段配置和知识源的新鲜度。2
回答时要把指标之间的关系说出来：草稿采纳率高，但错误写入率也高，不能算成功；会前时间减少了，但客户回复率下降，说明助手可能在追求速度时损害了沟通质量。模型离线评测和上线后的产品结果必须分开看。
5. 先设计失败时怎么停
这道题的加分点不在于承诺「几乎不会错」，而在于你知道错误发生后产品如何收住：
| 失败情况 | 产品行为 |
|---|---|
| CRM 记录过期或字段缺失 | 显示最后更新时间和缺失字段，提示销售补充，不生成确定结论 |
| 邮件与会议记录互相矛盾 | 同时列出两条来源，要求用户确认当前事实 |
| 无法确定对应账户或联系人 | 暂停生成写入动作，让用户选择对象 |
| 用户没有资料访问权限 | 明确说明无法读取，不通过其他数据源绕过权限 |
| 需要改变商机阶段、报价或对外发送 | 只生成预览，要求明确确认 |
| 来源无法支撑客户承诺 | 改写为待确认问题，禁止直接写成承诺 |
这样回答，面试官能听到四个产品判断：任务边界清楚，数据范围可解释，动作权限分级，失败有可恢复路径。
三个常见追问
「销售不想每次都点确认，能不能自动写入 CRM？」
可以优化确认成本，但不应该直接取消确认。对内部低风险字段，可以支持批量确认、撤销窗口和变更日志；对商机阶段、金额、报价、客户承诺等高影响字段，保留逐项确认。权限设计应按动作后果分级，而不是按 AI 是否看起来可靠分级。
「要不要让 AI 预测成交概率并自动排序？」
可以做辅助排序，但先说明它依赖什么数据、在哪些客户类型上有效，以及销售能否看到影响排序的主要因素。不要把预测概率当作销售判断的替代品，更不能用它自动淘汰商机。上线后要看分群校准、人工采纳、漏掉的高潜商机和不同销售团队之间的偏差。
「如何分阶段发布？」
第一阶段做只读摘要和资料引用，先验证上下文和事实质量；第二阶段加入邮件、会议纪要和 CRM 更新草稿，观察修改与采纳；第三阶段才考虑低风险的批量写入。对外发送、报价、折扣和商机阶段变更不作为默认自动化动作。
练习题
请你为一家 SaaS 公司设计一个 AI 销售助手，帮助销售跟进 100 个以上的商机。要求在 10 分钟内回答：
- 你选择哪个具体场景作为 MVP，为什么？
- 助手可以读取哪些数据，哪些动作必须确认？
- 如何让销售核对 AI 的摘要和建议？
- 你会同时看哪些模型指标、工作效率指标和业务指标？
- 当 CRM 数据过期、来源冲突或无法确认联系人时，产品怎么处理？
答题时先说清「减少哪一段重复劳动」，再说上下文和权限；最后用一个失败案例说明兜底。能把「AI 会做什么」和「AI 不能替用户做什么」同时讲明白，答案就从功能清单变成了产品方案。
Related content
- Sign in to comment.