52 lines
3.9 KiB
Markdown
52 lines
3.9 KiB
Markdown
---
|
||
title: "Customer Service Agent"
|
||
type: source
|
||
tags: [customer-service, agent, support, retention, escalation]
|
||
date: 2026-05-02
|
||
---
|
||
|
||
## Source File
|
||
- [[Agent/agency-agents/specialized/customer-service.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：通用行业客户服务 Agent 的角色定义与全流程操作规范——面向零售/SaaS/酒店/金融/电信/医疗行政/物流等多行业的全能客服专家，强调同理心优先、承诺必达、主动升级
|
||
- 问题域：客户咨询/投诉/账户管理/订单处理/取消挽留/升级转接的全场景覆盖
|
||
- 方法/机制：五步工作流（Greet & Assess → Understand → Resolve or Route → Confirm & Close → Document），配合十大关键规则（Empathy First、No Blame、Own the Problem、Proactive Escalation 等）
|
||
- 结论/价值：为跨行业客服场景提供标准化、可量化的 Agent 行为规范，涵盖 6 大行业、5 大渠道、10 项可追踪 KPI
|
||
|
||
## Key Claims（用中文描述）
|
||
- 客户服务的本质是哲学而非部门——每一个联系进来的客户都值得感到被重视、被理解
|
||
- 在任何政策或流程之前，必须先承认客户感受，否则无法建立信任
|
||
- 永远不要在没有提供替代方案的情况下说"那不可能"——总有你能做的事
|
||
- 永远不要把愤怒的客户置于等待状态而不征询同意——必须给予等待时间估计并提供回调选项
|
||
- 在客户沮丧爆发之前主动升级——识别早期信号并框架化地提供升级选项
|
||
- 绝不做出无法兑现的承诺——失信比原始问题更快地摧毁信任
|
||
- 每个取消请求都必须经过真诚的挽留尝试——永远不要立即处理取消
|
||
- 每次互动都必须记录——完整记录以便下一位代理或专员有充分上下文
|
||
|
||
## Key Quotes
|
||
> "Customer service isn't a department — it's a philosophy. Every person who reaches out deserves to feel like they matter, their issue is understood, and someone is genuinely working to help them." — 核心服务哲学
|
||
> "Every customer interaction is a chance to turn a problem into loyalty — handle it with care, speed, and a human touch." — 互动即忠诚转化机会
|
||
|
||
## Key Concepts
|
||
- [[EmpathyFirst]]：同理心优先——在任何政策、流程、解决方案之前必须先承认客户的感受
|
||
- [[ComplaintResponseProtocol]]：投诉响应协议（ACK/VIND/ACT 五步：Acknowledge → Validate → Clarify → Act → Commit）——绝不跳过承认步骤
|
||
- [[RetentionProtocol]]：挽留协议——绝不立即处理取消请求，必须先了解原因并提供替代方案
|
||
- [[EscalationProtocol]]：升级协议——立即/紧急/标准三级触发条件，Always Warm Transfer
|
||
- [[ActiveListening]]：主动倾听——在回应之前完整反射客户所述内容
|
||
|
||
## Key Entities
|
||
- [[HealthcareCustomerService]]：医疗客户服务 Agent — 与通用客服 Agent 共享投诉处理框架和升级协议，但医疗场景要求 HIPAA 强制身份验证
|
||
|
||
## Connections
|
||
- [[HealthcareCustomerService]] ← analogous_to ← [[CustomerService]]（两者共享投诉处理框架和升级协议，医疗场景额外要求 HIPAA 合规）
|
||
- [[HospitalityGuestServices]] ← analogous_to ← [[CustomerService]]（酒店客服 Agent 是通用客服 Agent 在款待业场景的具体化，HEARD 框架与通用投诉协议互通）
|
||
- [[SupportResponder]] ← extends ← [[CustomerService]]（通用客服响应 Agent 是 Customer Service Agent 的抽象层）
|
||
|
||
## Contradictions
|
||
- 与 [[LegalClientIntake]] 冲突（由 [[HealthcareCustomerService]] 记录）：
|
||
- 冲突点：身份验证严格程度在不同场景的差异
|
||
- 当前观点（通用客服）：基于姓名 + 邮箱验证即可开始处理账户操作
|
||
- 对方观点（医疗场景）：HIPAA 要求全名 + 出生日期 + SSN 后四位方可讨论 PHI
|
||
- 注：两者场景不同，冲突源于场景差异而非事实矛盾，可共存
|