客服中心业务分析数学建模

作为客服中心的数据分析师，日常面对的工作无非是两种。一是对员工行为的操作统计、监控，第二种则是对用户真实声音的建模。

其实第一类的需求不管多么复杂，都是有产品化埋点支持的，无非是脚本复杂一些，没有什么实现不了的，所以暂且不聊。

第二类则要复杂难缠得多。

原因主要一下三点：

1. 用户的声音各式各样：课中课外、咨询抱怨、对员工还是外教、政策不满。各种场景下的因果前后组合形成了用户当前的困局。分析难度本来就大。
2. 员工在记录followup时，并不会把用户遇到的情况完完整整的记录下来。员工用户思维的缺失，会在记录时遗漏一些关键因素。所以我们在分析单个case时，还需要将原始录音再听一遍，效率低下。在分析全部case时，更是不可能完成的任务。
3.  就算员工可以把录音的实况完整记录下来，人和人的问题表达方式都有不同，在没有打点训练数据或sop规范的前提下，很难将followup中的关键点一一提取。

目前产品化的分析解决方案是给每条followup添加一个三级分类，这种方案其实是不够的，原因如下：

1. 用户反映的声音很复杂，三级分类最多只能涵盖3个信息点，其实是无法cover用户所有的声音，尤其是分析的重点就是那些细节点。
2. 在用户反映的情况稍微复杂时，员工在选择三级分类时就会有犹豫不决，因为三级分类设置的不严谨、有重叠，这个case同时可以满足多个分类的条件。如果选择了某一个分类，在分析相近分类时，数据就会因为分流而缺失。
3. 「三级」这种设置方式，使信息点有了主次。也就是说，在这种框架下分析，只能由上至下的分析。无法把各分类的信息点不同层级交织起来作分析，分析结果自然就会片面。

现在业务方的补救方式是「增加更多的三级分类」，让每级分类涵盖更多的信息。看起来是补救了缺陷1，但是缺陷2,3会更加的突出，目前的做法有点陷入了泥潭。

2019年起，运营方做出了如下动作：

1. 在三级分类模板中完善“处理思路”模板，里面包括了该三级分类下所