1.本公开涉及互联网技术领域，客服尤其涉及一种客服会话请求处理方法、请求客服会话请求处理装置、处理程电子设备、及相存储介质及程序产品。关设
背景技术：
2.近年来，备流客户服务不仅在通信运营中被广泛应用，客服随着各类电商及其新零售商业模式的请求盛行，在线客户服务也已经成为客户服务中不可或缺的处理程一环，客户服务质量和成本已经成为衡量客服体系建设成功与否的及相标准。
3.为了能更好的关设服务用户，几乎所有的备流客户服务中心都具备“给一个客户分配一个最合适坐席”的能力。然而，客服现有的请求坐席资源分配大多都是针对单个通信渠道分别进行的。随着业务发展，处理程拥有单渠道技能能力的坐席已不满足业务诉求，一个坐席往往需要同时处理即时通信(im)渠道、电话渠道、电子邮件渠道以及工单渠道等多个通信渠道的业务问题，也即一个坐席需要具有同时支持多个通信渠道的技能。在这种情况下，如何实现支持多渠道技能的坐席资源分配已经成为了研究的热点之一。
技术实现要素：
4.有鉴于此，本公开的实施例提供一种客服会话请求处理方法，可以将多个通信渠道的客服会话请求进行统一处理，从全局角度进行坐席资源的统一管理，实现了多渠道坐席资源的准确以及高效分配。
5.根据本公开的一些实施例，上述客服会话请求处理方法可以包括：从第一通信渠道接收第一客服会话请求；将所述第一客服会话请求加入所述第一通信渠道对应的客服会话请求队列；从多个通信渠道对应的客服会话请求队列中提取待处理的第二客服会话请求；以及根据存储的多渠道坐席信息从多渠道坐席资源池中选择处理所述第二客服会话请求的目标坐席。
6.基于上述方法，本公开的实施例提供了一种客服会话请求处理装置，包括：
7.客服会话请求接收模块，用于从第一通信渠道接收第一客服会话请求；
8.请求入队模块，用于将所述第一客服会话请求加入所述第一通信渠道对应的客服会话请求队列；
9.请求提取模块，用于从多个通信渠道对应的客服会话请求队列中提取待处理的第二客服会话请求；以及
10.坐席资源分配模块，用于根据存储的多渠道坐席信息从多渠道坐席资源池中选择处理所述第二客服会话请求的目标坐席。
11.此外，本公开的实施例还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述客服会话请求处理方法。
12.本公开的实施例还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可
读存储介质存储计算机指令，所述计算机指令用于使计算机执行上述客服会话请求处理方法。
13.本公开的实施例还提供了一种计算机程序产品，包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机执行上述客服会话请求处理方法。
14.上述客服会话请求处理方法以及相关设备可以基于多渠道融合的信息将多个通信渠道的客服会话请求进行统一处理，从全局角度进行坐席资源的统一管理，提高客户服务的有效性和准确度，同时也提升了用户的服务体验。
附图说明
15.为了更清楚地说明本公开或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
16.图1显示了在本公开的实施例中客户服务中心存储的某一个用户在各个通信渠道下的上一负责坐席信息的示例；
17.图2显示了在本公开的实施例中客户服务中心存储的某一个坐席在各个通信渠道下的状态信息的示例；
18.图3显示了本公开一些实施例所述的客服会话请求处理方法的实现流程；
19.图4显示了本公开一些实施例所述的根据第一客服会话请求的上下文信息以及存储的多渠道用户信息确定第一客服会话请求的优先级的实现流程；
20.图5给出了本公开实施例中客户服务中心对来自多个通信渠道的客服会话请求进行处理的一个示例；
21.图6给出了本公开实施例中客户服务中心对来自多个通信渠道的客服会话请求进行处理的另一个示例；
22.图7显示了本公开一些实施例所述的根据存储的多渠道坐席信息从多渠道坐席资源池中选择处理所述第二客服会话请求的目标坐席的实现流程；
23.图8给出了本公开实施例中客户服务中心进一步根据上一负责坐席信息对来自多个通信渠道的客服会话请求进行处理的一个示例；
24.图9给出了本公开实施例中客户服务中心进一步根据上一负责坐席信息对来自多个通信渠道的客服会话请求进行处理的另一个示例。
25.图10给出了本公开实施例中客户服务中心进一步根据满意度信息对来自多个通信渠道的客服会话请求进行处理的一个示例；
26.图11给出了本公开实施例中客户服务中心进一步根据满意度信息对来自多个通信渠道的客服会话请求进行处理的另一个示例；
27.图12显示了本公开一些实施例所述的客服会话请求处理装置的内部结构；以及
28.图13示出了本公开一些实施例所述的一种更为具体的电子设备硬件结构示意图。
具体实施方式
29.为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照
附图，对本公开进一步详细说明。
30.需要说明的是，除非另外定义，本公开实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。
31.可以理解的是，在使用本公开中各个实施例的技术方案之前，均会通过恰当的方式对所涉及的个人信息的类型、使用范围、使用场景等告知用户，并获得用户的授权。
32.如前所述，在目前的客户服务中心，一个坐席往往需要同时处理im渠道、电话渠道、电子邮件渠道以及工单渠道等多个通信渠道的业务问题，也即一个坐席需要具有同时支持多个通信渠道的技能。在这种情况下，如何实现支持多渠道技能的坐席资源分配已经成为了研究的热点。
33.然而，在目前的客服会话请求处理过程中，各个通信渠道的信息基本上都是隔离的，客户服务中心无法根据实际的业务场景，在全局调度多渠道坐席资源。这种情况下，对于用户来讲，通常会出现排队时间过长，且无法被分配到全局最优的坐席的问题，从而导致用户的体验变差，最终导致用户的流失。举个例子，假设一个坐席正在接听用户的售后服务电话，此时又进线了多个im会话，im大多存在“首响时间”的考核指标，显然不宜再分配给该“忙碌”的坐席。但是，由于该坐席仅在电话渠道的状态是忙碌的，在其他通信渠道的状态都是空闲的，而且由于各个通信渠道的信息都是隔离的，因此，客户服务中心很有可能会将进线的im会话再分给上述“忙碌”的坐席，从而导致用户的体验变差，最终可能导致用户的流失。
34.为此，本公开的一些实施例提供了一种客服会话请求处理方法，可以基于多渠道融合的信息将多个通信渠道的客服会话请求进行统一处理，从全局角度进行坐席资源的统一管理，实现了多渠道坐席资源的准确以及高效分配。
35.在本公开的实施例中，上述客服会话请求处理方法可以由客户服务中心中具有计算能力的一台或多台服务器实现。
36.为了实现上述方法，在本公开的一些实施例中，上述客户服务中心需要收集来自各个通信渠道的用户侧数据以及坐席侧数据并对所收集的数据进行统一存储，以实现多渠道的数据融合，得到多渠道融合的信息。为了描述上的方便，在本发明的实施例中，将来自各个通信渠道的经过多渠道融合的用户侧的数据称为多渠道用户信息，而将来自各个通信渠道的经过多渠道融合的坐席侧的数据称为多渠道坐席信息。
37.具体地，在本公开的实施例中，上述多渠道用户信息可以包括用户的属性信息，例如，包括：用户的标识等其他可以表征用户特征的属性信息。除了上述用户的属性信息之外，上述多渠道用户信息还可以包括用户的历史客服信息，例如，包括：已处理完成的客服会话请求的相关信息，例如，进线时间、通信渠道、负责坐席、客服会话请求分类、以及用户对坐席的满意度等等。需要说明的是，上述信息的获取及使用可以参见本公开具体实施方
式开头部分说明，会告知用户，并获得用户的授权。在本公开的一些实施例中，上述历史客服信息还可以包括各个用户在各个通信渠道下的上一负责坐席(last agent)。也就是，在不同通信渠道下，之前服务各个用户的上一个坐席的坐席标识。例如，用户1通过im渠道进线，为其分配的坐席是坐席1，则在客服会话请求结束后，可以存储用户1在im渠道下的上一负责坐席为坐席1。可以看出，上述多渠道用户信息中的部分信息是动态变化的，需要进行实时或者定时的更新。例如，在本公开的一些实施例中，当有新的客服会话请求进线或者客服会话请求被分配了坐席或者被处理完成收到用户的反馈后，客户服务中心都会收到相应的消息，如此，客户服务中心都会根据所收到的消息更新自身存储的多渠道用户信息。具体地，在本公开的一些实施例中，客户服务中心可以采用键——值(key-value)的存储方式存储上述多渠道用户信息，也即，以用户的标识为key，将从多个通信渠道收集得到的多渠道用户信息作为value统一存储在一起。例如，图1显示了在本公开的实施例中客户服务中心存储的一个用户在各个通信渠道下的上一负责坐席信息的示例。具体地，在客户服务中心，一个用户在各个通信渠道下的上一负责坐席信息可以统一存储在一个列表中。如图1所示，该表显示了用户标识(id)为1的用户在各个通信渠道下的上一负责坐席信息。具体地，对于该用户，在im渠道，上一负责坐席是坐席id为1的坐席；在电话渠道，上一负责坐席也是坐席id为2的坐席。需要说明的是，图1仅给出了客户服务中心存储的某一个用户在各个通信渠道下的上一负责坐席信息，其他多渠道用户信息也可以采用类似的方式进行存储，例如，一个用户在各个通信渠道下的历史客服信息也可以以该用户的标识作为key统一存储在一起，在此不再重复举例说明了。
38.此外，在本公开的实施例中，上述多渠道坐席信息可以包括坐席的标识、在各个通信渠道下的坐席技能、各个坐席技能的技能等级、在各个通信渠道下的状态、当前进行中会话数、空闲时长以及当日总会话数等等。可以看出，上述多渠道坐席信息中的部分信息也是动态变化的，例如，当有客服会话请求被分配给该坐席或者被某一坐席处理完成后，客户服务中心都会收到相应的消息，如此，客户服务中心都会根据所收到的消息更新自身存储的多渠道坐席信息。具体地，客户服务中心也可以采用键——值(key-value)的存储方式存储上述多渠道坐席信息，也即，以坐席的标识为key，将从多个通信渠道收集得到的多渠道坐席信息作为value存储在一起。图2显示了在本公开的实施例中客户服务中心存储的某一个坐席在各个通信渠道下的状态信息的示例。在客户服务中心，一个坐席在各个通信渠道下的状态信息也可以统一存储在一个列表中。如图2所示，该表显示了坐席标识(id)为1的坐席在各个渠道下的状态信息。具体地，对于该坐席，在im渠道，当前进行中的会话数为2；在电话渠道，当前处于忙碌-进线状态。这说明，坐席标识(id)为1的坐席目前不仅服务一个从电话渠道进线的用户，还服务两个从im渠道进线的用户。需要说明的是，图2仅给出了客户服务中心存储的某一个坐席在各个通信渠道下的状态信息，其他多渠道坐席数据也可以采用类似的方式进行存储，在此不再重复举例说明了。
39.具体地，在本公开的实施例中，上述多渠道用户信息以及多渠道坐席信息可以分别用远程字典服务(remote dictionary server，redis)数据库中的列表(list)实现。
40.在本公开的实施例中，除了上述多渠道用户信息以及多渠道坐席信息之外，客户服务中心还将存储一些基础的静态配置数据，称为多渠道配置信息。上述多渠道配置信息可以包括：完成各个通信渠道属性配置的渠道属性配置数据，例如，各个通信渠道下设置的
默认坐席数等。上述多渠道配置信息还可以包括：坐席资源分配规则配置数据，例如，坐席资源的分配表达式等等。此外，上述多渠道配置信息还可以包括多渠道融合/隔离配置信息，用于标识是进行多渠道融合的坐席资源分配还是进线多渠道隔离的资源分配。
41.除了上述信息之外，还应当预先分别为每个通信渠道建立一个客服会话请求队列。例如，针对电话渠道、即时通信渠道、电子邮件渠道以及工单渠道等等分别建立一个客服会话请求队列，用于对从各个通信渠道进线的客服会话请求进行排队。具体地，在本公开的实施例中，上述多个通信渠道的客服会话请求队列也可以分别用redis数据库中的list实现。
42.经过上述配置后，客户服务中心即可以实现对多渠道进线的客服会话请求的统一处理。具体地，图3显示了本公开一些实施例所述的客服会话请求处理方法的实现流程。如图3所示，该方法主要包括如下步骤：
43.在步骤302，从第一通信渠道接收第一客服会话请求。
44.在本公开的实施例中，上述第一通信渠道可以是电话渠道、即时通信通信渠道、电子邮件通信渠道以及工单渠道等等多个通信渠道之一。
45.需要说明的是，前文虽然列举了多个通信渠道，但是本公开的实施例并不限于上述列举的通信渠道，而适用于任何已有或者未来可能出现的新的通信渠道。
46.此外，上述步骤302不限制上述第一客服会话请求的进线渠道，也即，对于从任意一个通信渠道进线的客服会话请求均可以执行上述步骤，因此，在上述步骤302中，将第一客服会话请求的进线渠道称为第一通信渠道以方便描述。
47.在步骤304，将第一客服会话请求加入第一通信渠道对应的客服会话请求队列。
48.在本公开的一些实施例中，可以直接按照第一客服会话请求的进线时间将上述第一客服会话请求加入第一通信渠道对应的客服会话请求队列，也即第一通信渠道对应的客服会话请求队列中的客服会话请求是按照客服会话请求的进线时间先后顺序排列的，这样，可以基本保障先进线的客服会话请求被先处理。在实际处理中，可以直接将第一客服会话请求加入第一通信渠道对应的客服会话请求队列的队尾。
49.在本公开的另一些实施例中，也可以先确定第一客服会话请求的优先级，然后，再根据所确定的优先级将第一客服会话请求加入第一通信渠道对应的客服会话请求队列。
50.具体地，在上述实施例中，客户服务中心可以根据上述第一客服会话请求的上下文信息以及存储的多渠道用户信息之一或其任意组合确定上述第一客服会话请求的优先级。
51.需要说明的是，无论用户选择从哪个通信渠道请求客服会话，客服系统都会在生成客服会话请求的同时获取发起当前客服会话的用户的用户标识以及发起当前客服会话的时间(也即进线时间)等与客服会话请求相关的信息，并以这些信息作为上述客服会话请求的上下文信息携带在客服会话请求中。如此，在本公开的实施例中，上述第一客服会话请求的上下文信息至少可以包括：发送所述第一客服会话请求的第一用户的用户标识以及所述第一客服会话请求的进线时间。进一步，在确定了上述第一客服会话请求的优先级之后，还可以将确定的优先级也携带在其上下文信息中，以便后续使用。
52.此外，如前所述，上述多渠道用户信息可以包括：用户的属性信息以及用户的历史客服信息等。
53.在本公开的实施例中，上述将第一客服会话请求加入第一通信渠道对应的客服会话请求队列的具体实现过程可如图4所示，包括：
54.在步骤402，根据上述第一客服会话请求的上下文信息中的第一用户的用户标识从存储的多渠道用户信息提取与所述第一用户的属性信息以及第一用户的历史客服信息。
55.在步骤404，从上述第一客服会话请求的上下文信息中获取第一客服会话请求的进线时间；
56.在步骤406，根据上述第一用户的属性信息以及上述第一用户的历史客服信息之一或其任意组合以及上述第一客服会话请求的进线时间确定所述第一客服会话请求的优先级。
57.在本公开的一些实施例中，可以预先设置确定客服会话请求的优先级所涉及的各项参数以及优先级的具体计算表达式。这样，在上述步骤406，可以先从上述第一客服会话请求的进线时间、上述第一用户的属性信息以及上述第一用户的历史客服信息中提取确定上述第一客服会话请求的优先级所涉及的各项参数的参数值；然后，根据所提取的各项参数值按照优先级的具体计算表达式计算得到上述第一客服会话请求的优先级。例如，可以对提取的各项参数的参数值进行加权求和，从而得到上述第一客服会话请求的优先级。
58.需要说明的是，由于上述第一用户的属性信息以及上述第一用户的历史客服信息是客户服务中心记录的多渠道用户信息，融合了各个通信渠道下的用户信息，因此，可以认为基于上述信息确定的第一客服会话请求的优先级是一个全局的优先级。而使用全局优先级对客服会话请求进行排序可以得到一个更为全面且准确的排序结果，进而使得客服会话请求的处理更为高效。
59.在步骤408，根据上述第一客服会话请求的优先级将所述第一客服会话请求加入所述第一通信渠道对应的客服会话请求队列。
60.在本公开的实施例中，在上述步骤中，可以按照上述第一客服会话请求的优先级将第一客服会话请求加入第一通信渠道对应的客服会话请求队列。也即，使第一客服会话请求前面的客服会话请求的优先级高于第一客服会话请求的优先级，而使第一客服会话请求后面的客服会话请求的优先级低于第一客服会话请求的优先级。也就是说，每个客服会话请求队列中从队头到队尾的客服会话请求是按照优先级从高到低的顺序排列的。通过这种按照优先级从高到低的顺序对客服会话请求进行排序，可以保证优先级高的客服会话请求会被优先处理，从而实现高效的客服会话请求处理。
61.在步骤306，从多个通信渠道对应的客服会话请求队列中提取待处理的第二客服会话请求。
62.在本公开的实施例中，由于客户服务中心可以根据自身的配置选择采用串行或者并行的方式处理客服会话请求，因此，从多个通信渠道对应的客服会话请求队列中提取待处理的第二客服会话请求的数量可以是一个也可以是多个。此外，对于如何从多个通信渠道对应的客服会话请求队列中提取待处理的第二客服会话请求本公开也给出了多种的实施方式。
63.例如，在本公开的一些实施例中，可以从所述多个通信渠道对应的客服会话请求队列中分别提取队头的客服会话请求，并将所提取多个客服会话请求均作为上述待处理的第二客服会话请求。可以看出，这种方式适用于对客户服务中心可以并行处理客服会话请
求的场景。
64.又例如，在本公开的另一些实施例中，可以先从所述多个通信渠道对应的客服会话请求队列中分别提取队头的客服会话请求；然后，从提取的多个客服会话请求中选择优先级最高的一个或者多个客服会话请求作为上述待处理的第二客服会话请求。可以看出，这种方式适用于对客服会话请求队列中的客服会话请求确定了优先级的场景。如前所述，上述第二客服会话请求的优先级可以从其上下文信息中提取获得。
65.除了上述客服会话请求的优先级之外，还可以根据各种通信渠道的响应时间要求进一步对客服会话请求队列设置优先级，并在实际提取客服会话请求时综合考虑客服会话请求队列的优先级以及客服会话请求自身的优先级，并选择其中优先级最高的一个或者多个客服会话请求作为上述待处理的第二客服会话请求。
66.本公开的实施例并不限制从多个通信渠道对应的客服会话请求队列中提取待处理的第二客服会话请求的具体方法，基本遵循先到先处理或者优先级高的优先处理的原则即可。
67.在步骤308，根据存储的多渠道坐席信息从多渠道坐席资源池中选择处理所述第二客服会话请求的目标坐席。
68.在本公开的实施例中，对于待处理的第二客服会话请求，客户服务中心可以根据存储的多渠道坐席信息，特别是多渠道坐席资源池中各个坐席的在各个通信渠道下的状态、在各个通信渠道下的坐席技能和各个坐席技能的技能等级等信息之一或其任意组合，从多渠道坐席资源池中选择处理所述第二客服会话请求的目标坐席。
69.具体地，客户服务中心可以根据多渠道坐席资源池中各个坐席的在各个通信渠道下的状态、在各个通信渠道下的坐席技能和各个坐席技能的技能等级等信息之一或其任意组合确定各个坐席与上述第二客服会话请求的匹配度，并从中选择与上述第二客服会话请求的匹配度最高的坐席作为上述目标坐席。在本公开的一些实施例中，在确定上述匹配度的过程中，可以预先设置确定上述匹配度所涉及的各项参数以及确定匹配度的表达式。这样，在上述步骤308，可以先从上述多渠道坐席信息中提取各个坐席对应的确定上述匹配度所涉及的各项参数的参数值；然后，根据各个坐席对应的各项参数值按照确定匹配度的表达式分别计算各个坐席与上述第二客服会话请求的匹配度。需要说明的是，由于上述各个坐席的在各个通信渠道下的状态、在各个通信渠道下的坐席技能和各个坐席技能的技能等级等信息是客户服务中心记录的多渠道坐席信息，融合了各个通信渠道下的各个坐席的信息，因此，可以认为基于上述信息确定的各个坐席与上述第二客服会话请求的匹配度是一个全局的匹配度。而使用全局匹配度选择处理所述第二客服会话请求的目标坐席基本可以为第二客服会话请求选择到一个最准确或者说最优的坐席，进而使得客服会话请求的处理更为准确，从而可以提升用户的体验。
70.需要说明的是，在本公开的另一些实施例中，上述在确定各个坐席与上述第二客服会话请求的匹配度时还可以参考存储的多渠道配置信息，特别是其中的多渠道融合/隔离配置信息。例如，在这些实施例中，客户服务中心将首先根据上述多渠道融合/隔离配置信息确定针对当前的第二客服会话请求是进行多渠道融合的坐席资源分配还是进行多渠道隔离的坐席资源分配。响应于确定针对当前的第二客服会话请求进行多渠道融合的坐席资源分配，客户服务中心可以根据多渠道坐席信息中各个坐席的在各个通信渠道下的状
态、各个通信渠道下的坐席技能和各个坐席技能的技能等级等信息之一或其任意组合确定各个坐席与上述第二客服会话请求的匹配度，并从中选择与上述第二客服会话请求的匹配度最高的坐席作为上述目标坐席。而响应于确定针对当前的第二客服会话请求进行多渠道隔离的坐席资源分配，客户服务中心可以根据多渠道坐席信息中各个坐席的在上述第二客服会话请求进线的第二通信渠道下的状态、在上述第二通信渠道下的坐席技能和技能等级等信息之一或其任意组合确定各个坐席与上述第二客服会话请求的匹配度，并从中选择与上述第二客服会话请求的匹配度最高的坐席作为上述目标坐席。
71.需要说明的是，在上述实施例中，上述多渠道融合/隔离配置信息也可以携带在第二客服会话请求的上下文信息中。这样，客户服务中心在提取了第二客服会话请求之后即可根据其上下文信息中的多渠道融合/隔离配置信息确定对其是进行多渠道融合的坐席资源分配还是进行多渠道隔离的坐席资源分配，而无需查找存储的多渠道配置信息，从而进一步提高客服会话请求的处理效率。
72.进一步，在选择了目标坐席之后，可以建立目标坐席以及第二客服会话请求所对应用户的之间通信连接，由上述目标坐席处理上述第二客服会话请求。
73.通过上述方法可以看出，通过收集并存储多渠道坐席信息以及多渠道用户信息可以利用多渠道融合后的信息将多个通信渠道的客服会话请求进行统一处理，从全局角度进行坐席资源的统一管理，实现了多渠道坐席资源的准确以及高效的分配。
74.下面通过两个具体的示例详细说明本公开实施例所述的客服会话请求处理方法的实现过程。
75.图5给出了本公开实施例中在多渠道融合的坐席资源分配的场景下客户服务中心对来自多个通信渠道的客服会话请求进行处理的一个示例。图6给出了本公开实施例中在多渠道隔离的坐席资源分配的场景下客户服务中心对来自多个通信渠道的客服会话请求进行处理的一个示例。在图5和图6中，用户1和用户4通过im渠道发出客服会话请求，因此用户1和用户4的客服会话请求被加入到im渠道对应的客服会话请求队列；用户2和用户5通过电话渠道发出客服会话请求，因此用户2和用户5的客服会话请求被加入到电话渠道对应的客服会话请求队列；用户3通过工单渠道发出客服会话请求，用户3的客服会话请求被加入到工单渠道对应的客服会话请求队列。
76.如图5所示，客户服务中心在为各个通信渠道对应的客服会话请求队列中的客服会话请求分配坐席资源的时候将以存储的多渠道坐席信息为数据支撑。也就是说，在对用户1-用户5的客服会话请求分配坐席资源时将综合考虑各个坐席资源在各个通信渠道下的状态、各个通信渠道下的坐席技能和各个坐席技能的技能等级等信息，实现全局的多渠道信息融合的坐席资源分配，使得坐席资源分配的结果更为准确和高效。此外，在将各个客服会话请求加入到相应的客服会话请求队列的过程中，客户服务中心也可以以存储的多渠道用户信息作为数据支撑，从而可以综合考虑用户的属性信息以及用户在各个通信渠道下的历史客服信息以确定客服会话请求的全局优先级，使得确定的客服会话请求的优先级更适用于多渠道融合的坐席资源分配场景，实现优先处理优先级高的客户会话请求的目的，提高用户的服务体验。
77.如图6所示，除了多渠道融合的坐席资源分配场景，客户服务中心在为各个通信渠道对应的客服会话请求队列中的客服会话请求分配坐席资源的时候，还可以根据客户服务
中心的分配规则配置或者用户的实际选择等条件选择进行多渠道隔离的坐席资源分配，也即客户服务中心进行坐席资源分配时可以只提取和考虑各个坐席在当前客服会话请求对应的通信渠道下的坐席信息，也即只提取单渠道坐席信息，而不考虑其他通信渠道下的坐席信息。也就是说，在对用户1和用户4的客服会话请求分配坐席资源时仅考虑各个坐席资源在im渠道下的状态、技能以及技能等级等信息；在对用户2和用户5的客服会话请求分配坐席资源时仅考虑各个坐席资源在电话渠道下的状态、技能以及技能等级等信息；而在对用户3的客服会话请求分配坐席资源时仅考虑各个坐席资源在工单渠道下的状态、技能以及技能等级等信息。这样的设置可以增加客户服务中心的灵活度，使客户服务中心可以适用更多以及更复杂的客户服务场景。此时，对于各个客服会话请求优先级的确定仍可以以存储的多渠道用户信息作为数据支撑，也即确定客服会话请求的全局优先级。作为替换方案，也可以选择以各自通信渠道下的用户信息作为优先级计算的数据基础，确定客服会话请求在各自通信渠道下的优先级。
78.除了上述实施方式之外，在本公开的又一些实施例中，在上述步骤308，除了上述多渠道坐席信息或进一步包括多渠道配置信息之外，客户服务中心还可以进一步根据存储的多渠道用户信息，特别是其中的用户的历史客服信息，从多渠道坐席资源池中选择处理所述第二客服会话请求的目标坐席。
79.在这种情况下，上述步骤308所述根据存储的多渠道坐席信息从多渠道坐席资源池中选择处理所述第二客服会话请求的目标坐席则可以如图7所示，包括：
80.在步骤702，获取发送上述第二客服会话请求的第二用户的多渠道用户信息中的第二用户的历史客服信息。
81.如前所述，在本公开的实施例中，上述用户的历史客服信息可以包括：用户在各个通信渠道下的上一负责坐席以及用户对坐席的满意度。
82.在步骤704，根据多渠道坐席信息以及上述第二用户的历史客服信息确定多渠道坐席资源池中各个坐席与上述第二客服会话请求的匹配度。
83.具体地，客户服务中心可以根据多渠道坐席资源池中各个坐席的在各个通信渠道下的状态、在各个通信渠道下的坐席技能和各个坐席技能的技能等级等信息之一或其任意组合以及第二用户的多渠道用户信息中的用户的历史客服信息确定各个坐席与上述第二客服会话请求的匹配度。在本例中，可以在上述确定匹配度的表达式中加入历史客服信息中的至少一个参数。如此，确定的匹配度将与上述第二用户的历史客服信息有关。
84.下面结合具体的示例详细说明进一步根据存储的多渠道用户信息中的用户的历史客服信息从多渠道坐席资源池中选择处理所述第二客服会话请求的目标坐席的方法。
85.以历史客服信息包括用户在各个通信渠道下的上一负责坐席为例，由于用户的上一负责坐席与其他坐席相比具有较高的概率更加了解用户的诉求，可以更加快速地帮用户解决问题，从而可以给用户带来更好的体验，因此，原则上可以为用户的客服会话请求优先分配其上一负责坐席。为了实现上述目标，可以在确定匹配度的表达式中加入上一负责坐席参数，并为其分配一个权重。具体地，在多渠道融合的坐席资源分配的场景下，可以先获取第二用户在各个通信渠道下的上一负责坐席，将这些坐席对应的上一负责坐席参数的参数值设置为1，其他坐席对应的上一负责坐席参数的参数值设置为0，从而使得第二用户在各个通信渠道下的上一负责坐席与其他坐席相比具有额外的“加分项”。此外，各个通信渠
道下的上一负责坐席之间相比，还可以为第二通信渠道下的上一负责坐席分配一个更大的权重，从而可以实现相同通信渠道的上一负责坐席与其他通信渠道的上一负责坐席相比加分更多。而在多渠道隔离的坐席资源分配的场景下，可以先获取第二用户在第二通信渠道下的上一负责坐席，将这一坐席对应的上一负责坐席参数的参数值设置为1，其他坐席对应的上一负责坐席参数的参数值设置为0，从而使得第二通信渠道下的上一负责坐席与其他坐席相比具有额外的“加分项”。可以看出，在将上一负责坐席参数融合到坐席资源分配过程中时，用户在多渠道下咨询仍然优先被分配最熟悉的坐席，问题解决效率高，坐席分配更精准。
86.再以历史客服信息包括用户对坐席的满意度为例，本着“好评靠前，差评靠后”的原则，可以为用户的客服会话请求优先分配其满意度较高的坐席或者尽量不为其分配满意度较差的坐席，从而可以给用户带来更好的体验。为了实现这一目标，可以在确定匹配度的表达式中加入满意度参数，并为其分配一个权重。具体地，在多渠道融合的坐席资源分配的场景下，可以先获取第二用户对各个坐席的满意度，并将满意度高的参数值设置为正数，满意度一般的参数值设置为0，而将满意度低的参数值设置为负数，从而使得满意度较高的坐席与其他坐席相比具有额外的“加分项”。在多渠道隔离的坐席资源分配的场景下，可以先获取第二用户在第二通信渠道下对各个坐席的满意度，从而使得在第二通信渠道下满意度较高的坐席与其他坐席相比具有额外的“加分项”。可以看出，在将用户对坐席的满意度参数融合到坐席资源分配过程中时，用户在多渠道下咨询将会是最满意的坐席，问题解决效率高，坐席分配更精准。
87.在步骤706，从多渠道坐席资源池中选择与上述第二客服会话请求的匹配度最高的坐席作为上述目标坐席。
88.下面通过两个具体的示例详细说明本公开实施例所述的在结合了历史客服信息的基础上客服会话请求处理方法的实现过程。
89.图8给出了本公开实施例中客户服务中心进一步根据上一负责坐席信息对来自多个通信渠道的客服会话请求进行处理的一个示例。图9给出了本公开实施例中客户服务中心进一步根据上一负责坐席信息对来自多个通信渠道的客服会话请求进行处理的另一个示例。其中，图8对应于多渠道融合坐席资源分配场景，而图9对应于多渠道隔离坐席资源分配场景。具体的，在图8中，客户服务中心在对从电话渠道进线的客服会话请求1进行坐席资源分配时，将首先获取发出客服会话请求1的用户1的历史客服消息中记录的各个通信渠道下的上一负责坐席。可见，用户1的历史客服消息中记录了用户1在电话渠道下的上一负责坐席为空，在im渠道下的上一负责坐席为坐席2。则在计算各个坐席与客服会话请求1的匹配度时，坐席2将具有上一负责坐席这一参数加分项，从而更有可能被分配给客服会话请求1。相应地，在图9中，客户服务中心在对从电话渠道进线的客服会话请求1进行坐席资源分配时，将首先获取发出客服会话请求1的用户1的历史客服消息中记录的在电话渠道下的上一负责坐席。可见，用户1的历史客服消息中记录了用户1在电话渠道下的上一负责坐席为坐席3。则在计算各个坐席与客服会话请求1的匹配度时，坐席3将具有上一负责坐席这一参数加分项，从而更有可能被分配给客服会话请求1。
90.图10给出了本公开实施例中客户服务中心进一步根据满意度信息对来自多个通信渠道的客服会话请求进行处理的一个示例。图11给出了本公开实施例中客户服务中心进
一步根据满意度信息对来自多个通信渠道的客服会话请求进行处理的另一个示例。其中，图10对应于多渠道融合坐席资源分配场景，而图11对应于多渠道隔离坐席资源分配场景。具体的，在图10中，客户服务中心在对从电话渠道进线的客服会话请求1进行坐席资源分配时，将首先获取发出客服会话请求1的用户1的历史客服消息中记录的各个通信渠道下的对各个坐席的满意度，也即多渠道下的满意度信息。可见，用户1的历史客服消息中记录了用户1在电话渠道下的对坐席1的满意度是8，对坐席2的满意度是2；在im渠道下，对坐席3的满意度是10。则在计算各个坐席与客服会话请求1的匹配度时，坐席1和坐席3将具有满意度这一参数的加分项，且坐席3的加分更多，而坐席2将具有满意度这一参数的减分项，从而坐席3更有可能被分配给客服会话请求1。相应地，在图11中，客户服务中心在对从电话渠道进线的客服会话请求1进行坐席资源分配时，将首先获取发出客服会话请求1的用户1的历史客服消息中记录的在电话渠道下的对各个坐席的满意度，也即单渠道下的满意度信息。可见，用户1在电话渠道下的对坐席1的满意度是8，对坐席2的满意度是2。由于坐席3的满意度是在im渠道下产生的，因此，图11所示场景下并不会提取用户1对坐席3在im渠道下的满意度。则在计算各个坐席与客服会话请求1的匹配度时，坐席1具有满意度这一参数的加分项，坐席2将具有满意度这一参数的减分项，且坐席3既不加分也不减分，从而坐席2更有可能被分配给客服会话请求1。
91.如此可以看出，在上述坐席资源分配过程中，除了考虑多渠道坐席信息还考虑了多渠道用户信息，特别是多渠道的用户的历史客服信息，从而可以为用户优先分配其最熟悉或者最满意的坐席，使得坐席资源的分配更为准确，提高了解决问题的效率，进一步提升了用户体验。
92.需要说明的是，本公开实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本公开实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。
93.需要说明的是，上述对本公开的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
94.对应上述方法，本公开的实施例还公开了一种客服会话请求处理装置。图12显示了本公开实施例所述的装置的内部结构。如图12所示，该装置可以包括：
95.客服会话请求接收模块1202，用于从第一通信渠道接收第一客服会话请求；
96.请求入队模块1204，用于将所述第一客服会话请求加入所述第一通信渠道对应的客服会话请求队列；
97.请求提取模块1206，用于从多个通信渠道对应的客服会话请求队列中提取待处理的第二客服会话请求；以及
98.坐席资源分配模块1208，用于根据存储的多渠道坐席信息从多渠道坐席资源池中选择处理所述第二客服会话请求的目标坐席。
99.在本公开的一些实施例中，上述请求入队模块1204可以包括：
100.优先级确定单元，用于根据所述第一客服会话请求的上下文信息以及存储的多渠道用户信息确定所述第一客服会话请求的优先级；以及
101.请求入队单元，用于根据所述第一客服会话请求的优先级将所述第一客服会话请求加入所述第一通信渠道对应的客服会话请求队列。
102.在本公开的一些实施例中，上述坐席资源分配模块1208可以包括：
103.第一匹配度确定单元，用于根据存储的多渠道坐席资源池中各个坐席的在各个通信渠道下的状态、在各个通信渠道下的坐席技能和各个坐席技能的技能等级等信息之一或其任意组合确定所述各个坐席与所述第二客服会话请求的匹配度；
104.选择单元，用于从所述多渠道坐席资源池中选择与所述第二客服会话请求的匹配度最高的坐席作为所述目标坐席。
105.在本公开的另一些实施例中，上述坐席资源分配模块1208可以包括：
106.多渠道配置信息判断单元，用于根据多渠道配置信息确定针对所述第二客服会话请求是进行多渠道融合的坐席资源分配还是进行多渠道隔离的坐席资源分配；
107.第二匹配度确定单元，用于响应于确定针对所述第二客服会话请求进行多渠道融合的坐席资源分配，根据存储的多渠道坐席资源池中各个坐席的在各个通信渠道下的状态、在各个通信渠道下的坐席技能和各个坐席技能的技能等级等信息之一或其任意组合确定所述各个坐席与所述第二客服会话请求的匹配度；以及响应于确定针对所述第二客服会话请求进行多渠道隔离的坐席资源分配，根据存储的多渠道坐席资源池中各个坐席的在所述第二客服会话请求进线的第二通信渠道下的状态、在所述第二通信渠道下的坐席技能和技能等级等信息之一或其任意组合确定所述各个坐席与所述第二客服会话请求的匹配度；
108.选择单元，用于从所述多渠道坐席资源池中选择与所述第二客服会话请求的匹配度最高的坐席作为所述目标坐席。
109.在本公开的又一些实施例中，上述坐席资源分配模块1208可以包括：
110.历史客服消息获取单元，用于获取发送所述第二客服会话请求的第二用户的多渠道用户信息中的历史客服信息；
111.第三匹配度确定单元，用于根据存储的多渠道坐席资源池中各个坐席的在各个通信渠道下的状态、在各个通信渠道下的坐席技能和各个坐席技能的技能等级等信息之一或其任意组合以及所述历史客服信息确定所述各个坐席与所述第二客服会话请求的匹配度；
112.选择单元，用于从所述多渠道坐席资源池中选择与所述第二客服会话请求的匹配度最高的坐席作为所述目标坐席。
113.上述各个模块的具体实现可以参考前述方法以及附图，在此不再重复说明。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本公开时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
114.上述实施例的装置用于实现前述任一实施例中相应的客服会话请求处理方法，并且具有相应的方法实施例的有益效果，在此不再赘述。
115.基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的客服会话请求处理方法。
116.图13示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备
可以包括：处理器2010、存储器2020、输入/输出接口2030、通信接口2040和总线2050。其中处理器2010、存储器2020、输入/输出接口2030和通信接口2040通过总线2050实现彼此之间在设备内部的通信连接。
117.处理器2010可以采用通用的cpu(central processing unit，中央处理器)、微处理器、应用专用集成电路(application specific integrated circuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
118.存储器2020可以采用rom(read only memory，只读存储器)、ram(random access memory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器2020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器2020中，并由处理器2010来调用执行。
119.输入/输出接口2030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
120.通信接口2040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。
121.总线2050包括一通路，在设备的各个组件(例如处理器2010、存储器2020、输入/输出接口2030和通信接口2040)之间传输信息。
122.需要说明的是，尽管上述设备仅示出了处理器2010、存储器2020、输入/输出接口2030、通信接口2040以及总线2050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
123.上述实施例的电子设备用于实现前述任一实施例中相应的客服会话请求处理方法，并且具有相应的方法实施例的有益效果，在此不再赘述。
124.基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的客服会话请求处理方法。
125.本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。
126.上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的任务处理方法，并且具有相应的方法实施例的有益效果，在此不再赘述。
127.所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非
旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本公开实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。
128.另外，为简化说明和讨论，并且为了不会使本公开实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(ic)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本公开实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本公开实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本公开实施例。因此，这些描述应被认为是说明性的而不是限制性的。
129.尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态ram(dram))可以使用所讨论的实施例。
130.本公开实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本公开实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。