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

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

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

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

原因主要一下三点：

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

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

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

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

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

1. 在三级分类模板中完善“处理思路”模板，里面包括了该三级分类下所有可能出现的场景的标准记录方法，让员工删改标准模板的内容进行标准化记录。但是这种方法在搭建初期需要耗费大量的人力进行模板校对。且在实际使用中，员工的交互模式也很不友好。所以此种方式作罢。
2. 在客服数据组自有的服务器上搭建记录followup的点选交互。随着与用户的沟通，搜索或点选信息关键点，选择的关键点自动形成了标准的followup文本，在沟通完毕时，followup也就自动生成了。这种交互方式在服务器上已经写好，在与业务方测试时，也得到了认可。但由于无法写入员工日常使用的管理端，造成跨平台的交互繁琐，再次搁置。
3. 建立了一种业务方可自行增加标签，也可自行增加标签匹配规则的建模方式。业务方随着业务的发展，可以自行将新的信息点加入匹配系统。也可以因为有不同的文字表达方式，针对同一个信息点增加不同的匹配方式。数据组这边实时扫描新建立的followup，使得一线员工的记录得到实时的匹配结果。这个方案也是目前线上在测试使用的方案。

如果能全面执行方案3的构想，将会实现（包括但不局限于）如下的分析方法：

1. 提取特定场景的case变得无比简单，只需要标签的筛选即可。之前的方案是多个三级分类的组合，且还要人工删减，才能粗略实现。
2. 由于每条followup的文字都会被完整建模，都是一个个标签的组合，那么也就可以将机器学习算法应用在followup分析中。用最简单的决策树就能分析出所有场景下，哪个特定场景的case用户最不容易「满意」、最不容易「首次解决」，如果在该父级场景下满足了某一子项场景，「满意」或「首解」会有何种改变。
3. 形成业务场景监控图，实时发现突发的场景发生频率变化，迅速执行管理动作。

 

由于自身的说服能力和推进能力不足以驱动整个业务进行迅速的转变，只能一点点渗透引导业务方转变。所以把当前的想法记录下来，期待后续的同仁们一起探讨实现。

 

答疑：

Q:为什么不用NLP?

A:我不会。且就算会的话，也没有训练数据。TF-IDF的话，也无法解决人与人之间表达方式的不同。