本發(fā)明涉及互聯網技術領域，尤其涉及一種工單處理方法及裝置。

背景技術：

客服系統經過多年的發(fā)展，已經成為網絡服務不可或缺的工具?？头到y主要包括實時的話務系統、實時的聊天系統，方便客服人員主動聯系客戶。

在o2o(onlinetooffline，線上到線下)領域，客服系統每天產生的問題數量非常巨大。目前，客服處理問題的模式是一種類似于隨機處理問題的模式，在接到問題的同時客服開始處理?？头到y將需要處理的問題生成工單來進行處理。每天來自客戶端的問題都會自動生成工單，客服人員隨機獲取工單后，進行人工處理。

技術實現要素：

客服系統針對每一個上報來的問題，都會自動為其生成一個對應的工單，并置于工單池中待客服人員領取。而現有的客服人員類似于隨機獲取工單的模式會嚴重影響客服平臺的服務質量。例如，重要客戶上報的工單遲遲得不到解決，故障申報類工單可能因處理不及時而造成客戶體驗度差等等。工單數量越大，因隨機處理工單致使的客戶滿意度低的問題就越發(fā)的突出。

于是，本發(fā)明實施例提供一種工單處理方法，包括：獲取工單的屬性信息；根據所述屬性信息，確定所述工單的優(yōu)先級；按照所述優(yōu)先級，調整所述工單的處理次序。工單池中的工單均可按照上述方法來調整處理次序，以保證優(yōu)先處理優(yōu)先級高的工單，有助于提升用戶對客服服務的滿意度。

可選地，上述根據所述屬性信息，確定所述工單的優(yōu)先級，可包括如下步驟：識別所述屬性信息以獲得識別結果；采用所述識別結果對應的權重獲取方式，獲取所述屬性信息對應的權重；基于所述權重計算得到所述工單的優(yōu)先級。

可選地，上述采用所述識別結果對應的權重獲取方式，獲取所述屬性信息對應的權重，可具體為：若所述識別結果為工單的問題來源屬性信息，則調取所述問題來源屬性信息對應的來源方畫像數據；根據所述來源方畫像數據，評價所述來源方的價值；獲取所述價值對應的權重。通過上述方案，可對問題上報者是否為重要用戶進行評估，然后根據評估結果來獲取相應的權重，使得優(yōu)先權確定的依據更加全面，多樣。

可選地，上述實施例提供的工單處理方法，還可包括：監(jiān)聽與工單相關的觸發(fā)事件；以及上述獲取工單的屬性信息的步驟可在監(jiān)聽到與工單相關的所述觸發(fā)時間后，被觸發(fā)執(zhí)行。由于工單的屬性信息中有部分屬性信息(例如用戶價值評估)是會隨著時間變化產生相應變化的，因此工單通過上述步驟調整完的處理次序也會動態(tài)變化?？赏ㄟ^上述方案，實時的對工單進行處理次序的調整，以避免優(yōu)先級低的工單總是不能被領取的情況出現，保證所有工單都會被領取到。

或者，所述獲取工單的屬性信息也可是等時間間隔地處理執(zhí)行的，即等時間間隔地獲取工單的屬性信息，然后根據所述屬性信息，確定所述工單的優(yōu)先級，按照所述優(yōu)先級，調整所述工單的處理次序。當然，上述兩種觸發(fā)獲取工單的屬性信息的步驟執(zhí)行的觸發(fā)條件也可同時存在。

在實際應用中，發(fā)明人發(fā)現很多工單的問題相同或相似，這些工單可同時處理，避免客服人員的重復勞動。除存在問題相同或相似的工單外，工單池還存在同一上報人的工單，這些同一上報人的工單實際上也可同時處理。因此，上述實施例提供的所述方法，還可包括：在工單池中，查找相關聯的多個工單；合并查找到的相關聯的多個工單。通過合并多個工單，一是可減少確定工單優(yōu)先權的數量，減少處理量；二是客服人員可一次性批處理多個工單，進而避免客服人員的重復勞動，提高工單處理效率。

可選地，所述在工單池中，查找相關聯的多個工單，可包括：在工單池中，查找工單問題來源相同的工單，和/或查找工單問題相同或相似的工單。

在一種可實現的方案中，采用上述方法對工單進行處理次序調整時，可能存在多個工單的優(yōu)先級相同的情況，這時可采用如下方法對這些優(yōu)先級相同的工單進行再次調整。即本發(fā)明實施例提供的所述方法，還可包括：若工單池中包含有至少兩個優(yōu)先級相同的工單，則獲取優(yōu)先級相同的工單的創(chuàng)建時間；根據所述創(chuàng)建時間，調整所述至少兩個優(yōu)先級相同的工單的處理次序。

在本發(fā)明的又一實施例中提供一種工單處理裝置。該裝置包括：第一獲取模塊、確定模塊和調整模塊。其中，所述第一獲取模塊用于獲取工單的屬性信息；所述確定模塊用于根據所述屬性信息，確定所述工單的優(yōu)先級；所述調整模塊用于按照所述優(yōu)先級，調整所述工單的處理次序。

在本發(fā)明實施例中，通過獲取工單的屬性信息，并根據屬性信息確定工單的優(yōu)先級，即可實現根據所述工單的優(yōu)先級，調整所述工單的處理次序的目的，解決了現有技術中因工單處理順序的隨機性而存在的諸多問題，且能保證優(yōu)先處理優(yōu)先級高的工單，有助于提升用戶對客服服務的滿意度。

附圖說明

為了更清楚地說明本發(fā)明實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作一簡單地介紹，顯而易見地，下面描述中的附圖是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。

圖1為本發(fā)明一實施例提供的工單處理方法的流程示意圖；

圖2為本發(fā)明另一實施例提供的工單處理方法的流程示意圖；

圖3為本發(fā)明一實施例提供的工單處理裝置的結構框圖；

圖4為本發(fā)明另一實施例提供的工單處理裝置的結構框圖。

具體實施方式

為了使本技術領域的人員更好地理解本發(fā)明方案，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述。

在本發(fā)明的說明書和權利要求書及上述附圖中的描述的一些流程中，包含了按照特定順序出現的多個操作，但是應該清楚了解，這些操作可以不按照其在本文中出現的順序來執(zhí)行或并行執(zhí)行，操作的序號如101、102等，僅僅是用于區(qū)分開各個不同的操作，序號本身不代表任何的執(zhí)行順序。另外，這些流程可以包括更多或更少的操作，并且這些操作可以按順序執(zhí)行或并行執(zhí)行。需要說明的是，本文中的“第一”、“第二”等描述，是用于區(qū)分不同的消息、設備、模塊等，不代表先后順序，也不限定“第一”和“第二”是不同的類型。

下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

圖1為本發(fā)明一實施例提供的工單處理方法的流程示意圖。本實施例的執(zhí)行主體可以是客服系統服務器。如圖1所示，該方法包括：

101、獲取工單的屬性信息。

102、根據所述屬性信息，確定所述工單的優(yōu)先級。

103、按照所述優(yōu)先級，調整所述工單的處理次序。

上述步驟101中，屬性信息可包括：創(chuàng)建時間、問題類型、問題來源途徑、問題來源信息及緊急度信息等中的一種或多種。其中，問題類型可分為：投訴類、故障申報類、建議類以及咨詢類等。問題來源途徑可包含有：通過web網頁、通過應用app和通過線下等多種方式。問題來源信息可包含有來源方標識(例如登錄賬號)、來源方所屬類型(例如vip用戶、普通用戶等)等。緊急度信息可以是人工干預設置的，也可以根據預設的問題類型的緊急度排序在生成工單時自動添加的。例如，故障申報類的緊急度>投訴類的緊急度>咨詢類的緊急度>建議類的緊急度。這里僅示例性的舉出了一種緊急度排序的情況，本發(fā)明實施例對具體排序的方案不作具體限定。

所述屬性信息在創(chuàng)建工單時即生成并攜帶在工單中。例如，接收到上報的問題后，從工單庫中調用相應的工單模板，從問題上報請求中獲取問題來源信息及問題內容；將該問題來源信息及問題內容填寫至工單模板，并基于識別的問題類型及獲取到的當前時間對工單進行編號。工單編號中的部分數字表征工單的問題類型，另一部分數字表征工單的創(chuàng)建時間、再一部分表征工單的流水號等等。當然，所述緊急度也可標記在所述工單的編號中，用工單編號中的一個位置處的數字表征緊急度。例如，工單號中第一位的數字代表緊急度，1代表高緊急度，2代表普通緊急度、3代表低緊急度。

或者，所述屬性信息不攜帶在工單中，但與工單存在關聯關系。例如，上述生成的屬性信息作為一個單獨的問題與工單進行關聯存儲。當工單被調取時，該屬性信息也可同時被獲取到。

在本實施例和下述實施例中，上述步驟102根據所述屬性信息，確定所述工單的優(yōu)先級可采用如下方式中的一種或多種實現：

方式一、將屬性信息作為預置確定規(guī)則的輸入參數，計算得到所述工單的優(yōu)先級。

方式二、識別所述屬性信息以獲得識別結果；采用所述識別結果對應的權重獲取方式，獲取所述屬性信息對應的權重；基于所述權重計算得到所述工單的優(yōu)先級。

其中，方式一中，預置的確定規(guī)則可人為設定，該確定規(guī)則可以是一個計算公式，也可以是一組邏輯判斷程序等等，本發(fā)明實施例對確定規(guī)則不作具體限定。

上述方式二中，不同的屬性信息可對應不同的權重獲取方式。例如，所述屬性信息包括創(chuàng)建時間、問題類型、問題來源途徑、問題來源信息及緊急度信息。其中，問題類型、問題來源途徑及緊急度信息，可直接通過下表1所示示例的對應關系獲取到。例如，投訴類工單的權重為a1；通過app途徑的權重為b2；普通緊急度的權重為c2。而創(chuàng)建時間和問題來源信息，是無法通過下表直接獲取到對應權重的。對于創(chuàng)建時間：由于時間是不斷變化的，工單池中的工單也是在不斷變化的，具體實現時是無法直接通過創(chuàng)建時間單一時間點來為其配置權重的；因此，在實際操作時可通過對工單池中所有工單進行時間排序，時間越靠后的創(chuàng)建時間需配置的權重越高。在一種可實現的方案中，可根據采用工單在工單池中的創(chuàng)建時間排序的序號，為工單的創(chuàng)建時間配置對應的權重。對于問題來源信息：問題來源信息中包含有來源方標識、來源方所屬類型等，其中來源方所屬類型也可通過下表1獲取到對應的權重；而單基于來源方標識為其配置權重是毫無意義的。在具體實施時，來源方標識可用來獲取來源方畫像數據的。該來源方畫像數據可存儲在客戶端畫像系統中?？蛻舳水嬒裣到y根據來源方的網絡操作記錄等信息生成對應畫像數據并進行存儲。獲取畫像數據的目的是為了評價該來源方的價值，價值不同的來源方所對應的權重也是不同。在一種可實現的方案中，來源方的價值與權重也可具有類似于下表1的對應關系。通過查找來源方的價值與權重的對應關系，即可獲得相應的權重。

表1屬性信息與權重的對應關系

綜上所述，采用方式二時，需識別屬性信息，然后根據識別結果采用對應的獲取方式獲取對應的權重。獲取到各屬性信息對應的權重后，可采用如下計算方式得到加權和，將加權和結果作為所述工單的優(yōu)先級：

計算方式一：優(yōu)先級＝a+b+c+d+e+f

計算方式二：優(yōu)先級＝問題類型＊a+問題來源途徑＊b+緊急度信息＊c+來源方所屬類型＊d+來源方價值＊e+創(chuàng)建時間＊f

其中，上述a為問題類型對應的權重，b為問題來源途徑對應的權重，c為緊急度信息對應的權重，d為來源方所屬類型對應的權重，e為來源方價值對應的權重，f為創(chuàng)建時間對應的權重。上述計算方式二中，問題類型、問題來源途徑、緊急度信息、來源方所屬類型、來源方價值以及創(chuàng)建時間為各自對應的設定基數。各屬性信息對應的設定基數可根據識別屬性信息的識別結果自動賦值。

上述計算得到的優(yōu)先級還可進行歸一化處理。歸一化處理的目的是為了將工單池中的所有工單的優(yōu)先級控制在一個取值范圍內，例如1～100之間。

這里需要補充的是：來源方畫像數據是根據來源方日常的行為數據和/或上傳的來源方數據等生成的。下面為了方便敘述和閱讀，將來源方換成用戶來表述。構建用戶畫像數據的核心工作即是給用戶貼“標簽”，而標簽是通過對用戶信息分析而來的高度精煉的特征標識。在外賣類應用場景下，用戶可分為商戶和客戶，商戶可通過商戶側app向平臺的客服系統上報問題，客戶可通過客戶側app向平臺的客服系統上報問題。例如，當用戶為商戶時，用戶畫像數據是對商戶的經營行為，商戶的描述信息、商戶的商品信息等等而抽象出的一個標簽化的用戶模型。抽象一詞在技術層面可理解為：通過對商戶的經營行為，商戶的描述信息、商戶的商品信息等等進行數據挖掘和分析的過程。該用戶畫像數據隨著用戶信息的變化而不斷更新。當用戶為客戶時，用戶畫像數據是用戶下單頻率、下單量、下單金額等等抽象出的一個標簽化的用戶模型。因此，在實際應用中可每天、每周等定時獲取用戶畫像數據?；谟脩舢嬒駭祿u估出用戶的價值。高價值用戶可從多個方面綜合去體現：對于商戶來說，在平臺上訂單量多的商戶、在平臺上收入最多的商戶、對平臺依賴度高的商戶等等；對于客戶來說，頻繁下單的客戶、訂單額度大的客戶等等。

綜上可知，本發(fā)明實施例基于上述多種屬性信息，確定所述工單的優(yōu)先級，優(yōu)先權確定依據更加全面，有助于提高工單優(yōu)先權確定的準確性。

上述步驟103中，優(yōu)先級可以是具體的數值(如60、70、45)，調整時直接根據數值大小從大到小的去調整所述工單的處理次序即可。

在本發(fā)明實施例中，通過獲取工單的屬性信息，并根據屬性信息確定工單的優(yōu)先級，即可實現根據所述工單的優(yōu)先級，調整所述工單的處理次序的目的，解決了現有技術中因工單處理順序的隨機性而存在的諸多問題，且能保證優(yōu)先處理優(yōu)先級高的工單，有助于提升用戶對客服服務的滿意度。

進一步的，由于根據工單的屬性信息確定優(yōu)先權過程中存在動態(tài)變化的信息(例如上述提到的工單在工單池中的創(chuàng)建時間排序，以及根據來源方畫像數據評價出的來源方的價值等)，所以工單的優(yōu)先級也是動態(tài)變化的，需要對工單池中工單處理次序進行動態(tài)的調整。具體實施時，可采用如下兩種方式實現動態(tài)的調整工單處理次序，一是事件觸發(fā)的方式；二是等時間間隔觸發(fā)的方式。其中，事件觸發(fā)方式是通過實時監(jiān)聽客服系統中與工單有關的觸發(fā)事件，當監(jiān)聽到有這類事件觸發(fā)時，即對工單池中的工單進行一次調優(yōu)先權，以按照最新的處理次序從工單池中調取工單。等時間間隔觸發(fā)的方式主要是通過定時任務觸發(fā)(如1小時、2小時等)，例如1個小時對工單池中的工單進行一次調優(yōu)先權。上述兩種觸發(fā)方式體現在方案上可表征為：在上述實施例和下述實施例中，所述工單處理方法還可包括：

監(jiān)聽與工單相關的觸發(fā)事件。其中，該觸發(fā)事件可以是新建工單事件、領取工單事件、操作處理工單事件等等。相應的，上述實施例中步驟101可以為：響應于監(jiān)聽到的所述觸發(fā)事件，獲取工單的屬性信息。

或者，上述實施例中步驟101可以為：等時間間隔地獲取工單的屬性信息。

采用上述技術方案，使得工單的處理次序動態(tài)的被調整，不會產生某個工單永遠不被處理的情況。另外，這里需要補充的是：上述兩種觸發(fā)方法也可同時存在。

在上述實施例和下述實施例中，所述工單處理方法，還可包括：在工單池中，查找相關聯的多個工單；合并查找到的相關聯的多個工單。

上述查找相關聯的多個工單的步驟可具體采用如下方法實現：在工單池中，查找工單問題來源相同的工單，和/或查找工單問題相同或相似的工單。其中，相同的工單即問題完全相同的工單。相似的工單可以是問題相似度符合預設相似度判定規(guī)則的工單。該預設相似度判定規(guī)則可人為設定。例如，故障申報工單1和故障申報工單2，這兩個工單中描述了不同的故障問題，但解決一個故障問題，另一個故障也就迎刃而解，則這兩個工單即可為相似的工單。又例如，咨詢工單3和咨詢工單4，這兩工單采用兩種語言描述方式描述的咨詢的問題，但通過語義分析得到這兩個咨詢工單中需解決的問題是一樣的，則這樣兩個工單即為相似的工單。上述合并可以理解為，將多個工單打包作為一個工單，或者將多個工單建立關聯關系，當其中一個工單被調取處理時，與該工單建立了關聯關系的工單也會被調取出，以便同一客戶服人員進行批量處理。

進一步的，在具體實施時，采用上述實施例提供的工單處理方法后還可能存在有至少兩個工單的優(yōu)先級相同。此時，可采用如下方法進行次序的調整，即在上述實施例和下述實施例中，所述工單處理方法，還可包括：

若工單池中包含有至少兩個優(yōu)先級相同的工單，則獲取優(yōu)先級相同的工單的創(chuàng)建時間；根據所述創(chuàng)建時間，調整所述至少兩個優(yōu)先級相同的工單的處理次序。

因為，在工單創(chuàng)建的過程中，是不可能存在同時創(chuàng)建的兩個工單的。實際應用中，可能創(chuàng)建時間可能隱含在工單編號中，還可根據工單編號的前后來，調整至少兩個優(yōu)先級相同的工單的處理次序。

本發(fā)明實施例提供的技術方案可適用于現有的所有客服系統中。例如，在現有的客服團隊和客服系統情況下，無需改變現有客服系統，只需新增優(yōu)先權確定和工單處理次序調整功能單元或模塊即可。其中，所述優(yōu)先權確定和工單處理次序調整功能單元或模塊可以是軟件程序，也可以是安裝在客戶系統中的一個具有嵌入式程序的硬件，還可以是嵌入在客服系統中的工具軟件等，本發(fā)明實施例對此不作限定。

圖2為本發(fā)明一實施例提供的工單處理方法的流程示意圖。如圖2所示，該方法包括：

201、獲取工單的屬性信息。

202、識別所述屬性信息以獲得識別結果。

203、采用所述識別結果對應的權重獲取方式，獲取所述屬性信息對應的權重。

204、基于所述權重計算得到所述工單的優(yōu)先級。

205、按照所述優(yōu)先級，調整所述工單的處理次序。

206、響應于領取工單的觸發(fā)操作，從工單池中領取待處理工單。

207、獲取所述待處理工單的處理結果。

208、根據所述工單的屬性信息，將所述處理結果發(fā)送至所述屬性信息指示的客戶端。

上述步驟201、205可參見上述實施例中的相應內容，此處不再贅述。

上述步驟202和203中，若識別所述屬性信息獲得的識別結果為：問題類型、問題來源途徑、緊急度信息或問題來源信息中的來源方類型信息，則可通過上述表1中表征的對應關系，獲取各屬性信息對應的權重。若識別所述屬性信息獲得的識別結果為創(chuàng)建時間，則獲取該創(chuàng)建時間在所述工單池中所有工單的創(chuàng)建時間中的時間排序；然后根據所述時間排序序號，為該創(chuàng)建時間配置權重。例如，假設工單池中包含有工單1、工單2和工單3。按照時間先后，工單1的創(chuàng)建時間t1早于工單2的創(chuàng)建時間t2；工單2的創(chuàng)建時間t2早于工單3的創(chuàng)建時間t3。那么，工單1在工單池中的所有工單的創(chuàng)建時間中的時間排序為第1，則為工單1的創(chuàng)建時間配置最高的權重；工單2在工單池中的所有工單的創(chuàng)建時間中的時間排序為第2，則為工單2的創(chuàng)建時間配置次高的權重；工單3在工單池中的所有工單的創(chuàng)建時間中的時間排序為第3，則為工單3的創(chuàng)建時間配置低的權重。當然，時間排序序號與權重也可具有類似于下表1的對應關系，通過查表即可獲得各排序序號對應的權重。若所述識別結果為工單的問題來源信息，則調取所述問題來源信息對應的來源方畫像數據；根據所述來源方畫像數據，評價所述來源方的價值；獲取所述價值對應的權重。其中，所述來源方畫像數據可由客戶畫像系統生成并進行本地存儲。有關來源方畫像數據的內容可參見上述實施例中的相關內容，此處不再贅述。

有關上述步驟204基于所述權重計算得到所述工單的優(yōu)先級的內容，可參見上述實施例中的相關內容，此處不再贅述。

這里需要補充的是：問題類型可存在默認的優(yōu)先級，例如：故障申報的優(yōu)先級>投訴的優(yōu)先級>咨詢的優(yōu)先級>咨詢的優(yōu)先級。因此，在具體實施時，本發(fā)明實施例還也可將問題類型的優(yōu)先級作為一個屬性信息，然后通過對應的獲取方式獲取該問題類型的優(yōu)先級對應的權重，然后在上述實施例的基礎上增加該問題優(yōu)先級對應的權重，計算工單的優(yōu)先級。

上述各屬性信息對應的權重除了可采用上述各方法實施例中提到的預先設置的方式外，還可根據預設的配置策略實時的為各屬性信息配置對應的權重。

上述步驟206中，客服人員在申請領取工單時，會進行領取工單的觸發(fā)操作。當有領取工單的觸發(fā)操作時，客服系統會采用上述步驟201～205對工單池中的工單進行一次處理次序的調整。

上述步驟207和208中，客服人員在處理完成工單后，會將工單處理結果的進行提交。客服系統獲取到工單處理結果后，即可根據所述工單的屬性信息中的問題來源屬性信息，將所述處理結果發(fā)送至所述問題來源屬性信息指示的客戶端。在外賣類應用場景下，客戶端可以是商戶的客戶端，也可是客戶的客戶端。商戶/客戶即可在其用戶界面上查看到工單處理結果。

需要說明的是：上述實施例所提供方法的各步驟的執(zhí)行主體均可以是同一設備，或者，該方法也由不同設備作為執(zhí)行主體。比如，步驟101至步驟103的執(zhí)行主體可以為設備a；又比如，步驟101和102的執(zhí)行主體可以為設備a，步驟103的執(zhí)行主體可以為設備b；等等。

圖3為本發(fā)明一實施例提供的工單處理裝置的結構示意圖。如圖3所示，所述工單處理裝置包括：第一獲取模塊20、確定模塊21和調整模塊22。其中，第一獲取模塊20用于獲取工單的屬性信息；確定模塊21用于根據所述屬性信息，確定所述工單的優(yōu)先級；調整模塊22用于按照所述優(yōu)先級，調整所述工單的處理次序。

這里需要說明的是：本實施例提供的所述工單處理裝置可實現上述各工單處理方法實施例提供的技術方案，具體的實現原理可參見上述各實施例中的相應內容，此處不再贅述。

在本發(fā)明實施例中，通過獲取工單的屬性信息，并根據屬性信息確定工單的優(yōu)先級，即可實現根據所述工單的優(yōu)先級，調整所述工單的處理次序的目的，解決了現有技術中因工單處理順序的隨機性而存在的諸多問題，有助于提高服務質量。

進一步的，上述的確定模塊21可采用圖4所示的結構實現。具體的，所述確定模塊21包括：識別單元211、獲取單元212和計算單元213。其中，識別單元211用于識別所述屬性信息以獲得識別結果；獲取單元212用于采用所述識別結果對應的權重獲取方式，獲取所述屬性信息對應的權重；計算單元213用于基于所述權重計算得到所述工單的優(yōu)先級。

再進一步的，上述的獲取單元212可具體用于：

若所述識別結果為工單的問題來源屬性信息，則調取所述問題來源屬性信息對應的來源方畫像數據；

根據所述來源方畫像數據，評價所述來源方的價值；

獲取所述價值對應的權重。

進一步的，如圖4所示，本發(fā)明實施例提供的所述工單處理裝置還可包括：監(jiān)聽模塊23。其中，所述監(jiān)聽模塊23用于監(jiān)聽與工單相關的觸發(fā)事件。以及所述第一獲取模塊20還用于響應于監(jiān)聽到的所述觸發(fā)事件，獲取所述工單的屬性信息。

或者，所述第一獲取模塊20還用于：等時間間隔地獲取所述工單的屬性信息。

進一步的，如圖4所示，本發(fā)明實施例提供的所述工單處理裝置還可包括：查找模塊24和合并模塊25。其中，所述查找模塊24用于在工單池中，查找相關聯的多個工單。所述合并模塊25用于合并查找到的相關聯的多個工單。

進一步的，上述的查找模塊24還用于：在工單池中，查找工單問題來源相同的工單，和/或查找工單問題相同或相似的工單。

進一步的，如圖4所示，本發(fā)明實施例提供的所述工單處理裝置還可包括：第二獲取模塊26。其中，所述第二獲取模塊用于若工單池中包含有至少兩個優(yōu)先級相同的工單，則獲取優(yōu)先級相同的工單的創(chuàng)建時間。所述調整模塊22還用于根據所述創(chuàng)建時間，調整所述至少兩個優(yōu)先級相同的工單的處理次序。

進一步的，本實施例中涉及的所述屬性信息包括：創(chuàng)建時間、問題類型、問題來源途徑、問題來源信息及緊急度信息中的一種或多種。

以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部模塊來實現本實施例方案的目的。本領域普通技術人員在不付出創(chuàng)造性的勞動的情況下，即可以理解并實施。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到各實施方式可借助軟件加必需的通用硬件平臺的方式來實現，當然也可以通過硬件?；谶@樣的理解，上述技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來，該計算機軟件產品可以存儲在計算機可讀存儲介質中，如rom/ram、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網絡設備等)執(zhí)行各個實施例或者實施例的某些部分所述的方法。

最后應說明的是：以上實施例僅用以說明本發(fā)明的技術方案，而非對其限制；盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解：其依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替換；而這些修改或者替換，并不使相應技術方案的本質脫離本發(fā)明各實施例技術方案的精神和范圍。