用户场景: AI Case Management System
用户场景文档 — 覆盖核心工作流、Agent 协作和异常处理
用户场景文档
AI Case Management System
版本: 2.1 日期: 2026-02-22 目标读者: 产品、设计、开发团队 更新说明: 基于产品评审新增3个关键场景（Agent入职培训、峰值流量管理、质量保证）
产品定位
我们是什么
一句话: 一个 AI 驱动的 Case 工作流管理系统，专注于工单的创建、流转、执行，通过 API 与各种外部系统协作。
我们不是什么
- ❌ 不是 Contact Center: 不做呼叫、聊天窗口、语音识别
- ❌ 不是 CRM: 不存储客户主数据
- ❌ 不直接接触终端客户: 通过 API 与 Contact Center 等系统协作
核心价值
Case = 数据定义 (Schema) + 工作流 (Workflow)
- Schema: 定义这类 Case 需要收集哪些数据
- Workflow: 定义 Case 如何流转、谁处理、什么自动化
AI 的角色: 不是"建议"，而是驱动——AI 做判断和生成，人做执行和审批。
AI 能力边界（重要）
设计原则：基于下限，非幻想
AI 在这个系统中的设计基于实际能力下限，而非理想状态：
- AI 可能识别错误 → 每个 AI 判断都需要人确认
- AI 可能低置信度 → 低于阈值时自动 Escalation
- AI 可能失败 → 系统有降级策略，不影响核心流程
架构原则
更强的 AI 只会裨益，不会冲击
- 更强的 AI 只能辅助，不会覆盖人的决策
- 可插拔的 AI 引擎（GPT-4 → GPT-5 无需改架构）
- 明确的 Escalation Path：AI → 人 → 主管
Verification Flow（关键）
每个 AI 参与的流程都是：
AI 提取/判断 → 人确认 → 执行
↓ ↓
置信度 可驳回
检查 修改
- AI 建议 → AI 解释推理 → 人批准 → 执行
- AI 识别错误 → 人可纠正 → 反馈给 AI 学习
系统边界
┌────────────────────────────────────────────────────────────────┐ │ 外部系统 │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │Contact Center│ │ CRM │ │ Jira等 │ │ │ │(Zoom, Five9) │ │ (Salesforce) │ │ 工作流系统 │ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ └─────────┼─────────────────┼─────────────────┼──────────────────┘ │ │ │ │ Transcript │ 客户信息查询 │ 状态同步 │ 会话事件 │ (只读) │ (双向) ▼ ▼ ▼ ┌────────────────────────────────────────────────────────────────┐ │ 我们的系统 │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ API 层 │ │ │ │ /intake /cases /workflows /suggestions /webhooks │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ │ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ │ │ AI 引擎 │ │ Case 管理 │ │ 工作流引擎 │ │ │ │ - 意图识别 │ │ - 创建/更新 │ │ - 状态流转 │ │ │ │ - 信息提取 │ │ - Schema定义 │ │ - 自动化规则 │ │ │ │ - 问题生成 │ │ - 数据验证 │ │ - 人工节点 │ │ │ │ - 回复建议 │ │ - 历史记录 │ │ - 外部触发 │ │ │ └───────────────┘ └───────────────┘ └───────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Web UI │ │ │ │ 人工客服工作台 | Supervisor 仪表板 | 配置管理 │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └────────────────────────────────────────────────────────────────┘
核心场景
场景 1: 从通话中创建 Case
背景
客服 Agent 正在使用 Zoom Contact Center 接听客户电话。Contact Center 与我们的系统已集成。
流程
Step 1: Contact Center 推送 Transcript
客户说: "我上周买的耳机有杂音，想退货"
Contact Center 调用我们的 API:
POST /api/intake
{
"source": "voice",
"channel": "zoom_contact_center",
"transcript": "我上周买的耳机有杂音，想退货",
"session_id": "call_12345",
"human_agent_id": "agent_001",
"customer_id": "cust_789"
}
**Step 2: AI 分析并响应**
我们的系统处理:
1. **意图识别**: "退货请求" (置信度 92%)
2. **信息提取**:
- 产品类型: 耳机
- 问题描述: 杂音
- 购买时间: 上周（约7天前）
3. **Case Type 匹配**: "退货申请"
4. **Schema 检查**: 退货申请需要 order_id、退货原因、期望处理方式
5. **数据缺口**: order_id 缺失
返回给 Contact Center:
```json
\{
"case_id": "case_001",
"case_type": "return_request",
"extracted_data": \{
"product_type": "耳机",
"issue": "杂音",
"purchase_timeframe": "约7天前"
\},
"missing_fields": [
\{
"field": "order_id",
"required": true,
"suggested_question": "请问您的订单号是多少？可以在购买确认邮件中找到。"
\},
\{
"field": "return_preference",
"required": true,
"suggested_question": "您希望退款还是换货？",
"options": ["退款", "换货"]
\}
],
"agent_guidance": "客户购买约7天，在7天无理由退货期内，可直接批准退货。"
\}
**Step 3: Contact Center 展示给 Agent**
在 Zoom Contact Center 界面，Agent 看到一个嵌入的卡片:
┌──────────────────────────────────────────────────────┐
│ 📋 Case #001 - 退货申请 [新建] │
├──────────────────────────────────────────────────────┤
│ 已识别信息: │
│ • 产品: 耳机 │
│ • 问题: 杂音 │
│ • 购买时间: 约7天前 │
│ │
│ 💡 提示: 客户在7天无理由退货期内 │
├──────────────────────────────────────────────────────┤
│ 请询问客户: │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ 请问您的订单号是多少？可以在购买确认邮件中找到。 │ │
│ │ [一键发送] [复制文本] │ │
│ └────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ 您希望退款还是换货？ │ │
│ │ ○ 退款 ○ 换货 [一键发送] [复制文本] │ │
│ └────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘
**Step 4: Agent 操作，数据回流**
Agent 点击"一键发送"，Contact Center 播放/发送问题给客户。
客户回答: "订单号是 ORD-2024-1234，我想退款"
Contact Center 将回答推送给我们:
```json
POST /api/cases/case_001/data
{
"field_updates": [
{"field": "order_id", "value": "ORD-2024-1234", "source": "customer_voice"},
{"field": "return_preference", "value": "退款", "source": "customer_voice"}
]
}
**Step 5: AI 更新 Case 并推进工作流**
1. **数据验证**: 订单号格式正确
2. **关联查询**: 调用 CRM API 查询订单信息
3. **规则检查**: 7天内购买，符合无理由退货政策
4. **工作流推进**: 自动流转到"待审批"状态
5. **生成建议**: 建议批准退款
返回给 Contact Center:
```json
\{
"case_id": "case_001",
"status": "pending_approval",
"order_verified": true,
"order_info": \{
"order_id": "ORD-2024-1234",
"product": "无线蓝牙耳机",
"price": 299.00,
"purchase_date": "2026-01-27"
\},
"ai_recommendation": \{
"action": "approve_refund",
"reason": "符合7天无理由退货政策",
"confidence": 0.95
\},
"suggested_response": "好的，我已确认您的订单。您的退款申请符合我们的退货政策，我这就为您办理。退款将在3-5个工作日内返回原支付账户。"
\}
**Step 6: Agent 确认并完成**
Agent 看到:
┌──────────────────────────────────────────────────────┐
│ 📋 Case #001 - 退货申请 [待审批] │
├──────────────────────────────────────────────────────┤
│ 订单信息: │
│ • 订单号: ORD-2024-1234 │
│ • 产品: 无线蓝牙耳机 │
│ • 金额: ¥299.00 │
│ • 购买日期: 2026-01-27 (6天前) │
│ │
│ 🤖 AI 建议: 批准退款 │
│ 理由: 符合7天无理由退货政策 │
├──────────────────────────────────────────────────────┤
│ 建议回复: │
│ ┌────────────────────────────────────────────────┐ │
│ │ 好的，我已确认您的订单。您的退款申请符合我们的 │ │
│ │ 退货政策，我这就为您办理。退款将在3-5个工作日 │ │
│ │ 内返回原支付账户。 │ │
│ │ [确认并发送] [修改] │ │
│ └────────────────────────────────────────────────┘ │
│ │
│ [✓ 批准退款] [✗ 拒绝] [↗ 升级主管] │
└──────────────────────────────────────────────────────┘
Agent 点击"批准退款"，Case 自动:
1. 状态变为"已批准"
2. 触发财务系统退款流程（如已集成）
3. 记录处理历史
4. 通知 Contact Center 会话可结束
#### 关键点
- **我们不做语音识别**: Contact Center 提供 transcript
- **我们不直接和客户说话**: 生成问题/回复，让 Agent 操作
- **AI 驱动决策**: 识别、提取、匹配、建议都是 AI 做的
- **人做最终确认**: Agent 确认关键操作（批准退款）
---
### 场景 2: Schema 驱动的数据收集
#### 背景
系统中定义了多种 Case Type，每种有不同的 Schema（需要的字段）。AI 根据 Schema 知道还缺什么信息。
#### Case Type 定义示例
```yaml
case_type: technical_support_bug
name: 技术支持 - Bug报告
schema:
required:
- product_name # 产品名称
- bug_description # 问题描述
- steps_to_reproduce # 复现步骤
- environment # 环境信息
optional:
- error_message # 错误信息
- screenshots # 截图
- priority # 优先级 (如用户未指定，AI判断)
field_definitions:
product_name:
type: enum
options: ["App A", "App B", "API Service"]
ai_extractable: true
bug_description:
type: text
ai_extractable: true
min_length: 10
steps_to_reproduce:
type: text
ai_extractable: false # 通常需要明确询问
prompt: "能否描述一下触发这个问题的操作步骤？"
environment:
type: object
properties:
os: { type: enum, options: ["Windows", "macOS", "Linux", "iOS", "Android"] }
browser: { type: enum, options: ["Chrome", "Safari", "Firefox", "Edge"] }
version: { type: string }
ai_extractable: partial # AI可能从描述中提取部分信息
workflow:
initial_status: new
statuses:
- new
- triaging
- assigned
- in_progress
- pending_customer
- resolved
- closed
transitions:
- from: new, to: triaging, auto: true, condition: "all_required_fields_filled"
- from: triaging, to: assigned, requires: "agent_assignment"
- from: assigned, to: in_progress, actor: "assigned_agent"
- from: in_progress, to: resolved, actor: "assigned_agent"
- from: resolved, to: closed, auto: true, delay: "7d", condition: "no_customer_response"
#### 流程
**Step 1: 初始输入**
客户通过聊天说: "你们的 App A 登录不了，一直转圈"
**Step 2: AI 分析与提取**
[AI 分析结果]
意图: 技术支持 - Bug报告
已提取:
✓ product_name: "App A"
✓ bug_description: "登录功能失败，界面持续loading"
✗ steps_to_reproduce: 未知
✗ environment: 未知
缺失必填字段: steps_to_reproduce, environment
**Step 3: 生成针对性问题**
AI 不会生成通用问题模板，而是基于已知信息生成上下文相关的问题:
```json
\{
"missing_fields": [
\{
"field": "steps_to_reproduce",
"question": "您是打开App后直接遇到登录问题，还是在输入账号密码后才出现的？",
"context": "根据描述，问题出现在登录环节"
\},
\{
"field": "environment.os",
"question": "您使用的是 iPhone 还是 Android 手机？",
"context": "App A 是移动应用"
\},
\{
"field": "environment.version",
"question": "能否在 App 的设置页面查看一下版本号？",
"context": "版本信息有助于定位问题"
\}
],
"collection_strategy": "progressive",
"priority_order": ["steps_to_reproduce", "environment.os", "environment.version"]
\}
**Step 4: 渐进式收集**
不是一次问所有问题，而是根据对话进展逐步收集:
**第一轮**:
- 问: "您是打开App后直接遇到登录问题，还是在输入账号密码后才出现的？"
- 答: "输入完密码点登录后，就一直转圈"
- AI 更新: steps_to_reproduce = "输入账号密码 -> 点击登录 -> 界面持续loading无响应"
**第二轮**:
- 问: "您使用的是 iPhone 还是 Android 手机？"
- 答: "iPhone 15"
- AI 更新: environment.os = "iOS", 并推断可能的 iOS 版本
**第三轮**:
- AI 判断: 已有足够信息创建有效 Bug 工单
- AI 决策: 不再追问版本号，避免骚扰用户
- Case 状态: 自动流转到 "triaging"
#### 关键点
- **Schema 是数据契约**: 定义每类 Case 需要什么
- **AI 理解 Schema**: 知道哪些字段必填，哪些可自动提取
- **智能收集策略**: 渐进式、上下文相关，不是机械填表
- **适时停止**: 够用就行，不追求完美数据
---
### 场景 3: 工作流流转与外部系统协作
#### 背景
客服发现这是一个需要开发修复的 Bug，需要流转到 Jira。
#### 流程
**Step 1: Case 达到流转条件**
Case #002
类型: 技术支持 - Bug报告
状态: triaging
处理人: 客服 Agent
数据:
- 产品: App A
- 问题: 登录失败
- 环境: iOS 17, iPhone 15
- 复现步骤: 输入账号密码后点击登录，持续loading
AI 分析:
- 这不是配置问题，是代码 Bug
- 过去7天有 8 个类似报告
- 建议: 升级到开发团队
**Step 2: Agent 决定升级**
Agent 在我们的系统（或 Contact Center 嵌入界面）点击 "升级到开发"
**Step 3: 系统执行跨系统流转**
[工作流引擎执行]
1. 检查 Jira 集成配置
- 项目: APPA
- Issue 类型: Bug
- 字段映射:
- summary <- case.bug_description
- description <- case.full_context
- priority <- case.ai_suggested_priority
- labels <- ["customer-reported", "login-issue"]
2. 调用 Jira API 创建 Issue
POST /rest/api/3/issue
\{
"fields": \{
"project": \{"key": "APPA"\},
"issuetype": \{"name": "Bug"\},
"summary": "iOS App 登录失败 - 持续loading",
"description": "...(包含复现步骤、环境信息、用户数量)...",
"priority": \{"name": "High"\},
"labels": ["customer-reported", "login-issue"]
\}
\}
3. 收到 Jira 响应: APPA-1234 已创建
4. 更新 Case 记录
- 关联外部任务: jira:APPA-1234
- 状态: waiting_for_fix
- 记录操作历史
**Step 4: 双向同步**
当 Jira Issue 状态变化时:
[Jira Webhook 回调]
APPA-1234 状态从 "Open" 变为 "In Progress"
[我们的系统处理]
1. 根据 jira:APPA-1234 找到 Case #002
2. 更新 Case 状态为 "fix_in_progress"
3. 记录: "开发已开始修复 (Jira APPA-1234)"
4. 可选: 通知原 Agent "您上报的 Bug 已开始修复"
当 Jira Issue 解决时:
[Jira Webhook 回调]
APPA-1234 状态变为 "Done"
解决方案: "修复登录接口超时问题，将在 v2.3.1 发布"
[我们的系统处理]
1. 更新 Case 状态为 "resolved"
2. 提取解决方案信息
3. 生成客户通知模板:
"您之前反馈的登录问题已修复，将在下个版本(v2.3.1)中发布。感谢您的反馈！"
4. 通知 Agent 可以跟进客户
5. 将解决方案存入知识库
**Step 5: 闭环**
Agent 联系客户，告知修复结果，Case 关闭。
#### 关键点
- **Case 是主记录**: Jira Issue 是执行层的任务
- **自动映射**: Schema 字段映射到 Jira 字段
- **双向同步**: Jira 变化反映到 Case
- **自动生成内容**: 给 Agent 的跟进模板
---
### 场景 4: Supervisor 视角 - 监控与优化
#### 背景
Supervisor 需要了解团队工作情况，发现问题和趋势。
#### 我们系统的 Dashboard
┌──────────────────────────────────────────────────────────────────┐
│ 📊 Case 概览 2026-02-03 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 今日数据 │ 趋势 (vs 昨日) │
│ ─────────── │ ───────────── │
│ 新建 Case: 127 │ ↑ 15% (原因: 促销活动) │
│ 已解决: 98 │ ↓ 5% │
│ 待处理: 43 │ ↑ 8% │
│ 平均处理时间: 23分钟 │ ↓ 12% ✓ │
│ │
├──────────────────────────────────────────────────────────────────┤
│ 🚨 需要关注 │
│ │
│ ⚠️ "App 登录失败" 相关 Case 激增 │
│ • 今日: 23 个 (昨日: 3 个, ↑ 667%) │
│ • 影响用户: 21 名 │
│ • 首次报告: 今天 09:15 │
│ • 可能原因: 今早的服务器部署? │
│ • [查看详情] [创建 P0 Bug] [通知开发团队] │
│ │
│ ⚠️ Agent 王小明 负载过高 │
│ • 当前待处理: 15 个 (团队平均: 5 个) │
│ • 原因: 技术类 Case 集中分配 │
│ • [重新分配] [查看详情] │
│ │
├──────────────────────────────────────────────────────────────────┤
│ 📈 Case 类型分布 │
│ │
│ 退货/退款 ████████████████████████ 35% │
│ 技术支持 ███████████████████ 28% │
│ 咨询 █████████████ 20% │
│ 投诉 ███████ 12% │
│ 其他 ███ 5% │
│ │
└──────────────────────────────────────────────────────────────────┘
#### AI 主动洞察
不需要 Supervisor 主动查询，AI 会主动推送:
┌──────────────────────────────────────────────────────────────────┐
│ 🤖 AI 洞察 刚刚 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 发现异常模式: │
│ │
│ 过去 2 小时，"登录失败" 类 Case 数量异常增长。 │
│ │
│ 分析: │
│ • 23 个 Case 提到 "登录" + "转圈/loading" │
│ • 地理分布: 全国各地 (非区域性问题) │
│ • 设备分布: iOS 78%, Android 22% │
│ • 时间点: 09:00 开始出现，与今早 08:45 的部署时间吻合 │
│ │
│ 建议行动: │
│ 1. 立即联系开发团队确认部署变更 │
│ 2. 考虑回滚今早的部署 │
│ 3. 对受影响用户发送统一通知 │
│ │
│ [一键创建 P0 事件] [通知开发 @backend-team] [草拟用户通知] │
│ │
└──────────────────────────────────────────────────────────────────┘
#### 关键点
- **数据在我们这**: Case 数据是我们的，分析在我们这做
- **主动洞察**: 不等人问，发现异常就推送
- **可执行建议**: 不只是报告问题，还提供具体行动
- **跨系统关联**: 能关联到部署时间等外部信息（如果有集成）
---
### 场景 5: 工作流自动化配置
#### 背景
Supervisor 想配置一个自动化规则："高优先级 Case 超过 30 分钟未响应，自动升级"
#### 配置方式
**方式 1: 自然语言配置**
Supervisor 在对话框输入:
> "当高优先级的Case超过30分钟没有人响应，自动分配给主管，并发送提醒"
AI 解析并生成配置:
```yaml
rule:
name: "高优先级 Case 超时升级"
trigger:
type: time_based
condition: "case.priority == 'high' AND case.status == 'new'"
delay: 30m
actions:
- type: reassign
to: "role:supervisor"
preserve_history: true
- type: notification
channel: ["email", "in_app"]
recipients: ["role:supervisor", "original_assignee"]
message: "高优先级 Case \{\{case.id\}\} 已超时 30 分钟，已升级处理"
- type: update_field
field: "escalation_count"
value: "\{\{case.escalation_count + 1\}\}"
AI 确认: "我理解您要: 高优先级Case 30分钟无响应 → 升级给主管 + 发通知。确认创建？"
**方式 2: 可视化配置**
┌──────────────────────────────────────────────────────────────────┐
│ 创建自动化规则 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 触发条件: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 当 [Case 优先级 ▼] [等于 ▼] [高 ▼] │ │
│ │ 且 [状态 ▼] [等于 ▼] [新建 ▼] │ │
│ │ 持续 [30] [分钟 ▼] │ │
│ │ [+ 添加条件] │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 执行动作: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 1. [重新分配 ▼] 给 [主管 (角色) ▼] │ │
│ │ 2. [发送通知 ▼] 给 [主管, 原处理人 ▼] 通过 [邮件+应用内 ▼]│ │
│ │ [+ 添加动作] │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ [取消] [保存为草稿] [启用] │
└──────────────────────────────────────────────────────────────────┘
#### 支持的自动化能力
| 触发器 | 说明 |
|--------|------|
| 时间触发 | Case 处于某状态超过 X 时间 |
| 状态变化 | Case 进入/离开某状态 |
| 字段变化 | 某字段值变化 |
| 外部事件 | Webhook 调用、Jira 状态变化 |
| 数量阈值 | 某类 Case 数量超过阈值 |
| 动作 | 说明 |
|------|------|
| 状态变更 | 自动流转 Case 状态 |
| 分配变更 | 重新分配处理人 |
| 通知 | 发送邮件/应用内/Webhook通知 |
| 外部调用 | 调用 Jira、Slack 等外部 API |
| 字段更新 | 更新 Case 字段值 |
| 创建子任务 | 基于当前 Case 创建关联任务 |
---
### 场景 6: Agent 在我们的 UI 中工作
#### 背景
不是所有场景都通过 Contact Center 嵌入。Agent 也可以直接在我们的系统 UI 中处理 Case。
#### Agent 工作台
┌──────────────────────────────────────────────────────────────────┐
│ 我的待办 张小明 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┬─────────┬─────────┬─────────┐ │
│ │ 全部(12)│ 紧急(2) │ 今日到期(5) │ 升级给我(1) │ │
│ └─────────┴─────────┴─────────┴─────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 🔴 Case #015 - 退款未到账 10分钟前 │ │
│ │ 客户: cust_456 | 金额: ¥599 | 来源: 电话 │ │
│ │ AI: 建议查询退款系统，可能是银行处理延迟 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 🟡 Case #014 - 产品功能咨询 25分钟前 │ │
│ │ 客户: cust_789 | 来源: 在线聊天 │ │
│ │ AI: 已匹配3篇知识库文章，可直接引用回复 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ ...更多 Case... │ │
│ │
└──────────────────────────────────────────────────────────────────┘
#### Case 详情页
┌──────────────────────────────────────────────────────────────────┐
│ Case #015 - 退款未到账 🔴 紧急 │
├──────────────────────────────────────────────────────────────────┤
│ 状态: 处理中 │ 创建: 2026-02-03 10:15 │
│ 处理人: 张小明 │ 来源: Zoom Contact Center - 电话 │
│ SLA: 剩余 50 分钟 │ 客户: cust_456 (王先生) │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 📋 Case 信息 │
│ ────────── │
│ 订单号: ORD-2024-5678 │
│ 原订单金额: ¥599.00 │
│ 退款申请时间: 2026-01-28 │
│ 退款状态: 已处理 (系统显示) │
│ 客户反馈: 已过5个工作日，款项未到账 │
│ │
│ 📝 对话历史 │
│ ────────── │
│ [10:15] 客户来电: "我上周申请的退款还没到，都快一周了" │
│ [10:16] AI 创建 Case，识别为"退款跟进" │
│ [10:16] AI 查询退款记录: 退款已于 01-29 处理 │
│ [10:17] 分配给 张小明 │
│ │
├──────────────────────────────────────────────────────────────────┤
│ 🤖 AI 助手 │
│ ────────── │
│ 分析: │
│ • 退款于 01-29 提交，到今天已 5 个工作日 │
│ • 银行通常 3-5 工作日到账，可能处于上限 │
│ • 建议确认客户收款账户是否正确 │
│ │
│ 建议回复: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 王先生您好，我查到您的退款已于1月29日处理。银行到账通常需 │ │
│ │ 要3-5个工作日，目前刚好在这个时间范围内。建议您再等1-2个 │ │
│ │ 工作日查看。如果仍未到账，我们可以联系银行查询。 │ │
│ │ │ │
│ │ 另外想确认一下，您的收款账户是尾号 1234 的工商银行卡吗？ │ │
│ │ [复制] [直接使用] │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 相关知识: │
│ • [退款到账时间说明] - 命中率 95% │
│ • [银行处理时间参考] - 命中率 87% │
│ │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 添加回复: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ (输入回复内容，或点击上方 AI 建议) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ [发送给客户] [内部备注] [升级] [标记解决] │
│ │
└──────────────────────────────────────────────────────────────────┘
#### 关键点
- **独立 UI**: 我们有自己的 Agent 工作台
- **AI 始终在场**: 每个 Case 都有 AI 分析和建议
- **知识库集成**: 自动匹配相关文档
- **操作简洁**: 常用操作一键触达
---
### 场景 7: 新 Agent onboarding（入职培训）
#### 背景
新 Agent 刚入职，需要快速上手处理 Case，但缺乏经验。
#### 流程
**Step 1: 培训模式激活**
新 Agent 登录系统，AI 检测到是新用户，自动进入"培训模式"：
┌──────────────────────────────────────────────────────────────────┐
│ 👋 欢迎，张小明！ [培训模式] │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 系统检测到您是新手，已为您激活培训模式。 │
│ │
│ 培训模式特点： │
│ • AI 会提供更详细的指导 │
│ • 每个操作都有说明和最佳实践提示 │
│ • 可以练习处理模拟 Case │
│ • 实时反馈和评分 │
│ │
│ [开始培训] [跳过，直接开始工作] │
└──────────────────────────────────────────────────────────────────┘
**Step 2: 引导式 Case 处理**
新 Agent 接到第一个真实 Case，系统提供逐步指导：
┌──────────────────────────────────────────────────────────────────┐
│ 📋 Case #100 - 退货申请 (培训模式) [新建] │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 🎓 新手引导 (步骤 1/5) │
│ ────────── │
│ │
│ 这是您的第一个 Case。让我们一步步处理： │
│ │
│ ✅ 步骤 1: 理解 Case 背景 (已完成) │
│ • Case 类型: 退货申请 │
│ • 客户问题: 产品有质量问题 │
│ • 优先级: 中等 │
│ │
│ 📝 步骤 2: 查看相关信息 (进行中) │
│ • [点击查看] 客户历史订单 │
│ • [点击查看] 退货政策 │
│ • [点击查看] 类似 Case 处理方式 │
│ │
│ ⏭️ 步骤 3: 生成回复建议 (待进行) │
│ ⏭️ 步骤 4: 确认并发送 (待进行) │
│ ⏭️ 步骤 5: 更新 Case 状态 (待进行) │
│ │
│ 💡 提示: 处理退货申请时，先确认订单信息，再检查是否符合退货政策。 │
│ │
└──────────────────────────────────────────────────────────────────┘
**Step 3: AI 实时辅导**
当 Agent 执行操作时，AI 提供实时反馈：
[Agent 点击"查看退货政策"]
AI: "很好！查看政策是处理退货的第一步。您看到政策中关于'7天无理由退货'的条款了吗？这个 Case 的购买时间是5天前，符合条件。"
[Agent 准备生成回复]
AI: "在生成回复前，建议先确认订单信息。点击'查看客户历史订单'可以快速获取订单详情。"
**Step 4: 模拟练习模式**
系统提供模拟 Case 供练习：
┌──────────────────────────────────────────────────────────────────┐
│ 🎮 模拟练习模式 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 练习 Case #SIM-001: 技术支持 - Bug报告 │
│ │
│ 这是一个模拟 Case，您可以安全地练习各种操作： │
│ • 尝试不同的回复方式 │
│ • 测试工作流操作 │
│ • 查看 AI 建议 │
│ │
│ [开始练习] [查看提示] [查看标准答案] │
│ │
└──────────────────────────────────────────────────────────────────┘
**Step 5: 绩效反馈和成长建议**
处理完几个 Case 后，AI 提供反馈：
┌──────────────────────────────────────────────────────────────────┐
│ 📊 您的表现分析 [培训模式] │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 已处理 Case: 5 个 │
│ 平均处理时间: 18 分钟 (团队平均: 15 分钟) │
│ 客户满意度: 4.2/5.0 │
│ │
│ ✅ 做得好的地方： │
│ • 回复及时，响应速度快 │
│ • 能够有效使用 AI 建议 │
│ │
│ 💡 改进建议： │
│ • 在处理前多查看历史类似 Case，可以更快找到解决方案 │
│ • 建议学习"退货政策详解"课程 │
│ │
│ [查看详细报告] [学习推荐课程] [退出培训模式] │
│ │
└──────────────────────────────────────────────────────────────────┘
#### 关键点
- **渐进式学习**: 从简单到复杂，逐步提升
- **实时指导**: AI 在每个步骤提供帮助
- **安全练习**: 模拟环境让新手放心尝试
- **数据驱动**: 基于实际表现提供个性化建议
---
### 场景 8: 峰值流量管理
#### 背景
促销活动导致 Case 量激增，需要快速响应和资源调配。
#### 流程
**Step 1: AI 检测异常流量**
系统检测到 Case 量异常增长：
┌──────────────────────────────────────────────────────────────────┐
│ 🚨 流量异常预警 刚刚 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 检测到 Case 量异常增长： │
│ │
│ • 过去 1 小时: 127 个新 Case (平时: 30 个/小时) │
│ • 增长率: +323% │
│ • 主要类型: 订单查询 (45%), 退货申请 (30%) │
│ • 可能原因: 今日促销活动开始 │
│ │
│ 📊 预测： │
│ • 未来 3 小时预计: 350-400 个新 Case │
│ • 当前待处理: 89 个 │
│ • 预计积压: 260+ 个 (如不采取措施) │
│ │
│ 💡 AI 建议： │
│ 1. 激活自动分流优先级规则 │
│ 2. 重新分配 Agent 负载 (当前不均衡) │
│ 3. 启用批量回复模板 (针对常见问题) │
│ 4. 通知主管考虑增加人手 │
│ │
│ [应用建议] [查看详细分析] [手动调整] │
│ │
└──────────────────────────────────────────────────────────────────┘
**Step 2: 自动优先级分流**
系统自动调整分流策略：
[AI 执行自动分流优化]
1. 优先级规则激活：
- 高优先级: VIP客户、紧急问题、SLA即将超时
- 中优先级: 普通订单查询、一般咨询
- 低优先级: 非紧急问题、可延迟处理
2. 智能分配：
- 高优先级 Case → 经验丰富的 Agent
- 中优先级 Case → 一般 Agent
- 低优先级 Case → 可批量处理或延迟
3. 负载均衡：
- 检测到 Agent A 负载过高 (15个待处理)
- 自动重新分配 5 个 Case 给 Agent B (3个待处理)
**Step 3: 批量处理建议**
AI 识别可批量处理的 Case：
┌──────────────────────────────────────────────────────────────────┐
│ ⚡ 批量处理建议 刚刚 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 发现 23 个相似 Case，可以批量处理： │
│ │
│ 问题类型: "订单号查询" │
│ 相似度: 95% (都是询问订单状态) │
│ │
│ 💡 建议操作： │
│ 1. AI 已生成统一回复模板 │
│ 2. 可以批量更新状态 │
│ 3. 预计节省时间: 2.5 小时 │
│ │
│ [查看 Case 列表] [批量应用回复] [逐个处理] │
│ │
└──────────────────────────────────────────────────────────────────┘
**Step 4: 资源调配建议**
AI 分析资源需求并提供建议：
┌──────────────────────────────────────────────────────────────────┐
│ 📈 资源调配分析 刚刚 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 当前状态： │
│ • 在线 Agent: 12 人 │
│ • 平均负载: 7.4 Case/人 │
│ • 预计处理时间: 2.3 小时/Case │
│ │
│ 预测需求： │
│ • 未来 3 小时需要: 18-20 人 │
│ • 建议增加: 6-8 人 │
│ │
│ 💡 可选方案： │
│ 1. 联系待命 Agent 上线 (3 人可用) │
│ 2. 从其他团队临时调配 (2 人可用) │
│ 3. 延长当前 Agent 工作时间 │
│ 4. 启用自动回复 (可处理 30% 的简单 Case) │
│ │
│ [通知待命 Agent] [联系其他团队] [查看详细分析] │
│ │
└──────────────────────────────────────────────────────────────────┘
**Step 5: 实时监控和调整**
Supervisor 实时监控峰值处理情况：
┌──────────────────────────────────────────────────────────────────┐
│ 📊 峰值流量监控面板 实时更新 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 当前指标 │ 目标 │ 状态 │
│ ────────── │ ───── │ ──── │
│ 待处理 Case: 156 │ < 100 │ ⚠️ 超限 │
│ 平均响应时间: 8 分钟 │ < 5 分钟 │ ⚠️ 超限 │
│ SLA 达成率: 78% │ > 95% │ ⚠️ 未达标 │
│ 平均处理时间: 22 分钟 │ < 20 分钟 │ ⚠️ 超限 │
│ │
│ 📈 趋势： │
│ • Case 量: 仍在增长 (预计 1 小时后达到峰值) │
│ • 处理速度: 已提升 15% (通过批量处理) │
│ • 积压情况: 预计 2 小时后开始缓解 │
│ │
│ 🎯 实时优化： │
│ • AI 已自动调整 8 个 Case 的优先级 │
│ • 已重新分配 12 个 Case 以平衡负载 │
│ • 已启用 3 个批量处理模板 │
│ │
└──────────────────────────────────────────────────────────────────┘
#### 关键点
- **主动检测**: AI 提前识别流量异常
- **自动优化**: 系统自动调整分流和分配策略
- **批量处理**: 识别相似 Case 提高效率
- **资源规划**: 预测需求并提供调配建议
- **实时监控**: Supervisor 实时掌握情况
---
### 场景 9: 质量保证 (QA)
#### 背景
Supervisor 需要监控和保证 Agent 的服务质量，确保符合标准。
#### 流程
**Step 1: 自动质量评分**
AI 自动分析每个已处理的 Case，生成质量评分：
┌──────────────────────────────────────────────────────────────────┐
│ 📋 Case #200 - 退货申请 [已解决] │
├──────────────────────────────────────────────────────────────────┤
│ │
│ ✅ 质量评分: 4.2/5.0 │
│ │
│ 评分维度： │
│ • 响应速度: 5.0/5.0 ✓ (5 分钟内响应) │
│ • 回复质量: 4.5/5.0 ✓ (专业、友好) │
│ • 问题解决: 4.0/5.0 ✓ (有效解决客户问题) │
│ • 政策遵循: 4.5/5.0 ✓ (正确应用退货政策) │
│ • 客户满意度: 4.0/5.0 (客户评分) │
│ │
│ 💡 改进建议： │
│ • 回复可以更简洁一些 (当前回复较长) │
│ • 建议主动询问客户是否需要其他帮助 │
│ │
│ [查看详细分析] [标记为样本 Case] [需要人工审核] │
│ │
└──────────────────────────────────────────────────────────────────┘
**Step 2: 异常检测和预警**
AI 检测到质量异常：
┌──────────────────────────────────────────────────────────────────┐
│ ⚠️ 质量异常检测 刚刚 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 检测到潜在质量问题： │
│ │
│ Case #201 - 技术支持 │
│ 处理人: 李四 │
│ 问题: 回复内容可能不符合公司政策 │
│ │
│ 分析： │
│ • AI 检测到回复中提到了"可以免费升级"，但政策要求需要审批 │
│ • 客户满意度: 2.0/5.0 (低于平均) │
│ • 处理时间: 45 分钟 (明显高于平均) │
│ │
│ 💡 建议操作： │
│ 1. Supervisor 立即审核此 Case │
│ 2. 可能需要联系客户更正信息 │
│ 3. 对 Agent 进行政策培训 │
│ │
│ [立即审核] [联系客户] [标记为培训案例] │
│ │
└──────────────────────────────────────────────────────────────────┘
**Step 3: 合规检查**
系统自动检查合规性：
┌──────────────────────────────────────────────────────────────────┐
│ ✅ 合规检查报告 刚刚 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ Case #202 - 账户问题 │
│ │
│ 合规检查项： │
│ ✅ 客户身份验证: 已通过 │
│ ✅ 敏感信息处理: 已脱敏 │
│ ✅ 数据隐私: 符合 GDPR 要求 │
│ ✅ 操作记录: 完整记录 │
│ ⚠️ 审批流程: 需要主管审批的操作已跳过 │
│ │
│ 问题： │
│ • Agent 直接批准了超过权限的退款操作 │
│ • 系统检测到应触发审批流程但未触发 │
│ │
│ 💡 建议： │
│ 1. 回滚该操作，重新走审批流程 │
│ 2. 检查工作流配置是否正确 │
│ 3. 对 Agent 进行权限培训 │
│ │
│ [查看详细日志] [回滚操作] [修复工作流] │
│ │
└──────────────────────────────────────────────────────────────────┘
**Step 4: 质量趋势分析**
Supervisor 查看团队质量趋势：
┌──────────────────────────────────────────────────────────────────┐
│ 📊 团队质量报告 2026-02-03 (本周) │
├──────────────────────────────────────────────────────────────────┤
│ │
│ 整体质量评分: 4.3/5.0 (↑ 0.2 vs 上周) │
│ │
│ 各维度表现： │
│ • 响应速度: 4.5/5.0 (↑ 0.3) ✓ 优秀 │
│ • 回复质量: 4.2/5.0 (→ 持平) ✓ 良好 │
│ • 问题解决: 4.4/5.0 (↑ 0.1) ✓ 优秀 │
│ • 政策遵循: 4.1/5.0 (↓ 0.1) ⚠️ 需关注 │
│ │
│ 👥 个人表现： │
│ • 张三: 4.6/5.0 ⭐ 优秀 │
│ • 李四: 3.8/5.0 ⚠️ 需改进 (政策遵循度低) │
│ • 王五: 4.4/5.0 ✓ 良好 │
│ • ... │
│ │
│ 📈 趋势分析： │
│ • 整体质量持续提升 │
│ • 政策遵循度略有下降，需要加强培训 │
│ • 响应速度显著改善 (AI 辅助效果明显) │
│ │
│ 💡 AI 建议： │
│ 1. 组织政策培训 (针对李四等低分员工) │
│ 2. 分享张三的最佳实践 │
│ 3. 优化 AI 政策检查规则 │
│ │
│ [导出报告] [安排培训] [查看详细分析] │
│ │
└──────────────────────────────────────────────────────────────────┘
**Step 5: 样本 Case 审核**
Supervisor 审核 AI 标记的样本 Case：
┌──────────────────────────────────────────────────────────────────┐
│ 📋 样本 Case 审核队列 待审核: 12 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ Case #203 - 技术支持 (AI 评分: 3.5/5.0) │
│ 处理人: 李四 | 处理时间: 2026-02-03 14:30 │
│ │
│ [Supervisor 审核界面] │
│ │
│ ✅ 评分确认: [4.0] /5.0 (AI: 3.5) │
│ │
│ 审核意见： │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ AI 评分偏低，实际处理质量良好。回复专业，问题解决有效。 │ │
│ │ 建议调整 AI 评分模型。 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ [通过] [需要改进] [标记为培训案例] [下一个] │
│ │
└──────────────────────────────────────────────────────────────────┘
#### 关键点
- **自动化评分**: AI 自动评估每个 Case 的质量
- **异常检测**: 主动识别潜在质量问题
- **合规保障**: 自动检查是否符合政策和法规
- **趋势分析**: 识别团队质量趋势和改进点
- **持续优化**: 基于审核反馈优化 AI 模型
---
## 总结: 产品核心能力
### 1. 智能 Intake（接入）
- 接收来自各渠道的输入（via API）
- AI 识别意图、分类、提取信息
- 自动匹配 Case Type
### 2. Schema 驱动的数据管理
- Case Type 定义所需数据结构
- AI 基于 Schema 分析数据缺口
- 智能生成收集问题
### 3. 工作流自动化
- 定义状态流转规则
- 时间/条件触发自动动作
- 人工审批节点
### 4. 外部系统集成
- 与 Contact Center 双向协作
- 与 Jira 等工作流系统同步
- 从 CRM 查询客户信息
### 5. AI 辅助
- 回复建议生成
- 知识库匹配
- 趋势分析和异常检测
- 工作负载优化建议
### 6. 多入口
- 我们的 Web UI（独立使用）
- 嵌入到 Contact Center（辅助使用）
- API（程序化使用）
---
## 与之前版本的区别
| 方面 | V1 (不实际的) | V2 (当前版本) |
|------|---------------|---------------|
| 语音识别 | 我们做 | Contact Center 做，给我们 transcript |
| 客户数据 | 我们存储 | 只缓存基本信息，主数据在 CRM |
| 客户交互 | 我们直接对话 | 我们生成内容，Agent 执行 |
| Contact Center | 我们做 | 不做，通过 API 集成 |
| UI | 只有我们的 | 我们的 + 嵌入外部系统 |
| AI 能力 | 无所不能 | 聚焦分析、生成、决策 |
**核心转变**: 从"全栈系统"到"专注工作流管理的平台"，通过 API 与生态协作。