具体实施方式
下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例,然而应当理解的是,本公开可以通过各种形式来实现,而且不应该被解释为限于这里阐述的实施例。相反,提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是,本公开的附图及实施例仅用于示例性作用,并非用于限制本公开的保护范围。
另外还需要说明的是,为了便于描述,附图中仅示出了与有关发明相关的部分。在不冲突的情况下,本公开中的实施例及实施例中的特征可以相互组合。
需要注意,本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分,并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。
需要注意,本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的,本领域技术人员应当理解,除非在上下文另有明确指出,否则应该理解为“一个或多个”。
本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的,而并不是用于对这些消息或信息的范围进行限制。
下面将参考附图并结合实施例来详细说明本公开。
图1是本公开的一些实施例的工单分配方法的一个应用场景的示意图。
在图1的应用场景中,***架构100可以包括终端设备101、102、103,网络104,服务器105和服务器106。网络104用以在终端设备101、102、103,服务器105和服务器106之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。终端设备101、102、103可以是具有显示屏并且支持信息处理的各种电子设备,包括但不限于智能手机、平板电脑、电子书阅读器、膝上型便携计算机和台式计算机等等。
终端设备101、102、103上可以安装有各种应用,用户在对各种应用进行操作时,可以通过终端设备101、102、103生成待处理工单。终端设备101、102、103可以通过网络104将待处理工单发送给服务器105。服务器105可以获取的待处理工单的工单属性信息,并计算工单属性信息对应的待处理工单的优先级。之后,服务器105可以根据优先级将待处理工单加入待处理工单序列。为了提高对待处理工单的处理效率,服务器106可以首先根据待处理工单的优先级从待处理工单序列中获取目标待处理工单。然后,服务器106可以查询目标待处理工单的客服组集合中对应待处理工单的目标客服组,并从目标客服组中确定对应目标待处理工单的目标客服。最后,将目标待处理工单发送至目标客服进行处理。本申请在分配目标待处理工单时,综合考虑了待处理工单的优先级选择目标客服,使得目标客服对目标待处理工单及时处理,提高了待处理工单的处理效率。
需要说明的是,上述服务器106可以是硬件,也可以是软件。当服务器106为硬件时,可以实现成多个服务器或终端设备组成的分布式集群,也可以实现成单个服务器或单个终端设备。当服务器106体现为软件时,可以安装在上述所列举的硬件设备中。其可以实现成例如用来提供分布式服务的多个软件或软件模块,也可以实现成单个软件或软件模块。在此不做具体限定。
应该理解,图1中的终端设备101、102、103,网络104,服务器105和服务器106的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备101、102、103,网络104,服务器105和服务器106。
继续参考图2,图2示出了根据本公开的工单分配方法的一些实施例的流程200。该工单分配方法,包括以下步骤:
步骤201,基于至少一个待处理工单的优先级从待处理工单序列中获取目标待处理工单。
在一些实施例中,工单分配方法的执行主体(例如图1所示的服务器106)可以通过有线连接方式或者无线连接方式从服务器105获取待处理工单序列中的待处理工单。需要指出的是,上述无线连接方式可以包括但不限于3G/4G连接、WiFi连接、蓝牙连接、WiMAX连接、Zigbee连接、UWB(ultra wideband)连接、以及其他现在已知或将来开发的无线连接方式。
执行主体可以首先通过待处理工单的优先级从待处理工单序列中获取目标待处理工单。其中,目标待处理工单通常是待处理工单序列中优先级最高的待处理工单。
步骤202,查询能够处理上述目标待处理工单的客服组集合。
执行主体可以根据目标待处理工单的信息类型等信息查询到对应的客服组集合。其中,上述客服组集合包括至少一个客服组。客服组可以用于处理上述目标待处理工单。
步骤203,基于预设规则对上述至少一个客服组进行筛选,确定目标客服组。
为了提高处理目标待处理工单的效率,执行主体还可以进一步对客服组集合中的至少一个客服组筛选,以确定目标客服组。
步骤204,对上述目标客服组中的至少一个客服信息进行过滤,确定目标客服,并将上述目标待处理工单发送至上述目标客服。
目标客服组还可以包含至少一个客服信息。其中,客服信息可以是客服名称、客服类型、客服编号等。执行主体进一步对客服信息过滤确定目标客服,并将上述目标待处理工单发送至上述目标客服。如此,通过待处理工单的优先级、客服组集合、直到目标客服组的多重选择确定处理目标待处理工单的目标客服,有利于目标待处理工单的及时处理,提高处理目标待处理工单的效率。
通过本公开的一些实施例的工单分配方法确定了目标客服,通过目标客服来处理目标待处理工单,提高了数据处理效率。具体来说,造成数据处理效率不高的原因在于:没有综合考虑待处理工单的优先级和客服的工作负载,无法找到处理待处理工单的最合适的客服。基于此,本公开的一些实施例的工单分配方法首先根据优先级从待处理工单序列中获取目标待处理工单,如此,可以整体上提高处理待处理工单的及时性;然后,从对应目标待处理工单的客服组集合中确定目标客服组,对目标客服组中的客服信息进行过滤来确定目标客服。最后,将目标待处理工单发送至上述目标客服。如此,可以找到最适合处理待处理工单的目标客服,有利于提高处理待处理工单的及时性和有效性,提高了数据处理效率。
继续参考图3,图3示出了根据本公开的工单分配方法的一些实施例的流程300。该工单分配方法,包括以下步骤:
步骤301,基于至少一个待处理工单的优先级从待处理工单序列中获取目标待处理工单。
步骤302,查询能够处理上述目标待处理工单的客服组集合。
步骤303,基于预设规则对上述至少一个客服组进行筛选,确定目标客服组。
步骤301至步骤303的内容与步骤201至步骤203的内容相同,此处不再一一赘述。
在一些实施例的一些可选的实现方式中,上述基于预设规则对上述至少一个客服组进行筛选,确定目标客服组,还可以包括:判断上述客服组中是否包括在线客服;若存在,判断上述客服组未处理完成的信息数量是否小于预设阈值;若小于,计算上述客服组负载率;当上述客服组负载率小与其他客服组负载率时,将上述客服组确定为目标客服组。
客服组中的客服可以是在线状态也可以是离线状态。离线(即离线状态)客服无法处理信息。当存在在线(即在线状态)客服时,执行主体可以进一步判断客服组未处理完成的信息数量是否小于预设阈值。当信息数量小于预设阈值时,说明客服组可能能够处理该目标待处理工单。进一步,执行主体可以计算上述客服组负载率。当上述客服组负载率小与其他客服组负载率时,说明该客服组有能力继续处理信息。此时,执行主体可以将上述客服组确定为目标客服组。
在一些实施例的一些可选的实现方式中,上述客服组负载率可以通过以下步骤计算得到:
第一步,计算上述客服组中客服信息对应的客服的数据处理量总量之和,得到客服组数据处理量总量。
执行主体可以计算客服信息对应的客服的数据处理量总量之和,得到客服组数据处理量总量。
第二步,计算上述客服组中客服信息对应的客服的最大数据处理量之和,得到客服组最大数据处理量。
执行主体可以计算客服信息对应的客服的最大数据处理量之和,得到客服组最大数据处理量。
第三步,将上述客服组数据处理量总量与客服组最大数据处理量的比值设置为客服组负载率。
之后,执行主体可以将上述客服组数据处理量总量与客服组最大数据处理量的比值设置为客服组负载率。
步骤304,获取上述至少一个客服的客服状态信息,基于上述客服状态信息确定目标客服,并将上述目标待处理工单发送至上述目标客服。
执行主体可以获取每个客服的客服状态信息。其中,上述客服状态信息可以包括客服在线状态、客服负载、待处理工单数量、空闲时长中的至少一个。之后,执行主体可以根据客服状态信息确定目标客服,并将上述目标待处理工单发送至上述目标客服。例如,执行主体可以选择空闲时长最长的最为目标客服等。
在一些实施例的一些可选的实现方式中,上述基于上述客服状态信息确定目标客服,还可以包括以下步骤:
第一步,判断上述目标客服组中的上述至少一个客服中是否存在上述在线信息为在线且上述待处理工单数量小于预设阈值的至少一个可用客服。
执行主体可以首先查询在线的至少一个客服,然后在这些在线客服里再查询待处理工单数量小于预设阈值的至少一个可用客服。
第二步,响应于存在,计算上述可用客服的客服负载率。
当存在这样的可用客服时,执行主体可以进一步计算可用客服的客服负载率。
在计算客服负载率前,首先获取处理中工单占用客服的资源数。以游戏场景下为例,可以是游戏中的客服工单,客服工单占用客服的资源数的计算公式如下:
其中,A为客服工单;load(A)为A工单占用客服的资源数;(1)为客服未回复时的客服的资源数;(2)为客服已开始回复A工单但为完成时的客服的资源数;e为自然常数,取值约为2.718281828459045。α为常量;wait_time(A)为客服回复后等待玩家的时间;round(A)为当前工单已经进行交互的次数。
根据以上公式,客服未对工单进行回复时,此工单占用一个单位的客服资源,当客服已经对工单进行处理回复后,随着客服等待玩家继续回复时间的加大以及回合数的增大,此工单问题趋近于解决,占用的客服资源数越来越少。
当客服回复玩家后,等待玩家回复的时间为该客服回复答复后历史平均等待时间,且工单交互次数为该客服处理单个客服工单的平均交互的次数时,工单占用资源数β通常较小。
此时,客服资源数的计算公式如下:
基于历史数据,β为(0,1)之间的一个常量,例如,可以是0.1。上述公式转换为:
进一步,以上wait_time(A)=avg_wait_time,round(A)=avg_round,上述公式转换为:
进而,α的计算公式为:
avg_wait_time为该客服历史平均等待时间;avg_round为该客服处理单个客服工单的平均交互的次数。
在上述公式的基础上,可以确定客服C的客服负载率。客服负载率可以通过以下公式计算:
其中,C为可用客服;load(C)为可用客服C的负载率;X为已经分配给客服C的待处理工单序列;max_load(C)为可用客服C的最大负载。
在获取到待处理工单占用的客服的资源数load(A)后,相应的客服组负载率可以通过以下公式计算得到:
其中,load(G)为客服组G的负载率;max_load(G)为客服组G的最大负载率。
其中,客服组G的最大负载率通过以下公式计算得到:
max_load(G)=∑C∈(所有在线客服集合)max_load(C)
其中,max_load(C)为客服C的最大负载率,该最大负载率可以基于客服的信息预先设定。
第三步,将上述客服负载率最小的上述可用客服确定为目标客服。
执行主体可以将客服负载率最小的上述可用客服确定为目标客服。如此,不仅可以平衡客服的负载,还有利于加快目标待处理工单的处理速度和效率。
继续参考图4,图4示出了根据本公开的工单处理方法的一些实施例的流程400。该工单处理方法,包括以下步骤:
步骤401,获取待处理工单的工单属性信息。
在一些实施例中,工单处理方法的执行主体(例如图1所示的服务器105)可以通过有线连接方式或者无线连接方式从用户利用其进行信息发送的终端设备101、102、103接收待处理工单。需要指出的是,上述无线连接方式可以包括但不限于3G/4G连接、WiFi连接、蓝牙连接、WiMAX连接、Zigbee连接、UWB(ultra wideband)连接、以及其他现在已知或将来开发的无线连接方式。
执行主体可以获取终端设备101、102、103发来的待处理工单,之后可以获取待处理工单的工单属性信息。其中,上述工单属性信息用于描述上述待处理工单,可以包括至少一个静态属性信息。上述静态属性信息为不随时间变化的属性信息。例如,静态属性信息可以是:信息类别、用户属性、信息语言类别等。
步骤402,根据上述工单属性信息计算上述待处理工单的优先级。
工单属性信息包含的信息可以有不同的权重信息。得到工单属性信息后,执行主体可以根据工单属性信息的权重信息来计算待处理工单的优先级。
在一些实施例的一些可选的实现方式中,上述工单属性信息还可以包括至少一个动态属性信息,上述动态属性信息可以为随时间变化的属性信息。上述根据上述工单属性信息计算上述待处理工单的优先级,可以包括以下步骤:
第一步,将上述至少一个动态属性信息的取值转换为静态值。
由于动态属性信息可能随时间发生变化,因此,现有方法在计算优先级时,优先级的结果也在不断变化,大大增加了计算优先级的数据量和处理时间,且优先级的有效性不高。为此,本申请可以将动态属性信息的取值转换为静态值。如此,实现了动态属性信息的静态化,有利于降低计算优先级的数据处理量,加快计算过程,并提高了优先级的有效性。
第二步,基于上述至少一个静态属性信息的取值和上述静态值计算上述待处理工单的优先级。
得到动态属性信息的静态值后,执行主体可以通过静态属性信息的取值和上述静态值计算上述待处理工单的优先级。如此,使得优先级为不随时间变化的一个定值,提高了优先级的稳定性和有效性。
在一些实施例的一些可选的实现方式中,上述工单属性信息还可以包括空缺属性信息,上述获取待处理工单的工单属性信息,可以包括:基于预设的取值补充上述空缺属性信息的属性取值。
实际中,由于多种原因,得到的待处理工单包含的工单属性信息还可以包括空缺属性信息,而包含空缺属性信息的待处理工单可能无法计算优先级。为此,当全局属性信息中包含上述至少一个静态属性信息和至少一个动态属性信息以外的空缺属性信息时,可以补充上述空缺属性信息的属性内容。通常,补充空缺属性信息的属性取值可以是“NULL”、“0”等。如此,既可以进行优先级的运算,也在优先级运算过程中不影响优先级的最终取值。
在一些实施例的一些可选的实现方式中,上述将上述至少一个动态属性信息的取值转换为静态值,可以包括以下步骤:
第一步,对于各上述动态属性信息,查询上述动态属性信息对应的时间戳,将上述时间戳对应的时间信息设置为上述动态属性信息的子静态值。
执行主体可以查询每个动态属性信息的时间戳,并将该时间戳设置为子静态值。其中,上述时间戳可以用于表征该动态属性信息的生成时间。例如,时间戳可以是20200720121030,表示该待处理工单的生成时间为2020年07月20日12时10分30秒。时间戳还可以通过在线时间戳等方式来表示,具体根据实际需要而定。
第二步,对上述至少一个动态属性信息对应的至少一个子静态值求和得到上述静态值。
执行主体可以将每个动态属性信息对应的子静态值求和,以得到静态值。实际中,每个动态属性信息的取值随时间变化。因此,执行主体还可以从多个动态属性信息中选择一个目标动态属性信息为基准,直接将该目标动态属性信息的子静态值设置为对应该动态属性信息的静态值。
在一些实施例的一些可选的实现方式中,上述基于上述至少一个静态属性信息的取值和上述静态值计算上述待处理工单的优先级,可以包括以下步骤:
第一步,查询各上述静态属性信息和/或静态值的加权系数和权重值,根据上述加权系数和权重值计算得到对应上述至少一个静态属性信息的静态优先级。
执行主体可以查询每个静态属性信息的加权系数和权重值,然后计算每个静态属性信息加权系数和权重值乘积,并计算全部静态属性信息的乘积和,得到静态属性信息的静态优先级。其中,加权系数可以用于表征静态属性信息与其他属性信息对比的重要程度。权重值可以用于表征静态属性信息自身的重要程度。
第二步,对上述静态优先级和静态值求和得到上述优先级。
得到静态优先级后,执行主体可以对上述静态优先级和静态值求和得到上述优先级。
执行主体可以将静态优先级和静态值的和设置为待处理工单的优先级。
优先级可以通过以下公式计算:
其中,Q为优先级;M为动态属性信息的数量;i为动态属性信息的编号,i=1,…,M;Ti为第i个动态属性信息的子静态值;N为静态属性信息的数量;j为静态属性信息的编号,j=1,…,N;αj为第j个静态属性信息的加权系数;qj为第j个静态属性信息的权重值。
步骤403,根据上述优先级将上述待处理工单加入待处理工单序列,以使上述待处理工单按照图2,图3上述的分配方法进行分配并处理。
执行主体可以根据上述优先级将上述待处理工单加入待处理工单序列。如此,使得服务器106能够按照优先级来分配待处理工单的目标客服,提高了数据处理效率。
继续参考图5,图5示出了根据本公开的待处理工单的分配方法的一些应用场景的示意图。
用户在终端设备102上操作游戏过程中,向服务器105发送待处理工单Y。其中,待处理工单Y包含了下表1中的工单属性信息。
表1
由上述表1可知,工单属性信息分为静态属性信息(例如:信息类别、用户属性、语言)和动态属性信息(例如:等待时间)。其中,信息类别、用户属性、语言为静态属性信息的属性名称。等待时间为动态属性信息的属性名称。服务器105可以根据表1可以获取到每个属性信息的权重和加权系数。其中,对相对紧急的问题,设定较小的权值,得到的优先级取值较小,在后续的待处理工单序列中的排序较高。即,待处理工单序列中的优先级按照优先级取值从小到大的顺序排序。
服务器105可以通过图4对应的实施例中的公式来计算得到待处理工单Y的优先级例如可以是0.6。然后,服务器105可以查询可以处理待处理工单Y的至少一个客服组y1。服务器105可以查询优先级0.6在待处理工单序列中的排序,并将待处理工单Y加入到待处理工单序列中。客服组y1可以与待处理工单Y对应设置,以便服务器106后续根据客服组y1查询待处理工单Y对应的目标客服。例如,当前的待处理工单序列X可以是:{x1,x2,x3,x4,···},其中,待处理工单x1的优先级可以是100,待处理工单x2的优先级可以是52320,待处理工单x3的优先级可以是1210320,···。可见,待处理工单Y的优先级最小。服务器105可以将待处理工单Y的优先级加入待处理工单序列,此时的待处理工单序列X可以为:{Y,x1,x2,x3,x4,···}。此时,待处理工单Y在待处理工单序列的首位,服务器106可以根据图3实施例中负载率的计算公式查询列表y1对应的客服组y1中每个客服的客服负载率,并根据客服负载率确定对应待处理工单Y的目标客服Z。最后,服务器106可以将待处理工单Y发送至目标客服Z。如此,实现了通过目标客服Z对待处理工单Y进行数据处理,有利于提高数据处理效率。
进一步参考图6,作为对上述各图所示方法的实现,本公开提供了一种工单分配装置的一些实施例,这些装置实施例与图2所示的那些方法实施例相对应,该装置具体可以应用于各种电子设备中。
如图6所示,一些实施例的工单分配装置600可以包括:目标待处理工单获取单元601、客服组集合查询单元602、目标客服组确定单元603和分配单元604。其中,目标待处理工单获取单元601,被配置成基于至少一个待处理工单的优先级从待处理工单序列中获取目标待处理工单;客服组集合查询单元602,被配置成查询能够处理上述目标待处理工单的客服组集合,上述客服组集合包括至少一个客服组;目标客服组确定单元603,被配置成基于预设规则对上述至少一个客服组进行筛选,确定目标客服组;分配单元604,被配置成对上述目标客服组中的至少一个客服信息进行过滤,确定目标客服,并将上述目标待处理工单发送至上述目标客服。
在一些实施例的可选实现方式中,上述目标客服组确定单元603还可以包括:第一判断子单元(图中未示出)、第二判断子单元(图中未示出)和第三判断子单元(图中未示出)。其中,第一判断子单元,被配置成判断上述客服组中是否包括在线客服;第二判断子单元,被配置成若存在,判断上述客服组未处理完成的信息数量是否小于预设阈值;第三判断子单元,被配置成若小于,计算上述客服组负载率;当上述客服组负载率小与其他客服组负载率时,将上述客服组确定为目标客服组。
在一些实施例的可选实现方式中,上述工单分配装置600可以包括客服组负载率计算单元(图中未示出),被配置成计算客服组负载率,上述客服组负载率计算单元可以包括:客服组数据处理量总量计算子单元(图中未示出)、客服组最大数据处理量计算子单元(图中未示出)和客服组负载率计算子单元(图中未示出)。其中,客服组数据处理量总量计算子单元,被配置成计算上述客服组中客服信息对应的客服的数据处理量总量之和,得到客服组数据处理量总量;客服组最大数据处理量计算子单元,被配置成计算上述客服组中客服信息对应的客服的最大数据处理量之和,得到客服组最大数据处理量;客服组负载率计算子单元,被配置成将上述客服组数据处理量总量与客服组最大数据处理量的比值设置为客服组负载率。
在一些实施例的可选实现方式中,上述分配单元604可以还包括:分配子单元(图中未示出),被配置成获取上述至少一个客服的客服状态信息,基于上述客服状态信息确定目标客服;上述客服状态信息包括客服在线状态、客服负载、待处理工单数量、空闲时长中的至少一个。
在一些实施例的可选实现方式中,上述分配子单元还可以包括:可用客服判断模块(图中未示出)、客服负载计算模块(图中未示出)和目标客服确定模块(图中未示出)。其中,可用客服判断模块,被配置成判断上述目标客服组中的上述至少一个客服中是否存在上述在线信息为在线且上述待处理工单数量小于预设阈值的至少一个可用客服;客服负载计算模块,被配置成响应于存在,计算上述可用客服的客服负载;目标客服确定模块,被配置成将上述客服负载最小的上述可用客服确定为目标客服。
可以理解的是,该装置600中记载的诸单元与参考图2描述的方法中的各个步骤相对应。由此,上文针对方法描述的操作、特征以及产生的有益效果同样适用于装置600及其中包含的单元,在此不再赘述。
如图7所示,一些实施例的工单处理装置700可以包括:工单属性信息获取单元701、优先级计算单元702和信息添加单元703。其中,工单属性信息获取单元701,被配置成获取待处理工单的工单属性信息,上述工单属性信息包括至少一个静态属性信息,上述静态属性信息为不随时间变化的属性信息;优先级计算单元702,被配置成根据上述工单属性信息计算上述待处理工单的优先级;信息添加单元703,被配置成根据上述优先级将上述待处理工单加入待处理工单序列,以使上述待处理工单按照图6的分配装置进行分配并处理。
在一些实施例的可选实现方式中,上述工单属性信息还可以包括至少一个动态属性信息,上述动态属性信息为随时间变化的属性信息;上述优先级计算单元702可以包括:静态值转换子单元(图中未示出)和优先级计算子单元(图中未示出)。其中,静态值转换子单元,被配置成将上述至少一个动态属性信息的取值转换为静态值;优先级计算子单元,被配置成基于上述至少一个静态属性信息的取值和上述静态值计算上述待处理工单的优先级。
在一些实施例的可选实现方式中,上述工单属性信息还包括空缺属性信息;上述工单属性信息获取单元701可以包括:信息补充子单元(图中未示出)。其中,信息补充子单元,被配置成基于预设的取值补充上述空缺属性信息的属性取值。
在一些实施例的可选实现方式中,上述静态值转换子单元可以包括:子静态值确定模块(图中未示出)和静态值计算模块(图中未示出)。其中,子静态值确定模块,被配置成对于各上述动态属性信息,查询上述动态属性信息对应的时间戳,将上述时间戳对应的时间信息设置为上述动态属性信息的子静态值,上述时间戳用于表征上述动态属性信息的生成时间;静态值计算模块,被配置成对上述至少一个动态属性信息对应的至少一个子静态值求和得到上述静态值。
在一些实施例的可选实现方式中,上述优先级计算子单元可以包括:静态优先计算模块(图中未示出)和优先级计算模块(图中未示出)。其中,静态优先计算模块,被配置成查询各上述静态属性信息和/或静态值的加权系数和权重值,根据上述加权系数和权重值计算得到对应上述至少一个静态属性信息的静态优先级;优先级计算模块,被配置成对上述静态优先级和静态值求和得到上述优先级。
可以理解的是,该装置700中记载的诸单元与参考图4描述的方法中的各个步骤相对应。由此,上文针对方法描述的操作、特征以及产生的有益效果同样适用于装置700及其中包含的单元,在此不再赘述。
如图8所示,电子设备800可以包括处理装置(例如中央处理器、图形处理器等)801,其可以根据存储在只读存储器(ROM)802中的程序或者从存储装置808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM 803中,还存储有电子设备800操作所需的各种程序和数据。处理装置801、ROM 802以及RAM803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。
通常,以下装置可以连接至I/O接口805:包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置806;包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置807;包括例如磁带、硬盘等的存储装置808;以及通信装置809。通信装置809可以允许电子设备800与其他设备进行无线或有线通信以交换数据。虽然图8示出了具有各种装置的电子设备800,但是应理解的是,并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。图8中示出的每个方框可以代表一个装置,也可以根据需要代表多个装置。
特别地,根据本公开的一些实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本公开的一些实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的一些实施例中,该计算机程序可以通过通信装置809从网络上被下载和安装,或者从存储装置808被安装,或者从ROM 802被安装。在该计算机程序被处理装置801执行时,执行本公开的一些实施例的方法中限定的上述功能。
需要说明的是,本公开的一些实施例上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开的一些实施例中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本公开的一些实施例中,计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读信号介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:电线、光缆、RF(射频)等等,或者上述的任意合适的组合。
在一些实施方式中,客户端、服务器可以利用诸如HTTP(HyperText TransferProtocol,超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信,并且可以与任意形式或介质的数字数据通信(例如,通信网络)互连。通信网络的示例包括局域网(“LAN”),广域网(“WAN”),网际网(例如,互联网)以及端对端网络(例如,ad hoc端对端网络),以及任何当前已知或未来研发的网络。
上述计算机可读介质可以是上述电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被该电子设备执行时,使得该电子设备:基于至少一个待处理工单的优先级从待处理工单序列中获取目标待处理工单;查询能够处理上述目标待处理工单的客服组集合,上述客服组集合包括至少一个客服组;基于预设规则对上述至少一个客服组进行筛选,确定目标客服组;对上述目标客服组中的至少一个客服信息进行过滤,确定目标客服,并将上述目标待处理工单发送至上述目标客服。
可以以一种或多种程序设计语言或其组合来编写用于执行本公开的一些实施例的操作的计算机程序代码,上述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)——连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图,图示了按照本公开各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的***来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开的一些实施例中的单元可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中,例如,可以描述为:一种处理器包括目标待处理工单获取单元、客服组集合查询单元、目标客服组确定单元和分配单元。其中,这些单元的名称在某种情况下并不构成对该单元本身的限定,例如,分配单元还可以被描述为“用于为待处理工单配置目标客服的单元”。
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如,非限制性地,可以使用的示范类型的硬件逻辑部件包括:现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上***(SOC)、复杂可编程逻辑设备(CPLD)等等。
根据本公开的一个或多个实施例,提供了一种工单分配方法,包括:基于至少一个待处理工单的优先级从待处理工单序列中获取目标待处理工单;查询能够处理上述目标待处理工单的客服组集合,上述客服组集合包括至少一个客服组;基于预设规则对上述至少一个客服组进行筛选,确定目标客服组;对上述目标客服组中的至少一个客服信息进行过滤,确定目标客服,并将上述目标待处理工单发送至上述目标客服。
根据本公开的一个或多个实施例,上述基于预设规则对上述至少一个客服组进行筛选,确定目标客服组,还包括:判断上述客服组中是否包括在线客服;若存在,判断上述客服组未处理完成的信息数量是否小于预设阈值;若小于,计算上述客服组负载率;当上述客服组负载率小与其他客服组负载率时,将上述客服组确定为目标客服组。
根据本公开的一个或多个实施例,上述客服组负载率通过以下步骤计算得到:计算上述客服组中客服信息对应的客服的数据处理量总量之和,得到客服组数据处理量总量;计算上述客服组中客服信息对应的客服的最大数据处理量之和,得到客服组最大数据处理量;将上述客服组数据处理量总量与客服组最大数据处理量的比值设置为客服组负载率。
根据本公开的一个或多个实施例,上述对上述目标客服组中的至少一个客服信息进行过滤,确定目标客服,还包括:获取上述至少一个客服的客服状态信息,基于上述客服状态信息确定目标客服;上述客服状态信息包括客服在线状态、客服负载、待处理工单数量、空闲时长中的至少一个。
根据本公开的一个或多个实施例,上述基于上述客服状态信息确定目标客服,还包括:判断上述目标客服组中的上述至少一个客服中是否存在上述在线信息为在线且上述待处理工单数量小于预设阈值的至少一个可用客服;响应于存在,计算上述可用客服的客服负载率;将上述客服负载率最小的上述可用客服确定为目标客服。
根据本公开的一个或多个实施例,提供了一种工单处理方法,包括:获取待处理工单的工单属性信息,上述工单属性信息包括至少一个静态属性信息,上述静态属性信息为不随时间变化的属性信息;根据上述工单属性信息计算上述待处理工单的优先级;根据上述优先级将上述待处理工单加入待处理工单序列,以使上述待处理工单按照上述的分配方法进行分配并处理。
根据本公开的一个或多个实施例,上述工单属性信息还包括至少一个动态属性信息,上述动态属性信息为随时间变化的属性信息;上述根据上述工单属性信息计算上述待处理工单的优先级,包括:将上述至少一个动态属性信息的取值转换为静态值;基于上述至少一个静态属性信息的取值和上述静态值计算上述待处理工单的优先级。
根据本公开的一个或多个实施例,上述工单属性信息还包括空缺属性信息;上述获取待处理工单的工单属性信息,包括:基于预设的取值补充上述空缺属性信息的属性取值。
根据本公开的一个或多个实施例,上述将上述至少一个动态属性信息的取值转换为静态值,包括:对于各上述动态属性信息,查询上述动态属性信息对应的时间戳,将上述时间戳对应的时间信息设置为上述动态属性信息的子静态值,上述时间戳用于表征上述动态属性信息的生成时间;对上述至少一个动态属性信息对应的至少一个子静态值求和得到上述静态值。
根据本公开的一个或多个实施例,上述基于上述至少一个静态属性信息的取值和上述静态值计算上述待处理工单的优先级,包括:查询各上述静态属性信息和/或静态值的加权系数和权重值,根据上述加权系数和权重值计算得到对应上述至少一个静态属性信息的静态优先级;对上述静态优先级和静态值求和得到上述优先级。
根据本公开的一个或多个实施例,提供了一种工单分配装置,包括:目标待处理工单获取单元,被配置成基于至少一个待处理工单的优先级从待处理工单序列中获取目标待处理工单;客服组集合查询单元,被配置成查询能够处理上述目标待处理工单的客服组集合,上述客服组集合包括至少一个客服组;目标客服组确定单元,被配置成基于预设规则对上述至少一个客服组进行筛选,确定目标客服组;分配单元,被配置成对上述目标客服组中的至少一个客服信息进行过滤,确定目标客服,并将上述目标待处理工单发送至上述目标客服。
根据本公开的一个或多个实施例,上述目标客服组确定单元还包括:第一判断子单元,被配置成判断上述客服组中是否包括在线客服;第二判断子单元,被配置成若存在,判断上述客服组未处理完成的信息数量是否小于预设阈值;第三判断子单元,被配置成若小于,计算上述客服组负载率;当上述客服组负载率小与其他客服组负载率时,将上述客服组确定为目标客服组。
根据本公开的一个或多个实施例,上述装置包括客服组负载率计算单元,被配置成计算客服组负载率,上述客服组负载率计算单元包括:客服组数据处理量总量计算子单元,被配置成计算上述客服组中客服信息对应的客服的数据处理量总量之和,得到客服组数据处理量总量;客服组最大数据处理量计算子单元,被配置成计算上述客服组中客服信息对应的客服的最大数据处理量之和,得到客服组最大数据处理量;客服组负载率计算子单元,被配置成将上述客服组数据处理量总量与客服组最大数据处理量的比值设置为客服组负载率。
根据本公开的一个或多个实施例,上述分配单元还包括:分配子单元,被配置成获取上述至少一个客服的客服状态信息,基于上述客服状态信息确定目标客服;上述客服状态信息包括客服在线状态、客服负载、待处理工单数量、空闲时长中的至少一个。
根据本公开的一个或多个实施例,上述分配子单元还包括:可用客服判断模块,被配置成判断上述目标客服组中的上述至少一个客服中是否存在上述在线信息为在线且上述待处理工单数量小于预设阈值的至少一个可用客服;客服负载计算模块,被配置成响应于存在,计算上述可用客服的客服负载;目标客服确定模块,被配置成将上述客服负载最小的上述可用客服确定为目标客服。
根据本公开的一个或多个实施例,提供了一种工单处理装置,包括:工单属性信息获取单元,被配置成获取待处理工单的工单属性信息,上述工单属性信息包括至少一个静态属性信息,上述静态属性信息为不随时间变化的属性信息;优先级计算单元,被配置成根据上述工单属性信息计算上述待处理工单的优先级;信息添加单元,被配置成根据上述优先级将上述待处理工单加入待处理工单序列,以使上述待处理工单按照上述的分配装置进行分配并处理。
根据本公开的一个或多个实施例,上述工单属性信息还包括至少一个动态属性信息,上述动态属性信息为随时间变化的属性信息;上述优先级计算单元包括:静态值转换子单元,被配置成将上述至少一个动态属性信息的取值转换为静态值;优先级计算子单元,被配置成基于上述至少一个静态属性信息的取值和上述静态值计算上述待处理工单的优先级。
根据本公开的一个或多个实施例,上述工单属性信息还包括空缺属性信息;上述工单属性信息获取单元包括:信息补充子单元,被配置成基于预设的取值补充上述空缺属性信息的属性取值。
根据本公开的一个或多个实施例,上述静态值转换子单元包括:子静态值确定模块,被配置成对于各上述动态属性信息,查询上述动态属性信息对应的时间戳,将上述时间戳对应的时间信息设置为上述动态属性信息的子静态值,上述时间戳用于表征上述动态属性信息的生成时间;静态值计算模块,被配置成对上述至少一个动态属性信息对应的至少一个子静态值求和得到上述静态值。
根据本公开的一个或多个实施例,上述优先级计算子单元包括:静态优先计算模块,被配置成查询各上述静态属性信息和/或静态值的加权系数和权重值,根据上述加权系数和权重值计算得到对应上述至少一个静态属性信息的静态优先级;优先级计算模块,被配置成对上述静态优先级和静态值求和得到上述优先级。
以上描述仅为本公开的一些较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本公开的实施例中所涉及的发明范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离上述发明构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开的实施例中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。