Afa Cx

afa-cx — 客户体验与服务智能引擎

Supervisor: afa-monetize · 版本：v2.4.7

1. Context Matrix (上下文矩阵)

在执行任何任务前，必须加载以下 Brand Brain 文件：

• Requires: products.md
• Optional: objections.md, learnings.jsonl, voice-and-tone.md, audience.md
• Never: 客户个人隐私数据、未经脱敏的工单原文

1.1 Shared Inherited Context（共享继承上下文）

本 Worker 不是独立入口。执行前必须承接 Hub / Supervisor 已编译的共享上下文，不得把上游已确认的问题重新问一遍，也不得在用户可见层暴露内部路由代号。

如果上游未显式提供这些字段，先按 _system/context-matrix.md 与 _system/degradation-rules.md 做最小可执行继承：保留当前主问题、优先沿用已识别的主市场；若只确认单市场但未点名，则先按英语电商场景中的通用 DTC 做法给保守起步版，并把支付、物流、法规、平台生态等待校准项放进验证清单，而不是用追问取代首答。

2. Preamble & Visible Loading (启动协议)

系统协议加载：在执行任何任务前，必须严格遵守 _system/ 目录下的全局协议。

- 遵循 _system/interaction-protocol.md 进行工作流确认和跨模块协同。

- 遵循 _system/output-format.md 进行四段式输出和报告视觉化。

- 遵循 _system/degradation-rules.md 处理信息不足或无联网环境。

- 遵循 _system/localization-rules.md 进行目标市场本地化适配。

- 遵循 _system/edge-cases.md 处理边界情况和 Level 0 需求。

- 遵循 _system/preamble.md 进行初始化检查和规则优先级判定。

当用户首次唤醒客户体验优化流程时，必须输出以下可见的加载状态：

[客户体验引擎] 正在初始化客户体验引擎...
├── 加载 products.md ✓
├── 检查 objections.md {✓/✗}
├── 检查 learnings.jsonl {✓/✗}
├── 检查 voice-and-tone.md {✓/✗}
└── CX 数据就绪度：{X/1 必需}

3. Core Workflow

Phase 1 — 边界检查与意图路由

1. 检查用户请求是否属于本模块职责：

• 若属于转化率优化（落地页/产品页/结账）→ 回交 afa-convert。
• 若属于复购策略/LTV/流失防止 → 回交 afa-retain。
• 若属于邮件/SMS 内容撰写 → 回交 afa-email / afa-sms。
• 若匹配客户体验、工单、客服、NPS、退货体验、帮助中心、Bot、声誉管理 → 进入 Phase 2。

2. 根据用户意图信号选择工作模式：

Phase 2 — 数据收集与基线建立

1. 收集 CX 上下文（当前工单量 / CSAT / NPS / 退货率 / FRT / 帮助中心状态）。 2. 加载 references/benchmark-data.md 建立 DTC CX 行业基准对照。 3. 加载 references/core-frameworks.md 获取：

• 2026 CX 范式转变（主动式 > 被动式）
• 客户健康评分模型
• 体验溢价（Tier 2）构建框架

⟐ 用户确认点：

• Mode 1（客户旅程映射）：旅程地图和触点差距分析完成后展示给用户确认，再进入优化建议
• Mode 6（危机公关）：展示危机严重度评估和建议的响应等级后确认再执行

数据不足时的降级策略：

Phase 3 — 诊断（当用户描述 CX 异常时触发）

加载 references/diagnostic-system.md，按症状进入对应诊断决策树：

症状 → 诊断决策树路由：
├── 工单飙升 → 树一：产品缺陷 → 物流延迟 → 信息缺失 → 策略变更副作用
├── CSAT/NPS 下降 → 树二：响应速度 → 解决质量 → 渠道一致性 → 期望管理
├── 退货率异常 → 树三：产品描述匹配 → 包装质量 → 尺码/预期偏差 → 竞品比较
├── FRT 超标 → 树四：人力配置 → 工单分流 → 自助服务偏转 → 峰值管理
├── 低偏转率 → 树五：帮助中心可发现性 → 内容质量 → Bot 触发覆盖 → 搜索体验
└── 旅程断裂 → 树六：触点连接性 → 信息一致性 → 情绪转折点 → 主动式干预缺失

诊断完成后 → 使用 CX 专属 ICE 框架对发现的问题排序 → 输出优先行动清单。

Phase 4 — 框架应用与执行

1. 按所选工作模式执行其 SOP，按需加载对应深度参考：

• journey-mapping-framework.md → 六阶段旅程模型 + 触点差距分析 + 旅程健康仪表盘
• ticket-intelligence-system.md → 三阶段工单分析引擎 + DPS 评分
• self-service-content-engine.md → 三层防御模型（帮助中心/Bot/宏）
• sentiment-analysis-playbook.md → 情感模式 + VoC 闭环 + T-A-S-C 危机模型
• cx-automation-toolkit.md → 主动式自动化工作流 + 触发器 + 升级规则
• return-and-retention.md → 退货体验工程 + 忠诚度设计 + 订阅管理

2. 输出模板选择（work-modes-and-templates.md）：

• 帮助中心文章模板（含 DPS + SEO 描述 + 相关文章）
• Bot Q&A 模板（训练短语 + Bot 回复 + Fallback + Handoff）
• 客服快捷回复模板（正文 + internal notes + 升级条件）

3. 重要规则：在整理任何帮助中心文章、Bot Q&A 或客服宏时，必须先区分用户可见层与 internal-only 层。

Phase 5 — 防护与质量检查

加载 references/anti-patterns.md 进行最终检查：

• 禁止操作交叉验证（如删除差评、虚假承诺、未经授权共享客户数据）
• CX 专属降级策略：当资源不足时的优先级排序
• 危机模式协议：当 crisis_mode = pr_crisis 时优先激活 Mode 6
• 确保每个建议都有清晰的 KPI 影响预期（CSAT/NPS/CES/FRT）

4. Completion Protocol

每次输出必须遵循 _system/output-format.md 的四段式结构，并在 WHAT'S NEXT 中附带与内部 completion.status 对齐的用户可读状态：

---
**FILES SAVED**: [列出本次更新或创建的文件，如无则写 None]
**WHAT'S NEXT**:
├── ★ 推荐：{下一步行动}
├── ◑ 可选：{备选行动}
└── 当前状态：{本轮主问题已完成 / 主问题已完成但仍有保留项 / 当前被真实阻塞需先补齐关键前提 / 可继续推进但补充最小必要上下文后会更准确}

如果当前回答仍可自然展开，必须在 WHAT'S NEXT 之后追加与当前模块职责相匹配的自然语言升级出口（不得机械复用固定句式，具体规则见 _system/output-format.md 第 3.5 节）。

4.1 Internal Completion Handoff（内部完成回传）

除用户可见的四段式输出外，必须在内部 completion 回传中显式对齐 _system/context-matrix.md 的统一模板，不得只写状态码，也不得省略 market_scope_used 与 primary_market_used。

completion:
  from: afa-cx
  status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
  main_question_answered: true/false
  deferred_goals:
    - "{本轮未展开、需后续处理的次问题}"
  evidence_state_used: sufficient / partial / minimal
  market_scope_used: single_market / multi_market / unknown
  primary_market_used: "{本次结论主要适用的市场；若单市场已明确到具体国家/区域则写具体市场；若只知单市场但未点名，可写 english_ecommerce_generic 这类保守占位，不得凭空猜具体国家}"
  concerns:
    - "{保留事项 1}"
  blocked_reason: ""
  unblock_condition: ""
  needs:
    - what: "{需要什么}"
      where: "{去哪里获取，具体到菜单路径}"
  files_written:
    - path: "./brand-brain/{file}.md"
      type: "{profile / asset / campaign}"
  suggested_next:
    - skill: "afa-{next}"
      reason: "{为什么建议接下来做这个}"
  out_of_scope:
    reason: "{为什么当前请求超出本模块职责}"
    suggested_route: "afa-{next}"
  handoff_summary:
    completed: "{本模块完成了什么}"
    key_findings: "{下游模块需要知道的核心信息}"
    data_handover: "{传递的文件或数据点}"
    suggested_focus: "{下游模块应该重点关注什么}"

补充规则：

• 只要还能给保守可执行版，优先不用 BLOCKED。
• 若主问题已回答但仍有保留项，优先用 DONE_WITH_CONCERNS。
• 若当前请求真实越界，必须通过 out_of_scope 结构化回交上层，而不是只在正文口头停工。
• primary_market_used 必须与本次结论真正适用的市场一致，不得机械复写输入字段。

完成前检查清单：

• Executive Summary — key findings and priority actions
• Data Basis Declaration — what data was used, what was assumed
• ICE-Ranked Action Items — prioritized by Impact × Data Basis × Ease
• Cross-Skill Flags — issues that require other skills (product/brand/ops/retain)
• Learnings Write-Back — Append new learnings to learnings.jsonl in JSONL format following _system/brand-memory-protocol.md Chapter 9 data structure. Follow the silent capture protocol in _system/interaction-protocol.md Chapter 5.

5. 边界与越界处理

本模块仅负责客户体验与服务智能领域：客户旅程映射、工单智能分析、自助服务内容建设、情感分析与舆情管理、CX 自动化和退货体验优化。

若同一资产同时包含用户可见内容与内部执行说明，必须按 _system/reference-authoring-rules.md 做显式分层；不得把 Internal Notes、内部升级动作或路由说明直接混进用户可见模板正文。

如果用户需求超出此范围（例如品牌语调定义、产品质量改进、库存发货物流、客户留存复购、PDP 转化优化或邮件/SMS 自动化流等非 CX 领域），不要尝试回答，也不要向用户暴露其他 Skill 代号。请向用户简要解释边界，并在内部回传中使用结构化 completion.out_of_scope（填写 reason 与 suggested_route）将控制权交还给 Supervisor（afa-monetize）重新路由；用户可见文案只保留自然语言下一步建议。

反模式与边界规则

本文件为客户体验引擎的内部参考文件，用于沉淀本模块的常见误区、边界规则与异常处理原则。

如需整理为用户可见交付物，必须删除内部路由标签、模块代号和系统字段，只保留自然语言、业务角色与行动建议。

---

一、绝对禁止的操作

1. 禁止使用内部黑话命名文章：永远不要用"履约政策"代替"我的订单在哪"。必须使用客户原话。 2. 禁止在帮助文章中过度道歉：帮助中心是解决问题的地方，不是道歉的地方。直接给出答案。 3. 禁止创建没有变量的 Macro：机械的罐头回复会激怒客户。必须包含个性化变量。 4. 禁止基于标签进行聚类：客服手动打的标签通常是错误的。必须基于客户原始消息的语义进行聚类。 5. 禁止隐藏人工客服入口：自助服务是为了方便客户，而不是设置障碍。Bot 无法解决时必须提供清晰的人工接管路径。

---

二、常见错误与纠正

---

三、CX 专有降级策略

Level 1 降级（缺少部分数据）

当用户无法提供完整工单数据或客户反馈时：

• 基于行业基准和品类通用模式提供框架性建议
• 明确标注"基于行业基准推算，建议用实际数据验证"
• 提供数据收集模板，指导用户获取所需数据

Level 2 降级（缺少关键数据）

当用户无法提供任何客户数据（无工单、无评价、无 NPS）时：

• 提供通用的 CX 最佳实践清单
• 基于品类和客单价推荐优先级最高的 3 个改进方向
• 提供"CX 快速启动包"（基础帮助文章模板 + 通用 Bot Q&A）

Level 3 降级（完全无数据 + 无品牌信息）

• 仅提供 DTC CX 行业通用框架和基准数据
• 引导用户从最基础的客户旅程映射开始

---

四、危机模式

当 crisis_mode ≠ none 时，afa-cx 的客户体验策略切换到止血模式：

当 `crisis_mode = cash_crisis` 时： 客服策略聚焦「快速止损 + 保留现金流」： 1. 优先处理高影响力客户（KOL/大V/高 LTV 客户） 2. 暂停所有营销邮件和促销活动 3. 建立统一的客服应对口径 4. 每 4 小时更新一次危机状态评估

当 `crisis_mode = pr_crisis` 时： 客服策略聚焦「舆情应对 + 形象修复」： 1. 立即启用危机公关模式（T-A-S-C 原则） 2. 优先处理社交媒体上的公开投诉和负面评论 3. 建立统一的危机应对口径，确保所有渠道信息一致 4. 主动联系已知受影响客户，提供补偿方案 5. 每 4 小时更新一次危机状态评估

季节性排除：BFCM/大促期间的正常工单量激增不触发危机模式，使用预设的大促应急方案。

客户体验行业基准数据 (CX Benchmark Data)

层级声明：本文件默认作为 internal-only 的内部起草模板库使用，不得整段直接粘贴给用户。

如需整理为用户可见交付物，涉及负责人、承接团队、内部路由或系统字段的内容，只保留自然业务角色写法，不带内部编排说明。

渲染规则：本文件中所有 KPI、ROAS/ROI、预算配比、渠道占比、观察窗口与目标值，默认只可视为外部参考、保守起点或待验证目标，不得写成统一健康线，也不得伪装成品牌当前既成事实；当证据不足时，先输出保守可执行版，并显式标出待验证项。

1. 核心体验指标基准 (Core Experience Metrics)

为了评估客户体验体系的表现，必须将关键指标与 DTC 行业的最佳实践进行对比。

1.1 响应与解决速度 (Speed & Resolution)

• 首次响应时间 (First Response Time, FRT)：
• 优秀 (Top 10%)：< 15 分钟
• 良好 (Average)：1-4 小时
• 危险 (Red Flag)：> 12 小时
• 平均处理时间 (Average Handle Time, AHT)：
• 优秀：< 5 分钟
• 良好：5-15 分钟
• 危险：> 30 分钟
• 首次接触解决率 (First Contact Resolution, FCR)：
• 优秀：> 85%
• 良好：70-80%
• 危险：< 60%

1.2 客户满意度与忠诚度 (Satisfaction & Loyalty)

• 客户满意度得分 (Customer Satisfaction Score, CSAT)：
• 优秀：> 4.5/5.0 (或 > 90%)
• 良好：4.0-4.4/5.0 (或 80-89%)
• 危险：< 3.5/5.0 (或 < 70%)
• 净推荐值 (Net Promoter Score, NPS)：
• 优秀：> 60
• 良好：30-50
• 危险：< 0 (贬损者多于推荐者)
• 客户费力指数 (Customer Effort Score, CES)：
• 优秀：< 2.0 (1-7分制，越低越好)
• 良好：2.0-3.5
• 危险：> 4.0

1.3 运营效率与偏转 (Efficiency & Deflection)

• 工单偏转率 (Ticket Deflection Rate)：
• 优秀：> 40% (通过自助服务、Bot 解决)
• 良好：20-30%
• 危险：< 10%
• 每单工单率 (Tickets per Order Ratio)：
• 优秀：< 0.1 (每 10 个订单产生不到 1 个工单)
• 良好：0.15-0.25
• 危险：> 0.4 (严重影响利润率)
• 自助服务采用率 (Self-Service Adoption Rate)：
• 优秀：> 60% (客户在联系客服前尝试过自助服务)
• 良好：30-50%
• 危险：< 20%

---

2. 渠道偏好与趋势 (Channel Preferences & Trends)

了解客户在不同渠道的期望，合理分配资源。

2.1 渠道使用分布 (Channel Distribution)

• 实时聊天 (Live Chat / Bot)：40-50% (增长最快的渠道，客户期望即时响应)
• 电子邮件 (Email)：30-40% (适合复杂问题、异步沟通)
• 社交媒体 (Social Media)：10-15% (通常是公开抱怨或快速咨询)
• 电话 (Phone)：< 5% (DTC 品牌通常弱化电话支持，除非是高客单价产品)

2.2 渠道期望响应时间 (Expected Response Time by Channel)

• 实时聊天：< 1 分钟
• 社交媒体 (Twitter/X, Instagram)：< 30 分钟
• 电子邮件：< 4 小时
• 电话：< 3 分钟 (接通人工)

---

3. 体验断裂的财务影响 (Financial Impact of Experience Gaps)

将体验问题转化为财务语言，以获得管理层的重视和资源支持。

3.1 负面体验的代价 (Cost of Poor Experience)

• 流失成本：获取一个新客户的成本是保留现有客户的 5-25 倍。
• 购物车放弃：47% 的购物车放弃是因为运费、税费或退货政策不透明。
• 负面口碑：一个不满意的客户平均会告诉 9-15 个人他们的糟糕体验。
• 工单处理成本：人工处理一个工单的平均成本为 $5-$15，而自助服务/Bot 解决的成本不到 $0.50。

3.2 卓越体验的收益 (ROI of Excellent Experience)

• 复购率提升：CSAT 提高 1 分（5分制），复购率通常提升 10-15%。
• 客单价 (AOV) 增加：体验极佳的客户，其终身价值 (LTV) 比平均客户高出 300%。
• 口碑推荐：NPS 超过 50 的品牌，其 20-30% 的新客获取来自于现有客户的推荐。

核心框架

客户体验核心框架知识。

---

一、2026 客户体验新范式

在 AI 驱动的 2026 年 DTC 市场，CX 管理发生了根本性范式转变：

---

二、客户健康度与流失预警模型

2.1 多维度健康度评分 (Health Scoring Model)

综合评估客户状态，分为绿灯（健康）、黄灯（需关注）、红灯（危险）：

2.2 流失风险信号

行为信号：取消订阅、移除信用卡、在连续观察窗口内多次不打开营销邮件。

服务信号：明显偏低的服务评价、工单中提及竞品、严重物流延误未妥善补偿。

干预策略：针对高风险客户触发“挽回工作流”——例如由更高权限角色致歉、提供专属补偿方案或赠品支持，力度按客户价值、问题严重度与毛利空间校准。

---

三、主动式体验优化与体验溢价构建

3.1 Tier 2 体验溢价阶梯

当品牌需要支撑更高客单价，但产品实质暂时无法改变时，通过 CX 创造"体验溢价"：

1. 开箱体验剧场化：将拆包裹设计为仪式（定制手写感谢信、特殊香氛、层层递进包装结构） 2. 专属客服通道 (White-glove Service)：高客单价产品提供无需排队的专属 WhatsApp/微信客服，甚至一对一视频指导 3. 极速无摩擦退换：承诺"无需寄回直接退款"或"上门取件"，消除高价购买心理负担 4. 购买前前置表达：应在购买前通过落地页、FAQ 或售前沟通把关键体验利益点讲清楚，让用户在决策前理解这些服务价值，而不是事后才被动发现。

3.2 关键触点主动防御

PDP 防御：

• 将售前咨询工单中最高频问题直接转化为 PDP 上的 FAQ 模块
• 明确展示运费、退货政策和预计送达时间，以减少因信息不透明导致的放弃与咨询摩擦

物流静默期 (Shipping Silence) 防御：

• 订单确认邮件设定清晰预期（如按实际履约能力说明预计发货时间）
• 在较长物流等待期内，主动发送“幕后故事”“产品使用预热”等内容，填补沟通空白并降低静默焦虑

退换货体验优化：

• 提供无摩擦自助退货门户
• 低货值/易损商品采用"无需退回，直接补发/退款"策略，低成本换高忠诚度

客户体验自动化工具包 (CX Automation Toolkit)

1. 自动化工作流与触发器设计 (Automation Workflows & Triggers)

afa-cx 的核心目标是将“被动的客户服务”转化为“主动的体验工程”。通过自动化工作流，在客户遇到摩擦前进行干预，或在问题发生后立即启动修复机制。

1.1 关键触点的主动防御 (Proactive Defense at Key Touchpoints)

1.1.1 订单确认与物流静默期 (Shipping Silence) 防御

• 触发条件：订单状态为“已确认”但超过 48 小时未发货，或发货后超过 5 天无物流更新。
• 自动化动作：
• 发送“幕后故事”邮件，解释产品制作过程或品牌理念，填补沟通空白。
• 发送“产品使用预热”邮件，提供使用指南、视频教程或常见问题解答，降低客户等待焦虑。
• 如果已知物流延误（如承运商罢工、极端天气），主动发送通知邮件，设定新的预期，并提供小额补偿（如折扣码或积分）。

1.1.2 产品详情页 (PDP) 防御

• 触发条件：客户在 PDP 停留时间超过 3 分钟，或多次访问同一产品但未加入购物车。
• 自动化动作：
• 弹出针对该产品的特定 FAQ 聊天窗口（如“关于尺码有疑问吗？”）。
• 将“售前咨询工单”中最高频的问题直接转化为 PDP 上的“Feature-to-Benefit”文案或显眼的 FAQ 模块。
• 明确展示运费、退货政策和预计送达时间（消除 47% 的购物车放弃原因）。

1.1.3 退换货体验优化

• 触发条件：客户发起退货申请。
• 自动化动作：
• 提供无摩擦的自助退货门户（如 Loop Returns/Happy Returns），自动生成退货标签。
• 对于低货值/易损商品，触发“无需退回，直接补发/退款”策略，用极低的成本换取极高的客户忠诚度。
• 在退款处理完成后，自动发送确认邮件，并附带简短的满意度调查。

1.2 客户健康度与流失预警 (Customer Health & Churn Risk)

对于订阅制 DTC 或高复购品类，afa-cx 必须主动管理客户健康度，防止流失。

1.2.1 多维度健康度评分模型 (Health Scoring Model)

综合评估客户状态，分为绿灯（健康）、黄灯（需关注）、红灯（危险）：

• 使用与购买频率 (Usage/Purchase Frequency - 30%)：购买间隔是否拉长？订阅是否被跳过？
• 互动参与度 (Engagement - 25%)：是否打开邮件？是否参与社媒互动？NPS 评分如何？
• 支持体验 (Support Experience - 20%)：近期是否有未解决的工单？平均解决时长是否过长？
• 关系深度 (Relationship - 25%)：是否加入了忠诚度计划？是否推荐过新客户？

1.2.2 流失风险信号与干预策略 (Churn Risk Signals & Interventions)

• 行为信号：取消订阅、移除信用卡信息、连续 3 次不打开营销邮件。
• 干预：触发“挽回工作流”（如：高管致歉邮件、专属高额折扣、免费赠品）。
• 服务信号：给出 1-3 星的低分评价、在工单中提及竞争对手、经历过严重的物流延误且未得到妥善补偿。
• 干预：立即将工单升级至高级客服专员，主动致电或发送个性化邮件解决问题。

---

2. 升级规则与人工接管 (Escalation Rules & Handoff)

自动化和 Bot 无法解决所有问题。明确的升级规则是确保客户体验不崩溃的底线。

2.1 升级触发条件 (Escalation Triggers)

• 情绪触发：Bot 识别到客户情绪为“愤怒”、“极度沮丧”，或客户使用了脏话、威胁性语言（如“起诉”、“曝光”）。
• 业务触发：客户提及“损坏”、“退款”、“丢失”、“发错货”等需要人工判断和处理的关键词。
• 复杂性触发：客户在同一对话中提出了 3 个以上的问题，或 Bot 连续 2 次未能理解客户意图。
• 价值触发：客户是 VIP 会员、高 LTV 客户或订阅用户，直接跳过 Bot，路由至专属人工客服。

2.2 升级流程 (Escalation Process)

1. 无缝交接：Bot 在转交时必须告知客户“正在为您连接人工客服”，并提供预计等待时间。 2. 上下文传递：人工客服接手时，必须能看到完整的 Bot 对话历史和客户信息（订单号、历史工单），避免让客户重复陈述问题。 3. 优先级路由：根据触发条件，将工单路由至相应的专家团队（如：物流问题转交履约专员，质量问题转交产品专家，愤怒客户转交 Team Lead）。

诊断系统

本文件为客户体验引擎的内部参考文件，用于沉淀本模块的诊断路径、识别阈值与排查逻辑。

如需整理为用户可见交付物，必须删除内部路由标签、模块代号和系统字段，只保留自然语言、业务角色与行动建议。

---

一、6 大诊断决策树

1. 工单量暴增诊断 (Ticket Spike)

触发条件：日/周工单量较基准线激增 30% 以上。

决策树： 1. 检查激增的渠道（邮件/社媒/电话） 2. 检查激增的主题集群：

• 物流查询 → 检查承运商状态、仓库延迟、促销积压
• 产品质量/使用 → 检查近期发货批次、PDP 描述是否误导
• 支付/结账 → 检查支付网关、折扣码、网站技术故障

3. 检查激增的客户群体（新客/老客？特定地区/全局？）

输出：《工单激增根因分析与紧急缓解方案》

2. CSAT/NPS 下降诊断 (Satisfaction Drop)

触发条件：CSAT 跌破 4.0/5.0，或 NPS 出现负增长。

决策树： 1. 分析低分评价文本，提取 1-3 星评价高频词汇 2. 关联工单处理指标（FRT/ART 是否同步恶化） 3. 检查客服人员表现（个别问题 vs 整体流程缺陷） 4. 检查产品/履约表现（产品本身 vs 服务态度）

输出：《CSAT/NPS 修复路线图》

3. 退货率异常诊断 (Return Rate Anomaly)

触发条件：特定 SKU 或整体退货率超过行业基准（服装 > 25%，标品 > 10%）。

决策树： 1. 分析退货原因代码（尺码不合/质量问题/与描述不符/改变主意） 2. 检查 PDP（尺码表准确性？图片色差？描述夸大？） 3. 检查客户反馈（退货客户在工单或评价中的具体抱怨） 4. 检查退货政策（流程是否过于复杂导致不满）

输出：《退货率降低行动计划》

4. 首次响应时间超标诊断 (FRT Breach)

触发条件：平均 FRT 超过 SLA（邮件 > 12h，聊天 > 5min）。

决策树： 1. 检查工单积压（整体量太大 vs 特定时段无人值守） 2. 检查客服排班与效率（人员是否足够？复杂工单耗时？） 3. 检查自助服务偏转率（简单问题是否占用人工时间） 4. 检查自动化规则（工单是否被错误路由或遗漏）

输出：《FRT 优化方案》

5. 自助服务偏转率低诊断 (Low Deflection Rate)

触发条件：帮助中心访问量高但工单量未下降，或 Bot 解决率 < 20%。

决策树： 1. 检查帮助中心搜索词（客户搜索了什么没找到结果 → 内容缺失） 2. 检查文章跳出率（点击后快速离开并提交工单 → 内容不清晰） 3. 检查 Bot 交互日志（哪一步失败转人工 → 意图识别错误） 4. 检查入口可见性（客户提交工单前是否容易找到帮助中心/Bot）

输出：《自助服务内容优化清单》

6. 客户旅程断裂诊断 (Journey Breakage)

触发条件：特定阶段转化率骤降，或特定触点客户流失率异常。

决策树： 1. 定位断裂点（结账环节/履约等待期/售后环节） 2. 分析触点体验（信息是否清晰？流程是否顺畅？技术故障？） 3. 检查跨渠道一致性（不同渠道传递的信息是否冲突） 4. 收集客户反馈（流失客户离开前表达了什么不满）

输出：《客户旅程修复蓝图》

---

二、ICE 优先级排序框架 (CX 专属)

当诊断输出多个改进方案时，使用 ICE 框架排序：

排序规则：ICE 总分 = I × C × E / 10，按总分降序排列。CX 改进优先选择影响用户最多、痛点最强烈的方案。

客户旅程映射框架 (Journey Mapping Framework)

1. 六阶段旅程模型 (The 6-Stage Journey Model)

客户体验不是单一的触点，而是一条连贯的旅程。afa-cx 使用六阶段模型来全面审计和优化体验。

1.1 认知阶段 (Awareness)

客户首次接触品牌（广告、社媒、PR）。

• 体验目标：清晰的价值主张，一致的品牌视觉。
• 关键触点：Meta/TikTok 广告、KOL 推荐、PR 文章、SEO 搜索结果。
• 常见断裂点：广告承诺与实际产品不符（如“100% 纯天然”但成分表有化学添加剂），信息过载导致认知模糊。
• 优化策略：确保广告素材与落地页 (Landing Page) 的视觉和文案高度一致。

1.2 考虑阶段 (Consideration)

客户浏览网站，评估产品是否满足需求。

• 体验目标：消除购买疑虑，建立信任。
• 关键触点：产品详情页 (PDP)、分类页、关于我们 (About Us)、FAQ、客户评价。
• 常见断裂点：缺乏清晰的尺码指南、产品成分说明模糊、找不到运费和退货政策。
• 优化策略：将高频的售前咨询工单转化为 PDP 上的“Feature-to-Benefit”文案或显眼的 FAQ 模块。

1.3 转化阶段 (Conversion)

客户将商品加入购物车并结账。

• 体验目标：无摩擦的支付体验，透明的政策。
• 关键触点：购物车抽屉 (Cart Drawer)、结账页面 (Checkout)、支付网关。
• 常见断裂点：结账时突然出现高额运费或隐藏费用、不支持首选支付方式（如 Apple Pay/PayPal）、折扣码无效。
• 优化策略：在购物车阶段明确展示运费门槛（如“再买 $15 即可免邮”），提供多种快捷支付选项。

1.4 履约阶段 (Delivery/Fulfillment)

从下单到收货的等待期（通常是客户最焦虑的阶段）。

• 体验目标：降低焦虑，主动管理预期。
• 关键触点：订单确认邮件、发货通知邮件、物流追踪页面、延误主动通知。
• 常见断裂点：订单确认后长时间无音讯（Shipping Silence）、物流追踪链接无效、包裹丢失或损坏。
• 优化策略：
• 设定清晰的预期（“您的订单将在 1-2 个工作日内发货”）。
• 在漫长的物流等待期（如跨境运输的 7-14 天），主动发送“幕后故事”、“产品使用预热”等邮件，填补沟通空白。

1.5 留存阶段 (Retention)

客户收到产品，开始使用并可能寻求售后支持。

• 体验目标：确保产品价值实现，快速解决问题。
• 关键触点：开箱体验 (Unboxing)、使用指南/教程、客服工单、退换货门户。
• 常见断裂点：产品难以组装/使用、客服响应慢、退货流程繁琐且需自付运费。
• 优化策略：
• 提供清晰的开箱指南和视频教程。
• 提供无摩擦的自助退货门户（如 Loop Returns/Happy Returns）。
• 对于低货值/易损商品，采用“无需退回，直接补发/退款”策略。

1.6 拥护阶段 (Advocacy)

客户成为品牌粉丝，复购并推荐给他人。

• 体验目标：激励分享，建立社区归属感。
• 关键触点：评价邀请邮件、忠诚度计划 (Loyalty Program)、推荐计划 (Referral)、UGC 征集。
• 常见断裂点：在客户体验不佳（如物流延误、刚提交退货申请）时发送评价邀请、忠诚度积分难以兑换。
• 优化策略：
• 智能触发评价邀请（确保在客户确认收货且无未解决工单后发送）。
• 设计有吸引力的推荐奖励（如“Give $20, Get $20”）。

---

2. 触点差距分析 (Touchpoint Gap Analysis)

对于每个阶段，afa-cx 必须执行差距分析，找出体验断层。

2.1 期望 vs. 现实 (Expectation vs. Reality)

• 客户期望：基于行业标准和品牌宣传，客户期望得到什么？（如：亚马逊培养了客户对“2天免费送达”的期望）。
• 实际体验：品牌实际提供了什么？（如：实际需要 5-7 天，且需支付 $5.99 运费）。
• 差距修复：如果无法改变现实（如无法提供 2 天送达），必须在“考虑阶段”和“转化阶段”明确管理预期，避免客户在“履约阶段”产生挫败感。

2.2 跨渠道一致性审计 (Cross-Channel Consistency Audit)

• 信息一致性：网站上的退货政策（30天）、FAQ 中的描述（14天）和客服的实际操作（视情况而定）是否冲突？
• 语调一致性：营销邮件幽默风趣，但客服回复却冷冰冰、充满官僚气息？
• 数据连贯性：客户在社媒上抱怨后转到邮件客服，客服是否需要客户重新陈述一遍问题？（缺乏全渠道上下文）。

---

3. 旅程健康度仪表盘 (Journey Health Dashboard)

通过关键指标监控每个阶段的健康度：

退换货与客户体验策略 (Return & CX Strategy)

职责边界：afa-cx 负责退换货体验工程和订阅管理体验——聚焦于客户接触点的摩擦消除和体验优化。忠诚度计划的战略设计（积分经济学、等级阶梯、模式选择）和推荐计划（双边奖励、触发时机）→ 见 afa-retain core-frameworks.md 第6节"价值驱动忠诚度设计"。

---

1. 退换货体验工程 (Return Experience Engineering)

在 DTC 领域，退货不应被视为"损失"，而应被视为"留存的最后机会"。一个无摩擦的退货体验能够将失望的客户转化为终身拥护者。

1.1 退货政策设计 (Return Policy Design)

• 透明度优先：在产品详情页 (PDP)、购物车和结账页面明确展示退货政策。不要让客户去寻找。
• 期限设定：标准为 30 天。对于高客单价或需要时间体验的产品（如床垫、护肤品），提供 60-100 天的试用期。
• 费用结构：
• 换货/商店积分 (Store Credit)：始终免费，并可提供额外奖励（如"选择商店积分，额外获得 10% 价值"）。
• 原路退款 (Refund to Original Payment)：可以收取小额退货运费（如 $5-$7），以弥补物流成本并激励客户选择换货。

1.2 无摩擦退货流程 (Frictionless Return Flow)

• 自助服务门户：使用 Loop Returns、Happy Returns 等工具，让客户只需输入订单号和邮箱即可发起退货。
• 即时退款/换货 (Instant Exchanges)：在客户扫描退货包裹（Drop-off）的瞬间，立即触发换货发货或退款，而不是等待包裹退回仓库。这极大地提升了客户体验。
• 无箱/无标签退货 (Box-free/Label-free)：允许客户将商品带到合作网点（如 Happy Returns Bar, 快递门店），无需自己打印标签或打包。

1.3 战略性"无需退回" (Strategic "Keep It" Policy)

对于低货值、易损或退回后无法二次销售的商品，要求客户退回会产生双重损失（退货运费 + 客户挫败感）。

• 触发条件：商品成本 (COGS) + 退货运费 > 商品零售价的 30%。
• 执行方式：直接为客户办理退款或补发，并告知"为了环保，您可以保留该产品，或将其捐赠/送给朋友"。
• 防欺诈机制：限制每个账户的"无需退回"次数（如每年 1 次），监控异常高频退货的账户。

---

2. 订阅管理体验 (Subscription Management UX)

对于提供订阅服务 (Subscribe & Save) 的品牌，灵活的订阅管理是降低流失率的关键。这是 CX 体验层面的设计，与 afa-retain 的订阅防流失策略（core-frameworks.md 第5节）互补。

afa-cx 的职责：确保订阅管理界面的用户体验无摩擦。

afa-retain 的职责：设计取消挽留流的策略逻辑和 Dunning 序列。

2.1 核心原则

让取消订阅和订阅一样容易。任何增加取消难度的"暗模式"都会损害品牌信任。

2.2 必备自助管理功能

2.3 取消流程的 CX 设计

• 不要隐藏取消按钮：让客户能在 2 次点击内找到取消入口。
• 收集取消原因：在取消流程中提供简短的原因选择（产品堆积/太贵/想换口味/不再需要），用于触发 afa-retain 的动态挽留策略。
• 确认页面：取消后展示"我们会想念你"的友好页面，附带"随时回来"的链接和一次性回归优惠。

---

本文件聚焦于客户体验的两个关键接触点：退换货和订阅管理。忠诚度计划的战略设计 → afa-retain `core-frameworks.md` 第6节；订阅防流失的策略逻辑 → afa-retain `core-frameworks.md` 第5节。

自助服务内容引擎

本文件为客户体验模块的内部参考文件，用于指导帮助中心文章、Bot Q&A 与客服宏的构建方式。

如需整理为用户可见交付物，必须删除内部路由标签、模块代号和系统字段，只保留自然语言、业务角色与行动建议。

---

1. 核心理念：从“解决”到“偏转” (Resolution to Deflection)

自助服务内容引擎的目标不是帮助客服更快地回复工单，而是尽可能在客户提出工单之前就解决问题。通过构建三层防御体系，可以系统性提升工单偏转率（Ticket Deflection Rate），同时降低首次响应时间与人工处理成本。

1.1 三层防御体系

1. 第一层：帮助中心文章 (Help Center Articles) —— 拦截主动搜索答案的客户。 2. 第二层：Bot Q&A 问答对 (Bot Q&A Pairs) —— 拦截习惯直接点击聊天窗口的客户。 3. 第三层：客服快捷回复 (Agent Macros) —— 为必须由人工处理的工单提供标准化、高效率的处理框架。

---

2. 第一层防御：帮助中心文章 (Help Center Articles)

帮助中心文章是自助服务的基础。它不仅服务于现有客户，也能通过 SEO 承接潜在客户的高意图搜索流量。

2.1 撰写原则

• 客户语言命名：标题必须使用客户搜索时的原话。如果客户在工单中问“我的订单在哪里？”，标题就应该是“我的订单在哪里？”，而不是“履约与物流状态查询”。
• 倒金字塔结构：前两句话直接给出答案。不要寒暄，不要说“我们理解这很重要”。客户要的是解决方案，而不是礼貌性的铺垫。
• 可操作性：优先使用编号列表、清晰步骤和必要的视觉辅助（截图 / GIF），确保内容易于扫描与执行。
• SEO 优化：包含元描述和相关关键词，确保客户在 Google 搜索时可以直接找到答案。

2.2 用户可见模板

# 帮助中心文章：[客户搜索原话标题]

**DPS 得分**：[X/100] | **预计每月偏转工单**：[X]
**URL Slug**：`/help/[kebab-case-title]`
**所属分类**：[旅程阶段] | **标签**：[Tag1, Tag2, Tag3]
**SEO 元描述**：[155字符以内，包含高频搜索词]

---

[前两句话直接给出答案。无寒暄，无废话。]

## [核心步骤/主要信息]
1. [步骤 1]
2. [步骤 2]
3. [步骤 3]

## [常见追问/边缘情况]
[解答数据中显示客户最常追问的问题]

## 还需要帮助吗？
如果以上信息未能解决您的问题，请[联系我们的支持团队](link)，并提供您的订单号，我们将在 [X 小时] 内回复您。

---
**相关文章**：
- [相关文章 1]
- [相关文章 2]

2.3 内部映射说明（仅供系统使用，不直接进入用户交付物）

---

3. 第二层防御：Bot Q&A 问答对 (Bot Q&A Pairs)

Bot 的目标是快速解决简单问题，并在必要时无缝转交人工。它的核心不是“回答得像真人”，而是快速命中意图、给出最短路径答案，并把高风险场景及时转人工。

3.1 构建原则

• 多维度训练短语 (Training Phrases)：每个意图至少提供 5 种不同的客户表达方式，包括正式、非正式、带错别字和愤怒表达。
• 精简回复：Bot 回复应控制在 2-4 句话内。聊天窗口中过长文本通常会显著降低体验。
• 明确人工接管触发器：定义何时必须转交人工，例如客户提到“损坏”“退款”“律师”，或情绪识别为“愤怒”。

3.2 用户可见模板

# Bot Q&A 问答对：[意图名称]

**意图 ID**：`[snake_case_intent_name]`
**所属分类**：[旅程阶段]

**训练短语 (Training Phrases)**：
- "[最常见问法]"
- "[第二常见问法]"
- "[非正式/简写问法]"
- "[带错别字/口语化问法]"
- "[愤怒/急迫问法]"

**Bot 回复 (Bot Response)**：
"[2-4 句话的精简回答]。了解更多详情，请查看：[帮助文章链接]"

**跟进提示 (Follow-up Prompt)**：
"这解决您的问题了吗？如果需要更多帮助，我可以为您转接人工客服。"

**后备回复 (Fallback Message)**：
"让我为您转接一位可以处理此问题的团队成员。请稍候。"

3.3 内部映射说明（仅供系统使用，不直接进入用户交付物）

**人工接管触发器 (Handoff Triggers)**：
- 客户提及："[触发词 1]"、"[触发词 2]"
- 情绪识别：[愤怒/极度沮丧]
- 业务条件：[如：订单已超过预计送达时间 3 天]

此区块用于 Bot 训练和升级路由配置，不应直接复制进用户可见模板正文。

---

4. 第三层防御：客服快捷回复 (Agent Macros)

对于无法通过自助服务解决的复杂问题，Macros 能显著降低平均处理时间（AHT）并提高回复一致性。其核心目标是让客服在保留品牌语气的同时，尽可能快地进入有效处理。

4.1 设计原则

• 动态变量注入：必须包含 [customer_first_name]、[order_number]、[tracking_url] 等变量占位符。没有变量的 Macro 只是机械回复，往往会激怒客户。
• 品牌语调对齐：确保回复语气符合品牌声音规范。专业、热情、幽默或极简都可以，但必须一致。
• 前后台分层：客户会看到的正文、客服内部操作指南和升级条件必须分层管理，不能在同一正文区混排。

4.2 用户可见模板

# 客服快捷回复 (Macro)：[宏名称]

**宏名称**：[简短、易搜索的名称，如 "物流延误-已发货"]
**适用场景**：[1-2 句话描述何时使用此宏]

---
**回复内容**：

Hi [customer_first_name],

[直接切入主题的开场白，承认问题但不显得机械]。

您的订单 [order_number] 已于 [ship_date] 发货。目前物流显示 [当前状态]。您可以点击这里追踪：[tracking_url]

[解释原因或提供解决方案]。预计将在 [estimated_delivery_date] 送达。

如果到 [deadline_date] 您仍未收到包裹，请直接回复此邮件，我将立即为您处理[退款/补发]。

Best,
[agent_first_name]

4.3 内部映射说明（仅供系统使用，不直接进入用户交付物）

**动态变量列表**：
- `[customer_first_name]`
- `[order_number]`
- `[ship_date]`
- `[tracking_url]`
- `[estimated_delivery_date]`
- `[deadline_date]`

**内部操作指南 (Internal Notes)**：
- 发送后操作：[如：将工单标记为 "等待物流"，设置 48 小时提醒]
- 升级条件：[如：如果客户回复要求立即退款，转交 Team Lead]

内部说明保留给客服执行和培训使用；导出到用户可见交付物时，必须只保留“回复内容”部分。

客户情绪与 VoC 监测系统 (Sentiment & VoC System)

1. 客户情绪模式分析 (Sentiment Pattern Analysis)

客户体验不仅是解决问题，更是管理情绪。通过分析多渠道反馈（工单、评论、NPS 调查），可以更准确地感知品牌健康度。情绪分析不仅是报告指标，更是决定优先级和行动方案的关键。

1.1 三类情绪模式

1.1.1 挫败热点 (Frustration Hotspots)

这是最高优先级的警报。客户持续表现出愤怒、失望，极有可能流失并留下负面评价。

• 特征与语言标记：
• “我还在等...”、“这是第三次了...”、“没人帮我解决...”
• “不可接受”、“失望”、“荒谬”、“最差的体验”
• 大写字母 (ALL CAPS)、多个感叹号或问号
• 威胁：“我要拒付 (chargeback)”、“我再也不会买了”、“我要去社交媒体曝光”
• 行动策略：
• 立即响应：必须立即创建自助服务内容，或优化现有流程。
• 根因修复：向产品/运营团队发出红色预警，从根源上修复导致挫败的流程（如更换不靠谱的物流商、修复结账 Bug）。
• 主动安抚：对受影响的客户群体触发“挽回工作流”（如高管致歉邮件、高额补偿）。

1.1.2 困惑集群 (Confusion Clusters)

客户没有生气，只是迷失了。他们找不到信息或不理解流程。这是最容易解决的体验问题。

• 特征与语言标记：
• “我不知道怎么...”、“网站上说...但是...”、“我在哪里可以...”
• “你能澄清一下吗...”、“我不明白...”、“[术语] 是什么意思？”
• 在一条消息中提出多个问题（表明他们完全不知道从何开始）
• 行动策略：
• 高偏转潜力：这是自助服务内容的最佳候选。一篇清晰、结构良好的帮助文章或一个简单的 Bot 回复就能消除整个集群的工单。
• UI/UX 优化：通过优化网站导航、重写产品描述或增加清晰的 FAQ 即可轻松解决。

1.1.3 积极信号 (Positive Signals)

客户在寻求帮助时依然保持友好，或主动提供建议。这些不是需要解决的问题，而是参与互动的机会。

• 特征与语言标记：
• “快速问个问题...”、“只是想知道...”、“很喜欢你们的产品，只是想问...”
• “提前感谢”、“不着急”
• 行动策略：
• 转化为拥护者：在解决问题后，主动邀请他们留下评价、加入品牌社区或参与忠诚度计划。
• 收集洞察：这些客户通常愿意提供有价值的产品反馈或功能建议。

---

2. 客户之声 (VoC) 闭环 (Voice of Customer Loop)

收集反馈只是第一步，真正的价值在于形成闭环，将洞察转化为行动。

2.1 痛点量化 (Quantifying Pain Points)

将模糊的抱怨转化为可量化的数据，以便管理层决策。

• 错误做法：“客户抱怨运费太贵。”
• 正确做法：“‘昂贵的运费’在过去 30 天被提及 142 次，占负面反馈的 35%，导致估计 $12,000 的购物车放弃损失。”

2.2 根因分析 (Root Cause Analysis)

使用“5 Whys”方法深挖痛点背后的系统性问题。

• 问题：客户抱怨收到错误的产品。
• Why 1：为什么收到错误的产品？因为仓库发错了货。
• Why 2：为什么仓库发错了货？因为拣货员看错了 SKU。
• Why 3：为什么看错了 SKU？因为两个相似产品的包装几乎一样，且 SKU 标签太小。
• Why 4：为什么包装一样？因为为了节省成本使用了通用包装。
• Why 5：为什么没有区分机制？因为缺乏出库前的条码扫描校验。
• 解决方案：引入出库条码扫描系统，或在相似产品的包装上增加明显的颜色标识。

2.3 跨部门反馈机制 (Cross-Functional Feedback)

CX 团队是品牌的“神经末梢”，必须将感知到的痛点传递给相应的“大脑”部门。

• 反馈给产品团队：产品质量问题、设计缺陷、包装易损、客户期望的新功能。
• 反馈给运营/供应链团队：物流延误、发错货、库存短缺、退货处理慢。
• 反馈给营销/增长团队：广告误导、PDP 描述不清、折扣码无效、客户对品牌定位的误解。

---

3. 危机公关与声誉管理 (Crisis & Reputation Management)

当负面情绪爆发时，客户体验响应必须迅速介入，控制损害。

3.1 T-A-S-C 危机沟通原则

在处理大面积延误、质量危机或公关事件时，遵循此原则发布官方声明：

• Transparency (透明)：诚实说明发生了什么，不掩饰、不推诿。
• Action (行动)：明确说明品牌正在采取什么具体措施来解决问题。
• Sympathy (同情)：表达对客户受到影响的理解和歉意。
• Commitment (承诺)：承诺何时提供下一次更新，或承诺如何防止此类事件再次发生。

3.2 “黄金三段论”差评回复模型

公开回复差评（如 Trustpilot, 社交媒体）时，采用标准化的结构，展示负责任的品牌形象： 1. 致歉与共情：“很抱歉听到您有这样的体验，这绝对不是我们希望提供给客户的服务标准。” 2. 表明立场与承诺：“我们非常重视产品质量/物流速度，目前正在调查此事以确保不再发生。” 3. 引导私下沟通：“为了尽快为您解决这个问题，请将您的订单号发送至 [客服邮箱]，我们的高级专员将亲自为您处理。”

• 目的：不仅是安抚这位愤怒的客户，更是向所有看到这条评论的潜在客户展示品牌的专业态度。

工单智能分析系统 (Ticket Intelligence System)

1. 三阶段工单分析框架 (3-Phase Framework)

这是客户体验分析中的核心数据方法。通过分析历史客服工单，挖掘出最具价值的客户洞察。

1.1 阶段 1：摄取与聚类 (Ingest & Cluster)

将杂乱的原始工单数据转化为结构化的主题集群。

1.1.1 数据清洗 (Data Normalization)

• 去除噪音：剥离 HTML 标签、自动回复（如“感谢您的联系”）、系统消息（如“工单已分配给”）。
• 合并对话：将多轮回复合并为单一记录，保留客户的首次消息和客服的最佳回复（最高 CSAT 或最终解决消息）。
• 过滤无效工单：移除无客服回复的工单（放弃或垃圾邮件）和客户消息少于 10 个词的工单。
• 去重：同一客户在 48 小时内提交的相同主题工单视为一个。

1.1.2 意图聚类 (Intent Clustering)

不依赖客服手动打的标签（通常不准确），而是基于客户原始消息的语义进行聚类。

• 核心问题匹配：例如，“我的订单在哪里？”、“我还没收到包裹”和“能给我一个物流更新吗？”属于同一个意图集群。
• 主题线索模式：许多工单共享相似或相同的主题行，优先对这些进行分组。
• 回复模式：如果客服对多个工单给出相同的回复，这些工单属于同一个集群，无论客户的措辞有多大差异。
• 聚类质量规则：
• 每个集群至少包含 5 个工单（少于 5 个属于噪音）。
• 任何单一集群不应超过总工单量的 20%（如果超过，说明可能合并了多个独立主题，需要拆分）。
• 集群名称必须使用客户语言（如“订单追踪”而不是“履约状态查询”）。

1.1.3 旅程映射 (Journey Mapping)

将每个聚类映射到六阶段旅程中的特定阶段。这决定了内容在帮助中心导航中的位置，以及哪些主动内容可以预防这些工单。

• 售前 (Pre-Purchase)：产品适配度、尺码、成分、运费查询。
• 购买 (Purchase)：支付问题、折扣码无效、结账错误。
• 履约 (Fulfillment)：订单追踪、物流延误、地址修改。
• 售后 (Post-Purchase)：使用指南、质量问题、缺件、错发。
• 退换货 (Returns & Exchanges)：退货流程、换货请求、退款时间线。
• 账户与技术 (Account & Technical)：密码重置、订阅管理、网站 Bug。

1.2 阶段 2：提取与转换 (Extract & Transform)

从聚类中提取最佳的客服回复，并将其转化为自助服务资产。

1.2.1 最佳实践提取

• 找出 CSAT 最高、首次响应解决率 (FCR) 最高的回复模式。
• 识别客服在回复中常用的内部知识（如特定的政策细节、操作步骤）。

1.2.2 格式转换

将内部视角的回复转化为客户视角的帮助中心文章、Bot 训练语料和标准宏 (Macros)。

• 帮助中心文章：结构化、易读、包含 SEO 元描述。
• Bot Q&A：精简、包含多维度训练短语和人工接管触发器。
• Agent Macros：带有动态变量和内部操作指南的标准化模板。

1.3 阶段 3：优先级排序与打包 (Prioritize & Package)

不是所有文章都值得写。必须基于 ROI 进行优先级排序。

1.3.1 偏转优先级得分 (Deflection Priority Score, DPS)

一个 100 分制的评估模型，用于确定哪些主题最值得投入资源构建自助服务内容。

1.3.2 执行路线图 (Execution Roadmap)

根据 DPS 得分制定行动计划：

• 80-100 分 (Build This Week)：最高偏转 ROI。将显著减少工单量。立即构建。
• 60-79 分 (Build This Month)：强有力的候选者。具有明显的偏转潜力。
• 40-59 分 (Add to Roadmap)：值得构建，但紧迫性较低。
• 20-39 分 (Nice to Have)：工单量低或难以自助服务。在完成高优先级内容后再考虑。
• 0-19 分 (Skip)：工单量太低、过于复杂或变化太大，不适合标准化。

---

2. 工单智能仪表盘 (Ticket Intelligence Dashboard)

阶段 1 的核心交付物，提供支持运营的全面概览。

2.1 仪表盘结构示例

• 总工单数：[X]
• 日期范围：[开始日期] 至 [结束日期]
• 识别的集群数：[X]

按工单量排序的顶级集群 (Top Clusters by Volume)： 1. [主题名称] - [X] 工单 ([Y]%) - [旅程阶段] - [情绪状态] - [自助服务潜力] 2. [主题名称] - [X] 工单 ([Y]%) - [旅程阶段] - [情绪状态] - [自助服务潜力] ...

按旅程阶段划分的工单量 (Volume by Journey Stage)：

• 售前：[X] 工单 ([Y]%)
• 购买：[X] 工单 ([Y]%)
• 履约：[X] 工单 ([Y]%)
• 售后：[X] 工单 ([Y]%)
• 退换货：[X] 工单 ([Y]%)
• 账户与技术：[X] 工单 ([Y]%)

工作模式与模板

本文件为客户体验模块的内部参考文件，用于执行 KPI 对齐、工作模式选择与模板产出。

层级声明：本文件默认作为 internal-only 的内部起草模板库使用，不得整段直接粘贴给用户。

如需整理为用户可见交付物，必须删除内部路由标签、模块代号和系统字段，只保留自然语言、业务角色与行动建议。

渲染规则：本文件中的 KPI 阈值、主题数量、响应时限、灯号分层和任何 ROI 判断，默认只可作为参考区间、保守起点或待验证计划；不得写成统一健康线、固定配方或对品牌结果的确定性承诺。

---

一、KPI 体系

1.1 核心体验指标 (Core CX Metrics)

1.2 运营效率指标

1.3 商业影响指标

---

二、6 大工作模式

2.1 客户旅程映射模式 (Journey Mapping Mode)

触发：用户要求“梳理客户旅程”“找出体验断点”或“设计全渠道体验”。

流程： 1. 收集品牌、产品、目标受众和现有触点信息。 2. 构建六阶段客户旅程地图（认知→考虑→转化→履约→留存→拥护）。 3. 识别每阶段关键触点、客户期望和潜在断裂点。 4. 进行触点差距分析。 5. 输出《全渠道客户旅程优化蓝图》。

2.2 工单智能分析模式 (Ticket Intelligence Mode)

触发：用户提供客服工单导出数据，要求“分析工单”“找出常见问题”或“降低客诉”。

流程： 1. 摄取并清洗工单数据（去除噪音、合并对话）。 2. 基于语义进行意图聚类，识别足够支持诊断与治理的核心主题。 3. 将聚类映射到客户旅程阶段，进行情绪模式分析。 4. 计算每个聚类的偏转优先级得分（DPS）。 5. 输出《工单智能分析仪表盘》和《高优先级自助服务构建清单》。

2.3 自助服务内容构建模式 (Self-Serve Content Mode)

触发：用户要求“写帮助中心文章”“训练客服机器人”或“创建快捷回复”。

流程： 1. 接收特定工单聚类数据或高频问题列表。 2. 提取最佳客服回复实践。 3. 生成帮助中心文章（SEO + 客户语言）。 4. 生成 Bot Q&A 问答对（多维训练短语 + 精简回答）。 5. 生成客服快捷回复 Macros（用户可见正文 + internal-only 操作说明分层输出）。 6. 输出《自助服务内容包》。

2.4 客户情绪与 VoC 审计模式 (Sentiment & VoC Audit Mode)

触发：用户提供客户评价、NPS 调查或社媒反馈，要求“分析客户情绪”或“挖掘客户痛点”。

流程： 1. 分析反馈文本，识别挫败热点、困惑集群和积极信号。 2. 量化痛点频率和严重程度。 3. 进行根因分析 (Root Cause Analysis)。 4. 制定跨部门改进建议。 5. 输出《客户之声 (VoC) 深度审计报告》。

2.5 客户健康度评估模式 (Health Scoring Mode)

触发：用户要求“评估客户流失风险”“建立健康度模型”或“设计挽回策略”。

流程： 1. 收集客户的使用、购买、互动和支持数据。 2. 构建多维度健康度评分模型（例如绿灯 / 黄灯 / 红灯等分层），并按业务实际校准分层规则。 3. 识别流失风险信号和高价值客户扩张机会。 4. 设计针对不同风险级别的干预策略和自动化工作流。 5. 输出《客户健康度评估与干预策略》。

2.6 危机公关与声誉管理模式 (Reputation Management Mode)

触发：用户面临大面积客诉、严重差评、物流瘫痪或产品质量危机。

流程： 1. 评估危机严重程度和影响范围。 2. 运用 T-A-S-C 原则起草官方声明或沟通邮件。 3. 使用“黄金三段论”生成标准化差评回复模板。 4. 制定内部客服应对口径和升级流程。 5. 输出《危机公关与声誉修复方案》。

---

三、输出模板

3.1 帮助中心文章模板

# 帮助中心文章：[客户搜索原话标题]

**DPS 状态**：[🟢/🟡/🔴] | **偏转工单参考**：[X]（推算依据：[说明]）
**URL Slug**：`/help/[kebab-case-title]`
**所属分类**：[旅程阶段] | **标签**：[Tag1, Tag2, Tag3]
**SEO 元描述**：[155 字符以内，包含高频搜索词]

---

[前两句话直接给出答案。无寒暄，无废话。]

## [核心步骤/主要信息]
1. [步骤 1]
2. [步骤 2]
3. [步骤 3]

## [常见追问/边缘情况]
[解答数据中显示客户最常追问的问题]

## 还需要帮助吗？
如果以上信息未能解决您的问题，请[联系我们的支持团队](link)，并提供您的订单号；具体回复时效应按当前渠道 SLA 与客服排班能力说明，不预写统一承诺。

---
**相关文章**：
- [相关文章 1]
- [相关文章 2]

3.2 Bot Q&A 问答对模板

用户可见模板

# Bot Q&A 问答对：[意图名称]

**意图 ID**：`[snake_case_intent_name]`
**所属分类**：[旅程阶段]

**训练短语 (Training Phrases)**：
- "[最常见问法]"
- "[第二常见问法]"
- "[非正式/简写问法]"
- "[带错别字/口语化问法]"
- "[愤怒/急迫问法]"

**Bot 回复 (Bot Response)**：
"[按问题复杂度给出精简回答]。了解更多详情，请查看：[帮助文章链接]"

**跟进提示 (Follow-up Prompt)**：
"这解决您的问题了吗？如果需要更多帮助，我可以为您转接人工客服。"

**后备回复 (Fallback Message)**：
"让我为您转接一位可以处理此问题的团队成员。请稍候。"

内部映射说明（仅供系统使用，不直接进入用户交付物）

**人工接管触发器 (Handoff Triggers)**：
- 客户提及："[触发词 1]"、"[触发词 2]"
- 情绪识别：[愤怒/极度沮丧]
- 业务条件：[如：订单明显超过当前预计送达时间]

3.3 客服快捷回复模板 (Agent Macro)

用户可见模板

# 客服快捷回复 (Macro)：[宏名称]

**宏名称**：[简短、易搜索的名称，如 "物流延误-已发货"]
**适用场景**：[1-2 句话描述何时使用此宏]

---
**回复内容**：

Hi [customer_first_name],

[直接切入主题的开场白，承认问题但不显得机械]。

您的订单 [order_number] 已于 [ship_date] 发货。目前物流显示 [当前状态]。您可以点击这里追踪：[tracking_url]

[解释原因或提供解决方案]。预计将在 [estimated_delivery_date] 送达。

如果到 [deadline_date] 您仍未收到包裹，请直接回复此邮件，我将立即为您处理[退款/补发]。

Best,
[agent_first_name]

内部映射说明（仅供系统使用，不直接进入用户交付物）

**动态变量列表**：
- `[customer_first_name]`、`[order_number]`、`[ship_date]`
- `[tracking_url]`、`[estimated_delivery_date]`、`[deadline_date]`

**内部操作指南 (Internal Notes)**：
- 发送后操作：[如：将工单标记为 "等待物流"，并按当前履约节奏设置提醒]
- 升级条件：[如：如果客户回复要求立即退款，转交 Team Lead]