问题场景：某物流公司，担任管司机的调度中心，会给每个未上线司机标示原因，标示格局如下：

　　这么做看起来比0级有深度了不少，但没处理一个核心问题：“究竟司机不上线是啥原因？“，特别是“请假”份额这么高，究竟是司机不想干，仍是没需求，仍是渠道出了问题。

　　▌第三层分类逻辑，能够看司机是否投诉反应渠道。比方渠道扣钱太多，这是个规矩问题。渠道方也不可能由于一个司机的诉苦就改规矩。可是，对投诉类问题要先掌握情况。这样才能够继续监控，发现更深化的问题。至于没有投诉情况下，司机个人问题，另行处理：

　　没真话。拉货的司机不是办公室文质彬彬的小白领，没心境一句句细讲心路历程。一句：“累”背面，可能有多重意义：

　　●线路跑得累，不想干这个线路的司机了单纯盼望口头问，很难理清楚这儿逻辑。更不要说大部人连个“累”都懒得说，便是简简略单的不接电话/“请个假”。调度员每天对着几十个司机，也没空一个个谈心，也不太盼望调度员能把个人原因都整了解。所以这儿能够简略记载原因，靠后续剖析来做深。

　　这些并不反映在调度表里，可是却直接影响调度结果与司机上线，因而就需要从线路需求表里，先剖析清楚，这样解说调度的原因才简单说。

　　这样归纳剖析，才便利运营评价：是否要呼应投诉，看到投诉目标改变，也好了解这个目标对事务的影响程度。

　　▌比方问题3：司机究竟是累仍是不想干，得先看内部数据说话经过内部数据，能看出司机实践行车时刻，把“累“字背面意义：真的累or赚不到钱区别出来，然后针对性剖析。这样做比追着司机寻根究底，更简单发觉缺点（如下图）。

　　很长时刻以来，人们把做数据剖析的当作算命先生：我不说话，你丢几个铜钱（敲几下键盘）就天知地知。这是十分十分扯淡和过错的。