面向在線客服系統的調度算法研究*

嵇友浪，朱 君，鄒云峰，周子馨，陳 興

(1．國網江蘇省電力有限公司營銷服務中心,江蘇 南京 210019；2．河海大學計算機與信息學院,江蘇 南京 211100)

1 引言

傳統的客戶服務系統，又稱呼叫公司系統，是一種基于計算機與電話集成CTI(Computer Telecommunication Integration)、通信、網絡和數據庫等技術為基礎的綜合信息系統[1]，是企業為了客戶服務、市場營銷、技術支持等建立的一個接收和發出呼叫的實體。其目的是快速應答客戶的電話、E-mail、Web等多種現代化媒體的呼叫，處理客戶的咨詢、報修和投訴等服務業務[2]。傳統的客戶服務系統采用一對一服務模式，即一位客服人員在某一時刻只能服務一位客戶，在請求服務的客戶較多時客戶等待時間較長，客服響應度低，影響客戶體驗[3]。

隨著科學技術的發展，各行各業為其客戶提供服務的方式不僅僅局限于電話呼叫，還包括依托信息檢索與互聯網技術的在線客服系統[2]。在線客服系統通常采用一對多的服務模式，并引入智能機器人交互功能[4]，提升系統工作效率，大幅減少客戶等待時間，降低企業成本。然而，隨著在線服務量的增大和客戶對服務質量要求的提升，在線客服系統仍然面臨著合理分配、客服團隊管理等難題[5]。所以，面向在線客服系統的調度算法已經成為各個公司實現服務優質化的迫切需求之一。

目前，客服系統中常用的調度算法主要有先到先服務算法、最短服務時間優先算法、最長等待時間優先算法、基于單一技能分配算法、黑名單算法和技能組算法等[6]。

在調度策略研究方面，丁振國等人[7]針對Web呼叫中心的排隊問題，提出了一種適應Web呼叫中心的新客戶優先、上次服務和最近最閑分配相結合的策略，以及與平均通話時長、通話次數、等待時間相關的動態優先級排隊策略。在調度算法研究方面，Servi等人[8]提出了一種負載均衡和最小化傳輸成本的優化伯努利調度算法，解決了在離散時間瞬間分配概率的問題。Wallace等人[9]提出了一種基于客服技能的調度算法，實現了將客戶分配給具備不同技能的非通用技能型客服。Gurvich等人[10]提出了一種面向客服中心的服務級別差異調度算法，基于服務質量的等級劃分解決客服與客戶之間的匹配問題，實現了人員配置成本的最優化。在模型構建與評估研究方面，Chen等人[11]提出了一種動態優先級客服中心的擾動分析方法，驗證了具有確定性閾值的動態優先客服中心流體模型的準確性。

概括起來，目前已有工作大都基于傳統呼叫中心人工接線的服務方式，主要針對調度策略、調度算法和模型評估進行研究。針對這一研究現狀，本文在分析在線客服基本特征的基礎上，提出了一種面向在線客服系統的調度模型及其調度算法，主要工作如下所示：

(1)根據客戶相關特征構建多優先級客戶隊列，綜合在線客服負荷與客戶隊列狀態特征劃分調度系統狀態并構建狀態之間的轉換關系。

(2)建立調度策略與調度系統狀態之間的對應關系，構建調度模型。

(3)在調度模型基礎上，根據系統狀態及其之間轉換關系，設計對應的在線客服系統調度算法。

(4)通過實驗驗證了調度模型的合理性與調度算法的有效性。

一方面，調度算法在實現相關調度策略為客戶提供高質量服務的前提下，確保了客戶平均等待時間在可接受范圍內，符合預期；另一方面，實現了客服坐席的合理分配，達到了客服負載均衡的目標。

2 在線客服系統分析

在線客服系統能夠實時處理客戶發起的對話和客服的應答對話，整合企業資源，實現高效的服務調度。從客服的角度來看，大大縮短了服務響應時間，工作量的安排比傳統呼叫公司時代更加科學、公平，提高了服務質量和客戶滿意度。從客戶的角度來看，極大地縮短了等待時間，訴求得到快速響應，用戶體驗得到很大的提升。

在線客服系統由3個部分組成，即客服、客戶和在線客服系統。這3個部分的特征對調度算法的設計至關重要。

2.1 客服特征分析

對客服選取技能組別、客服等級、最大接線數、階段性總服務量和滿意度5個特征進行分析。

(1)技能組別。結合業務內容將技能劃分為故障報修、營業業務、電能計量、電價政策、電費管理、供用電管理和電子渠道，具體情況視客服能力而定。

(2)客服等級。根據各客服的業務水平，客服等級分為初級、中級和高級。

(3)最大接線數。即客服可同時服務客戶的最大數量。每位客服依據能力強弱設定最大接線數，在服務過程中，客服同時提供服務的數量不能大于最大接線數。

(4)階段性總服務量。即某位客服在一段工作周期內接待的總客戶數量。為客服設置階段性總服務量，對工作量的公平分配提供參考依據。

(5)滿意度。客服在完成一次服務后，客戶對其服務過程和服務結果進行滿意度評價，有利于找出客服服務短板，提高服務質量。

2.2 客戶特征分析

客戶有如下幾個特征：

(1)等待時間。客戶從請求服務開始計算等待時間，遵循先來先服務原則，在僅有等待時間差異的條件下，客戶等待時間越長，服務的優先級理應越高。

(2)客戶等級。針對所有綁定戶號的客戶預先設置其級別，級別劃分為VIP、普通客戶和游客。游客是指尚未綁定戶號的請求服務的客戶。

(3)歷史訪問。單次歷史訪問特征包括客戶的訴求信息、服務該客戶的客服信息、服務時長和訪問頻率，為合理分配客服提供參考。

(4)訴求類別。不同的訴求類別在實際調度中有優先次序關系，例如故障報修業務可視為緊急業務，相比較咨詢類業務應優先調度，根據訴求的緊迫程度進行訴求分類。

2.3 在線客服系統特征分析

在線客服系統與傳統客服系統相比有如下幾個特征：階段性、并行性、弱連接性、多渠道接入和多形式交互。

Figure 1 Multi-queue scheduling model圖1 多隊列調度模型

(1)階段性。在線客服系統存在明顯的階段性特征，不同的客服人員業務能力水平存在差異，因此處理業務的時長存在差距，針對不同的客戶群體，同一客服在處理業務時也會有明顯的時間開銷差異。同時客戶訪問量具有階段性特征，例如某一緊急突發事件會導致某一時段客戶的集體性訪問，而隨著該事件的解決，客戶訪問量也會迅速下降。

(2)并行性。在某一時間段內，一個客服需要面對的不僅僅是一個客戶，為了提高效率，在線客服服務通常采用并行服務形式，即一個客服同時保持對多個客戶的服務。

(3)弱連接性。區別于傳統客服系統，弱連接性是指客服不需要實時響應客戶提出的服務請求，允許有一定的延時，這也是客服可以并行服務的原因所在。

(4)多渠道接入。傳統客服系統中，客戶只能通過撥打熱線電話對客服人員提出訴求，而在線客服系統大大拓展了溝通渠道，一套系統的接入通道往往不止一個，通常包含Web端、移動端、PC客戶端和微信公眾號等。

(5)多形式交互。與傳統客服系統相比，在線客服系統的交互方式不僅僅局限于語音溝通，還包括圖片、視頻和文字等形式。

3 調度模型構建與算法設計

面向在線客服系統的調度算法模型由3個部分組成，分別為：基于客戶多特征偏序關系生成具備優先級的多隊列，不同系統狀態下的調度策略選擇，基于調度策略的客戶篩選與客服分配。

3.1 模型框架

圖1展示了在線客戶系統的多隊列調度模型，任意客戶在進入客服系統發起服務請求時，按照客戶的請求服務時間順序進入客戶時序隊列，等待分派客服。

(1)基于客戶多特征偏序關系生成具備優先級的多隊列。依據客戶的靜態特征將時序隊列中的客戶分派至多隊列中。如結合某公司的實際業務，分派客戶產生的多隊列可依據被分派的客戶等級和訴求業務緊迫性來設定。假設客戶等級有x級，業務緊急程度有y級，那么有x×y級客戶多隊列。其二元偏序關系如圖2a所示。

Figure 2 Diagram of binary partial order relation圖2 二元偏序關系示意圖

圖2b為二元2×2級偏序關系圖，訴求業務的緊急程度級別參數設置為uB1,uB2，其中uB1>uB2，即B1類業務緊急程度高于B2類業務。以某公司業務為例，搶修類業務屬于B1類業務集合，其緊急程度級別為uB1；咨詢電費等不緊急業務可設置為B2類業務集合，其緊急程度級別為uB2；客戶級別即客戶重要性參數設置為uG1,uG2，uG1>uG2，即G1類客戶重要性高于G2類客戶。以某公司業務為例，VIP客戶屬于G1類客戶，普通客戶和游客屬于G2類客戶。所以，以uB1uG1為例，其表示客戶c為VIP且訴求業務最為緊急，其他組合以此類推。圖2b中，uB1uG1隊列的優先級高于uB2uG1，uB2uG1隊列的優先級高于uB1uG2,uB2uG2隊列的優先級最低，在系統中參數uB1,uB2,uG1,uG2結合實際業務進行賦值，多隊列的優先級劃分策略比較靈活，根據不同業務可采取不同策略，但總體需要遵循如圖2a所示的偏序關系。

(2) 基于對應系統狀態的調度策略選擇。系統狀態由客服服務狀態與客戶排隊狀態共同決定。基于不同的狀態選擇不同的調度策略，以保證系統良好運行，避免資源浪費。

(3) 基于調度策略的客戶篩選與客服分配。客戶進入多隊列后，隊列內遵循時間次序，先來先服務；而隊列外遵循隊列優先級次序。所以，在多隊列調度中，有如下規則：①同一個隊列中，排隊靠前的客戶先于排隊靠后的客戶；②不同隊列中，優先級高的隊列調度優先于優先級低的隊列。

在多隊列的客戶篩選過程中，僅考慮每隊隊首的客戶，依據當前系統狀態映射的調度策略選取當前最應該被調度的客戶，并為其分配客服。

3.1.1 特征形式化定義

(1)客服。

定義1任意一個客服s=(i,D,l,m1,m2)，其中，i為數值串，表示客服s的工號，是s的唯一標識符；D為客服s的業務集合，D?B，B為所有客服業務的集合；l為客服等級；l?L，L為所有客服等級的集合；m1表示客服s正在接線人數，m1∈N,m2表示客服s最大接線人數，m2∈N且m1

(2)客戶。

定義2任意一個客戶c=(j,g,b,t,W)，其中，j為數值串，表示客戶c的ID，是客戶c的唯一標識符，綁定c的其他特征；g為客戶等級,g∈G,G為所有客戶等級的集合;b為客戶的訴求業務,b∈B；t為客戶c進入客服系統請求服務到接入客服的等待時長；W為客戶c服務記錄集合，所有客戶的集合記為C。

(3)在線客服系統。

定義3客服系統Q可表示為Q=(S,C,A,P)，其中，S為客服集合，C為客戶集合，A為條件狀態轉換自動機，P為策略集合。

3.1.2 條件狀態轉換自動機

定義4條件狀態轉換自動機A是一個5元組，A=(F,R,δ,IF,TF),其中，F是一個有限狀態集合，R為布爾表達式的集合；δ:F×R→F,δ(Fi,Rk)=Fj,Fi,Fj∈F,Rk∈R表示狀態Fi在滿足條件Rk時，轉換為狀態Fj;IF為初始狀態集合，IF?F;TF為終止狀態集合，TF?F。

根據某中心實際業務，綜合考慮客服負荷狀態與客戶排隊等待狀態2個影響因素，將系統狀態劃分為5個狀態。

(1)起始狀態F0：所有客服接線數為0的一種狀態。此狀態為系統開啟或結束瞬間。

(2)接線填充狀態F1：客服中有部分接線數未被占用，客戶排隊人數較多的一種狀態。此狀態一般對應初始狀態后，系統向有空閑接線數的客服接入客戶并且有客戶尚未被調度仍在等待隊列中的情況。

(3)低負荷狀態F2：客服中有部分接線數未被占用，客戶排隊人數較少的一種狀態。關鍵特征為客服接線數大部分未被占用，且等待隊列中的排隊人數未超過客服的空閑接線量。

(4)正常負荷狀態F3：客服的接線絕大多數或全部被占用，客戶排隊人數與系統總容量之間的比率未超出平均排隊等待時間與客服平均服務時間之間的比率范圍。此狀態為系統常態，一般對應接線填充狀態后仍然有客戶進入系統排隊且平均等待時長穩定或有下降趨勢的情況。

(5)超負荷狀態F4：客服的接線絕大多數或全部被占用，客戶排隊人數與系統總容量之間的比率超出平均排隊等待時間與客服平均服務時間之間的比率范圍。此狀態一般對應接線填充狀態后仍然有客戶進入系統排隊且平均等待時長上升的情況。

結合某中心實際業務流程，給出定義該5種狀態的數學表達式如表1所示。

Table 1 Definition of system states表1 系統狀態定義

狀態轉換圖如圖3所示。結合實際業務場景狀態之間的轉換條件共包含7種，如表2所示。

Figure 3 System states transition diagram圖3 系統狀態轉換圖

Table 2 State transition conditions 表2 狀態轉換條件

3.1.3 調度策略

3.1.2節詳細描述了面向在線客服系統的狀態轉換關系和轉換條件，這樣區分的好處在于條件狀態轉換自動機A在不同的系統狀態下可以采取不同的調度策略，有效地完成調度任務，提高服務質量。

根據業務需求建立調度策略集，并構造狀態集到策略集冪集的映射；根據業務需求創建調度策略，包括先來先服務、負載均衡、技能優先、熟客優先和隨機等策略，調度策略集可不限于這5種策略，還可以是包含上述5種策略中一部分的策略子集或以上述5種策略為關鍵策略的超集。5種調度策略如表3所示。

Table 3 Scheduling strategies表3 調度策略

3.2 算法設計

算法1為構造多隊列的算法，構造出的多隊列是一種系統設置不同客戶類別以區分其服務優先級的數據結構。系統中預設客戶等級級數與客戶訴求業務類別數，并且客戶等級和客戶訴求業務類別之間存在優先級，各隊列之間存在優先級偏序關系，偏序關系如圖2a所示。實際業務中的客戶等級c.g和客戶訴求業務c.b的取值決定了隊列數量。

算法1構建具備優先級的多隊列

輸入：x:number of defined values inc.g;y:number of defined values inc.b;priority[x:y]:two-dimensional array of sizex×y。

輸出：multiQueue:a set of queues。

1.multiQueue←{};

2.fori←1 toxdo;

3.forj←1 toydo/*create queues based onpriority[i,j]*/

4.q←CreateQueue(priority[i,j]);

5.multiQueue←multiQueue∪{q};

6.endfor

7.endfor

6.returnmultiQueue;

算法2為將時序隊列中元素分派至多隊列的算法，是對多優先級隊列的初始化操作。此算法在算法1運行完成后調度。客戶c在進入系統請求服務時，系統將其分配至時序隊列temporalQueue，并根據客戶c的客戶等級和訴求業務將其從時序隊列temporalQueue中分派至對應的優先級隊列中，隊列內元素均是按照到達時間先后順序排隊。

算法2從時序隊列分配元素到多隊列。

輸入：x:number of defined values inc.g;y:number of defined values inc.b;priority[x:y]:two-dimensional array of sizex×y;temporalQueue:one queue based on time series;multiQueue:queues initialized from 算法1。

輸出：multiQueue:a set of queues。

1.whiletemporalQueue≠?do

2.c←DeQueue(temporalQueue);

3.l1←GetLevel(c.g); /*get the corresponding level ofc.g*/

4.l2←GetLevel(c.b); /*get the corresponding level ofc.b*/

5.q←FindQueue(multiQueue,l1,l2);

6.EnQueue(q,c);

7.endwhile

8.returnmultiQueue;

算法3為多隊列中選擇調度元素的算法，實際業務中元素對象為系統中的客戶，該算法為調度客戶操作。在已初始化的多隊列中，系統從各隊列中選出各隊首元素，綜合考慮各隊首元素所在隊列的優先級和客戶當前的等待時間來判定調度次序，隊列優先級越高，客戶當前等待時間越長，其被優先調度的概率越大。

算法3從多隊列中選擇調度元素

輸入：multiQueue:a set of queues。

輸出：c:an element from a set of customersC。

1.AssumeHto be ax×ytwo-dimensional array;

2.AssumeVto be ax×ytwo-dimensional array;

3.z←0;

4.fori←1 toxdo

5.forj←1 toydo

6.q←FindQueue(multiQueue,i,j); /*obtain queueqwith subscripts [i,j] inmultiqueue*/

7.H[i,j]←FrontQueue(q);/*The head element of queueq*/

8.x←Normalization(C[i,j].t,MAXTIME);/*normalizeH[i,j].t(waiting time ofH[i,j])*/

9.y←GetPriority(q);

10.V[i,j]←μ×x+(1-μ)×y;

11.ifV[i,j]>z

12.z←V[i,j];

13.q′←q;

14.endfor

15.endfor

16.c←DeQueue(q′);

17.returnc;

算法 4為選取客服的算法，根據系統所處的狀態采用最為恰當的路由策略，選擇為客戶c服務的客服人員s，其中的路由策略如表3所示。S為客服集合；若客服s的業務集合s.D包含客戶c的訴求業務c.b，即c.b∈s.D，那么s進入集合S′，S′中的任一客服可為客戶c提供服務。在非超負荷狀態下，優先從S′選擇能為客戶c服務且技能匹配的客服s。在超負荷狀態下從S中篩選客服，存在所選客服業務類型、級別與客戶匹配度不高的可能性，但有助于提升總體調度效率。

算法4選取客服。

輸入：c:an element from a set of customers’ features;S:a set of customer service;status:states of system。

輸出：s:an element from a set of customer service。

1.forsinSdo

2.ifc.bins.D

3.S′←S′∪{s};

4.endfor

5.switch(status)

6.case{0,1,2}:

7. FindsfromS′ according to strategyP2;

8. returns;

9.case{3}:

10.ifc.g=“VIP”

11. FindsfromS′ according to strategyP3;

12.ifs= ?

13. FindsfromS′ according to strategyP4;

14.ifs=?

15. FindsfromS′ according to strategyP5;

16.ifc.g≠“VIP”

17. FindsfromS′ according to strategyP4;

18.ifs= ?

19. FindsfromSaccording to strategyP5;

20.returns;

21.case{4}:

22. FindsfromSaccording to strategyP5;

23.returns;

算法 5為系統狀態判定算法,根據客服當前正在服務的人數、系統中客服負荷狀態與客戶排隊等待狀態判定當前系統所處的狀態。具體的狀態判定條件如表1所示。

算法5判定系統狀態。

輸入：n:number of people being served in the system;m:number of people waiting in queues;N:maximum number of people can be served;TN:average service time;TC:expected queueing time。

輸出：status。

1.switch(n,m)

2.case{(n=0)∧(m≥0)}:status←0;

3.case{(n≤μ×Ν)∧(m>(1-μ)×Ν)}:status←1;

4.case{(n≤μ×Ν)∧(m≤(1-μ)×N)}:status←2;

5.case{(n>μ×Ν)∧(0≤m

6.case{(n>μ×Ν)∧(m≥w1×TC×N/TN)∧(d(t)>m(t))}:status←4;

7.returnstatus;

算法6為系統并行總算法，調度算法1構造多隊列，當temporalQueue≠?時，調度算法2將客戶分派至構造完成的多隊列multiQueue。同時，只要出現服務請求，調度算法5判斷系統狀態，調度算法3從各隊列的隊首中選擇客戶c,算法4根據系統狀態調度對應的路由策略選擇客服s，最后分配客服s為客戶c服務完成一次調度。

算法6并行調度算法

1.execute 算法 1;

2.Parallelforeach

3.whiletemporalQueue≠?do

4. execute 算法2;

5.whiletruedo

6. execute 算法5;

7. execute 算法3;

8. execute 算法4;

9. Assignctos;

設客戶隊列長度為len，多隊列中的隊列個數為Count，則調度算法的基本執行步數為count*len。其中，Count值只和客戶屬性相關，與客戶排隊人數無關。例如，在本文設計的系統中，預設客戶等級與客戶訴求業務類別，且均存在優先級，其中客戶等級分為3級：VIP、普通用戶和游客，客戶訴求業務分為2級：緊急業務和非緊急業務，因此Count的值為6。所以，算法時間復雜度為O(Len)。

4 實驗及結果分析

實驗數據來源于某電力客服中心2017年7月至2018年7月共計348 439條客服服務數據。采用基于線程的模擬實驗方法驗證本文設計的在線客服系統調度算法的有效性。

4.1 實驗方法

為充分利用數據，以上午或下午工作時間4小時為基本時長，對2017年7月到2018年7月間的數據作了劃分，進行了多次模擬實驗，一次實驗模擬4小時工作時長。同時，為進一步加快模擬實驗效率，對現實時長做了放縮處理。將現實時間持續4小時的工作時長映射為400 s的模擬時長，即模擬時長中1 s對應現實時間36 s,將模擬時長放大36倍后可得到該模擬時長對應的現實時長，即圖4所示的現實時間與模擬時間具有一一對應映射關系。

Figure 4 Simulation experiment based on thread圖4 基于線程的模擬實驗

如圖4所示，以客服系統從8:00到12:00的調度情況為例，詳細說明了基于線程的模擬實驗流程。假定在8:00到12:00共計到達E位客戶，在模擬時間0 s分別為E位客戶開啟線程CustomerArrivalThread，當模擬時間分別到達E位客戶的到達時刻時，關閉線程CustomerArrivalThread，客戶請求服務，并開啟線程CustomerWaitThread，表示該客戶處在等待客服系統分配客服服務狀態，當客服系統為該客戶分配客服服務后，等待線程CustomerWaitThread停止，記錄等待時長，開啟線程CustomerServiceThread，模擬客服服務線程，服務結束后CustomerServiceThread線程關閉。待模擬時間到達400 s模擬實驗結束。

模擬實驗共設計7位客服，其中2位高級客服，3位中級客服，2位初級客服。對應客服級別的客服最大接線數分別設為1,2,4。

Figure 5 Number of people being served in real time and number of people waiting on line圖5 實時服務人數與等待人數

Figure 6 Relationship between system state and time 圖6 系統狀態與時間關系

4.2 實驗結果

如圖5所示，上方折線表示當前時刻的實時服務人數，下方折線表示當前時刻的實時等待人數。圖6表示系統所處的狀態與時間的關系曲線，以及各個狀態所持續的時長。可見超負荷持續時長最短，正常負荷持續時長最長，低負荷次之，所占比重詳細數據如圖7a所示。

圖7b所示為系統分別在不同負荷下的客戶平均等待時長，可見低負荷下等待時間最短，超負荷下等待時間最長。多次實驗的客戶平均等待機器模擬時長為0.410 19 s，等比例放大36倍后可得實驗中客戶平均等待時長為14.767 s。

Figure 7 Proportion and average waiting time of each state 圖7 各狀態下占比和平均等待時長

如圖8所示，灰色條形表示7位客服在模擬實驗中服務總數，白色條形表示每一個接線坐席在模擬時間內的接線服務量。其中，10001,10004為高級客服，10002,10005,10007為中級客服，10003,10006為初級客服。7位客服的均衡指數(坐席的平均接待人數)穩定在96～120，客服服務量符合預期，客服系統調度滿足客服公平性考量。

Figure 8 Number of people served by customer service staff圖8 客服服務人數

4.3 結果分析

從整個實驗過程看，調度模型一直處于正常的工作狀態中。其中，正常負荷狀態與低負荷狀態共占據99%以上時長，且以正常負荷狀態為主，為64%；而由于客戶訪問的隨機性，低負荷狀態也會占據一部分時長。由此可見，調度模型能合理利用客服資源而不會造成客服資源的浪費。因此，調度模型的設計較為合理。

在調度模型正常工作情況下，調度算法有效地實現了客服角度與客戶角度的兩方面調度目標。首先，在整個調度過程中，客服均衡指數較為接近，特別是相同類別客服之間均衡指數非常一致，客服之間相差基本不超過5%，這表示不同客服服務客戶數量之間保持了高度的均衡性，不會出現有些客服長時間空閑而另一些長時間忙碌。因此，調度算法在相同類型客服之間或不同類型客服之間根據接線數差別實現了客戶分配的公平性與合理性。其次，與某省電力營銷服務中心正在運營的客服系統相比，調度算法在客戶服務質量和服務效率上均有較為明顯的提升。在服務質量上，調度算法先通過多隊列對客戶進行細致劃分，并在多種狀態下實施了技能優先、熟客優先等調度策略，與客服系統采用的隨機分配策略相比，一定程度上實現了服務質量的提升；在服務效率上，客服系統的實際平均等待時長為29.858 s，而在調度算法下(實驗參數設置與客服系統實際配置基本一致)客戶平均等待時長為14.767 s，較大地提升了客戶服務效率。

實驗結果表明，面向在線客服的調度模型設計合理，調度算法可靈活、高效、公平地實現多客戶與在線客服之間的調度任務，在實現較高質量服務的情況下，既較大幅度地降低了客戶的平均等待時間，又確保了客服之間的負載均衡。

5 結束語

本文提出了一種面向在線客服系統的調度模型及其調度算法。調度模型由3個部分構成：一是根據客戶相關特征構建的多優先級客戶隊列；二是綜合在線客服系統與客戶隊列狀態特征所劃分出的調度系統狀態，包括狀態特征及狀態之間的轉換關系；三是調度策略與調度系統狀態之間的對應關系。在調度模型基礎上，進一步設計了相應的在線客服系統調度算法。通過模擬實驗，一方面驗證了調度模型的可用性與合理性，另一方面驗證了調度算法可以有效地實現調度目標。從客戶角度看，在實現較高質量的客戶服務情況下，客戶平均等待時間較大幅度減少；從客服角度看，客戶分配合理，客服之間負荷均衡。在將調度模型與算法應用于具體的在線調度問題時，可根據問題特征對模型與算法中的相關參數如客戶隊列、客服特征與數量等進行相應調整，以適應特定的應用場景。因此，本文提出的面向在線客服的調度模型與調度算法可靈活、高效、公平地實現多客戶與在線客服之間的調度任務。