话务处理、服务处理方法、装置及服务器与流程

本申请涉及计算机技术领域，尤其涉及话务处理、服务处理方法、装置及服务器。

背景技术：

日常生活中，经常会出现用户由于某种需求，需要向服务方拨打服务电话、网络咨询或现场咨询等情况。以拨打服务电话为例，用户遇到问题后，可能会在特定的时间内进行拨打服务电话进行求助。例如早上可能是一个电话求助高峰期，对于服务方来说，此时话务流入量增加，而服务方配置的话务员可能无法满足此时话务流入量，造成应答量处于饱和且一直恒定，从而导致电话接通率偏低，排队数增加。一方面，在线的大量等待接听的用户会占用一定的处理资源，给服务器造成一定的处理压力；另一方面，用户求助时遇到电话暂时无法接通，队列中等待时间过长，很可能造成了用户呼损，用户体验较差。

技术实现要素：

为克服相关技术中存在的问题，本申请提供了话务处理、服务处理方法、装置及服务器。

一种话务处理方法，包括：

接收话务处理请求，确定所述话务处理请求的接收时刻；

若确定本次话务为可预约话务，则确定本次话务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量而确定；

其中，所述至少一个单位时间段的话务请求量通过如下方式预估得到：根据所述接收时刻获取本次话务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的话务总量历史统计数据、距离所述接收时刻一定时间内全天的话务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的话务请求量预估模型，利用所述话务请求量预估模型计算出所述单位时间段的话务请求量；

响应于所述话务处理请求，输出所确定的本次话务的预约时间。

可选的，通过如下一种或多种方式确定本次话务为可预约话务：

当前话务处理率低于第一预设阈值；

所述本次话务的业务信息指示所述本次话务为可预约话务；

发起所述话务处理请求的用户的历史话务数据指示所述用户对可预约话务的接受度高于第二预设阈值。

可选的，所述预约时间通过如下方式确定：

获取所述单位时间段内的话务员数量；

根据历史话务统计数据预估话务员在所述单位时间段内对一次话务的平均处理时长；

根据所述话务员数量和所述平均处理时长，计算所述单位时间段内可承接的话务总量；

根据所述可承接的话务总量减去所述话务请求量的差值，以及该单位时间段内已被预约的数量，确定所述预约时间。

可选的，所述话务请求量预估模型通过利用历史话务数据对机器学习模型训练得到。

可选的，所述方法还包括：

为本次话务分配处理资源，并锁定所述处理资源；

在输出所述预约时间后的预定时间内，确定发起所述话务接入请求的用户是否接受本次预约；

若所述用户不接受本次预约，则释放所述处理资源。

一种服务处理方法，所述方法包括：

接收服务处理请求，确定所述服务处理请求的接收时刻；

若确定本次服务为可预约服务，则确定本次服务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的服务总量、以及预估所述至少一个单位时间段的服务请求量而确定；

其中，所述至少一个单位时间段的服务请求量通过如下方式预估得到：根据所述接收时刻获取本次服务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的服务总量历史统计数据、距离所述接收时刻一定时间内全天的服务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的服务请求量预估模型，利用所述服务请求量预估模型计算出所述单位时间段的服务请求量；

响应于所述服务处理请求，输出所确定的本次服务的预约时间。

可选的，所述预约时间通过如下方式确定：

获取单位时间段内的服务员数量；

根据历史服务数据预估所述服务员在所述单位时间段内对一次服务的平均处理时长；

根据所述服务员数量和所述平均处理时长，计算所述单位时间段内可承接的服务总量；

根据所述可承接的服务总量减去所述服务请求量的差值，以及该单位时间段内已被预约的数量，确定所述预约时间。

一种话务处理装置，包括：

请求接收模块，用于：接收话务处理请求，确定所述话务处理请求的接收时刻；

预约确定模块，用于：在确定本次话务为可预约话务后，则确定本次话务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量而确定；

其中，所述至少一个单位时间段的话务请求量通过如下方式预估得到：根据所述接收时刻获取本次话务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的话务总量历史统计数据、距离所述接收时刻一定时间内全天的话务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的话务请求量预估模型，利用所述话务请求量预估模型计算出所述单位时间段的话务请求量；

预约时间输出模块，用于：响应于所述话务处理请求，输出所确定的本次话务的预约时间。

可选的，所述预约确定模块，还用于：通过如下一种或多种方式确定本次话务为可预约话务：

当前话务处理率低于第一预设阈值；

所述本次话务的业务信息指示所述本次话务为可预约话务；

发起所述话务处理请求的用户的历史话务数据指示所述用户对可预约话务的接受度高于第二预设阈值。

可选的，所述预约确定模块，还用于：

获取所述单位时间段内的话务员数量；

根据历史话务统计数据预估话务员在所述单位时间段内对一次话务的平均处理时长；

根据所述话务员数量和所述平均处理时长，计算所述单位时间段内可承接的话务总量；

根据所述可承接的话务总量减去所述话务请求量的差值，以及该单位时间段内已被预约的数量，确定所述预约时间。

可选的，所述预约确定模块，还用于：通过如下方式预估所述至少一个单位时间段的话务请求量：

根据所述接收时刻获取本次话务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的话务总量历史统计数据、距离所述接收时刻一定时间内全天的话务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；

将所获取的目标特征输入至预设的话务请求量预估模型，利用所述话务请求量预估模型计算出所述单位时间段的话务请求量。

可选的，所述话务请求量预估模型通过利用历史话务数据对机器学习模型训练得到。

可选的，所述装置还包括资源处理模块，用于：

为本次话务分配处理资源，并锁定所述处理资源；

在输出所述预约时间后的预定时间内，确定发起所述话务接入请求的用户是否接受本次预约；

若所述用户不接受本次预约，则释放所述处理资源。

一种服务处理装置，所述装置包括：

请求接收模块，用于：接收服务处理请求，确定所述服务处理请求的接收时刻；

预约确定模块，用于：在确定本次服务为可预约服务后，则确定本次服务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的服务总量、以及预估所述至少一个单位时间段的服务请求量而确定；

其中，所述至少一个单位时间段的服务请求量通过如下方式预估得到：根据所述接收时刻获取本次服务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的服务总量历史统计数据、距离所述接收时刻一定时间内全天的服务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的服务请求量预估模型，利用所述服务请求量预估模型计算出所述单位时间段的服务请求量；

预约时间输出模块，用于：响应于所述服务处理请求，输出所确定的本次服务的预约时间。

可选的，所述预约确定模块，还用于：获取单位时间段内的服务员数量；

根据历史服务数据预估所述服务员在所述单位时间段内对一次服务的平均处理时长；

根据所述服务员数量和所述平均处理时长，计算所述单位时间段内可承接的服务总量；

根据所述可承接的服务总量减去所述服务请求量的差值，以及该单位时间段内已被预约的数量，确定所述预约时间。

一种服务器，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收话务处理请求，确定所述话务处理请求的接收时刻；

若确定本次话务为可预约话务，则确定本次话务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量而确定；

其中，所述至少一个单位时间段的话务请求量通过如下方式预估得到：根据所述接收时刻获取本次话务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的话务总量历史统计数据、距离所述接收时刻一定时间内全天的话务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的话务请求量预估模型，利用所述话务请求量预估模型计算出所述单位时间段的话务请求量；

响应于所述话务处理请求，输出所确定的本次话务的预约时间。

一种服务器，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收服务处理请求，确定所述服务处理请求的接收时刻；

若确定本次服务为可预约服务，则确定本次服务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的服务总量、以及预估所述至少一个单位时间段的服务请求量而确定；

其中，所述至少一个单位时间段的服务请求量通过如下方式预估得到：根据所述接收时刻获取本次服务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的服务总量历史统计数据、距离所述接收时刻一定时间内全天的服务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的服务请求量预估模型，利用所述服务请求量预估模型计算出所述单位时间段的服务请求量；

响应于所述服务处理请求，输出所确定的本次服务的预约时间。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请实施例提出了一种预约形式的服务处理方案，考虑到某些时间段可能服务量较少，本实施例可以将高峰期的服务请求异步化到空闲的指定时间段，并通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量，确定合适的预约时间。本实施例可以在不增加服务资源的情况下，将高峰服务请求异步化到空闲时间段，因此降低高峰时期的服务处理压力，提升服务资源的利用率，避免了成本浪费。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是本申请根据一示例性实施例示出的一种服务处理方法的流程图。

图2a是相关技术中一种话务场景的示意图。

图2b是根据一示例性实施例示出的一种话务处理方法的流程图。

图3a是根据一示例性实施例示出的一种话务处理方法的系统组件示意图。

图3b是根据一示例性实施例示出的另一种话务处理方法的流程图。

图3c是根据一示例性实施例示出的另一种话务处理方法的流程图。

图4是本申请根据一示例性实施例示出的一种话务处理装置的框图。

图5是本申请根据一示例性实施例示出的另一种话务处理装置的框图。

图6是本申请话务处理/服务处理装置所在服务器的一种硬件结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

日常生活中，经常会出现用户由于某种需求，需要拨打服务方提供的服务电话或进行在线网络咨询等请求服务的情况，当有较多的用户请求服务时，可能会出现排队数增加、用户等待时间过长的缺陷。例如，以话务场景为例，早上可能是一个电话求助高峰期，对于服务方来说，此时话务流入量增加，而服务方配置的话务员可能无法满足此时话务流入量，应答量持续处于饱和的状态，从而导致电话接通率偏低，排队数增加。在线的大量等待接听的用户会占用一定的资源，给服务器造成一定的处理压力。以购物场景为例，若举办某些购物活动，在线服务平台可能会有较多的用户咨询，对于服务方来说，此时请求流入量增加，而服务方配置的服务员可能无法满足此时流入量，在线的大量等待的用户会占用一定的处理资源，给服务器造成一定的处理压力。

本申请实施例提出了一种预约形式的服务处理方案，考虑到某些时间段可能服务量较少，本实施例可以将高峰期的服务请求异步化到空闲的指定时间段，并通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量，确定合适的预约时间。本实施例可以在不增加服务资源的情况下，将高峰服务请求异步化到空闲时间段，因此降低高峰时期的服务处理压力，提升服务资源的利用率，避免了成本浪费。接下来对本申请实施例进行详细说明。

如图1所示，图1是本申请根据一示例性实施例示出的一种服务处理方法的流程图，包括以下步骤101至103：

在步骤101中，接收服务处理请求，确定所述服务处理请求的接收时刻。

在步骤102中，若确定本次服务为可预约服务，则确定本次服务的预约时间，其中，所述预约时间为：预计可以开始处理本次服务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的服务总量、以及预估所述至少一个单位时间段的服务请求量而确定。

其中，所述至少一个单位时间段的服务请求量通过如下方式预估得到：根据所述接收时刻获取本次服务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的服务总量历史统计数据、距离所述接收时刻一定时间内全天的服务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的服务请求量预估模型，利用所述服务请求量预估模型计算出所述单位时间段的服务请求量。

在步骤103中，响应于所述服务处理请求，输出所确定的本次服务的预约时间。

本实施例的服务处理方案可应用于服务方，在服务方的处理量较大、处理请求积压的情况下，由服务方将服务处理请求进行异步化处理，向用户提供预约服务。该方案可以适用于多种场景，例如电话服务场景或网络咨询场景等等。

实际情况中，当处理量较大、处理请求积压的情况下，服务方可能采取临时增加人力等方式，安排更多的服务资源。此种处理方式相对滞后，可能在增加服务资源的过程中，服务器已面临了较大的压力，并且等待时间过长可能会造成用户流失。而在某些时间，服务请求可能较少，服务资源也可能处于空闲的状态，服务资源无法得到合理的分配。针对此类可能出现服务资源空闲、也可能出现服务请求高峰的情况，本实施例的预约形式的异步服务的方案，能将用户的服务请求分配到未来的其他时间进行处理。在提供预约服务时，需要确定一合适的预约时间，假设没有确定一合适的时间，也有可能造成在预约时间到达时，由于预约量过多或服务请求量较大，同样造成服务资源较少、不够分配的情况。

基于此，本实施例可以基于现场服务请求情况，通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的服务总量、以及预估所述至少一个单位时间段的服务请求量而确定合理的预约时间。该单位时间段可以根据实际需求而灵活配置，例如可以是30分钟、一小时或两个小时等。该可承接的服务总量，可以通过服务资源的预分配情况而确定；该服务请求量可以通过对历史服务数据的统计结果而进行预估。当未来的某些单位时间段的可承接的服务总量较大，而该单位时间段的服务请求量较少，则表示在该单位时间段有空闲的服务能力，可以将服务处理请求迁移至该时间段进行处理。

其中，对于如何合理预估各单位时间段的空闲的服务能力，考虑到大多数服务场景中，服务方会安排服务员处理服务请求，而服务请求的处理时长可能会趋近于一个稳定的数值，本申请实施例提供了一种对单位时间段的空闲的服务能力的量化方式，在一个可选的实现方式中，所述预约时间通过如下方式确定：

获取单位时间段内的服务员数量。

根据历史服务数据预估所述服务员在所述单位时间段内的平均处理时长。

根据所述服务员数量和所述平均处理时长，计算所述单位时间段内可承接的服务总量。

根据所述可承接的服务总量减去所述服务请求量的差值，以及该单位时间段内已被预约的数量，确定所述预约时间。

本实施例中，由于异步服务是调用空闲的服务员来为用户进行服务，这里的关键问题是：服务员在什么时候空闲，空闲时大约能处理多少服务请求的能力。由于服务请求的流入量、流入时间、服务员的处理时间等因素都是不确定的，准确预估某个服务员在什么时间是空闲的问题相当困难。本实施例将问题确定：将时间划分为固定时长的单位时间段(例如可以是半小时或一小时等等)，需要预估每个单位时间段服务员的空闲时间能够处理多少服务请求。而这个问题可细分成如下几个因素：单位时间段的服务请求量、单位时间段的服务员数量和单位时间段的服务员的效能(一个服务请求需要多长的处理时间)。基于此，可通过对历史服务数据的统计结果，分析对一次服务请求的平均处理时长。另外，通常服务员会对应有一定排班数据，由于未来各单位时间段的排班数据，可以确定各单位时间段的根据服务员数量，从而可确定单位时间段内可承接的服务总量；例如，假设单位时间段是一个小时(60分钟)，未来某个单位时间段的服务员有10人，一次服务的平均处理时长需要10分钟，则单位时间段内可承接的服务总量为60个。根据该单位时间段的服务请求量，假设是40个，则该单位时间段可以处理20个预约服务，由于该单位时间段具有空闲的服务能力，因此可选取该单位时间段作为预约时间。

由上述实施例可知，本实施例可以将高峰期的服务请求异步化到空闲的指定时间段，并通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量，确定合适的预约时间。本实施例可以在不增加服务资源的情况下，将高峰服务请求异步化到空闲时间段，因此降低高峰时期的服务处理压力，提升服务资源的利用率，避免了成本浪费。

接下来以话务场景为例再次说明。如图2a所示，是相关技术中一种话务场景的示意图，首先对后续所涉及的一些词语进行说明：

ivr：interactivevoiceresponse，互动式语音应答系统。

呼损：用户在话务求助过程中，未能享受到人工服务，即挂断电话。

队列：用户在人工求助过程中排队的通道。

排班：基于用户求助预测量级确定客服人员上班人数的具体情况。

话务流入量：用户求助人工服务的总量。

话务应答量：客服接起电话的总量。

接通率：(话务应答量)/(话务流入量)，用以衡量服务中心承接能力的指标。

排队数：用户人工求助过程中在排队通道等待的人数。

削峰填谷：当用户在话务高峰期求助时，将其预约到空闲时段，在空闲时段到达时对该话务进行处理，在不增加客服数量的前提下提高服务量的一种能力。

在一个ivr系统中，用户遇到问题后，可能会在特定的时间内进行电话咨询。例如，早上就是一个电话咨询的高峰期，此时流入量增加，应答量处于饱和且一直恒定。这样的结果会导致接通率偏低，排队数增加，对系统造成一定的处理压力。那么用户求助会遇到电话暂时无法接通，队列中等待时间过长也很可能造成了用户呼损。

对于服务方而言，为了更友好地解决话务请求较大而无法及时提供服务的问题，可以通过现场临时增加人员来消耗流量，但调控手段相对滞后：可能在增加人员的缓存时间内用户就已经流失；临时可调控的人员有限，增加人员很难立即到位，且会增加额外人力成本。如果通过粗暴预约方式，例如语音播报告知客户，稍后来电求助，或者尝试自助的方式解决问题，可能无法解决客户问题。另外，若随意开放预约时间，可能现场人员承接能力有限进而导致回访压力过大，可能造成承诺未兑现等事件。

如图2b所示，是根据一示例性实施例示出的一种话务处理方法的流程图，本实施例的话务处理方法可包括如下步骤201至203：

在步骤201中，接收话务处理请求，确定所述话务处理请求的接收时刻。

在步骤202中，若确定本次话务为可预约话务，则确定本次话务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量而确定。

其中，所述至少一个单位时间段的话务请求量通过如下方式预估得到：根据所述接收时刻获取本次话务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的话务总量历史统计数据、距离所述接收时刻一定时间内全天的话务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的话务请求量预估模型，利用所述话务请求量预估模型计算出所述单位时间段的话务请求量。

在步骤203中，响应于所述话务处理请求，输出所确定的本次话务的预约时间。

本申请实施例的方法可应用于提供电话服务的服务方，相关技术中服务方通常配置有ivr系统进行电话服务，在某些例子中，上述方案可应用于已有的ivr系统中，由ivr系统对拨入的电话提供预约服务；在其他例子中，服务方还可以配置独立于ivr系统的其他服务平台，由新配置的服务平台应用本实施例的方案，根据当前话务承接现状、预约资源管理等等信息进行决策，指示ivr系统是对用户的话务处理请求进行预约处理，还是直接由话务员接听服务等等，本领域技术人员可根据需要灵活配置。

实际应用中，用户拨打的服务电话可以接入ivr系统，通过ivr系统接收到用户发起的话务处理请求。通常，用户拨打服务电话是需要咨询某一方面的信息，还可以获取本次话务的业务信息等等，以确定用户本次话务将会涉及哪些业务。实际应用中，业务信息的获取，可以是用户描述其咨询的问题，通过语音识别等技术进行识别；或者，也可以是ivr系统设定了各类问题对应的按键信息并进行语音播放，用户通过触发相应的按键，以反馈其需要咨询的问题等等方式。

在获取到包括有本次话务的用户信息、时间、业务信息等等相关数据后，可以确定本次话务是否为可预约话务。其中，具体的确定过程实际应用中可灵活配置，例如可以是在话务量较大的时候、或者是所有话务员当前时间都在处理话务等预设的策略确定本次话务是否需要预约。在某些例子中，如果预设策略较为简单，有可能存在确定本次话务需要预约后，而用户实际并不想接受预约的情况，此种情况下，用户会再次发起话务处理请求，进而增加服务方的处理压力。因此，可以考虑当前话务请求量是否非常大、排队人数较多；或者是用户所要咨询的业务是否是紧急业务，或者是用户对预约服务是否接受等等多种因素，以更为精确地确定可预约话务。

基于此，在一个可选的实现方式中，通过如下一种或多种方式确定本次话务为可预约话务：

当前话务处理率低于第一预设阈值。

所述本次话务的业务信息指示所述本次话务为可预约话务。

发起所述话务处理请求的用户的历史话务数据指示所述用户对可预约话务的接受度高于第二预设阈值。

本实施例中，可以查询当前的话务处理率(接通率)，若当前时刻话务请求量非常大，话务员全部处于通话状态，则会有大量排队等候的话务处理请求，话务处理率非常低，此种情况下，可以考虑将本次话务确定为可预约话务。

在某些情况下，可能用户需要处理的业务较为紧急，某些业务可能对及时性要求较低，例如，对于账户被盗用的紧急程度较高，而某些咨询类业务的紧急程度较低。因此可以根据需要灵活配置具体场景中各种业务的紧急程度，某些非紧急的业务可确定为可预约话务。当用户请求处理此类业务时，可以考虑将本次话务确定为可预约话务。

或者，可以采用用户标识(userid，可以包括用户名称、用户账号或用户联系方式等)作为key，查询该用户的历史话务数据，判断用户对可预约服务的接受度。假设用户历史话务数据指示用户对于多次预约服务都采用拒绝的方式，则说明该用户对可预约话务的接受度较低；假设用户历史话务数据指示用户对于多次预约服务都采用接受的方式，则说明该用户对可预约话务的接受度较高，则可以考虑将本次话务确定为可预约话务。

若确定本次话务不是可预约话务，则将本次话务接入服务中心，等待话务员接入，以对本次话务进行处理。在确定本次话务为可预约话务，则可进一步确定本次话务的预约时间。由于异步服务是调用每天闲时人力来为忙时呼损的用户进行服务，这里的关键问题是：话务员在什么时候空闲，空闲时大约能提供多少话务外呼的能力。由于话务流入量、流入时间、服务时间等因素都是不确定的，难以准确预估某个座席在什么时间处于空闲状态。本实施例中，将问题确定为：将时间划分为固定时长的单位时间段，需要预估每个单位时间段话务员的空闲时间能够打多少电话，可以细分成如下几个因素：单位时间段的话务请求量、单位时间段的话务员数量和单位时间段的话务员的效能(一个话务请求需要多长的处理时间)。

因此，可以通过历史话务数据、话务员排班数据以及话务的历史流量等数据，以及接收到请求的当前时间的话务量数据等流量数据，预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量，从而确定一个合理的预约时间。例如，若预估未来的某个单位时间段内可承接的话务总量较大，且该单位时间段的话务请求量较大，则该单位时间段可确定为预约时间。

在一个可选的实现方式中，本实施例还提供了其中一种确定预约时间的方式：

获取所述单位时间段内的话务员数量；

根据历史话务统计数据预估话务员在所述单位时间段内的平均处理时长；

根据所述话务员数量和所述平均处理时长，计算所述单位时间段内可承接的话务总量；

根据所述可承接的话务总量减去所述话务请求量的差值，以及该单位时间段内已被预约的数量，确定所述预约时间。

可以通过如下公式表示上述确定过程：

ccall是指该单位时间段空闲话务员能处理的预约话务量；clabor是指单位时间段内的话务员数量，可以通过话务员的排班数据获得；time是指该单位时间段的时长，具体的数值可以根据所采用的时间单位而确定；fle是指话务员在所述单位时间段内的平均处理时长，cinflow是指预估的该单位时间段的话务请求量。预约时间的确定，可以理解为，根据话务员数量预估一个单位时间段内可承接的话务总量，减去可能的话务请求量，就是该单位时间段话务员在空闲时间所能处理的预约话务量。因此，只要ccall为大于或等于1的整数，及表示单位时间段话务员具有空闲时间能够处理预约话务量，可以确定该单位时间段可以作为预约时间。

其中，fle可以利用历史话务数据，统计出一个整体平均值，当数据量较大，多个话务员对于一个话务请求的处理时间会趋近于一个平均值，在该平均值上下波动，基本不会受到外界因素干扰，历史话务数据量较大时，波动可以相互抵消，使得fle可以基本趋于算术平均。

而对于cinflow，其受到外界因素的影响非常大，可以考虑多个因素进行预估：

根据所述接收时刻获取本次话务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的话务总量历史统计数据、距离所述接收时刻一定时间内全天的话务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份。

将所获取的目标特征输入至预设的话务请求量预估模型，利用所述话务请求量预估模型计算出所述单位时间段的话务请求量。

本实施例中，可以从历史话务数据中取得较大的样本量，该话务请求量预估模型通过利用历史话务数据对机器学习模型训练得到，例如可以包括gbdt回归模型等等，目标特征通过考虑上述多种因素而进行选取，例如可以是提取历史同一天的用户话务数据特征、历史一个月内该时间段的话务请求量、最近七天全天的话务请求量、最近五个小时的话务请求量、指示当天是否是节假日的特征、当天的月份特征等等，从而可以提高模型的预估准确率。

实际应用中，确定的预约时间可以是一个单位时间段，例如3点至4点、也可以是多个单位时间段、或者也可以是具体的时刻等等。在输出预约时间时，对于多个单位时间段的情况，还可以向用户提供选择具体单位时间段的功能，在实际应用中可以灵活配置。

由于在确定本次话务的预约时间后，到用户确认是否接受预约之间，有可能还有其他用户的话务请求需要分配服务资源，为了防止预约量较大而服务资源分配出错、防止话务员无法及时处理话务的情况，所述方法还可包括：

为本次话务分配处理资源，并锁定所述处理资源；

在输出所述预约时间后的预定时间内，确定发起所述话务接入请求的用户是否接受本次预约；

若所述用户不接受本次预约，则释放所述处理资源。

本实施例中，可以统计每个单位时间段已经被预约的数量，在确定该可预约时间后，可以生成针对本次话务的预约单，并锁定为本次话务分配的处理资源。在输出所述预约时间后的预定时间内，确定发起所述话务接入请求的用户是否接受本次预约，若所述用户不接受本次预约，则释放所述处理资源，若用户接受，则可激活预约单。

接下来再通过一实施例说明话务处理方案的具体应用过程。图3a所示，是根据一示例性实施例示出的一种话务处理方法的系统组件示意图，图3a中包括了ivr系统、智能调度平台和cc服务平台，该智能调度平台可应用图2b所述的话务处理方法，从而可以监控ivr系统的话务处理请求的数量，以指示ivr系统是否对用户的话务处理请求进行预约处理，cc服务平台用于承接话务，该cc服务平台可包括多个坐席，坐席对应有话务员接通电话，为用户提供电话服务。

图3a中的智能调度平台包括多个组件(component)，各个组件用于执行本实施例的话务处理方法的某些步骤。可以理解，图3a中的系统组件示意图只为示例说明，实际应用中可不局限于上述架构，本实施例的话务处理方法的各个步骤可以根据实际需要而灵活配置不同的组件进行执行。在其他可选的实现方式中，本实施例所提供的方案还可以集成于ivr系统中，本领域技术人员可以结合实际需要进行灵活配置。

结合图3b所示的另一种话务处理流程图、图3c所示的另一种话务处理流程图进行说明，本实施例中，ivr系统主要用于职责是调用cc服务平台进行服务承接；智能调度平台用于根据当前话务承接现状、预约资源管理等决策，指示ivr系统是对用户的话务处理请求进行预约处理，还是直接由话务员接听服务等等。

其中，ivr系统包括的组件有：分流派单、渠道选择、直流派单和预约回呼。智能调度平台包括的组件有：现场决策、小二预约资源推荐和预约单管理。cc系统包括的组件有：软电话拉起。

结合图3a、图3b和图3c说明具体的时序流程：

在步骤1中，用户拨打求助热线，例如95188。

在步骤1.1中，由ivr系统的分流派单组件针对本次话务生成sessionid(acid)。

在步骤2中，用户一句话描述问题。

在步骤2.1中，ivr系统的分流派单组件根据识别出来的问题，解析出派单结果，最终以json结构存储。

在步骤2.2中，ivr系统的渠道选择组件请求智能调度平台的现场决策组件(rpc)输出对本次话务是否为可预约话务的决策。

智能调度平台执行如下步骤：

在步骤2.2.1中，http请求方式查询派单技能组接通率(answerate)，以确定当前话务处理率低于第一预设阈值。

在步骤2.2.2中，以userid作为key，查询该用户的历史求助轨迹(历史话务数据)，以确定用户对可预约话务的接受度是否高于第二预设阈值。

在步骤2.2.3中，以渠道关键字(channelkey)查询个性化渠道的业务，以根据本次话务的业务信息判断本次话务是否为可预约话务。

在步骤2.2.4中，rpc请求查询hbase(数据库)获取预约人力时段推荐名额，以确定各单位时间段内话务员具有空闲时间能够处理预约话务量。

在步骤2.2.5中，统计状态为创建状态(created)的所有预约单。

在步骤2.2.6中，如果输出渠道是预约，即表示本次话务被确定为可预约话务，需要提前锁定预约单，具体的，包括：1.生成操作记录(operate_history)2.生成状态为未激活(init)的预约单。

在步骤2.2.7中，以json格式返回可能的渠道结果：1.直流(hotline)；22.预约(order)&预约时段(ordertime)。其中，直流表示本次话务需提交给cc服务平台，以及时接入话务员进行处理。

在步骤2.3中，若输出结果为hotline，ivr系统同步调用cc服务平台中的软电话拉起组件。

在步骤2.3.1中，cc服务平台中的软电话拉起组件执行电话拉起操作。

在步骤2.3.2中，软电话拉起组件立马接通电话或告诉用户需要等待。

在步骤2.4中，对于可预约话务，ivr系统向用户的设备输出tts合成预约时间的语音。

在步骤2.5中，如果用户同意预约，发送异步消息，并激活预约单。

在步骤2.5.1中，预约单管理组件的激活处理器接收到消息并处理，预约单状态由init更新为created(init->created)

在步骤2.6中，如果用户不接受预约，发送异步消息，解除已经锁定的预约单，释放该单位时间段的名额。

在步骤2.6.1中，预约单管理组件的取消处理器接收消息并处理，预约单状态由init更新为cancel(init->cancel)。

本申请实施例所提供的方案，通过用户历史话务数据、话务员排班数据以及话务流量等特征，结合现场话务的实时服务能力，可预测出空闲时段的富余承接量，将其转化为高峰时段为客户提供的预约服务名额；通过智能语音交互，与用户确认是否接受延时的人工回访服务。通过本方案，可以在约定的时间段对客户进行人工回呼，解决了临时增加人力的滞后性与成本问题，同时有效保障预约名额可控，有益于客户体验，降低流失率。ivr热线服务作为传统呼叫中心的服务模式，需平衡客户体验与人员利用率，传统解决方案缺少综合有效途径，有可能导致成本浪费或客户体验受损。本实施例通过模型数据，基于用户历史求助轨迹、排班数据以及话务流量等特征预测时段可预约容量，将波谷时段富余承接能力转化为话务高峰时段可供客户预约的名额达到削峰填谷的目的。在算法的支撑下，实现了不增加客服名额的情况下，有效保障接通率，提高客户体验，同时避免了预约不可控的风险。

与前述话务处理、服务处理方法的实施例相对应，本申请还提供了话务处理、服务处理装置及其所应用的服务器的实施例。

如图4所示，图4是本申请根据一示例性实施例示出的一种话务处理装置的框图，所述装置包括：

请求接收模块41，用于：接收话务处理请求，确定所述话务处理请求的接收时刻；

预约确定模块42，用于：在确定本次话务为可预约话务后，则确定本次话务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量而确定；

其中，所述至少一个单位时间段的话务请求量通过如下方式预估得到：根据所述接收时刻获取本次话务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的话务总量历史统计数据、距离所述接收时刻一定时间内全天的话务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的话务请求量预估模型，利用所述话务请求量预估模型计算出所述单位时间段的话务请求量；

预约时间输出模块43，用于：响应于所述话务处理请求，输出所确定的本次话务的预约时间。

可选的，所述预约确定模块，还用于：通过如下一种或多种方式确定本次话务为可预约话务：

当前话务处理率低于第一预设阈值；

所述本次话务的业务信息指示所述本次话务为可预约话务；

发起所述话务处理请求的用户的历史话务数据指示所述用户对可预约话务的接受度高于第二预设阈值。

可选的，所述预约确定模块，还用于：

获取所述单位时间段内的话务员数量；

根据历史话务统计数据预估话务员在所述单位时间段内的平均处理时长；

根据所述话务员数量和所述平均处理时长，计算所述单位时间段内可承接的话务总量；

根据所述可承接的话务总量减去所述话务请求量的差值，以及该单位时间段内已被预约的数量，确定所述预约时间。

可选的，所述话务请求量预估模型通过利用历史话务数据对机器学习模型训练得到。

可选的，所述装置还包括资源处理模块，用于：

为本次话务分配处理资源，并锁定所述处理资源；

在输出所述预约时间后的预定时间内，确定发起所述话务接入请求的用户是否接受本次预约；

若所述用户不接受本次预约，则释放所述处理资源。

如图5所示，图5是本申请根据一示例性实施例示出的一种服务处理装置的框图，所述装置包括：

请求接收模块51，用于：接收服务处理请求，确定所述服务处理请求的接收时刻；

预约确定模块52，用于：在确定本次服务为可预约服务后，则确定本次服务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的服务总量、以及预估所述至少一个单位时间段的服务请求量而确定；

其中，所述至少一个单位时间段的服务请求量通过如下方式预估得到：根据所述接收时刻获取本次服务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的服务总量历史统计数据、距离所述接收时刻一定时间内全天的服务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的服务请求量预估模型，利用所述服务请求量预估模型计算出所述单位时间段的服务请求量；

预约时间输出模块53，用于：响应于所述服务处理请求，输出所确定的本次服务的预约时间。

可选的，所述预约确定模块，还用于：获取单位时间段内的服务员数量；

根据历史服务数据预估所述服务员在所述单位时间段内的平均处理时长；

根据所述服务员数量和所述平均处理时长，计算所述单位时间段内可承接的服务总量；

将所述可承接的服务总量减去所述服务请求量，获得所述单位时间段内可承接的服务总量，根据所述可承接的服务总量以及该单位时间段内已被预约的数量，确定所述预约时间。

相应的，本申请还提供一种服务器，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收话务处理请求，确定所述话务处理请求的接收时刻；

若确定本次话务为可预约话务，则确定本次话务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的话务总量、以及预估所述至少一个单位时间段的话务请求量而确定；

其中，所述至少一个单位时间段的话务请求量通过如下方式预估得到：根据所述接收时刻获取本次话务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的话务总量历史统计数据、距离所述接收时刻一定时间内全天的话务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的话务请求量预估模型，利用所述话务请求量预估模型计算出所述单位时间段的话务请求量；

响应于所述话务处理请求，输出所确定的本次话务的预约时间。

相应的，本申请还提供一种服务器，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收服务处理请求，确定所述服务处理请求的接收时刻；

若确定本次服务为可预约服务，则确定本次服务的预约时间，其中，所述预约时间为：预计可以开始处理本次话务的时间；所述预约时间通过预估从所述接收时刻之后未来的至少一个单位时间段内可承接的服务总量、以及预估所述至少一个单位时间段的服务请求量而确定；

其中，所述至少一个单位时间段的服务请求量通过如下方式预估得到：根据所述接收时刻获取本次服务的目标特征，所述目标特征包括如下一种或多种特征：与所述接收时刻在同一单位时间段内的服务总量历史统计数据、距离所述接收时刻一定时间内全天的服务请求总量，以及指示所述接收时刻是否关联有预设标签的特征，所述预设标签包括节假日和/或月份；将所获取的目标特征输入至预设的服务请求量预估模型，利用所述服务请求量预估模型计算出所述单位时间段的服务请求量；

响应于所述服务处理请求，输出所确定的本次服务的预约时间。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

本申请话务处理/服务处理装置的实施例可以应用在服务器。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在话务处理/服务处理的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图6所示，为本申请话务处理/服务处理装置所在服务器的一种硬件结构图，除了图6所示的处理器610、内存630、网络接口620、以及非易失性存储器640之外，实施例中装置631所在的服务器，通常根据该服务器的实际功能，还可以包括其他硬件，对此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。