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.未來規劃
界面改版
增加部分快捷工具：任務打標、置頂等等
信息集成
避免跳轉到其他頁面查詢信息，提高信息查詢效率
訂單退款進度、大神違規記錄