客诉分析鱼骨图怎么画

很多人搜“客诉分析鱼骨图怎么画”，其实不是想学一个管理术语，而是手上已经出现了投诉：客户抱怨发货慢、质量不稳定、售后响应差，或者同类问题反复出现，团队开了几次会还是说不清根因。这种情况下，鱼骨图有用的地方，不是把图画得多漂亮，而是把“客户为什么会投诉”从一句笼统结论，拆成一组可以排查、可以验证、可以改进的原因。

先给直接结论：客诉分析鱼骨图的画法并不复杂，核心就三步——先把投诉问题定义清楚，再按几个固定维度拆主因，最后把每个主因继续往下追问到能落地处理的层级。 真正难的不是画图本身，而是避免把情绪判断、主观甩锅和模糊表述直接写进图里。

客诉分析为什么适合用鱼骨图

客户投诉往往不是单一原因导致的。表面上看，客户说的是“东西不好”“服务很差”“体验不行”，但背后可能同时牵涉：

• 产品本身确实有质量波动
• 包装、物流、安装等交付环节出了问题
• 客服回复慢或解释不一致
• 销售承诺和实际交付不一致
• 内部标准不清，导致不同人处理方式不同

如果只靠会议里口头讨论，很容易停留在“以后注意一点”“加强培训”“提升服务意识”这种空话上。鱼骨图的价值就在于，它能逼着团队把问题拆具体，把猜测变成待验证项，把责任争论变成排查路径。

画客诉分析鱼骨图之前，先把问题写对

很多鱼骨图之所以越画越乱，不是模板不行，而是一开始问题就写错了。

好的问题定义，必须包含具体对象和具体表现

比如下面这些写法太空：

• 客户不满意
• 投诉变多了
• 售后有问题
• 服务体验差

更适合写成：

• 为什么 3 月某型号产品的“到货破损”投诉明显增加
• 为什么新客户在首周内频繁投诉客服响应慢
• 为什么本月关于“安装后无法正常使用”的客诉持续上升
• 为什么电商渠道针对“描述不符”的差评集中出现

问题写得越清楚，后面越容易判断要排查产品、流程、人员，还是信息传达。

一个鱼骨图最好只分析一个明确问题

不要把“质量差、发货慢、售后差”全部塞进一张图。这样看似全面，实际会把不同类型的问题搅在一起，最后谁都说不清重点。

更稳妥的做法是：

• 一张图只聚焦一个投诉主题
• 如果投诉类型不同，就分别建图
• 先分析投诉量最大、影响最大、复发最高的问题

客诉分析鱼骨图怎么画：实操步骤

第一步：把“投诉结果”写在鱼头位置

鱼头就是你要分析的结果，也就是最终暴露出来的投诉问题。

例如：

• 客户投诉发货延迟
• 客户投诉产品漏液
• 客户投诉售后处理周期过长
• 客户投诉安装说明不清导致无法使用

这里有个原则：写现象，不要先写结论。

比如“客户投诉是因为员工不负责”就不适合放在鱼头，因为这已经把原因先写死了。鱼头应该保留为待分析的问题现象。

第二步：确定主骨架分类

客诉分析没有唯一标准模板，但常见做法是根据业务场景，从几个高频维度拆主骨。你不一定要照搬制造业里的 5M1E，也不一定非要用固定格式，关键是分类要对当前投诉问题有帮助。

做客诉分析时，常见的主骨可以参考下面这些方向：

1. 产品 / 服务本身

适合写：

• 产品质量不稳定
• 功能缺陷
• 使用门槛过高
• 说明不清楚
• 服务内容和客户预期不一致

如果客户投诉的核心是“买到的东西不好用”或者“实际体验和承诺不同”，这一条通常是重点。

2. 流程

适合写：

• 工单流转慢
• 售后审批环节过多
• 异常上报机制不清
• 问题处理没有时限要求
• 跨部门交接断点多

很多客诉并不是因为一线人员态度差，而是内部流程本来就拖，任何人来处理都会慢。

3. 人员

适合写：

• 客服培训不足
• 对产品不了解
• 回答口径不统一
• 一线人员没有处理权限
• 销售过度承诺

这一类要特别注意，不要简单写“员工责任心不足”。更有价值的是写出可观察、可改善的问题。

4. 信息与沟通

适合写：

• 下单前宣传与实际不一致
• 客户未被提前告知关键限制
• 物流异常未及时通知
• 售后反馈没有闭环
• 内部信息传递失真

很多投诉表面上是产品问题，实质上是预期管理失败。

5. 交付与外部环节

适合写：

• 物流时效不稳定
• 外包安装质量参差不齐
• 第三方维修配合慢
• 供应商来料异常

如果你的业务涉及仓储、快递、安装、代理商、渠道商，这一条通常不能漏。

6. 标准与数据

适合写：

• 没有明确处理标准
• 同类客诉缺少分类统计
• 无法识别高频问题
• 没有满意度回访机制
• 没有复盘机制

有些企业客诉总是反复，不是不会处理，而是根本没有把历史投诉沉淀成标准。

第三步：每个主因继续往下拆到“能处理”的层级

这一步是鱼骨图最关键的地方。

比如你在主骨里写了“客服响应慢”，这还不够，因为它更像一个中间现象。你要继续追问：

• 为什么响应慢？
• 是人手不足，还是班次安排不合理？
• 是系统提醒不及时，还是工单优先级没有设置？
• 是需要层层请示，还是常见问题没有标准话术？

继续拆后，才可能得到真正能改的内容，比如：

• 高峰时段客服排班不足
• 工单系统未设置超时预警
• 常见退款场景需主管审批，导致等待时间长
• 客服无法直接查询物流异常原因

判断一个原因是否写得足够好，可以看它能不能被验证、能不能分配责任、能不能对应改善动作。如果不能，说明还拆得不够具体。

一个简单的客诉鱼骨图示例思路

假设你要分析的问题是：“为什么客户频繁投诉售后处理太慢”。

可以这样搭骨架：

鱼头

• 客户投诉售后处理太慢

主骨一：流程

• 工单需要多级审批
• 不同问题没有分级处理机制
• 异常件必须人工转派

主骨二：人员

• 新客服对流程不熟
• 一线人员没有补偿权限
• 高峰期人员配置不足

主骨三：系统工具

• 工单系统提醒滞后
• 处理进度客户不可见
• 历史问题无法快速检索

主骨四：沟通

• 首次响应后缺乏主动回访
• 不同人员回复口径不一致
• 未提前告知预计处理时长

主骨五：外部协同

• 物流取件慢
• 维修商反馈周期长
• 供应商换货确认慢

这样一张图出来后，你基本就能很快看出：问题不是一句“售后效率低”能概括的，而是多个环节叠加造成。

客诉分析鱼骨图常见误区

误区一：把“客户情绪”当根因

比如写“客户太敏感”“客户要求太高”“客户不理解流程”。这种写法对内部改善几乎没有帮助。

客诉分析的重点不是评价客户，而是找出为什么客户会在当前触点上产生不满，以及企业哪些环节让这个不满被放大。

误区二：把部门名称直接写成原因

比如：

• 销售部问题
• 客服部问题
• 仓库问题

这不叫分析，这只是贴标签。更好的方式是写部门行为或流程缺陷，例如：

• 销售未提前说明交付周期
• 客服缺少统一补偿标准
• 仓库出库复核不完整

误区三：原因只停留在第一层

“产品问题”“服务问题”“物流问题”都太粗。第一层只是分类，不是根因。真正能推动改进的，往往在第二层、第三层。

误区四：一边开会一边凭感觉填图

鱼骨图不是谁声音大谁就对。比较靠谱的做法是结合：

• 客诉记录
• 通话录音或聊天记录
• 工单数据
• 退换货原因
• 差评关键词
• 一线反馈

有数据支撑的鱼骨图，后续整改才更容易落地。

客诉分析时，怎么判断已经拆到位了

你可以用这 4 个问题自查：

1. 这条原因能不能被事实验证？
2. 这条原因能不能归属到具体流程、岗位或机制？
3. 如果要改，是否能想到明确动作？
4. 这条内容是原因，还是另一个结果？

如果一条内容看起来很大、很抽象、很像口号，通常就还没拆到位。

适合搭配鱼骨图一起用的方法

如果你想把客诉分析做得更扎实，鱼骨图通常可以和下面几种方法配合：

1. 5Why 追问法

适合在鱼骨图找出重点分支后，继续往下深挖。比如“为什么物流投诉多”可以继续问五层，找到真正的断点。

2. 客诉分类统计

先统计高频投诉类型，再决定先画哪张鱼骨图。这样不会一上来就陷进零散个案里。

3. 帕累托分析

如果投诉问题很多，可以先找出占比最高的前几类，再优先处理主要矛盾。

4. 闭环复盘

鱼骨图不是画完就结束，最好后面再接：责任人、整改动作、完成时点、复查结果。

什么场景下，客诉鱼骨图最有用

它尤其适合这些情况：

• 同类投诉反复发生，但团队总说不清原因
• 客服、销售、产品、仓储之间容易互相甩锅
• 需要开复盘会，但不想只停留在主观讨论
• 想把投诉问题沉淀成标准化改进项目
• 管理层需要快速看清问题分布，而不是听一堆零散描述

如果只是单个偶发事件、信息量很少、事实还没查清，鱼骨图可以稍后再做；先把基本事实核实完更重要。

客诉分析鱼骨图怎么画，最终可以记住这套顺序

如果你只想记一套最简流程，可以直接按这个顺序走：

1. 明确一个具体投诉问题
2. 把问题写在鱼头
3. 按产品、流程、人员、沟通、交付、标准等维度拆主骨
4. 对每个主骨持续追问，拆到可以验证和改进的层级
5. 用数据、记录和案例验证重点原因
6. 输出整改动作，而不是只停留在图上

换句话说，客诉分析鱼骨图不是为了做一张图，而是为了把“客户为什么不满意”从模糊印象，变成有结构的排查清单和改进清单。

如果你已经有一个明确的客诉主题，想更快把思路整理出来，也可以直接用鱼骨图制作工具先搭骨架，再根据你的投诉场景继续补充分支，会比从空白文档硬写更省时间。