aifinlab/customer-complaint-attribution-and-improvement-assistant

客诉归因与改进助手

一、技能定位

本技能用于支持银行零售金融场景下的客户投诉分析与改进工作。它不是简单对投诉文本做情绪总结，而是围绕“投诉发生了什么、为什么发生、责任链条在哪里、对客户与银行产生了什么影响、后续如何改进和追踪”展开结构化分析。

本技能适用于以下任务：

• 对单笔或批量客户投诉进行主题分类、问题聚类与根因归因；
• 识别投诉涉及的产品、流程、渠道、系统、服务人员、外部协作方等责任环节；
• 输出可执行的改进建议，包括短期止损、中期整改、长期机制优化；
• 形成管理层可阅读的客诉分析报告、专项复盘报告、整改计划和追踪台账。

二、适用范围

适用行业：银行
业务条线/能力域：零售金融
场景/能力：客服分析
层级：task

常见适用场景包括但不限于：

• 手机银行、网上银行、柜面、电话客服、信用卡、贷款、理财、支付结算等客诉分析；
• 高发客诉主题专项复盘；
• 某一渠道、某一产品、某一地区、某一时间段的投诉成因分析；
• 监管关注问题、服务质量问题、客户体验问题的成因梳理与整改设计；
• 客诉升级、重复投诉、集中投诉、舆情投诉的专门分析。

三、不适用场景

以下场景不建议直接使用本技能给出确定性结论：

• 缺乏原始投诉记录、通话记录、工单轨迹、处理过程证据，仅有模糊摘要；
• 涉及明确法律争议、监管处罚认定、合规定责、员工处分定性，需要法律、合规、人力正式流程介入；
• 涉及欺诈、洗钱、账户盗用、身份冒用等高度敏感事件，仅凭一般投诉信息无法完成准确定性；
• 用户要求直接生成“追责决定”或“处罚结论”时。

在上述情况下，本技能应输出：事实梳理、疑点提示、待核验事项、建议的进一步核查路径，而不是越权定责。

四、核心任务

1. 投诉分类：识别投诉主题、子主题、产品、渠道、服务节点；
2. 根因归因：从客户、产品、流程、系统、服务、政策规则、外部因素等多个维度分析原因；
3. 责任链识别：判断问题发生在哪个环节，由谁主责、谁协同、谁兜底；
4. 影响评估：评估客户体验影响、潜在舆情风险、重复投诉风险、监管风险；
5. 改进建议：提出可执行的修复、优化、整改、培训、监控和机制改进措施；
6. 闭环跟踪：形成整改项、责任部门、时间要求、复盘计划和效果观察指标。

五、建议输入

建议尽量提供以下资料，资料越完整，归因和改进建议越可靠：

• 客户投诉原文、录音转写、工单摘要、客服会话记录；
• 客户基础信息、业务办理时间线、交易或服务触点信息；
• 涉及产品说明、流程规则、收费规则、营销话术、短信通知模板；
• 工单流转记录、升级记录、处理时效、补偿方案、回访结果；
• 渠道日志、系统报错、业务处理截图、前中后台协同记录；
• 历史同类投诉样本、投诉量趋势、地区/渠道/产品维度分布数据；
• 整改历史、SOP、质检规则、培训记录。

六、使用指导

1. 单笔投诉分析时

适合在以下情况下使用：

• 需要快速识别投诉主题与潜在根因；
• 需要形成对外回复前的内部分析底稿；
• 需要给客服主管、产品经理、运营团队提供问题复盘建议。

推荐步骤：

1. 先整理投诉事件时间线；
2. 提取客户诉求、承诺事项、争议点和证据点；
3. 判断投诉涉及的环节与责任边界；
4. 输出“已确认事实 / 高概率归因 / 待核验事项”；
5. 再给出修复建议和后续跟踪动作。

2. 批量投诉分析时

适合在以下情况下使用：

• 需要识别高频投诉问题；
• 需要做月报、专题分析、专项治理；
• 需要支持管理层决策或监管应对。

推荐步骤：

1. 先统一投诉分类口径；
2. 做主题聚类与渠道/产品/地区维度切片；
3. 分析高发问题的主因与次因；
4. 区分偶发问题与系统性问题；
5. 输出分层整改清单和优先级建议。

3. 输出原则

• 没有证据支撑时，不直接写“根因已确认”；
• 对主观判断必须标明依据；
• 对责任归因必须区分主责、协同、管理改进责任；
• 对改进建议必须给出执行对象、预期效果和跟踪方式；
• 对涉及客户权益、监管、舆情的问题要单独提示风险等级。

七、分析框架

1. 投诉分类维度

可从以下维度进行分类：

• 产品维度：借记卡、信用卡、消费贷、按揭贷、理财、基金、保险代销、支付结算等；
• 渠道维度：APP、网银、柜面、电话、客户经理、第三方支付场景等；
• 问题维度：服务态度、处理时效、收费争议、规则不透明、系统异常、误导营销、信息通知不到位、流程复杂、重复提交、资料要求不清等；
• 严重程度维度：一般投诉、重复投诉、升级投诉、疑似监管敏感投诉、疑似舆情投诉。

2. 根因归因维度

建议至少从以下层面归因：

• 客户认知原因：规则理解偏差、预期不一致、信息接收不完整；
• 产品设计原因：条款复杂、权益边界模糊、费用结构不清晰、功能不稳定；
• 流程原因：审批长、协同慢、节点断裂、回传机制差；
• 系统原因：页面错误、接口失败、状态不同步、通知遗漏；
• 服务原因：解释不清、承诺不一致、服务态度问题、回复模板机械；
• 管理原因：培训不到位、质检覆盖不足、监控阈值不合理、升级机制滞后；
• 外部原因：清算机构、合作商户、外部通道、节假日因素、监管政策变化。

3. 责任识别逻辑

责任判断时，不宜直接写“某部门有责”，应按以下方式表达：

• 直接触发环节：问题最直接发生在哪个节点；
• 形成原因环节：导致问题产生的前置条件来自哪里；
• 扩大影响环节：为什么小问题演变成投诉、升级投诉或重复投诉；
• 闭环缺失环节：为什么处理后客户仍不满意或再次投诉。

4. 改进建议框架

建议至少覆盖四类措施：

• 短期止损：客户安抚、解释口径统一、话术修正、快速补偿、专项回访；
• 中期整改：流程修补、知识库完善、规则提示增强、系统提示优化、工单分流优化；
• 长期机制：监控看板、规则回溯、培训机制、质检抽样、跨部门联动、责任复盘制度。

八、推荐输出结构

输出时建议包括以下部分：

1. 投诉概况；
2. 事实时间线；
3. 客户核心诉求；
4. 投诉分类结果；
5. 归因分析；
6. 责任链条识别；
7. 风险影响评估；
8. 改进建议；
9. 待核验事项；
10. 后续跟踪计划。

九、调用参考资料

需要更详细的分类规则时，阅读：

• references/complaint_taxonomy.md
• references/root_cause_framework.md

需要更详细的改进措施模板时，阅读：

• references/improvement_playbook.md
• references/follow_up_kpi_guide.md

需要固定输出格式时，阅读：

• references/output_schema.md
• assets/templates/complaint_analysis_report_template.md

十、可调用脚本

• scripts/complaint_taxonomy_classifier.py：对投诉记录进行规则化分类；
• scripts/root_cause_scorer.py：根据投诉特征打分并输出潜在根因；
• scripts/render_complaint_report.py：将分析结果渲染为 Markdown 报告。

十一、注意事项

• 不能把投诉情绪强度直接等同于问题严重性；
• 不能把客户单方描述直接当作最终事实；
• 不能因缺少证据而回避问题，应明确写出需补充的数据和核验路径；
• 对高风险投诉应单独标识并建议人工升级处理；
• 本技能输出的是分析与建议，不替代正式法务、合规、审计、纪检、人力结论。