1、工單業(yè)務(wù)簡(jiǎn)介及核心鏈路

1.1  業(yè)務(wù)簡(jiǎn)介

得物客服工單系統(tǒng)主要承載著得物與用戶(hù)關(guān)聯(lián)需要客服處理的事件，其主要功能可以認(rèn)為有如下兩項(xiàng)：

• 承載事件的基本信息及關(guān)聯(lián)信息
• 允許客服處理事件，并可以流轉(zhuǎn)相關(guān)信息至關(guān)聯(lián)方或用戶(hù)

簡(jiǎn)單來(lái)說(shuō)就是客服根據(jù)工單信息進(jìn)行流轉(zhuǎn)處理，圍繞著這個(gè)核心鏈路，工單域在處理中心、信息分類(lèi)的管理配置、客服人員的管理及分配，以及信息處理過(guò)程的質(zhì)檢抽檢等做了很多建設(shè)。

1.2  核心鏈路

要完成這個(gè)核心鏈路作業(yè)那就需要有一個(gè)承載平臺(tái)，那就是工單工作臺(tái)，包括工單的來(lái)源，展現(xiàn)，處理流轉(zhuǎn)及最終處理方案的完結(jié)，如下圖所示：

工單工作臺(tái)作為核心鏈路承載平臺(tái)，是二線(xiàn)客服對(duì)工單作業(yè)的“生產(chǎn)流水線(xiàn)”，是整個(gè)工單作業(yè)的核心，因此在這篇文章后續(xù)所有的優(yōu)化都是圍繞著這一點(diǎn)來(lái)進(jìn)行的。

工單作業(yè)的流程是相當(dāng)復(fù)雜的，我們需要另外一張圖將核心部分的流程表達(dá)出來(lái)，如下圖所示：

• 工單中心每天會(huì)收集來(lái)自各個(gè)來(lái)源的工單，在線(xiàn)客服進(jìn)線(xiàn)產(chǎn)生的工單是主要部分，占比一半左右。
• 二線(xiàn)客服根據(jù)工單的信息還有與用戶(hù)溝通的情況，需要其他客服或其他域提供協(xié)助或其他信息，此時(shí)工單會(huì)流轉(zhuǎn)至關(guān)聯(lián)方。
• 當(dāng)關(guān)聯(lián)方提供相關(guān)信息或協(xié)助后，大部分工單會(huì)返回到當(dāng)前客服繼續(xù)下一步處理。
• 當(dāng)客服本身與客戶(hù)，其他關(guān)聯(lián)方全部協(xié)商一致后，會(huì)根據(jù)工單情形進(jìn)行對(duì)應(yīng)的完結(jié)處理，而完結(jié)的處理流程目前有數(shù)十種。

在這個(gè)核心的作業(yè)流水線(xiàn)上，平均每天有很多很多的客服處理更多更多的工單，這些客服每天工作至少非常多的時(shí)間是在章魚(yú)工單工作臺(tái)上持續(xù)的作業(yè)。

這是我們?cè)诙€(xiàn)客服職場(chǎng)調(diào)研時(shí)的場(chǎng)景，在工位上的客服基本都在使用工單工作臺(tái)（10個(gè)打開(kāi)屏幕的，至少有九個(gè)屏幕內(nèi)容是工單工作臺(tái)），說(shuō)實(shí)話(huà)，作為一個(gè)前端，當(dāng)上百號(hào)客服同時(shí)在你面前使用你開(kāi)發(fā)的應(yīng)用時(shí)，還是相當(dāng)震撼的，同時(shí)也深感責(zé)任的重大。

這在前端方面對(duì)工作臺(tái)從性能，穩(wěn)定性，易用性等各個(gè)角度的體驗(yàn)問(wèn)題上提出了很大的要求！

2、工單域前端問(wèn)題

在參與工單業(yè)務(wù)開(kāi)發(fā)時(shí)，工單在前端這方面存在很多的問(wèn)題，這些問(wèn)題集中在兩個(gè)方面：

• 面向客服同學(xué)的使用體驗(yàn)問(wèn)題，集中在性能，穩(wěn)定性和易用性等方面；
• 面向研發(fā)同學(xué)的研發(fā)體驗(yàn)或效能問(wèn)題，集中在代碼維護(hù)困難，花費(fèi)大量精力處理線(xiàn)上問(wèn)題等。

而需要解決這些問(wèn)題，需要多種手段多種維度介入。

3、多維度重構(gòu)優(yōu)化現(xiàn)有系統(tǒng)

在架構(gòu)設(shè)計(jì)中, 架構(gòu)形態(tài)往往是跟隨業(yè)務(wù)形態(tài)變化而變化。在客服域內(nèi)，面向一二線(xiàn)客服作業(yè)的章魚(yú)工作臺(tái)已使用微前端來(lái)區(qū)分IM，電話(huà)，工單及工具箱；而對(duì)工單域來(lái)說(shuō)，除了要開(kāi)發(fā)作為章魚(yú)工作臺(tái)的子應(yīng)用外，還有各個(gè)方面的架構(gòu)調(diào)整或性能提升優(yōu)化需要做：

3.1  聚合接口，加速工單渲染

工單詳情每次渲染初始接口數(shù)有21個(gè)，在服務(wù)端同學(xué)梳理整合這些接口成本過(guò)高的情況下，與服務(wù)端同學(xué)一起推動(dòng)使用網(wǎng)關(guān)聚合的模式，將前端請(qǐng)求接口數(shù)降低至5個(gè)，整體渲染完成時(shí)間降低至600ms以?xún)?nèi)。

3.2  區(qū)分快慢，縮短訂單FMP

訂單詳情接口字段有190多個(gè)，但是其中首屏接口100多個(gè)，其中有部分字段還依賴(lài)外域，導(dǎo)致整個(gè)接口RT過(guò)長(zhǎng)，前端與后端協(xié)商后，推動(dòng)了快慢接口的方案的落地，其原理如下：

• 快接口：將首屏較慢的依賴(lài)外域的字段去除，經(jīng)過(guò)分析, 去除最慢5個(gè)字段后，接口rt能降低到300ms以?xún)?nèi)；
• 慢接口：即全量接口，作為補(bǔ)充快接口未返回字段之用；
• 接口批次處理：其他接口，在以往是返回即更新，會(huì)導(dǎo)致頁(yè)面過(guò)于頻繁的更新，甚至抖動(dòng)，因此將頁(yè)面更新機(jī)會(huì)集中在三次，以降低渲染偏移量(CLS, Cumulative Layout Shift)。

其中首屏渲染能將首屏中95%的字段優(yōu)先展示，方案運(yùn)行后，首屏FMP渲染時(shí)間從873ms降至376ms，下降了57%，95分位567ms，下降了62%。另外我們也在推動(dòng)優(yōu)化外域接口，后續(xù)將進(jìn)一步降低渲染時(shí)間。

3.3  引入Module Federation， 使應(yīng)用互聯(lián)

引入MF（Module Federation，遠(yuǎn)程組件）是一個(gè)十分創(chuàng)新和實(shí)用的新技術(shù)轉(zhuǎn)化的舉措，其解決了子應(yīng)用間互相渲染業(yè)務(wù)組件的困局：

• 使用iframe，性能差，渲染慢，內(nèi)存占用高，經(jīng)常導(dǎo)致崩潰；
• 使用npm包，嚴(yán)重推高研發(fā)維護(hù)成本，提升線(xiàn)上風(fēng)險(xiǎn)。

而MF遠(yuǎn)程組件能十分完美的解決上述問(wèn)題。

使用后將渲染時(shí)間降低了6倍，內(nèi)存占用減少到了之前的1/10以?xún)?nèi)：

除了提升性能，在業(yè)務(wù)模塊間高效率復(fù)用也是該技術(shù)的亮點(diǎn)，所以這也是接下來(lái)幾個(gè)重要業(yè)務(wù)技術(shù)重構(gòu)的基礎(chǔ)技術(shù)。

該技術(shù)方案也獲得了2022年技術(shù)部微創(chuàng)新之星獎(jiǎng)，相關(guān)詳細(xì)內(nèi)容也已發(fā)布到得物技術(shù)公眾號(hào)上：《Module Federation 在得物客服工單業(yè)務(wù)中的最佳實(shí)踐》。

3.4  推行單實(shí)例，提升性能

在開(kāi)發(fā)工單工作臺(tái)工單詳情時(shí)，由于客服作業(yè)時(shí)經(jīng)常保留多個(gè)工單詳情tab，如果詳情使用多實(shí)例，那勢(shì)必會(huì)造成頁(yè)面dom節(jié)點(diǎn)數(shù)多，內(nèi)存占用高的情況，因此開(kāi)發(fā)時(shí)就是設(shè)計(jì)成單實(shí)例的。

而工單工作臺(tái)與工單系統(tǒng)兩個(gè)應(yīng)用隔離后，工單系統(tǒng)使用工作臺(tái)的詳情頁(yè)面時(shí)，由于兩個(gè)系統(tǒng)的技術(shù)棧是不一樣的，因此不能通過(guò)遠(yuǎn)程組件聯(lián)通，只能使用iframe，由于工單系統(tǒng)打開(kāi)詳情頁(yè)也有較高的頻次，每次渲染iframe也依舊很慢，因此利用iframe的postMessage通信，及工單詳情的單實(shí)例特性，工單系統(tǒng)切換tab時(shí)將工單號(hào)通過(guò)postMessage通知工單工作臺(tái)，再通過(guò)工單詳情的單實(shí)例切換，在非首屏場(chǎng)景也能取得與MF相當(dāng)?shù)捻憫?yīng)速度。

這個(gè)方案是在兩個(gè)互相關(guān)聯(lián)的應(yīng)用不是同一技術(shù)棧情況的下的過(guò)渡方案，隨著所有應(yīng)用都向React遷移，未來(lái)MF仍舊是主力方案。

3.5  動(dòng)態(tài)渲染，降開(kāi)發(fā)維護(hù)成本

簡(jiǎn)單來(lái)說(shuō)思路就是：過(guò)簡(jiǎn)單的數(shù)據(jù)內(nèi)容的增減和修改，根據(jù)約定動(dòng)態(tài)渲染，快速達(dá)成業(yè)務(wù)目標(biāo)。以替代工單創(chuàng)單，關(guān)單流程，訂單渲染等關(guān)鍵環(huán)節(jié)的各自問(wèn)題。

3.5.1  創(chuàng)建工單的重構(gòu)

創(chuàng)建工單以往存在著這樣的問(wèn)題：

• 不同工單類(lèi)型對(duì)應(yīng)創(chuàng)單表單不一樣，模板渲染又十分復(fù)雜
• 多個(gè)應(yīng)用維護(hù)同樣業(yè)務(wù)代碼，代碼技術(shù)棧又不一致的情況，維護(hù)起來(lái)十分頭疼
• 在IM創(chuàng)單場(chǎng)景，由于客服切換IM會(huì)話(huà)頻次較快，又沒(méi)有涉及按會(huì)話(huà)ID維度的單獨(dú)表單內(nèi)存存儲(chǔ)空間，時(shí)常會(huì)發(fā)生表單信息丟失或錯(cuò)亂的情況, 線(xiàn)上很多問(wèn)題多是由于這樣的原因?qū)е碌摹?/li>

因此在設(shè)計(jì)新的架構(gòu)時(shí)，設(shè)計(jì)了兩個(gè)維度的數(shù)據(jù)隔離：第一維度是會(huì)話(huà)維度，第二維度是會(huì)話(huà)內(nèi)數(shù)據(jù)內(nèi)容和模板數(shù)據(jù)的隔離，以便提交表單時(shí)能立即將當(dāng)前表單數(shù)據(jù)內(nèi)容提交。

• 一份不同會(huì)話(huà)維度的數(shù)據(jù)表，該表會(huì)隨著客服與不同用戶(hù)的會(huì)話(huà)的新增結(jié)束而動(dòng)態(tài)變化
• 客服切換會(huì)話(huà)時(shí)，根據(jù)對(duì)應(yīng)會(huì)話(huà)的數(shù)據(jù)，立即渲染出對(duì)應(yīng)的表單內(nèi)容
• 客服會(huì)高頻的切換不同的會(huì)話(huà)
• 將客服在當(dāng)前創(chuàng)建工單表單的修改內(nèi)容反應(yīng)至對(duì)應(yīng)的數(shù)據(jù)，這里的難點(diǎn)是：

有時(shí)修改數(shù)據(jù)的交互是異步的，例如修改訂單號(hào)會(huì)異步查詢(xún)訂單信息并自動(dòng)填充

假設(shè)這個(gè)過(guò)程中發(fā)生了客服切換會(huì)話(huà)，那有可能導(dǎo)致信息錯(cuò)亂

解決手段是充分利用閉包緩存的特性，當(dāng)異步返回時(shí)設(shè)置對(duì)應(yīng)閉包下會(huì)話(huà)id的數(shù)據(jù)內(nèi)容

通過(guò)以上重構(gòu)的手段，再結(jié)合Module Federation統(tǒng)一不同應(yīng)用中的業(yè)務(wù)代碼，徹底解決了之前的問(wèn)題。

相關(guān)流程圖：

3.5.2  關(guān)單流程的重構(gòu)

關(guān)單流程目前存在著數(shù)十個(gè)不同的流程類(lèi)型，每種流程類(lèi)型客服關(guān)單時(shí)的表單內(nèi)容和流程都是不一樣的，在以往都是按簡(jiǎn)單的判斷邏輯堆砌流程，導(dǎo)致代碼十分冗長(zhǎng)和復(fù)雜，在充分梳理不同流程類(lèi)型的業(yè)務(wù)邏輯后，新的架構(gòu)設(shè)計(jì)方案如下：

• 將不同流程類(lèi)型渲染邏輯通過(guò)schema表達(dá)，由于該表達(dá)較為復(fù)雜并且與交互關(guān)聯(lián)較大，因此維護(hù)在前端
• 通過(guò)schema組件渲染器邏輯，渲染對(duì)應(yīng)流程表單，也可將通用信息或特殊業(yè)務(wù)信息透?jìng)鹘o該流程下的對(duì)應(yīng)組件
• 不同流程類(lèi)型通過(guò)schema配置，可快速插拔組件和復(fù)用組件

該方案有點(diǎn)類(lèi)似低代碼的渲染邏輯，能很好的梳理出不同流程各自的邏輯，也便于后期的開(kāi)發(fā)維護(hù)，該重構(gòu)上線(xiàn)后，前后端在關(guān)單業(yè)務(wù)上的開(kāi)發(fā)比例從1:1下降至1:3，節(jié)省了很多前端開(kāi)發(fā)維護(hù)成本。

3.5.3  訂單詳情的重構(gòu)

訂單詳情平常需求中，約60%的需求都是配合外域或者內(nèi)部的簡(jiǎn)單的字段增改，雖然前端開(kāi)發(fā)內(nèi)容不多，但每個(gè)也要花費(fèi)前端的開(kāi)發(fā)成本。在最新的重構(gòu)中，設(shè)計(jì)是這樣的：

• 將變化較大的訂單基本信息及關(guān)聯(lián)信息通過(guò)統(tǒng)一schema維護(hù)
• 前后端約定schema的格式，后端將對(duì)應(yīng)數(shù)據(jù)通過(guò)該schema格式的數(shù)據(jù)返回
• 前端根據(jù)該格式渲染至頁(yè)面，簡(jiǎn)單增減字段時(shí)前端無(wú)需開(kāi)發(fā)，只需后端配置對(duì)應(yīng)字段值即可。

該方案是前后端共同推進(jìn)的，目前已上線(xiàn)，正在灰度中（2023年3月底），統(tǒng)計(jì)以往數(shù)據(jù)，訂單需求預(yù)計(jì)可節(jié)省66%的前端人力投入，在最近515的需求中已有部分需求無(wú)需在新的重構(gòu)版本中投入人力。

4、發(fā)布、值班機(jī)制的健全

在以往由于人力都陷入到平常繁雜的維護(hù)和線(xiàn)上問(wèn)題處理中，對(duì)CR等機(jī)制投入度不足，在經(jīng)過(guò)一系列重構(gòu)后，線(xiàn)上問(wèn)題得到很大的緩解，因此可以人力投入到一些預(yù)防性的機(jī)制中。

4.1  發(fā)布機(jī)制

發(fā)布前會(huì)設(shè)置各項(xiàng)嚴(yán)格的卡口，都通過(guò)后才能發(fā)布，卡口如下

• 各環(huán)境驗(yàn)證，需求確認(rèn)，權(quán)限配置確認(rèn)
• 每個(gè)需求都會(huì)列出前端修改點(diǎn)以及前端評(píng)估的影響面
• 每個(gè)需求都需要兩位以上前端對(duì)功能進(jìn)行實(shí)際的驗(yàn)收
• 每個(gè)需求都需要測(cè)試知曉修改點(diǎn)和影響面，并確認(rèn)

4.2  值班機(jī)制

在之前的值班機(jī)制上加強(qiáng)或增加這些環(huán)節(jié)：

• 正式迭代發(fā)布次日早上，會(huì)與二線(xiàn)客服上班時(shí)間同步值班（早上8點(diǎn)半左右）

解答客服對(duì)新迭代功能的可能的疑惑

如有問(wèn)題能馬上定位，采取回滾或其他方式立馬止血

• 線(xiàn)上客服作業(yè)問(wèn)題反饋，查看最近一個(gè)季度數(shù)據(jù)，基本做到了5分鐘響應(yīng)，10分鐘左右給到相應(yīng)解答，大多數(shù)在響應(yīng)的同時(shí)給到解答方案。

5、階段性總結(jié)

5.1  線(xiàn)上TS問(wèn)題歸零

在首先通過(guò)多項(xiàng)重構(gòu)優(yōu)化手段改進(jìn)當(dāng)前架構(gòu)后，架構(gòu)的文檔性，線(xiàn)上穩(wěn)定性在逐步提升，最顯著的表現(xiàn)就是線(xiàn)上TS問(wèn)題反饋數(shù)在逐步的降低，至2023年Q1，線(xiàn)上歸因前端的TS問(wèn)題數(shù)降至0個(gè)，如下所示：

5.2  滿(mǎn)意度穩(wěn)步提升

線(xiàn)上問(wèn)題變少了，客服系統(tǒng)前端可用性變高了，架構(gòu)優(yōu)化了，速度性能提高了，也必定會(huì)助力二線(xiàn)客服的體驗(yàn)和滿(mǎn)意度節(jié)節(jié)攀升，2023年Q1滿(mǎn)意度達(dá)到了80%，如下所示：

注：2022年Q1由于未開(kāi)始調(diào)研，暫無(wú)數(shù)據(jù)，用Q2數(shù)據(jù)替代；該數(shù)據(jù)來(lái)源于二線(xiàn)客服直接發(fā)放的調(diào)研問(wèn)卷，平均每季度回收400多份，取分?jǐn)?shù)8,9,10三個(gè)分?jǐn)?shù)為滿(mǎn)意。

線(xiàn)上系統(tǒng)的穩(wěn)定性和客服滿(mǎn)意度這兩個(gè)指標(biāo)是系統(tǒng)健壯性，完善性的最終端指標(biāo)，這兩個(gè)數(shù)據(jù)可以說(shuō)是這一系列工作的成果，能代表在工單域所做的事情是很有成效的。

6

類(lèi)端能力的探索

工單工作臺(tái)與章魚(yú)其他工作臺(tái)一樣，與傳統(tǒng)的中后臺(tái)系統(tǒng)不同，其存在這么幾個(gè)特性：

• 使用頻次高：以二線(xiàn)工單詳情為例，二線(xiàn)客服一天打開(kāi)工單詳情的中位數(shù)在數(shù)百次（含重復(fù)打開(kāi)）左右
• 使用時(shí)間長(zhǎng)：一天工作時(shí)間使用工作臺(tái)時(shí)間占比90%（7+小時(shí)）以上
• 操作強(qiáng)度高：即頁(yè)面內(nèi)表單，按鈕點(diǎn)擊等操作的數(shù)量和頻率（該數(shù)據(jù)收集能力在建設(shè)中）

上面所述的很多優(yōu)化就是為了更好的適配這些特性所要求的高性能高速度而建設(shè)的，上述的很多特性其實(shí)更接近于桌面客戶(hù)端的一些要求，例如常見(jiàn)的繪圖軟件、office等辦公軟件，桌面軟件除了上述性能要求外，其實(shí)還具備其他很多特性，如：本地特性（本地權(quán)限），版本化，閉環(huán)化，緩存、狀態(tài)持久化等等。

對(duì)于工單工作臺(tái)而言，除了本地權(quán)限要求不高外，接下來(lái)遇到的挑戰(zhàn)與其他桌面軟件其他特性高度相似！因此接下來(lái)將圍繞著這些能力進(jìn)行建設(shè)，簡(jiǎn)稱(chēng)為類(lèi)端能力，這些能力根據(jù)重要性將會(huì)分為這幾個(gè)方面：

6.1  流程閉環(huán)化

客服日常作業(yè)的特點(diǎn)是鏈路固定，操作流程清晰是連貫持續(xù)的，而且不希望操作流程被各種窗口跳轉(zhuǎn)給意外打斷，而目前工單工作臺(tái)中或多或少存在需要跳轉(zhuǎn)到工單系統(tǒng)或其他系統(tǒng)的情況，這種情況就是非閉環(huán)的，而從日常的客服反饋及到客服現(xiàn)場(chǎng)調(diào)研的結(jié)果來(lái)看，各種鏈接外跳也是最影響操作情況，是我們要克服的而建設(shè)路徑有這幾點(diǎn)：

6.1.1  業(yè)務(wù)組件插件化

分析很多外跳的原因，大部分都是關(guān)聯(lián)查詢(xún)類(lèi)、操作類(lèi)訴求，首先這些查詢(xún)功能可能不是歸為當(dāng)前項(xiàng)目的，那可以將所有的被依賴(lài)的功能點(diǎn)都插件化，主要手段就是MF。

使用Mlodule Federation：鏈接不同項(xiàng)目間的插件，這一方式會(huì)隨著React技術(shù)棧的統(tǒng)一，應(yīng)用會(huì)越來(lái)越頻繁

在2022年Q4，坐席輔助的SOP項(xiàng)目，就是大量使用了工單/訂單的業(yè)務(wù)遠(yuǎn)程組件，而不需要各種外跳。而工單，訂單詳情本身的外跳則需要后期不斷的插件建設(shè)和React技術(shù)棧統(tǒng)一來(lái)解決。

6.1.2  路由跳轉(zhuǎn)規(guī)范化

引入MF后，加上仍有部分場(chǎng)景的iframe，路由跳轉(zhuǎn)是日常維護(hù)中很大的一個(gè)痛點(diǎn)，被引用方需要進(jìn)行判斷以何種方式被打開(kāi)，怎么通知父項(xiàng)目，根據(jù)不同的方式跳轉(zhuǎn)等等問(wèn)題，導(dǎo)致這一方面的維護(hù)成本很大，未來(lái)將針對(duì)性對(duì)路由跳轉(zhuǎn)封裝相應(yīng)SDK，將各種跳轉(zhuǎn)場(chǎng)景進(jìn)行收斂和規(guī)范。

6.1.3  便利工具內(nèi)建

一些可以便利客服作業(yè)的工具內(nèi)建，例如之前客服反饋需要截圖的內(nèi)容在工單上傳十分麻煩：截圖->保存本地->點(diǎn)擊上傳->查找選取對(duì)應(yīng)圖片->上傳；可以發(fā)現(xiàn)，這個(gè)鏈路也不是閉環(huán)的，需要跑到操作系統(tǒng)進(jìn)行操作，而加入自動(dòng)粘貼截圖內(nèi)容功能后，客服的操作就變成了：截圖 -> ctrl+v粘貼 ，在工作臺(tái)內(nèi)就能完成。

6.2  資源緩存與接口數(shù)據(jù)持久化與管理

在工作臺(tái)內(nèi)存在著一些數(shù)據(jù)不通用，一些情況需要重復(fù)請(qǐng)求的情況，如工單詳情頁(yè)面切回原來(lái)工單時(shí)，其數(shù)據(jù)會(huì)被重新請(qǐng)求，而頁(yè)面需要重新依賴(lài)新數(shù)據(jù)進(jìn)行渲染的情況，在客服作業(yè)場(chǎng)景，平均同一個(gè)工單號(hào)會(huì)被重復(fù)打開(kāi)5次，因此這個(gè)場(chǎng)景值得優(yōu)化。一個(gè)優(yōu)化辦法是將重點(diǎn)接口緩存并有機(jī)更新，將主要依賴(lài)service worker技術(shù)，在嘗試中取得了很好的成績(jī)：

經(jīng)過(guò)SW緩存的接口，返回速度呈現(xiàn)了數(shù)量級(jí)的提升；

但該方案仍有一個(gè)重點(diǎn)問(wèn)題需要解決：

• 如何有機(jī)更新同一工單接口數(shù)據(jù)，否則可能拿到的一直是老的數(shù)據(jù)

該方案成熟上線(xiàn)后將使應(yīng)用響應(yīng)速度上一新的臺(tái)階。

6.3  其他類(lèi)端能力

接下來(lái)兩個(gè)優(yōu)化需要進(jìn)一步與產(chǎn)品探討和調(diào)研。

6.3.1  版本推送

與產(chǎn)品探討過(guò)，增加新版本推送通知能幫助客服及早使用到新的功能，也能在解決完線(xiàn)上故障或回滾時(shí)立馬推送及時(shí)線(xiàn)上止血。

6.3.2  獨(dú)立窗口

將工作臺(tái)獨(dú)立窗口，與部分客服溝通過(guò)，認(rèn)為能增加作業(yè)效率，因?yàn)榘l(fā)現(xiàn)日常作業(yè)過(guò)程中，客服需要經(jīng)常切換瀏覽器其他窗口或者切換飛書(shū)，當(dāng)將工作臺(tái)作為獨(dú)立窗口后，1. 可以通過(guò)快捷鍵ctrl+tab快速切換不同的應(yīng)用; 2. 獨(dú)立APP應(yīng)用icon打開(kāi)工作臺(tái)。