CN112070518B - 一种客服提供方法和系统 - Google Patents

Abstract

本说明书涉及一种客服提供方法和系统，其包括：接收用户的客服请求，将客服请求对应的客服模式作为用户初始选择的客服模式；获取用户的用户特征数据，以及两种或以上客服模式的负载信息；基于所述用户特征数据、用户初始选择的客服模式以及各客服模式的负载信息，确定各客服模式对应的服务评估值；基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式；通过所述目标客服模式向用户提供的客服。本申请基于各客服模式对应的服务评估值，均衡分配各客服模式对应的用户数量，并同时满足不同用户对不同客服渠道的各异性需求，最大限度地提升用户的客服体验。

Description

一种客服提供方法和系统

技术领域

本申请涉及计算机通信技术领域，特别涉及一种客服提供方法和系统。

背景技术

现如今，随着人们对于高品质生活的追求，对客服（客户服务）质量的要求也越来越高。为满足不同用户的需求，服务平台往往开通了多种客服模式的客户服务专线。例如，某服务平台可以同时设立电话人工客服和应用软件人工客服两种客服模式以进行客户服务。然而，服务平台的客服承接能力是有限的，当过多的用户同时涌入某一客服模式时（如同时打电话进入电话人工客服模式），则会出现长时间的排队等待，影响用户的服务体验。

因此，有必要设计一种客服提供方法和系统，以将用户转移至其他优选的客服模式，提升用户的服务体验。

发明内容

本申请的一个方面提供一种客服提供方法，其包括：接收用户的客服请求，将客服请求对应的客服模式作为用户初始选择的客服模式；获取用户的用户特征数据，以及两种或以上客服模式的负载信息；基于所述用户特征数据、用户初始选择的客服模式以及各客服模式的负载信息，确定各客服模式对应的服务评估值；基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式；通过所述目标客服模式向用户提供的客服。

本申请的另一个方面提供一种客服提供系统，其包括：客服请求接收模块，用于接收用户的客服请求，将客服请求对应的客服模式作为用户初始选择的客服模式；数据获取模块，用于获取用户的用户特征数据，以及两种或以上客服模式的负载信息；服务评估值确定模块，用于基于所述用户特征数据、用户初始选择的客服模式以及各客服模式的负载信息，确定各客服模式对应的服务评估值；目标客服模式选择模块，用于基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式；客服提供模块，用于通过所述目标客服模式向用户提供的客服。

本申请的另一个方面还提供一种客服提供装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现所述客服提供方法。

附图说明

本申请将以示例性实施例的方式进一步描述，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本申请的一些实施例所示的客服提供方法的应用场景图；

图2是根据本申请的一些实施例所示的客服提供方法的示例性流程图；

图3是根据本申请的一些实施例所示的确定客服模式对应服务评估值的示例性流程图；

图4是根据本申请一些实施例所示的一种客服提供系统的示例性系统框图；

图5是根据本申请一些实施例所示的与缺口值相关的负载函数曲线示意图；

图6是根据本申请另一些实施例所示的与实际接入的用户数量相关的负载函数曲线示意图。

具体实施方式

为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

应当理解，本申请中所使用的“系统”、“装置”、“单元”和/或“模组”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

当前，各大服务平台都配备有自己的客服系统以及客服团队，以提供与自身产品相匹配的咨询、售前、售后等服务。客服的主要目的是完善对用户的服务。在用户使用产品的过程中，难免会出现各种各样的问题，提供一个好的客服可以有效的帮助用户解决相应问题，提高用户体验，最终获得更多的用户。

在一些实施例中，平台提供的客服可以通过电话的方式进行。如用户通过电话号码直接呼叫平台的客服系统，寻求客服系统的帮助。基于电话的客服系统能够提供质量更高的服务，因为该种形式保证了一个用户在咨询问题的过程中，有一个专有客服人员提供服务，服务质量得到了保证。然而，采用这种方式，一个客服人员无法同时服务多个用户，客服人员与用户只能以一对一的形式进行沟通，因此所需的客服人员较多。

在一些实施例中，平台提供的客服还可以通过应用程序（如APP）以即时聊天窗口的方式进行。如，用户可以在客服系统的聊天窗口中输入需要咨询的文本信息，寻求客服系统帮助。这种方式进行客服通常在入口处会带入用户信息，比如用户的订单、咨询的产品等，这种形式一定程度上减少了用户描述问题的耗时，提升了用户体验，且一个客服人员可以同时服务多个用户。例如，一些大型电商平台多采用该种形式提供咨询服务。

进一步地，为减少成本，提高客服效率，还可以使用机器人减少或者替代客服人员，采用大规模知识处理、自动问答系统等技术实现用户问题的自助回答。

在一些实施例中，平台提供的客服可以是以上客服模式的任意组合。例如，提供客服的客服模式可以包括电话渠道和应用程序渠道。进一步的，不同的服务渠道中由不同类型的服务提供者进行服务。例如，可以是由人工服务，也可以是由机器人进行服务。在该场景的实施例中，用户可以根据喜好选择相对应的服务渠道和服务提供者类型。

然而，不同的客服模式由于其承接能力和拥堵时段不同，在不同时间段内的拥堵程度不一样。在一些具体的实施场景中，平台的某一客服模式（如电话渠道人工服务）爆满，用户排队时间很长；而另一客服模式（如应用程序端人工客服）处于空闲状态。这不仅造成了客服资源的浪费，也影响了用户的客服体验。

为解决上述问题，在一些实施例中，可以根据实时情况，将处于繁忙状态客服模式的用户分流到较为空闲的客服模式，能够减少用户等待时间，提升用户体验和满意度。然而，对于不同的人，不同的问题，不同的时间，用户对切换另一客服渠道的接受度不同。例如，某用户年龄较大，其操作应用软件并不熟练，因此更倾向于使用电话渠道的客服。此时，若将该用户转至应用程序渠道的客服时，会极大影响该用户的用户体验。因此，如何根据实际情况，将用户分配到合适的客服模式，是需要精心设计的调度问题。

在本说明书涉及的一个或多个实施例中，可以通过用户的特征数据以及客服模式的闲忙程度等信息，确定各客服模式对应的服务评估值。进一步地，基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式，以向用户提供客服。采用这种方式，不仅可以均衡分配各客服模式对应的用户数量，避免少数客服连续处于接待量大的状态而导致接待质量降低的情况；也可以基于不同用户对不同客服渠道的各异性需求，最大限度地提升用户的客服体验。需要说明的是，服务平台所提供的客服模式并不局限于前文列举的内容，随着互联网技术的发展，相信还会有更多全新的客服模式出现，本说明书旨在提供不同客服模式的选择决策方案，不应将客服模式的类别作为本说明书内容的限制。

图1是根据本申请的一些实施例所示的客服提供方法的应用场景图。

如图1所示，该应用场景中应用客服提供方法的系统100包括用户终端110、服务端120以及网络130。

在一些实施例中，用户可以通过用户终端110发起客服请求。例如，用户可以通过用户终端110以电话、网络电话的方式发起客服请求。在一些实施例中，用户终端110可以是部署有应用程序（如APP、小程序等）的设备。例如，用户可通过用户终端110上的应用程序发起客服请求。

在一些实施例中，用户终端110可以包括但不限于移动设备110-1、平板电脑110-2、笔记本电脑110-3等或其任意组合。在一些实施例中，移动设备可以包括但不限于智能家居设备、可穿戴设备、智能移动设备、增强现实设备等或其任意组合。在一些实施例中，可穿戴设备可以包括智能手镯、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣物、智能背包、智能配饰等或其任意组合。

服务端120可以是部署有服务平台后端的服务器。服务平台可以是线上的购物平台、支付平台、信息查询平台、金融理财平台等能够提供任意类型服务的平台。所述服务端120还部署有客服系统，以针对用户终端110发起的客服请求（如服务使用过程中的疑问或者咨询等）进行处理。在一些实施例中，客服提供者可以是客服人员（如人工在线应答或者人工电话应答），也可以是客服机器人（如在线应答机器人、APP应答机器人、电话对话机器人等）。

在一些实施例中，服务端120可以包含一个或多个子处理设备(如：单核处理器或多核处理器)。仅仅作为范例，在一些实施例中，服务端120可以包括处理设备120-1。处理设备120-1可包括但不限于中央处理器(CPU)、专用集成电路(ASIC)、专用指令处理器(ASIP)、图形处理器(GPU)、物理处理器(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编辑逻辑电路(PLD)、控制器、微控制器单元、精简指令集电脑(RISC)、微处理器等或以上任意组合。在一些实施例中，处理设备120-1可以根据用户的特征数据以及客服模式的闲忙程度等信息，确定各客服模式对应的服务评估值。进一步地，基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式，以向用户提供客服。有关服务器120确定目标客服模式的相关描述可参见图2的相应描述，此处不再赘述。

在一些实施例中，服务器120还包括存储设备120-2可以存储处理设备120-1执行使用的数据和/或指令，处理设备120-1可以通过执行或使用所述数据和/或指令以实现本说明书中的示例性方法。例如，存储设备120-2可以用于存储将客服请求进行处理的相关指令。又例如，存储设备可以存储用户的特征数据，或者存储在完成各类信息处理时所用到的机器学习模型参数及训练样本。在一些实施例中，存储设备120-2可包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器（ROM）等或其任意组合。

网络130可以促进信息和/或数据的交换。在一些实施例中，服务器120可以通过网络130与用户终端110相连。网络可以包括但不限于局域网、广域网、公用网络、专用网络、无线局域网、虚拟网络、都市城域网、公用交换电话网络等中的一种或几种的组合。网络可以包括多种网络接入点，如有线或无线接入点、基站或网络交换点，通过以上接入点使数据源连接网络并通过网络发送信息。

图2是根据本申请的一些实施例所示的客服提供方法的示例性流程图；如图2所示，客服提供处理流程200可以在具有处理能力的设备（如服务器120，或者处理设备120-1）中执行，具体的，流程200可以包括：

步骤210，接收用户的客服请求，将客服请求对应的客服模式作为用户初始选择的客服模式。

具体地，步骤210可以由客服请求接收模块410执行。

客服请求是指用户端发出的请求客服提供系统（如服务端120）提供客户服务的指令。在一些实施例中，用户可以通过用户终端110发出客服请求，以要求客服提供系统（如服务端120）提供客户服务。

在一些实施例中，用户可以通过不同的服务渠道（如APP、电话等）提出客服请求，也可以在提出客服请求时要求服务提供者类型（如要求人工服务、智能机器人服务等）。换言之，客服请求接收模块410所接收到的客服请求可以是多样的，其可以来自于不同的服务渠道，也可以要求不同的服务提供类型。

在本申请的一个或多个实施例中，可以用客服模式统一指代服务渠道类型以及服务提供者类型。其中，不同的客服模式可以是服务渠道类型不同，也可以是服务提供者类型不同，也可以是两者均不相同。可以理解，不同的客服模式对应于服务渠道类型与服务提供者类型不同的组合。

以图2进行示例性说明，图中，服务渠道类型可以包括应用程序渠道和电话渠道，服务提供者类型包括人工和机器人两种。此时，客服模式共有四种组合，分别为电话自助、电话人工、程序端自助、程序端人工。在该场景的实施例中，客服请求可以是来自于电话渠道并要求人工客服的（即用户初始选择的客服模式对应于电话人工），也可以是来自于应用软件渠道并要求机器人客服的（即用户初始选择的客服模式对应于程序自助）。

步骤220，获取用户的用户特征数据，以及两种或以上客服模式的负载信息。

具体地，步骤220可以由数据获取模块420执行。

在一些实施例中，数据获取模块420可以获取用户的用户特征数据。在一些实施例中，数据获取模块420可以基于用户的服务请求，获取服务平台内存储的有关于用户的特征数据。例如，用户通过电话渠道提出服务请求，可以基于用户的电话号码获取相对应的特征数据。又例如，用户通过应用程序渠道提出服务请求，可以基于用户的账号ID获取相对应的特征数据。

用户的用户特征数据可以反映用户的个人属性。具体地，用户的特征数据可以是用户的基本情况信息，如可以包括但不限于用户的性别、年龄、所在地、职业等。又例如，用户的特征数据也可以是用户的一些喜好信息，如用户的偏好等。

在一些实施例中，用户的用户特征数据也可以包括用户的历史行为轨迹信息，其可以包括但不限于在过去的一段历史时间（过去一周、三个月或一年等等）内：用户开通了什么功能、向客服咨询的什么问题、购买了什么商品或做了什么评价等。

进一步地，用户的用户特征数据也可以包括客服请求意图。客服请求意图是指本次用户要求客服进行服务的目的是什么。在一些实施例中，客服请求意图可以是已经被分类好的客服请求意图分类，由用户发起客服请求之前进行勾选。例如，客服请求意图可以分类为“服务投诉”、“账号丢失”、“退款问题”、“账号锁定”等不同的分类。在一些实施例中，客服请求意图也可以是用户简述问题的文字或者是语音。此时，数据获取模块420可以通过机器学习算法（如语义分析模型）等方式基于文字或者是语音提取关键词，进而对客服请求意图进行分类。在一些实施例中，语义分析模型可以包括但不限于Word Embedding模型、BiLSTM模型、Word2vec模型等。

在一些实施例中，数据获取模块420还可以获取两种或以上客服模式的负载信息。在一些实施例中，数据获取模块420可以获得所有客服模式对应的负载信息（如图2中全部4种客服模式对应的负载信息）。在一些替代性实施例中，数据获取模块420也可以仅获得部分客服模式（如图2中任意两种及以上客服模式）对应的负载信息。

客服模式的负载信息用于反映客服模式对应的闲忙程度，其具体与该客服模式对应的可承接访客量与预计访客量的差值相关。

可承接访客量指的是客服模式对应的可接受的用户数量上限。例如，以电话人工这一客户模式进行示例性说明。假定共有100个接话员（即人工客服）进行电话人工客户服务，每小时每个接话员可服务的用户平均为10个，那么1小时内电话人工这一客户模式可承接访客量即为1000个。在一些实施例中，对于机器人客服（如电话自助客服），由于自助客服采用的是机器人进行，其可承接访客量取决于服务器同一时间可承接的用户数量。在一些具体计算场景中，可以将机器人客服可承接访客量视为没有上限。

预计访客量是指客服模式下一时段（如下一小时）预计的用户数量。在一些实施例中，数据获取模块420可以通过统计的方法获得客服模式对应的预计访客量。例如，数据获取模块420要预计电话人工这一客服模式对应的早上8~9点之间的预计访客量，可以统计某一段历史时间（如过去7天内）早上8~9点之间的电话人工这一客服模式对应的多个历史访客量，取其均值作为的此次计算的预计访客量。

需要说明的是，以上实施例仅作为参考，并不作为对本申请的限制。例如，统计的时间可以是如3天、5天、1个月等时间任意地设置。又例如，参与计算的历史访客量可以是具体设置的，如可以是不同天的不同时段对应的访客量（如不同天早上5~6点的访客量），亦或是相同天的不同时段对应的访客量。再例如，预计访客量预测时采用的统计方法可以是平均、加权平均、截尾平均、条件平均等统计计算方法。类似这样的变换，依然在本申请的保护范围内。

在一些实施例中，数据获取模块420还可以基于访客量预测模型处理历史访客量从而获取客服模式对应的预计访客量。其中，访客量预测模型包括机器学习模型。具体地，访客量预测模型可以是RNN网络或者是LSTM网络。由于某一时刻的预计访客量的波动往往跟之前的访客量蕴含某种联系，因此采用RNN网络和LSTM网络可以提取历史访客量中的关系，从而可以获得更加准确的预测模型。

下面，以访客量预测模型为RNN网络为例说明访客量预测模型的训练过程。在预计访客量这个实施场景下，模型的输入可以是在先时刻的序列化历史访客量，训练标签值可以是在后时刻的历史访客量。具体的，可以将时刻t-6、t-5、t-4、t-3、t-2、t-1对应的历史访客量组成的序列化历史访客量作为模型输入，将t时刻对应的历史访客量或者从t时刻到t+1时刻对应的历史访客量作为训练样本的标签值，以此类推得到训练样本集。进一步地，基于训练样本集训练访客量预测模型，并以模型输出得到的在后时刻或时段对应预测值与标签值构建模型损失函数，多次迭代训练即可得到训练好的访客量预测模型。在一些其他实施例中，数据获取模块420可以通过客服模式的不同，分别训练不同的访客量预测模型，以使得训练得到的模型与实际情况更加吻合。

在获得可承接访客量与预计访客量后，数据获取模块420可以基于此计算客服模式对应的访问量缺口值。在本申请得到一些实施例中，访问量缺口值即为可承接访客量与预计访客量的差值。缺口值为正，说明其对应的预计访客量不多，存在客服资源的“富余”；缺口值为负，说明客服模式服务的预计访客量较多，客服资源比较“紧张”。

进一步地，数据获取模块420可以基于访问量缺口值计算各个客服模式的负载信息。

在一些实施例中，客服模式的负载信息可以设置为与该客服模式对应的访问量缺口值负相关。例如，某客服模式的访问量缺口值为正，且越大，则对应的负载信息越小，服务的用户数不足。又例如，某客服模式的访问量缺口值为负，且越小，则对应的负载信息越大，服务的用户数较多。

在一些实施例中，客服模式的负载信息可以为该客服模式对应的访问量缺口值的其他形式的函数表征。在该场景中，客服模式的负载信息可以理解为访问量缺口值的评分，当访问量缺口值不同时，可以有不同的负载信息（不同的评分）。有关客服模式的负载信息函数表征的更多说明可参见步骤320的相关说明，在此不再赘述。

步骤230，确定各客服模式对应的服务评估值。

具体地，步骤230可以由服务评估值确定模块430执行。

在一些实施例中，服务评估值确定模块430可以基于用户初始选择的客服模式以及步骤220中获得的用户特征数据、各客服模式的负载信息，确定各客服模式对应的服务评估值。

服务评估值指的是用户对各客服模式的综合评价结果，其可以综合反映用户对不同客服模式的接受程度、用户对于从初始选择的客服模式切换至另一客服模式的接受程度以及不同客户模式的处理能力。可以理解，不同的用户由于行为习惯、接收能力以及经历的不同，对于不同的客服模式的认可程度和接受程度不一样。因此，对于不同的用户，其对各客服模式对应的服务评估值是不一致的。例如，对于某些用户，其曾经在应用程序端客服有过不满的经历，这一部分用户对于应用程序端的服务评估值相应较低。又例如，对于一些比较敏感的问题来说（如“密码被盗”一类），采用人工客服的方法或许让用户从心理层面上觉得更安全，这一部分用户对于人工客服的服务评估值较高。

具体地，各客服模式对应的服务评估值可以由图3所示的流程300进行实现，在此不再赘述。

步骤240，基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式。

具体地，步骤240可以由目标客服模式选择模块440执行。

目标客服模式选择模块440可以基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式。示例性的，目标客服模式选择模块440可以选取服务评估值最大的客服模式作为目标客服模式。

步骤250，通过所述目标客服模式向用户提供的客服。

具体地，步骤250可以由客服提供模块450执行。

客服提供模块450可以基于选择出的目标客服模式对用户进行服务。例如，用户初始选择的客服模式为电话人工，经过以上步骤处理后，所得的目标客服模式为程序端人工，此时，即将用户由最初选择的电话人工客服模式切换至程序端自助，以提高用户的客服体验。

需要说明的是，以上步骤210~250是以图2为例进行示例性的说明。在本申请的一些实施例中，服务渠道类型可以有多个（如3个、4个、5个等），并且服务渠道类型还可以有多种设计（如可以是远程视频渠道、网络电话渠道等）。在一些实施例中，服务提供者类型也可以不仅限于人工和机器人的分类。例如，服务提供者类型还可以包括远程视频处理、人工上门服务等。因此，客服模式也不仅仅只限于图2中所示的4中客服模式，客服模式可以是以上服务渠道类型以及服务提供者类型的任意组合。类似这样的变化，依然可以执行与步骤210~250类似的流程，在此不再赘述。

图3是根据本申请的一些实施例所示的确定客服模式对应服务评估值的示例性流程图；如图3所示，确定服务评估值的处理流程300可以在具有处理能力的设备（如服务器120或处理设备120-1）中执行，具体的，流程300可以由服务评估值确定模块430执行。对于任意一种前述提到的客服模式，均可以执行流程300的相应步骤，得到其服务评估值。具体地，确定服务评估值的处理流程300可以包括：

步骤310，基于用户特征数据与该客服模式，确定用户满意度预测值。

在一些实施例中，服务评估值确定模块430可以基于所获得的用户特征数据以及客服模式，确定用户对客服模式的满意程度。具体地，用户满意度的预测值可以基于一个用户满意度预测模型获取。在一些实施例中，用户满意度预测模型可以是一个机器学习模型。

该用户满意度预测模型可以通过以下方式训练：

获取训练样本，所述训练样本由用户特征数据以及客服模式构成，训练的标签可以为是否满意解决（如满意为1，不满意为0）或者是满意度的评分（如0~100分）。

其中，用户特征数据至少反映样本用户的个人属性信息（如包括性别、年龄、偏好等）、历史行为轨迹以及客服请求意图。其中，历史行为轨迹反映用户在平台内的历史操作行为信息；客服请求意图反映用户的诉求。关于用户特征数据的更多信息可以在图2的相关说明中找到。

进一步地，将训练样本中的用户特征数据以及客服模式作为用户满意度预测模型的输入，调整用户满意度预测模型的参数，使得用户满意度预测模型输出的该训练样本的预测值与训练样本的标签差异最小化。具体地，在对用户满意度预测模型进行训练过程中，可以利用梯度反向传递调节用户满意度预测模型的参数。

基于上述训练好的用户满意度预测模型，可以得到用户满意度预测值。在本申请的一个和多个实施例中，用字母E表示用户满意度预测值，其具体可以由下式进行表示：

（1）

式（1）中，E表示用户满意度预测值；u表示用户的相关数据，包括用户个人特征、历史行为轨迹、客服请求意图等；

表示用户对应的服务渠道；

表示用户对应的服务提供者类型；

表示用户满意度预测模型。

在如图2所示的实施场景中，可以用

表示服务渠道（0是电话服务渠道，1是程序服务渠道）；用

表示服务提供者类型（其中，0表示机器人服务，1表示人工服务）。以电话人工这一客服模式为例，此时，这一客服模式对应的用户满意度预测值为，

。

步骤320，确定当该客服模式作为目标客服模式时各客服模式的更新负载信息。

在一些实施例中，服务评估值确定模块430可以确定当某客服模式作为目标客服模式时各客服模式的更新负载信息。客服模式的负载信息可以反映该客服模式对应的可承接访客量与预计访客量的差值（也可以理解客服模式对应的缺口值）。显然，当上述差值为正（即客服模式对应的缺口值为正），说明该客服模式仍有可接待的余量。当上述差值为负（即客服模式对应的缺口值为负），说明该客服模式用户过多，需要排队等候。

在一些实施例中，客服模式的负载信息可以是与客服模式对应的缺口值相关的函数（或称为负载函数）。负载信息可以理解为与缺口值（可承接访客量与预计访客量的差值）相关的评分值，缺口值为正，评分高；缺口值为负，评分低。在一些实施例中，当缺口值为正，且大于预设阈值时，表明该客服模式的客服资源过于闲置，不能充分利用，此时评分可以降低。基于此，可以示例性的将所述负载函数设置为以y轴为中心轴的准正太分布曲线函数，可参见图5。在一些实施例中，可以将 y轴左侧曲线斜率设置为大于右侧曲线的斜率。在一些具体计算场景中，可以将机器人客服可承接访客量视为没有上限，相应的，自助客服模式的负载函数可以设置为一个不变的常数。在实际接入的用户数量小于设定阈值时，对应的负载信息为较高的评分值，实际接入的用户数量超过设定阈值时，对应的负载信息为与实际接入的用户数量负相关的评分值，可参见图6。可以理解，负载函数形式的选择可以基于具体的场景设计，本说明书对此不做限制。

不难理解，对于当前服务请求，当选定某一种客服模式作为目标客服模式时，可能会给平台提供的一种或多种的客服模式的当前负载信息带来影响。对此，可以先确定将选定的客服模式（或所述该客服模式）作为目标客服模式时，各已有客服模式的缺口值更新结果，再基于各缺口值更新结果确定各客服模式的更新负载信息。

由于服务提供者类型为机器人时，其可以接纳的用户数量非常大(如服务器可以同时接受100万人同时访问)，可以认为将目标客服模式确定为服务提供者为机器人的客服模式时，该客户模式的实际接入用户数量加1，进一步，将更新后的客户模式的实际接入用户数量输入这类客户模式对应的负载函数（如图6所示的曲线的函数表达式），得该客户模式的更新负载值。对于服务提供者类型为人工的实施场景，由于其对应的承接人员是有限的，因此其缺口值会因用户切换客服模式而发生变动。可以认为将目标客服模式确定为服务提供者为人工的客服模式时，该服务提供者为人工的客服模式的缺口值需要减1。例如，当将程序端人工渠道作为目标客服模式时，程序端人工渠道对应的缺口值需要减1。进一步，将更新后的缺口值输入负载函数（如图5所示的曲线的函数表达式），得到程序端人工渠道的更新负载信息。

换句话说，在确定当该客服模式作为目标客服模式时各客服模式的更新负载信息时，则基于前段描述计算该客服模式的更新负载信息，其余各客服模式的负载信息维持不变。

步骤330，确定当该客服模式作为目标客服模式时的跨模式用户接受度预测值。

服务评估值确定模块430可以确定当该客服模式作为目标客服模式时的跨模式用户接受度预测值。在本申请的一些实施例中，以字母G表示跨模式用户接受度预测值。

在一些实施例中，跨模式用户接受度预测值G可由两个参数确定。两个参数包括用户初始选择的客服模式与所述该客服模式，在该场景的实施例中，可以用下式计算跨模式用户接受度预测值G：

(2)

其中，

表示用户初始选择的客服模式对应的服务渠道（0是电话服务渠道，1是程序服务渠道）；当用户停留在进来时的端口时，

，这样用户不需要跨端就能解决问题，对于用户来说是方便的，满意度也高，这样g(0)就会有较高的分数；

不等于

时

必然等于1，g(1)表示跨端对用户满意度有一定的影响。函数

可以是解析表达式，也可以是经训练的机器学习模型。

在一些实施例中，可以使用训练样本来训练机器学习模型，得到跨模式用户接受度预测模型。其中，所述机器学习模型可以CNN、RNN、LSTM等神经网络模型。训练样本的输入特征可以包括历史用户初始选择的客服模式以及最终为历史用户提供客服的客服模式，其中，最终为历史用户提供客服的客服模式不同于历史用户初始选择的客服模式，训练的标签可以为历史用户是否满意（如满意为1，不满意为0）或者是满意度的评分（如0~100分）。训练标签可通过问卷调查获得。

进一步地，将训练样本的输入特征作为跨模式用户接受度预测模型的输入，调整跨模式用户接受度预测模型的参数，使得跨模式用户接受度预测模型输出的预测值与训练样本的标签差异最小化，得到训练好的跨模式用户接受度预测模型。

在一些实施例中，还可以在跨模式用户接受度预测模型的输入中引入用户特征数据，相应的，模型训练样本的输入特征还包括历史用户的用户特征数据。在计算跨模式用户接受度预测值时引入用户特征数据，可以提高预测准确度。

步骤340，基于该客服模式对应的用户满意度预测值、各客服模式的更新负载信息以及跨模式用户接受度预测值，确定该客服模式的服务评估值。

服务评估值确定模块430可以基于步骤310~330所计算的用户满意度预测值E、更新负载信息F以及跨模式用户接受度预测值G确定该客服模式对应的服务评估值M。具体地，服务评估值M可以由以下公式获取：

(3)

服务评估值M采用如（3）所示的方法进行计算可以从用户满意度预测值、各客服模式的更新负载信息以及跨模式用户接受度预测值等三个维度共同衡量用户的满意程度，从而得到用户对各客服模式的综合评定。通过这样的计算，使得服务评估值M的评价结果更加准确。

需要说明的是，以上步骤中涉及的服务评估值M仅作为示例性的说明。在一些实施例中，服务评估值M还可以采用其他方法进行计算。例如，服务评估值M可以是用户满意度预测值E、更新负载信息F以及跨模式用户接受度预测值G中任意两项求和的结果，又或者服务评估值M可以是用户满意度预测值E、各客服模式的更新负载信息F以及跨模式用户接受度预测值G的加权求和，各权值的大小可以视具体应用场景调整。类似这样的变化，依然在本申请所涉及的保护范围内。

图4是根据本申请一些实施例所示的一种客服提供系统的示例性系统框图。

如图4所示，客服提供系统400可以包括客服请求接收模块410、数据获取模块420、服务评估值确定模块430、目标客服模式选择模块440以及客服提供模块450。这些模块也可以作为应用程序或一组由处理引擎读取和执行的指令实现。此外，模块可以是硬件电路和应用/指令的任何组合。例如，当处理引擎或处理器执行应用程序/一组指令时，模块可以是处理器的一部分。

客服请求接收模块410，可以用于接收用户的客服请求，将客服请求对应的客服模式作为用户初始选择的客服模式。在一些实施例中，客服模式包括服务渠道类型以及服务提供者类型。其中，服务渠道类型包括应用程序渠道和电话渠道，服务提供者类型包括人工和机器人。有关客服模式的更多描述可见图2中的相应说明，在此不再赘述。

数据获取模块420，可以用于获取用户的用户特征数据，以及两种或以上客服模式的负载信息。在一些实施例中，用户特征数据包括以下中的一种或多种的组合：性别、年龄、偏好、历史行为轨迹以及客服请求意图。在一些实施例中，客服模式的负载信息反映该客服模式对应的可承接访客量与预计访客量的差值。在一些实施例中，客服模式对应的预计访客量通过访客量预测模型处理历史访客量预测获得。其中，访客量预测模型包括机器学习模型。有关用户特征数据、负载信息以及预计访客量的更多描述可见图2、5中的相应说明，在此不再赘述。

服务评估值确定模块430，可以用于基于所述用户特征数据、用户初始选择的客服模式以及各客服模式的负载信息，确定各客服模式对应的服务评估值。有关服务评估值确定的更多描述可参见图3的相应说明，此处不再赘述。

目标客服模式选择模块440，可以用于基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式。

客服提供模块450，可以用于通过所述目标客服模式向用户提供的客服。

在一些实施例中，服务评估值确定模块还用于，对于每一种客服模式：基于用户特征数据与该客服模式，确定用户满意度预测值；基于各客服模式的负载信息，确定当该客服模式作为目标客服模式时各客服模式的更新负载信息；至少基于用户初始选择的客服模式，确定当该客服模式作为目标客服模式时的跨模式用户接受度预测值；基于该客服模式对应的用户满意度预测值、各客服模式的更新负载信息以及跨模式用户接受度预测值，确定该客服模式的服务评估值。

在一些实施例中，服务评估值确定模块还用于：基于用户特征数据以及用户初始选择的客服模式，确定所述跨模式用户接受度预测值。

应当理解，图4所示的装置及其模块可以利用各种方式来实现。例如，在一些实施例中，装置及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中，硬件部分可以利用专用逻辑来实现；软件部分则可以存储在存储器中，由适当的指令执行装置，例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和装置可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器（固件）的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本说明书的装置及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用例如由各种类型的处理器所执行的软件实现，还可以由上述硬件电路和软件的结合（例如，固件）来实现。

需要注意的是，以上对于数据下载装置及其模块的描述，仅为描述方便，并不能把本说明书限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该装置的原理后，可能在不背离这一原理的情况下，对各个模块进行任意组合，或者构成子装置与其他模块连接。例如，图4中客服请求接收模块410和数据获取模块420可以为同一个模块，任意模块在获取身份标识后进行提取。又例如，客服提供系统400中的各个模块可以位于同一服务器上，也可以分属不同的服务器。诸如此类的变形，均在本说明书的保护范围之内。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本申请实施例可能带来的有益效果包括但不限于：（1）基于各客服模式对应的服务评估值实现了用户在不同客服模式间的调度，均衡分配了各客服模式对应的用户数量；（2）基于用户的用户特征数据确定各客服模式对应的服务评估值，进而选出使用户最为满意的目标客服模式，提升用户的客服体验；（3）服务评估值基于用户满意度预测值、各客服模式的更新负载信息以及跨模式用户接受度预测值三个维度共同衡量，使得服务评估值的评价结果更加准确。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本申请中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件（包括固件、常驻软件、微码等）执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

计算机存储介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等，或合适的组合形式。计算机存储介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机存储介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF、或类似介质，或任何上述介质的组合。

本申请各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、Visual Basic、Fortran2003、Perl、COBOL2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或处理设备上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网（LAN）或广域网（WAN），或连接至外部计算机（例如通过因特网），或在云计算环境中，或作为服务使用如软件即服务（SaaS）。

此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的处理设备或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20%的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

针对本申请引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本申请作为参考。与本申请内容不一致或产生冲突的申请历史文件除外，对本申请权利要求最广范围有限制的文件（当前或之后附加于本申请中的）也除外。需要说明的是，如果本申请附属材料中的描述、定义、和/或术语的使用与本申请所述内容有不一致或冲突的地方，以本申请的描述、定义和/或术语的使用为准。

最后，应当理解的是，本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此，作为示例而非限制，本申请实施例的替代配置可视为与本申请的教导一致。相应地，本申请的实施例不仅限于本申请明确介绍和描述的实施例。

Claims (13)

1.一种客服提供方法，其包括：

接收用户的客服请求，将客服请求对应的客服模式作为用户初始选择的客服模式；

获取用户的用户特征数据，以及两种或以上客服模式的负载信息；

基于用户特征数据，确定用户对于各客服模式的满意度预测值；

基于各客服模式的负载信息，确定各客服模式作为目标客服模式时对应的更新负载信息；

至少基于用户初始选择的客服模式，确定各客服模式作为目标客服模式时的跨模式用户接受度预测值；

基于各客服模式对应的用户满意度预测值、各客服模式的更新负载信息以及跨模式用户接受度预测值，确定各客服模式的服务评估值；

基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式；

通过所述目标客服模式向用户提供客服。

2.如权利要求1所述的方法，其中，所述客服模式包括服务渠道类型以及服务提供者类型，所述服务渠道类型包括应用程序渠道和电话渠道，所述服务提供者类型包括人工和机器人。

3.如权利要求1所述的方法，其中，客服模式的负载信息反映该客服模式对应的可承接访客量与预计访客量的差值。

4.如权利要求3所述的方法，其中，客服模式对应的预计访客量通过访客量预测模型处理历史访客量预测获得；所述访客量预测模型包括机器学习模型。

5.如权利要求1所述的方法，所述至少基于用户初始选择的客服模式，确定各客服模式作为目标客服模式时的跨模式用户接受度预测值，包括：

基于用户特征数据以及用户初始选择的客服模式，确定所述跨模式用户接受度预测值。

6.如权利要求1所述的方法，所述用户特征数据包括以下中的一种或多种的组合：性别、年龄、偏好、历史行为轨迹以及客服请求意图。

7.一种客服提供系统，其包括：

客服请求接收模块，用于接收用户的客服请求，将客服请求对应的客服模式作为用户初始选择的客服模式；

数据获取模块，用于获取用户的用户特征数据，以及两种或以上客服模式的负载信息；

服务评估值确定模块，用于基于用户特征数据，确定用户对于各客服模式的满意度预测值；基于各客服模式的负载信息，确定各客服模式作为目标客服模式时对应的更新负载信息；至少基于用户初始选择的客服模式，确定各客服模式作为目标客服模式时的跨模式用户接受度预测值；基于各客服模式对应的用户满意度预测值、各客服模式的更新负载信息以及跨模式用户接受度预测值，确定各客服模式的服务评估值；

目标客服模式选择模块，用于基于各客服模式对应的服务评估值，从各客服模式中选出目标客服模式；

客服提供模块，用于通过所述目标客服模式向用户提供客服。

8.如权利要求7所述的系统，其中，所述客服模式包括服务渠道类型以及服务提供者类型，所述服务渠道类型包括应用程序渠道和电话渠道，所述服务提供者类型包括人工和机器人。

9.如权利要求7所述的系统，其中，客服模式的负载信息反映该客服模式对应的可承接访客量与预计访客量的差值。

10.如权利要求9所述的系统，其中，客服模式对应的预计访客量通过访客量预测模型处理历史访客量预测获得；所述访客量预测模型包括机器学习模型。

11.如权利要求7所述的系统，所述服务评估值确定模块还用于：

基于用户特征数据以及用户初始选择的客服模式，确定所述跨模式用户接受度预测值。

12.如权利要求7所述的系统，所述用户特征数据包括以下中的一种或多种的组合：性别、年龄、偏好、历史行为轨迹以及客服请求意图。

13.一种客服提供装置，其中，包括处理器和存储设备，所述存储设备用于存储指令，当所述处理器执行指令时，实现如权利要求1~6中任一项所述客服提供方法。

Images