Case Study 03 — AI Sales Assistant（AI 销售助理）

知识库位置：FDE Knowledge Base/06 Case Studies/03-AI-Sales-Assistant.md

Case Metadata（案例元数据）

Case ID: CS-003

Industry（行业）:
B2B（企业对企业）

Primary Domain（主要领域）:
Sales（销售）

Case Type（案例类型）:
Reference Scenario（参考情景）

Complexity（复杂度）:
Medium（中）

Primary Technologies（主要技术）:
CRM API（客户关系管理接口）
RAG（检索增强生成）
LLM Synthesis（大语言模型综合）
Model Routing（模型路由）

Business Function（业务职能）:
Sales（销售）

Delivery Stage（交付阶段）:
End-to-End（端到端）

Status: Core
Version: v0.1

本案例为 Reference Scenario（参考情景）：用于教学和方法论说明的综合案例，并非某个真实客户项目。参见 Case Studies README（案例域使用说明）。

1. Customer Background（客户背景）

客户是一家 B2B（Business to Business，企业对企业）企业。

销售人员需要：

研究客户
阅读历史邮件
查看 CRM（Customer Relationship Management，客户关系管理系统）
准备会议
写 Follow-up（跟进沟通）
更新 CRM
搜索产品资料

2. Business Problem（业务问题）

最初需求：

给销售团队做一个 AI Copilot（AI 智能副手）。

Discovery（客户调研）后发现销售每天大量时间花在：

Information Gathering（信息收集）
+
CRM Updates（CRM 更新）
+
Meeting Preparation（会议准备）
+
Follow-up Writing（跟进邮件撰写）

真正目标：

降低销售非销售活动所占时间。

3. Discovery（客户调研）

访谈：

Sales Rep（销售代表）
Sales Manager（销售经理）
RevOps（Revenue Operations，收入运营）
Marketing（市场）
CRM Admin（CRM 管理员）

分析完整 Workflow（工作流）：

Lead（线索）
↓
Research（客户调研）
↓
Qualification（资格认定）
↓
Meeting（会议）
↓
Follow-up（跟进）
↓
Opportunity Update（商机更新）
↓
Next Action（下一步行动）

4. Scoping（范围界定）

第一阶段选三个场景：

Pre-meeting Brief（会前简报）
Meeting Summary（会议纪要摘要）
CRM Update Suggestion（CRM 更新建议）

暂不自动：

修改机会金额
修改 Forecast（销售预测）
发送邮件
创建合同

5. Architecture Design（架构设计）

Sales Rep（销售代表）
↓
Sales Assistant（销售助理）
├─ CRM API（CRM 接口）
├─ Email / Calendar Context（邮件 / 日历上下文）
├─ Product Knowledge RAG（产品知识检索增强生成）
└─ Meeting Transcript（会议转录）
↓
LLM（大语言模型）
↓
Structured Sales Brief（结构化销售简报）

6. Engineering Implementation（工程实现）

Pre-meeting Brief（会前简报）：

Account（客户账户）
↓
CRM Data（CRM 数据）
↓
Recent Activities（近期活动）
↓
Relevant Product Knowledge（相关产品知识）
↓
LLM Synthesis（大语言模型综合）
↓
Structured Brief（结构化简报）

输出 Schema（结构定义）：

Account Summary（客户概要）
Key Contacts（关键联系人）
Open Opportunities（进行中的商机）
Recent Interactions（近期互动）
Potential Risks（潜在风险）
Suggested Questions（建议提问）

Key Decision（关键决策）：结构化数据与非结构化知识分别处理

CRM 数据：

Direct API（直接接口调用）

产品知识：

RAG（检索增强生成）

原因：

CRM 是实时结构化数据。

Product Docs（产品文档）是非结构化知识。

采用 Hybrid Architecture（混合架构）。

7. Prototype（原型）

最初 Prototype（原型）把：

CRM
Emails（邮件）
Meeting Transcript（会议转录）
Product Docs（产品文档）

全部塞入一个大 Prompt（提示词）。

问题：

Token Cost（词元成本）高
Latency（延迟）高
信息重复
输出不稳定

Fix（修复）

改为：

Retrieve（检索）
↓
Filter（过滤）
↓
Structured Summaries（结构化摘要）
↓
Final Synthesis（最终综合）

并对 CRM 使用明确字段。

8. Pilot（试点）

20 名销售参与。

Pilot（试点）发现：

有些 AI 建议的问题看起来不错，但实际对当前 Deal（商机）没什么帮助。

于是评估体系从：

"答案看起来不错吗？"（Does the answer look good?）

升级成：

Was the brief useful for the meeting?（简报对会议真的有用吗？）
Did seller use the suggested question?（销售是否用上了建议提问？）
Did preparation time decrease?（准备时间是否下降？）

9. Production（生产）

增加：

SSO（Single Sign-On，单点登录）
CRM User-context Permission（CRM 用户级权限）
Prompt Versioning（提示词版本管理）
Cost Tracking（成本追踪）
Feedback（用户反馈）
Model Routing（模型路由）

简单摘要使用较小模型。

复杂 Deal Analysis（商机分析）使用较强模型。

关联：Decision Guide：Small Model vs Large Model（小模型 vs 大模型）

10. Business Outcome（业务结果）

主要指标：

Meeting Prep Time（会议准备时长）
CRM Update Completion（CRM 更新完成率）
Seller Adoption（销售采用率）
Time Spent on Administration（行政事务耗时）
Opportunity Data Completeness（商机数据完整度）

长期才考虑：

Conversion Rate（转化率）
Deal Velocity（商机流转速度）

避免过早把收入变化全部归因于 AI。

11. Challenges（挑战）

12. Key Decisions（关键决策）

Decision（决策）	Options（选项）	Choice（选择）	Why（原因）
CRM 数据接入	RAG vs Direct API	Direct API	CRM 是实时结构化数据
产品知识接入	Direct API vs RAG	RAG	产品文档是非结构化知识
上下文组织	全部塞入 Prompt vs 分层摘要	Retrieve → Filter → Summaries → Synthesis	降低成本与延迟、输出更稳定
模型选择	单一模型 vs 模型路由	Model Routing	简单任务用小模型、复杂分析用强模型

13. Reusable Lessons（可复用经验）

Copilot（智能副手）的核心不是 Chat UI（聊天界面），而是 Workflow Integration（工作流集成）。
Structured Data（结构化数据）应优先走 API。
非结构化知识适合 RAG（检索增强生成）。
不要把所有 Context（上下文）直接塞给模型。
衡量「用户是否真正因此更高效」比模型质量评分更重要。
Sales AI（销售 AI）的价值归因需要谨慎。