| name | customer-complaint-attribution-and-improvement-assistant |
| description | 当用户需要对银行零售金融场景中的客户投诉进行分类、归因、责任环节识别、
问题复盘、改进建议设计、闭环跟踪与管理汇报时，使用本技能。
适用于客服分析、服务体验分析、流程改进、客诉高发问题识别、渠道体验优化、
产品服务缺陷排查、客服坐席问题复盘等任务。
输出时应严格区分“已确认事实”“高概率归因”“待核验事项”，避免在证据不足时直接下结论。
|
客诉归因与改进助手
一、技能定位
本技能用于支持银行零售金融场景下的客户投诉分析与改进工作。它不是简单对投诉文本做情绪总结，而是围绕“投诉发生了什么、为什么发生、责任链条在哪里、对客户与银行产生了什么影响、后续如何改进和追踪”展开结构化分析。
本技能适用于以下任务：
- 对单笔或批量客户投诉进行主题分类、问题聚类与根因归因；
- 识别投诉涉及的产品、流程、渠道、系统、服务人员、外部协作方等责任环节；
- 输出可执行的改进建议，包括短期止损、中期整改、长期机制优化；
- 形成管理层可阅读的客诉分析报告、专项复盘报告、整改计划和追踪台账。
二、适用范围
适用行业：银行
业务条线/能力域：零售金融
场景/能力：客服分析
层级：task
常见适用场景包括但不限于：
- 手机银行、网上银行、柜面、电话客服、信用卡、贷款、理财、支付结算等客诉分析；
- 高发客诉主题专项复盘；
- 某一渠道、某一产品、某一地区、某一时间段的投诉成因分析；
- 监管关注问题、服务质量问题、客户体验问题的成因梳理与整改设计；
- 客诉升级、重复投诉、集中投诉、舆情投诉的专门分析。
三、不适用场景
以下场景不建议直接使用本技能给出确定性结论：
- 缺乏原始投诉记录、通话记录、工单轨迹、处理过程证据，仅有模糊摘要；
- 涉及明确法律争议、监管处罚认定、合规定责、员工处分定性，需要法律、合规、人力正式流程介入；
- 涉及欺诈、洗钱、账户盗用、身份冒用等高度敏感事件，仅凭一般投诉信息无法完成准确定性；
- 用户要求直接生成“追责决定”或“处罚结论”时。
在上述情况下，本技能应输出：事实梳理、疑点提示、待核验事项、建议的进一步核查路径，而不是越权定责。
四、核心任务
- 投诉分类：识别投诉主题、子主题、产品、渠道、服务节点；
- 根因归因：从客户、产品、流程、系统、服务、政策规则、外部因素等多个维度分析原因；
- 责任链识别：判断问题发生在哪个环节，由谁主责、谁协同、谁兜底；
- 影响评估：评估客户体验影响、潜在舆情风险、重复投诉风险、监管风险；
- 改进建议：提出可执行的修复、优化、整改、培训、监控和机制改进措施；
- 闭环跟踪：形成整改项、责任部门、时间要求、复盘计划和效果观察指标。
五、建议输入
建议尽量提供以下资料，资料越完整，归因和改进建议越可靠：
- 客户投诉原文、录音转写、工单摘要、客服会话记录；
- 客户基础信息、业务办理时间线、交易或服务触点信息；
- 涉及产品说明、流程规则、收费规则、营销话术、短信通知模板；
- 工单流转记录、升级记录、处理时效、补偿方案、回访结果；
- 渠道日志、系统报错、业务处理截图、前中后台协同记录；
- 历史同类投诉样本、投诉量趋势、地区/渠道/产品维度分布数据；
- 整改历史、SOP、质检规则、培训记录。
六、使用指导
1. 单笔投诉分析时
适合在以下情况下使用：
- 需要快速识别投诉主题与潜在根因；
- 需要形成对外回复前的内部分析底稿；
- 需要给客服主管、产品经理、运营团队提供问题复盘建议。
推荐步骤：
- 先整理投诉事件时间线；
- 提取客户诉求、承诺事项、争议点和证据点；
- 判断投诉涉及的环节与责任边界；
- 输出“已确认事实 / 高概率归因 / 待核验事项”；
- 再给出修复建议和后续跟踪动作。
2. 批量投诉分析时
适合在以下情况下使用：
- 需要识别高频投诉问题；
- 需要做月报、专题分析、专项治理；
- 需要支持管理层决策或监管应对。
推荐步骤：
- 先统一投诉分类口径；
- 做主题聚类与渠道/产品/地区维度切片；
- 分析高发问题的主因与次因；
- 区分偶发问题与系统性问题；
- 输出分层整改清单和优先级建议。
3. 输出原则
- 没有证据支撑时，不直接写“根因已确认”；
- 对主观判断必须标明依据；
- 对责任归因必须区分主责、协同、管理改进责任；
- 对改进建议必须给出执行对象、预期效果和跟踪方式；
- 对涉及客户权益、监管、舆情的问题要单独提示风险等级。
七、分析框架
1. 投诉分类维度
可从以下维度进行分类：
- 产品维度：借记卡、信用卡、消费贷、按揭贷、理财、基金、保险代销、支付结算等；
- 渠道维度：APP、网银、柜面、电话、客户经理、第三方支付场景等；
- 问题维度：服务态度、处理时效、收费争议、规则不透明、系统异常、误导营销、信息通知不到位、流程复杂、重复提交、资料要求不清等；
- 严重程度维度：一般投诉、重复投诉、升级投诉、疑似监管敏感投诉、疑似舆情投诉。
2. 根因归因维度
建议至少从以下层面归因：
- 客户认知原因：规则理解偏差、预期不一致、信息接收不完整；
- 产品设计原因：条款复杂、权益边界模糊、费用结构不清晰、功能不稳定；
- 流程原因：审批长、协同慢、节点断裂、回传机制差；
- 系统原因：页面错误、接口失败、状态不同步、通知遗漏；
- 服务原因：解释不清、承诺不一致、服务态度问题、回复模板机械；
- 管理原因：培训不到位、质检覆盖不足、监控阈值不合理、升级机制滞后；
- 外部原因：清算机构、合作商户、外部通道、节假日因素、监管政策变化。
3. 责任识别逻辑
责任判断时，不宜直接写“某部门有责”，应按以下方式表达：
- 直接触发环节：问题最直接发生在哪个节点；
- 形成原因环节：导致问题产生的前置条件来自哪里；
- 扩大影响环节：为什么小问题演变成投诉、升级投诉或重复投诉；
- 闭环缺失环节：为什么处理后客户仍不满意或再次投诉。
4. 改进建议框架
建议至少覆盖四类措施：
- 短期止损：客户安抚、解释口径统一、话术修正、快速补偿、专项回访；
- 中期整改：流程修补、知识库完善、规则提示增强、系统提示优化、工单分流优化；
- 长期机制：监控看板、规则回溯、培训机制、质检抽样、跨部门联动、责任复盘制度。
八、推荐输出结构
输出时建议包括以下部分：
- 投诉概况；
- 事实时间线；
- 客户核心诉求；
- 投诉分类结果；
- 归因分析；
- 责任链条识别；
- 风险影响评估；
- 改进建议；
- 待核验事项；
- 后续跟踪计划。
九、调用参考资料
需要更详细的分类规则时，阅读：
references/complaint_taxonomy.mdreferences/root_cause_framework.md
需要更详细的改进措施模板时，阅读：
references/improvement_playbook.mdreferences/follow_up_kpi_guide.md
需要固定输出格式时，阅读：
references/output_schema.mdassets/templates/complaint_analysis_report_template.md
十、可调用脚本
scripts/complaint_taxonomy_classifier.py：对投诉记录进行规则化分类；scripts/root_cause_scorer.py：根据投诉特征打分并输出潜在根因；scripts/render_complaint_report.py：将分析结果渲染为 Markdown 报告。
十一、注意事项
- 不能把投诉情绪强度直接等同于问题严重性；
- 不能把客户单方描述直接当作最终事实；
- 不能因缺少证据而回避问题，应明确写出需补充的数据和核验路径；
- 对高风险投诉应单独标识并建议人工升级处理；
- 本技能输出的是分析与建议，不替代正式法务、合规、审计、纪检、人力结论。
