我手把手分析了一个复杂的数据问题

0 评论 1351 浏览 1 收藏 12 分钟

本文深入探讨了一个复杂数据问题的分析过程,‌作者通过手把手的方式,‌详细剖析了问题的各个层面。‌文章首先介绍了数据问题的背景和重要性,‌随后逐步展开分析步骤,‌包括数据收集、‌预处理、‌探索性分析等关键环节。‌在分析过程中,‌作者运用了多种统计方法和可视化工具,‌深入挖掘数据背后的规律和模式。‌最终,‌文章总结了分析结果,‌并提出了针对性的建议和解决方案。‌本文不仅展示了复杂数据问题的分析方法,‌还为读者提供了实践指导和思路启发。‌

网上从0到1的文章很多,可面对复杂问题,该怎么搭建数据分析思路呢?首先,“复杂”一词在不同等级的数据分析师里含义不同。

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

而有经验的同学都知道,企业里真正复杂的才不是这些。来看个具体例子:

场景:电商行业(纸质书、视频光盘等商品为主),客服领导对物流领导意见非常大,认为物流问题影响了客户满意度。但物流领导表示:所有发货不及时,发货过程中包装破损等问题已经被处理了,怎么可能还有物流问题。现在有一份分析需求,要求:建立全面、细致的客户满意度评估指标体系。什么是真正的复杂问题。

问题1:收到这个需求,你会百度哪个关键词?

  • 评估指标
  • 客户满意度指标
  • 客服客户满意度指标
  • 物流客户满意度指标

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

于是开始百度上边四个关键字,找一个看起来可行的就开始干了。可关键问题是:眼前的问题,是大家不知道客户满意度怎么考核吗?

不是!眼前的问题是客服跟物流俩部门干上了!这才是大问题。所谓“客户满意度”只是两边干架的一个由头。如果“客户满意度”的标准不能让两边共识,那不管书本上是怎么定义的,只要你甩出来,都会被其中一方喷到死。这才是第一大难题。所以这一题根本就不该选。第一步要干的事,是先了解具体不满的点在哪里。

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

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

  • 到底啥算满意?
  • 客户不满意是不是就一定投诉?
  • 是不是客户满意了就不会投诉?

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

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

也可能客户闷声不响,但是最后退货!退货!退货!

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

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

这又涉及第三个问题:如何在各种庞杂数据里,真正识别出客户投诉/非投诉。如果按客户领导的说法,得把所有客户来电都转文字记录+关键词过滤一遍才能识别情况。可显然这么干太费时费力,得找个简单的处理办法。

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

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

  • 部门利益有冲突
  • 指标含义不清楚
  • 原始数据内容乱
  • 相关流程要改动

这些才是老鸟眼中真正难解决的问题。然而这也是企业真实的经营场景,那种数据完美,含义清晰,静静躺在excel表里等着被建模的事,只存在于网上文章里。现实就是各种利益纠葛,数据混杂,流程不清,咋弄呢???如何建立分析思路

总结下本次的问题。表面上看,是:客服反馈物流问题多,客户满意度低。可往深入看,客服与物流对客户满意度口径不统一,导致无法解决问题。再往深入看,客户的很多问题并非物流引起,却都怪到物流头上,客服自己没有做区分,而是一股脑打上门来。

这种场面下,有三种解决思路:

第一:中立判官。

如果得到了更高层授权,或者两个部门能平心静气谈,希望数据部门站在中间当判官,可以用这种思路。这时候可以围绕客服反馈的客户不满意问题,逐级梳理,把哪些是真问题,哪些是假抱怨一层层剥清楚:

第二:故作小白。

如果两个部门打得不可开交,铁了心要吵架的话,可以用这个思路。数据部门好像一只人畜无伤的小白兔,表示:“你看我们也不懂物流业务,也不懂客服业务,如果有需要区分哪些来电是不满意的,可以业务给具体的区分规则,我们按规则去提取数据”。

是滴,让两家自己吵架,定清楚了到底什么算不满意、从哪里、依照什么标准提数,数据部门就当个跑数机。并且只给数据,不给判断。这样是看着很怂,但是能在部门混战里先保护好自己。

第三:解决问题。

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

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

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

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

  • 依据物流原则,目前执行不到位的客户情况分析
  • 基于物流原则,客户真实不满意、假不满意的分析
  • 基于现有客服安抚方式,客户真/假不满意最终处理情况分析

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

小结

你会发现:

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

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

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

其实三种做法,单独看都没错,难的不是做某一种方法,而是审时度势,结合真实的问题点,系统数据现状,处理问题的决心,选择一个贴合实际的做法。这就要求数据分析师们,如果真想参与解决问题的话,就得从问题沟通、开会、聊天就开始观察情势,构建思路,而不是像开篇那样,上来抓个关键词就百度走起了。

然而,有的同学会说:老师,我的领导结结实实的提了“模型”俩字,感觉好难做啊。我辛辛苦苦做个模型,领导却说“没屁用!”“我说的不是这个!”咋办?

本文由人人都是产品经理作者【接地气的陈老师】,微信公众号:【接地气的陈老师】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 目前还没评论,等你发挥!