1. Version0.1时代（2019.09之前）
团队规模小 30人左右，极不规范，无服务意识
无自研客服系统 最早用网易七鱼，价格贵，不好用。后来用环信，开始使用环信的任务系统，但不好用。
查询信息效率低 用户进线后，客服在运营后台查询各种数据来处理用户的各种问题
2. Version1.0时代（2019.10-2020.06）
2019年10月，开始建设客服任务工作台，客服可以在任务工作台跟进各类用户问题。
前端：工作台查询任务，进行相关操作的界面
环信：客服可在环信页面上录入任务，这里调用的是Jira接入层提供的接口
工作台后端：负责提供订单相关操作的接口，同时给前端封装了一些操作jira的接口。工作台里与订单关联不大的数据，存在bixin-playmate-lite-service的DB中，如员工、组、投诉之类的信息。
Jira接入层：Java语言开发，代码及其不规范。与Jira部署在同一台机器上，基于Jira的接口对外提供接口给前端和客服工作台后端，也会从工作台后端查询一些配置数据。前期存在严重的性能问题，导致系统无法正常运行。经过优化后，现在已经可以正常运行。
Jira+MySQL：破解版Jira，部署在一台独立的机器上，没有源码，通过http接口与接入层交互。无性能问题，存在法律风险。
2019年10月底，系统上线
2019年12月起，开始零星出现前端页面无法正常展示客服任务的问题。
2020年1月底，新冠疫情，比心订单量暴增，客服人员增加到100人左右。
2020年4月起，客服工作台频繁出现无法相应的情况。
2020年5月某天Jira接入层系统监控图如下
问题总结：
①法律风险，Jira为未授权的产品，用于商业用途存在法律上的风险。
②Jira接入层代码质量太差，无法持续支撑业务发展。
③调用关系混乱，没有进行合理组织，可以看到Jira接入层同时对接了环信、前端和工作台后端。
④数据分散存储，缺乏统一管理。任务的数据存在Jira里，但是一些配置数据如员工信息、组信息等存在bixin-playmate-lite-service的DB中。
3.Version2.0时代（2020.06至今）
2020年6月开始建设新客服任务系统，目前是在不改变客服人员操作习惯的前提下，彻底解决上述问题。
3.1 核心功能点
3.2 表结构关系
3.3 任务核心字段
3.4 任务状态流转
3.5 任务分配方式
3.5.1 预闲分配
①给每个员工设置最大分配数量
②定时任务捞取待分配的任务
③找到 在线&&处理中的任务数量最少&&未达到最大分配数量 的客服
④乐观锁更新任务的处理人
3.5.2 轮询分配
①定时任务捞取待分配的任务
②找到所属工作组在线的客服
③找到上次被分配任务的客服A的下一个客服B
④乐观锁更新任务的处理人
3.5.3 领取分配
客服自己更新任务处理人即可
3.6 字段存储原则
任务相关的核心字段（影响任务分配流程）都放在任务主表里
业务相关的字段（不应该任务分配主流程）都放在扩展字段里
需要用来查询的子段拆到ES服务中
前端需要展示业务相关信息时，从扩展字段里拿到业务ID去系统系统查询数据展示（客服系统不做转发）
3.7 业务校验
某些情况下，在对任务进行操作时，需要进行业务逻辑判断。
如订单申诉的任务在完成前需要判断对应的申诉是否已完结，如果没有完结，则不可以完成任务。
创建任务时，在扩展字段中加上needCheckBeforeComplete=true checkBeforeCompleteServiceGroup=ORDER_APPEAL
在完成任务时，判断如果needCheckBeforeComplete=true ，就通过SPI请求Group=ORDER_APPEAL的dubbo服务，判断是否能完成任务。
4.经验教训
不可依赖存在风险的组件
破解版Jira存在诸多不确定性
编码规范&方案合理
重要项目需进行技术方案评审和Code Review
正确理解产品经理的意思 举例~
5.未来规划
界面改版
增加部分快捷工具：任务打标、置顶等等
信息集成
避免跳转到其他页面查询信息，提高信息查询效率
订单退款进度、大神违规记录