提问：如何分析一个复杂的数据问题？

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

面对复杂问题，该怎么搭建数据分析思路呢？作者根据实际情况选取了几个具体的例子，并赋予其场景，提出了三种做法，我们审时度势，结合真实的问题点，系统数据现状，处理问题的决心，选择一个贴合实际的做法试试吧！

全文共 2789 字，阅读需要 6 分钟

——————/ BEGIN /—————

网上从0到1的文章很多，可面对复杂问题，该怎么搭建数据分析思路呢？

首先，“复杂”一词在不同等级的数据分析师里含义不同。

对小白而言，领导传达命令的时候，有“模型”俩字的就是复杂问题，一听“模型”，新人就开始狂翻《西瓜书》《统计学习》《机器学习》誓要与“模型”血战300回合。

而有经验的同学都知道，企业里真正复杂的才不是这些。

来看个具体例子：

场景：电商行业（纸质书、视频光盘等商品为主），客服领导对物流领导意见非常大，认为物流问题影响了客户满意度。

但物流领导表示：所有发货不及时，发货过程中包装破损等问题已经被处理了，怎么可能还有物流问题。

现在有一份分析需求，要求：建立全面、细致的客户满意度评估指标体系。

什么是真正的复杂问题

问题1：收到这个需求，你会百度哪个关键词？

• 评估指标

• 客户满意度指标

• 客服客户满意度指标

• 物流客户满意度指标

很多新人一看这种问题就觉得：简单。不就是建个评估指标吗，这种文章网上一天能见8篇。而且“客户满意度”这个词我也熟悉，又不是私域流量，精准画像这种玄乎词。

于是开始百度上边四个关键字，找一个看起来可行的就开始干了。

可关键问题是：眼前的问题，是大家不知道客户满意度怎么考核吗？

不是！眼前的问题是客服跟物流俩部门干上了！这才是大问题。所谓“客户满意度”只是两边干架的一个由头。

如果“客户满意度”的标准不能让两边共识，那不管书本上是怎么定义的，只要你甩出来，都会被其中一方喷到死。

这才是第一大难题。

所以这一题根本就不该选。

第一步要干的事，是先了解具体不满的点在哪里。

又有新人表示：既然是客服对物流不满，那客服记录用户来电里，有“客户投诉”这一项，直接把这个指标拿出来不就完了（如下图）

这就涉及到第二个难题：客户满意度，是个含义丰富，但采集数据非常难的指标：

• 到底啥算满意？

• 客户不满意是不是就一定投诉？

• 是不是客户满意了就不会投诉？

以上三个都不一定！特别是涉及物流问题：

• 可能客户假装发脾气，只是为了让客服处理速度快一点。

• 也可能客户闷声不响，但是最后退货！退货！退货！

• 更有可能客户拨打的是咨询/建议，但是发脾气：为啥还不答复

只靠一个字段：投诉，是无法真实反映情况的。比如客服领导给出来的“客户不满意”是以下场景（如下图）

这又涉及第三个问题：如何在各种庞杂数据里，真正识别出客户投诉/非投诉。

如果按客户领导的说法，得把所有客户来电都转文字记录+关键词过滤一遍才能识别情况。可显然这么干太费时费力，得找个简单的处理办法。

然而这又涉及到第四个问题：客服的工作流程得调整。不调工作流程，依然会有大量真真假假的投诉混杂在其他来电里，后续还是没法跟踪，客服依然会无休无止的抱怨，物流依然不知道自己错在哪。

然而，调流程这事，又涉及业务部门能不能、肯不肯、想不想的问题。这时候如果有个人冒出来，说：“你们做数据的不是会人工智能大数据吗，就不能我们照常干，你们Duang一下就分析的一清二楚吗。肯定是你能力不行”……是不是你也想打爆他的狗头了。

• 部门利益有冲突

• 指标含义不清楚

• 原始数据内容乱

• 相关流程要改动

这些才是老鸟眼中真正难解决的问题。

然而这也是企业真实的经营场景，那种数据完美，含义清晰，静静躺在excel表里等着被建模的事，只存在于网上文章里。

现实就是各种利益纠葛，数据混杂，流程不清，咋弄呢？？？

如何建立分析思路

总结下本次的问题。

表面上看，是：客服反馈物流问题多，客户满意度低。

可往深入看，客服与物流对客户满意度口径不统一，导致无法解决问题。

再往深入看，客户的很多问题并非物流引起，却都怪到物流头上，客服自己没有做区分，而是一股脑打上门来。

这种场面下，有三种解决思路：

1. 中立判官

如果得到了更高层授权，或者两个部门能平心静气谈，希望数据部门站在中间当判官，可以用这种思路。

这时候可以围绕客服反馈的客户不满意问题，逐级梳理，把哪些是真问题，哪些是假抱怨一层层剥清楚：

2. 故作小白

如果两个部门打得不可开交，铁了心要吵架的话，可以用这个思路。

数据部门好像一只人畜无伤的小白兔，表示：“你看我们也不懂物流业务，也不懂客服业务，如果有需要区分哪些来电是不满意的，可以业务给具体的区分规则，我们按规则去提取数据”。

是滴，让两家自己吵架，定清楚了到底什么算不满意、从哪里、依照什么标准提数，数据部门就当个跑数机。

并且只给数据，不给判断。

这样是看着很怂，但是能在部门混战里先保护好自己。

3. 解决问题

注意，客户总是想多占点好处，所以客户真真假假的抱怨是避免不了的。但物流提高配送能力却是结结实实要花钱的。就像所有的老板都说要提高客户满意度，可你问他花100个亿来提高满意度——十有八九就不同意了。

所以站在解决问题的角度，第一步并非建立客户满意度指标，而是先定义物流的服务原则，比如最长发货时间是多久，比如发货破损率控制在多少，等等。

有了这个标准，第二步就能推动客服，在应对客户投诉的时候，先区分有没有违背服务原则。如果有就是物流执行没到位，转物流处理；如果没有，就得靠客服努力，或者安抚客户，或者向客户解释原则。这样大家都能在有限的成本内，最大化解决问题。

如果用问题解决思路，需要的分析就不1个建立客户满意度指标体系，而是3个相互配合的分析：

1. 依据物流原则，目前执行不到位的客户情况分析

2. 基于物流原则，客户真实不满意、假不满意的分析

3. 基于现有客服安抚方式，客户真/假不满意最终处理情况分析

分析的复杂度大大提高。

实际上，解决问题导向的分析逻辑都很复杂，并且依赖于数据分析师的业务处理能力。

小  结

你会发现：

• 一般网络文章里的数据分析思路都是中立判官式的，作者都喜欢把自己当成最大的老板，指点江山，真他妈爽。

• 一般现实工作中，都是故作小白的搞法。“请业务自己想清楚”“我就是个跑数据的，我啥也不懂”——到头来经常被人骂“没有用”“你分析了啥”。

• 一般老板们解决问题的时候，会用问题解决型思路，可丢给数据分析师的，是三份独立的取数表。跑数的同学还是不知道在干啥。

其实三种做法，单独看都没错，难的不是做某一种方法，而是审时度势，结合真实的问题点，系统数据现状，处理问题的决心，选择一个贴合实际的做法。

这就要求数据分析师们，如果真想参与解决问题的话，就得从问题沟通、开会、聊天就开始观察情势，构建思路，而不是像开篇那样，上来抓个关键词就百度走起了。

——————/ E N D /——————

产品经理培训｜产品运营培训｜企业内训服务

请在公众号后台回复「培训」了解更多

▼ 喜欢请分享&收藏，满意点个赞，最后点「在看」 ▼