P10c customer service case
Skill gmaxxxie/ai-native-product-agent-skills/skills/p10c-customer-service-case
AI Native Product Methodology — 80 executable skills across P0-P14 stages, covering needs discovery to aesthetic authority. From 8 books.
npx -y skills add gmaxxxie/ai-native-product-agent-skills --skill p10c-customer-service-caseAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
What its author says it does
Copied from the file, not written here
'AI Native 产品方法论——AI 客服行业案例模板 Skill。
SKILL.md
19.3 KB, as published. Nobody here has run it
AI 客服案例模板 Skill
使用场景
- 客服团队希望引入 AI 能力,需要系统性方法论指导
- 需要设计客服 Copilot 或智能客服系统的完整路径
- 关注服务协同、经验复利、反馈驱动的持续优化场景
客服场景特征与适配性
| 客服特征 | 对方法论的影响 |
|---|---|
| 高频重复:同类问题大量发生 | 适合 AI 规模化,价值密度容易验证 |
| 知识密集:依赖 SOP 和历史经验 | 需要 RAG 和知识沉淀系统 |
| 风险可控:错误影响相对有限 | 可更快进入灰度和自主模式 |
| 反馈丰富:用户互动产生大量标注 | 天然适合持续学习和反馈回灌 |
| 商业价值清晰:省人力、提体验 | 适合商业实验和定价验证 |
客服方法论路径
@ai-native-direction-framing
→ 选择最值得先协同化的客服任务
→ 输出:Direction Brief
@p2a-experiment-overview + @p2b-product-form-exploration
→ 验证理解、检索、候选回复和风险识别
→ 输出:产品形态建议(Copilot)
@p2c-process-redesign
→ 服务升级链设计
→ 输出:人机协作矩阵
@p2e-shadow-validation
→ 影子验证:Copilot 并行运行
→ 输出:采纳率、错误率、风险漏过率
@ai-native-audit-release
→ 客服场景审计放行
→ 输出:放行决策
@ai-native-production-ops
→ 客服生产观测和反馈回灌
→ 输出:生产运行方案
@p7e-customer-loop
→ 早期客户计划设计
→ 输出:客户循环方案
@p10a-value-discovery-loop
→ 价值信号识别与商业验证
→ 输出:价值发现方案
客服能力分层
第一层:辅助检索(低风险)
- FAQ 问答
- 订单/物流状态查询
- 政策规则解释
- → 适合:自动回答 + 知识库兜底
第二层:Copilot 协同(中风险)
- 回复建议生成
- 意图识别与分类
- 风险标记与升级提示
- → 适合:Copilot + 人工确认
第三层:自动处理(高风险)
- 自动退款建议(附条件)
- 自动好评引导
- 投诉预判与升级
- → 适合:人在回路中 + 严格审计
客服案例 Skill 输出模板
```yaml
AI 客服案例方案
方向定界: 核心问题: [选择最值得先协同化的任务] 目标场景: [工单处理 / 在线咨询 / 外呼 / 投诉处理] 现有系统: [工单系统 / 在线客服 / CRM] Direction Brief: [输出]
试验展开: 能力实验: - 意图识别: [准确率/适用场景] - 知识检索: [命中率/长尾覆盖] - 回复生成: [采纳率/风险率] 产品实验: - 形态: [Copilot / 自动问答 / 工作台] - 采纳率目标: [>60%] 商业实验: - 客服效率提升目标: [首响时间缩短X%] - 培训周期缩短: [从Y天到Z天] - ROI 测算
系统构建: Agent 设计: - 意图识别 Agent - 知识检索 Agent - 回复生成 Agent Memory: [会话上下文 / 用户画像 / 历史工单] Context: [订单状态 / 物流信息 / 售后政策] RAG: [FAQ库 / SOP / 历史工单 / 规则文档] UX: [侧边栏建议 / 风险标记 / 一键采纳]
审计放行: 风险分级: - 低风险(可直接自动): [状态查询 / FAQ] - 中风险(Copilot确认): [回复建议 / 意图分类] - 高风险(人工复核): [退款建议 / 投诉处理]
生产运行: 可观测性: [采纳率 / 修改率 / 投诉率 / 解决率] 反馈回灌: [修正案例 → 样本库 → 模型优化] 客户循环: [早期客户计划 → 反馈 → 产品改进] 价值发现: [效率信号 / 商业信号 / 留存信号] ```
与其他 Skill 的关系
- 核心协同:@ai-native-direction-framing, @p2b-product-form-exploration, @ai-native-ux-design, @p7e-customer-loop
- 配套:@ai-native-production-ops(生产运行),@p10a-value-discovery-loop(价值发现)
- 案例 Skill:@p10b-aiops-case(AIOps场景),@p10d-saas-case(数据分析场景)
适用边界
- ✅ 客服协同、FAQ问答、工单处理、售后支持等场景
- ✅ 高频、可标准化、有历史数据的客服流程
- ✅ 需要持续学习和人机协同优化的场景
- ❌ 高度情绪化、需要强同理心的场景(建议以辅助为主)
- ❌ 法律咨询、医疗建议等需要专业资质的领域
核心概念
1. 服务任务链而非单点问答
客服场景真正的难点不是"写一句回复",而是完成一整条服务任务链:理解用户意图、查订单、查物流、核规则、判断是否触发赔付或退款、决定是否升级人工、最后再组织回复。真正有价值的 AI 客服产品,不是替客服"说话",而是帮助整个服务任务链跑得更快、更稳、更一致。
2. 协同优先于全自动
客服里最危险的从来不是慢,而是错。错误承诺、规则误判、敏感信息暴露、例外场景处理失控,这些问题一旦发生,代价常常不只是一次回答质量差,而是直接影响用户信任、平台成本和组织风险。更合理的起点是客服 Copilot——让 AI 先承担高频重复环节(意图理解、规则检索、候选回复、风险标记),让人保留承诺、裁决和例外处理权。
3. 服务经验复利
客服场景最珍贵的地方,在于它每天都能产生真实反馈。每天新增的真实对话、人工改写、失败案例和升级路径,都可以回到知识系统、规则系统和训练样本里。如果这些经验能被沉淀下来,产品会越来越懂组织自己的服务边界和用户问题结构;如果沉淀不下来,系统就永远停留在"每次都从头生成"的初级阶段。
4. 服务升级链设计
客服产品最怕的,不是偶尔说得不够自然,而是沿着错误路径做出本不该做出的承诺。退款、赔付、时效、账户处理、特殊政策解释,这些节点都不是简单的回答问题,而是在代表企业做决定。因此,必须设计清晰的服务升级链:哪些问题只能给出候选建议,哪些问题必须人工确认,哪些问题要直接升级主管或特殊流程。
5. 能力复利而非话术复利
一个成熟的 AI 客服系统,最深层的价值是把原本散落在资深客服、主管经验和各种临时规则里的服务能力,逐步沉淀成组织级资产。AI 客服的长期结果不是"少雇几个人",而是让更多普通客服更快进入稳定状态,让高风险判断更早被识别,让服务经验持续回流产品本身。
分步执行
步骤 1:方向定界——选择最值得先协同化的客服任务
输入:客服团队现状、工单数据、对话记录、规则文档
执行要点:
- 判断基础条件:是否拥有足够的工单、对话记录、规则文档、订单数据和失败案例?是否存在高频、重复、标准相对清楚的服务任务?
- 评估业务重视度:首响时间、服务一致性、培训成本和升级效率是否是组织关注的指标?
- 选择第一批目标:通常从高频标准化任务开始(如订单查询、物流状态、FAQ 问答、政策解释)
输出:Direction Brief(含目标场景、现有系统、约束条件)
步骤 2:试验展开——验证理解、检索、回复和风险识别能力
输入:Direction Brief、历史工单样本、规则文档
执行要点:
- 意图理解验证:模型能否稳定识别用户意图?准确率和覆盖范围如何?
- 知识检索验证:能否检索到正确的规则和政策?长尾问题覆盖如何?
- 回复生成验证:候选回复的采纳率和风险率如何?
- 风险识别验证:能否识别高风险话题(退款、投诉、敏感信息)并及时标记?
- 重点暴露:资料口径不一致、规则描述模糊、订单上下文缺失、长尾场景难覆盖
输出:产品形态建议(Copilot / 自动问答 / 工作台)+ 能力实验报告
步骤 3:系统构建——打通订单、规则、知识和升级链
输入:试验结论、系统架构约束
执行要点:
- 拆分能力单元:意图识别 Skill、知识检索 Skill、回复生成 Skill、风险标记 Skill、升级路由 Skill
- 构建 Agent 编排:意图识别 Agent → 知识检索 Agent → 回复生成 Agent → 风险检查
- 设计 Memory:会话上下文、用户画像、历史工单
- 设计 Context:订单状态、物流信息、售后政策、会员等级
- 设计 RAG:FAQ 库、SOP、历史工单、规则文档
- 设计 UX:侧边栏建议、风险标记、一键采纳、修改追踪
输出:系统架构方案(含 Agent 设计、Skill 清单、服务升级链)
步骤 4:审计放行——明确高风险承诺边界和人工接管条件
输入:系统架构方案、业务规则
执行要点:
- 风险分级:低风险(可直接自动:状态查询、FAQ)、中风险(Copilot 确认:回复建议、意图分类)、高风险(人工复核:退款建议、投诉处理)
- 设计服务升级链:自动建议 → 人工确认 → 主管介入 → 特殊流程
- 设置边界规则:涉及金额承诺、法律风险、隐私信息的回复必须人工确认
输出:放行决策 + 风险分级清单 + 升级链设计
步骤 5:生产运行——观测采纳率、修改率和满意度
输入:放行决策、生产环境配置
执行要点:
- 设计可观测性指标:首响时间、候选回复采纳率、人工修改率、升级率、投诉率、满意度
- 建立反馈回灌机制:修正案例 → 样本库 → 模型优化
- 识别改进信号:哪些问题始终需要人工主导?哪些规则描述需要优化?哪些知识需要补充?
- 建立循环优化节奏:周度指标复盘 + 月度知识更新 + 季度能力评估
输出:生产运行方案
步骤 6:客户循环与价值发现——从早期客户到商业验证
输入:生产运行数据、客户反馈
执行要点:
- 设计早期客户计划:选择 3-5 个典型客户深度合作,收集反馈
- 识别价值信号:效率信号(首响时间缩短)、商业信号(人力成本降低)、留存信号(客户续费率提升)
- 沉淀服务能力:将高频问题、最佳回复、升级路径沉淀为组织级服务资产
输出:客户循环方案 + 价值发现方案
示例 1:电商客服 Copilot 系统
背景
某电商平台客服团队有 50 人,日均处理工单 3000+ 单。当前痛点:
- 新客服培训周期 2 周,期间回复质量不稳定
- 高峰期(大促)首响时间从 30 秒飙升到 5 分钟
- 退款、赔付等高风险决策依赖主管判断,主管成为瓶颈
- 服务经验分散在资深客服脑中,难以传承
Skill 执行输出
# AI 客服案例方案:电商客服 Copilot
方向定界:
核心问题: 高峰期首响时间飙升 + 新人培训成本高 + 主管决策瓶颈
目标场景: 在线客服 Copilot(覆盖售前咨询 + 售后处理)
现有系统: 工单系统 + 在线客服 + CRM + 订单系统
Direction Brief: 先做 Copilot 协同模式,覆盖高频标准化任务,目标首响时间缩短 60%
试验展开:
能力实验:
意图识别:
准确率: 91%(覆盖 20+ 种常见意图)
结论: 稳定可用,长尾意图需补充
知识检索:
命中率: 85%(Top3 命中正确规则)
长尾覆盖: 65%(需持续补充)
结论: 可用,需建立知识缺口反馈机制
回复生成:
采纳率: 68%(客服直接采纳或小幅修改后使用)
风险率: 3%(生成了不当承诺或敏感信息)
结论: 可用,需加强风险过滤
产品实验:
形态: 侧边栏 Copilot(候选回复 + 风险标记 + 知识引用)
采纳率目标: >60%
商业实验:
首响时间目标: 从 5 分钟缩短到 2 分钟
培训周期缩短: 从 2 周缩短到 3 天
ROI: 人力成本节省约 30%,大促期间无需临时增员
系统构建:
Agent 设计:
意图识别 Agent: 分析用户消息 → 识别意图 → 提取关键信息
知识检索 Agent: 根据意图 → 检索规则/FAQ/历史案例
回复生成 Agent: 组织上下文 → 生成候选回复 → 标记风险
升级路由 Agent: 判断是否需要升级 → 路由到主管或特殊流程
Memory:
- 会话上下文: 当前对话历史
- 用户画像: 会员等级、历史订单、投诉记录
- 历史工单: 近 90 天工单(10 万+ 条)
Context:
- 订单状态: 物流信息、退款状态
- 售后政策: 退换货规则、赔付标准
- 会员权益: 不同等级的权益差异
RAG:
- FAQ 库: 500+ 条常见问答
- SOP 库: 100+ 篇标准操作流程
- 规则文档: 退款规则、赔付政策、会员权益
- 历史工单: 标注过的高质量工单样本
UX:
- 侧边栏: 候选回复 + 知识引用 + 风险标记
- 一键采纳: 客服可直接采纳或修改后发送
- 风险提示: 高风险回复用红色标记
- 修改追踪: 记录客服修改内容,用于反馈回灌
审计放行:
风险分级:
- 低风险(自动回答): 订单状态查询、物流追踪、FAQ 问答
- 中风险(Copilot 确认): 回复建议、意图分类、政策解释
- 高风险(人工复核): 退款建议、赔付决策、投诉处理、账户操作
升级链: 自动建议 → 客服确认 → 主管介入 → 特殊流程
生产运行:
可观测性:
- 首响时间: 平均值 + P95
- 采纳率: 候选回复被采纳的比例
- 修改率: 客服修改回复的比例和修改内容
- 投诉率: 用户投诉率变化
- 解决率: 一次解决率
反馈回灌:
- 每次客服修改 → 更新回复模板
- 每次风险漏过 → 加强风险过滤规则
- 每次知识未命中 → 补充知识库
客户循环:
- 早期客户: 选择 3 个高流量店铺深度合作
- 反馈周期: 每周收集客服反馈
- 产品迭代: 双周一次功能优化
价值发现:
- 效率信号: 首响时间、人均处理量
- 商业信号: 人力成本、大促增员需求
- 留存信号: 客服满意度、用户满意度
关键决策点
| 决策点 | 选择 | 理由 |
|---|---|---|
| 产品形态 | Copilot 协同模式 | 客服场景风险可控但不能失控 |
| 第一批能力 | 意图识别 + 知识检索 + 候选回复 | 高频、标准化、价值直接 |
| 高风险处理 | 人工复核 | 退款赔付等决策需人负责 |
| 知识来源 | FAQ + SOP + 历史工单 | 结构化程度高,质量可控 |
示例 2:SaaS 产品技术支持客服系统
背景
某 B2B SaaS 公司技术支持团队有 12 人,服务 500+ 企业客户。当前痛点:
- 技术问题复杂,新人需要 3 个月才能独立处理
- 同类技术问题反复被问,但解决方案分散在个人笔记和 Slack 群聊中
- 客户等待时间长(平均 2 小时),满意度下降
- 高级工程师被大量重复问题占用,无暇处理复杂问题
Skill 执行输出
# AI 客服案例方案:SaaS 技术支持
方向定界:
核心问题: 技术知识碎片化 + 新人成长慢 + 高级工程师被重复问题占用
目标场景: 技术支持 Copilot(问题诊断 + 解决方案推荐 + 知识沉淀)
现有系统: 工单系统 + Slack + Confluence + Jira
Direction Brief: 构建技术支持 Copilot,将专家经验转化为可检索的组织能力
试验展开:
能力实验:
问题理解:
准确率: 84%(识别技术问题类型和关键信息)
结论: 可用,需结合产品文档增强
解决方案检索:
命中率: 78%(Top5 命中相关解决方案)
结论: 知识库需大幅补充
回复生成:
采纳率: 72%(技术支持工程师采纳或修改后使用)
结论: 技术准确性需加强审核
产品实验:
形态: 工作台模式(问题诊断 + 方案推荐 + 文档引用)
使用率: 日均 100+ 次查询
商业实验:
首响时间: 从 2 小时缩短到 30 分钟
新人独立处理周期: 从 3 个月缩短到 1 个月
高级工程师释放: 重复问题处理时间减少 50%
系统构建:
Agent 设计:
问题诊断 Agent: 分析客户描述 → 识别问题类型 → 提取关键信息
方案检索 Agent: 根据问题特征 → 检索知识库 → 排序推荐
回复生成 Agent: 组织解决方案 → 生成回复 → 附带文档引用
知识更新 Agent: 从新对话中提取新知识 → 更新知识库
Memory:
- 客户环境: 产品版本、部署方式、配置信息
- 历史问题: 该客户历史工单和解决方案
- 问题上下文: 当前诊断进展
RAG:
- 产品文档: API 文档、配置指南、故障排除手册
- 解决方案库: 300+ 篇结构化解决方案
- 已知问题库: Bug 列表 + Workaround
- Slack 精华: 从群聊中提取的技术讨论
审计规则:
- 低风险: 文档引用、常见问题解答
- 中风险: 配置建议、Workaround 推荐
- 高风险: 数据库操作建议、生产环境变更建议
审计放行:
RAX 评估:
风险: 中(错误技术建议可能导致客户系统故障)
接受度: 高(技术支持团队对知识系统需求强烈)
体验: 中(技术准确性需持续优化)
放行条件: 附条件通过
约束:
- 技术建议必须附带文档引用
- 涉及生产环境操作的建议必须高级工程师确认
- 数据库操作建议必须双人审核
生产运行:
可观测性:
- 首响时间: 平均值 + P95
- 解决率: 一次解决率
- 采纳率: 技术支持工程师采纳率
- 知识覆盖率: 已沉淀方案占历史问题的比例
反馈回灌:
- 每次新问题解决 → 自动抽取并更新知识库
- 每次方案不准确 → 标记并修正
- 每次知识未命中 → 标记知识缺口
客户循环:
- 选择 5 个典型客户深度合作
- 每周收集技术支持团队反馈
价值发现:
- 效率信号: 首响时间、解决时间、人均处理量
- 知识信号: 知识库查询频率、覆盖率趋势
- 人员信号: 新人成长速度、高级工程师时间分配
关键决策点
| 决策点 | 选择 | 理由 |
|---|---|---|
| 产品形态 | 工作台模式 | 技术问题复杂,需要多步骤诊断 |
| 第一批能力 | 问题理解 + 方案检索 | 解决知识碎片化核心痛点 |
| 知识来源 | 产品文档 + 解决方案库 + Slack 精华 | 覆盖结构化和非结构化知识 |
| 高风险处理 | 高级工程师确认 | 涉及客户生产环境,风险较高 |