CN116545970A - 咨询队列显示方法、装置及电子设备 - Google Patents

Abstract

本申请提供了一种咨询队列显示方法、装置及电子设备，其中方法包括：将咨询请求发送至客服系统；将接收到的所述客服系统反馈的排序结果进行提示，所述排序结果是根据第一号码和第二号码确定的；所述第一号码是所述咨询请求在目标咨询队列中的号码，所述第二号码是所述目标咨询队列中排在所述咨询请求之前的正在占用客服资源的其他咨询请求的号码。依据本申请实施例，对于客户端而言，在发送咨询请求后，便可定期接收到客服系统反馈来的排序结果。排序结果可表征客户端的咨询请求的等待时间。由此可以有效缓解客户在等待过程中的焦虑情况。

Description

咨询队列显示方法、装置及电子设备

技术领域

本申请涉及大数据处理技术领域，尤其涉及一种咨询队列显示方法、装置及电子设备。

背景技术

在通过即时通讯软件进行咨询场景中，由于处理咨询请求的客服资源有限，导致使用者排队的现象时有发生。在极端情况下，排队人数会达到百人甚至千人，但使用者并不了解当前的服务现状，由此时常会引发用户的不满情绪，影响用户体验。

发明内容

本申请实施例提供一种咨询队列显示方法、咨询请求队列管理方法、客服资源管理方法、咨询请求的处理方法、各方法对应的装置、以及电子设备和存储介质，以使得用户实时了解当前的服务现状，可以提高用户的使用体验。

第一方面，本申请实施例提供了一种咨询队列显示方法，应用于即时通讯客户端，该方法可以包括：

将咨询请求发送至客服系统。

将定期接收到的客服系统反馈的排序结果进行提示，排序结果是根据第一号码和第二号码确定的；第一号码是咨询请求在目标咨询队列中的号码，第二号码是目标咨询队列中排在咨询请求之前的正在占用客服资源的其他咨询请求的号码。

第二方面，本申请实施例提供了一种咨询请求队列管理方法，应用于即时通讯客服系统，该方法可以包括：

对接收到的咨询请求进行解析，得到解析结果。

将咨询请求添加至目标咨询队列，目标咨询队列是依据解析结果，从多个候选咨询队列中选择的。

确定并反馈排序结果；其中，排序结果是根据第一号码和第二号码确定的；第一号码是咨询请求在目标咨询队列中的号码，第二号码是目标咨询队列中排在咨询请求之前的正在占用客服资源的其他咨询请求的号码。

第三方面，本申请实施例提供了一种客服资源管理方法，应用于即时通讯客服调配系统，该方法可以包括：

获取目标咨询队列的排序结果，排序结果是根据第一方面所涉及的方法确定的；

利用排序结果以及客服的处理能效，对客服资源进行调配。

第四方面，本申请实施例提供了一种客服资源管理方法，应用于即时通讯客服端，该方法可以包括：

获取已分配的咨询请求在目标咨询队列的排序结果，排序结果是根据第一方面所涉及的方法确定的；已分配的咨询请求为分配给客服端的多个咨询请求。

根据已分配的咨询请求在目标咨询队列的排序结果，确定已分配的咨询请求的处理优先级。

第五方面，本申请实施例提供了一种咨询请求队列管理装置，该装置可以包括：

发送模块，用于将咨询请求发送至客服系统。

提示模块，用于将定期接收到的客服系统反馈的排序结果进行提示，排序结果是根据第一号码和第二号码确定的；第一号码是咨询请求在目标咨询队列中的号码，第二号码是目标咨询队列中排在咨询请求之前的正在占用客服资源的其他咨询请求的号码。

第六方面，本申请实施例提供了一种咨询请求队列管理装置，该装置可以包括：

解析模块，用于对接收到的咨询请求进行解析，得到解析结果。

队列添加模块，用于将咨询请求添加至目标咨询队列；目标咨询队列是根据解析结果，从多个候选咨询队列中选择的。

排序结果反馈模块，用于确定并反馈排序结果；其中，排序结果是根据第一号码和第二号码确定的；第一号码是咨询请求在目标咨询队列中的号码，第二号码是目标咨询队列中排在咨询请求之前的正在占用客服资源的其他咨询请求的号码。

第七方面，本申请实施例提供了一种客服资源管理装置，该装置可以包括：

排序结果确定模块，用于获取目标咨询队列的排序结果，排序结果是根据第一方面所涉及的方法确定的；

客服资源调配模块，用于利用排序结果以及客服的处理能效，对客服资源进行调配。

第八方面，本申请实施例提供了一种咨询请求的处理装置，该装置可以包括：

排序结果获取模块，用于获取已分配的咨询请求在目标咨询队列的排序结果，排序结果是根据第一方面所涉及的方法确定的；已分配的咨询请求为分配给客服端的多个咨询请求。

优先级确定模块，用于根据已分配的咨询请求在目标咨询队列的排序结果，确定已分配的咨询请求的处理优先级。

第九方面，本申请实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，处理器在执行计算机程序时实现上述任一项的方法。

第十方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质内存储有计算机程序，计算机程序被处理器执行时实现上述任一项的方法。

与现有技术相比，本申请具有如下优点：

依据本申请实施例，对于客户端而言，客户端在发送咨询请求后，便可定期接收到客服系统反馈来的排序结果。排序结果可表征客户端的咨询请求的等待时间。由此可以有效缓解客户在等待过程中的焦虑情况。对于客服系统而言，在确定排序结果时，由于目标咨询队列是从多个候选咨询队列中确定的，使得咨询队列会有多个。由此对应整个确定排序结果的过程是去中心化的，即便目标咨询队列出现单点问题，也不会影响全局的其他咨询队列中的排序结果的计算，整个系统的运行稳定性会提高。此外，排序结果的确定无需进行号码遍历而只需要获取第一号码和第二号码两个数字进行减法计算即可快速确定出排序结果，效率方便会有保障。对于客服调配系统而言，可以依据目标咨询队列的排序结果实现对于客服资源的自动化、精准化调整。根据实际情况安排客服资源，以实现客服资源的最优配置。对于客服端而言，利用排序结果作为处理优先级，在同时处理多个咨询请求的场景下，可以区分轻重缓急，根据优先级处理已分配的咨询请求，对于客服端处理咨询请求的先后顺序提供建议，在同时处理多个咨询请求的情况下，可以让排队更早的用户优先得到服务。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，可依照说明书的内容予以实施，并且为了让本申请的上述和其他目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请的一些实施方式，而不应将其视为是对本申请范围的限制。

图1为本申请提供的咨询请求队列管理方法的场景示意图之一；

图2为本申请一实施例的咨询队列显示方法的流程图；

图3是本申请一实施例的咨询交互页面的示意图；

图4为本申请提供的咨询请求队列管理方法的流程图；

图5是本申请提供的咨询请求队列管理方法的场景示意图之二；

图6是本申请一实施例的客服资源管理方法的流程图；

图7是本申请一实施例的咨询请求的处理方法的流程图；

图8是本申请一实施例的客服端显示页面的示意图；

图9是本申请一实施例的咨询队列显示装置的结构框图；

图10是本申请一实施例的咨询请求队列管理装置的结构框图；

图11是本申请一实施例的客服资源管理装置的结构框图；

图12是本申请一实施例的咨询请求的处理装置的结构框图；以及

图13为用来实现本申请实施例的电子设备的框图。

具体实施方式

在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本申请的构思或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的，而非限制性的。

为便于理解本申请实施例的技术方案，以下对本申请实施例的相关技术进行说明。以下相关技术作为可选方案与本申请实施例的技术方案可以进行任意结合，其均属于本申请实施例的保护范围。

在面对如何向电商平台的使用者推送排队信息时，相关技术主要依赖于以下几点。其中之一是基于客户端的轮询推送排队信息。即，在接收到客户端发送的排队信息获取请求的情况下，作为排队信息查询方的客服系统从数据库里通过结构化查询语言(SQL，Structured Query Language)计算排队的信息，并将计算结果发送给客户端。上述方案虽然可以实现对于排队信息的更新，但是也存在着弊端。例如，上述方案的发起者是客户端，会存在一些干扰因素。例如，干扰因素可以包括客户端在发出排队信息获取请求后，由于等候时间过长、网络不稳定等事由退出咨询，由此客服系统便执行了一次无效查询。又例如，干扰因素可以包括由于网络延时或者系统抖动造成客服系统无法成功接收排队信息获取请求，由此客服系统便无法执行查询操作。此外，上述方案中，客服系统在计算排序结果时通常采用扫表的方式。所谓扫表的方式是指从数据库的拉取所有还在排队的咨询请求，即，需要在数据库中读取所有行，然后过滤掉不符合选择条件的行，直到所有符合选择条件的记录返回为止，选择条件便可以是正在排队的咨询请求。由于数据库的队列是全量数据，因此扫表的方式对数据库压力较大，如果正在排队的咨询请求数量比较大，例如购物节常出现的百万数量级或千万数量级，由此可能导致由于扫表将数据库压垮。即，由于是全量数据的扫描，在稳定性方面无法满足要求，由此便会导致用户端无法及时的接收到排序结果，最终导致用户体验较差。

相关技术中还包括由服务端发起定时任务，以定期从数据库中拉取所有还在排队的使用者，然后对排队的使用者进行排序，排序之后再依次将排队信息推送到用户端。上述方法的弊端在于，由于是单一队伍，若遇到排队的使用者数量众多时，一次定时任务的执行过程会消耗较长时间。当排队信息推送到用户端时已较为滞后，无法满足实时性要求。用户端接收到的排序结果往往是滞后的甚至是错误的。此外，定时任务的运行过程包括对全量数据库的排序以及排序结果推送，上述过程会对硬件造成较大压力，影响其他任务的正常运行，同样存在稳定性无法满足要求的弊端。即，同样会导致用户端无法及时的接收到排序结果，最终导致用户体验较差。

图1为示例性的用于实现本申请实施例的方法的一个应用场景的示意图。本申请以电商平台为咨询请求发生的场景，以客服系统执行的动作为示例进行阐述。客服系统对接收到的由客户端发出的咨询请求进行解析，可以根据解析结果将咨询请求添加至对应的目标咨询队列中。图1所示为3个咨询队列，是根据咨询请求的内容划分的，在电商平台咨询场景下，咨询请求的内容可以大致分为售前、售后和投诉。示例性地，可以采用表格1的分组方式，对于接收到的咨询请求，可以先进行解析，以确定出解析结果。进而根据解析结果，将咨询请求添加至对应的队列。例如，对于咨询请求1，解析结果为售前类型，则可以添加至售前咨询队列。对于咨询请求n，解析结果为售后类型，则可以添加至售后咨询队列。不难理解，如果是其他场景，咨询请求的内容划分方式略有不同。示例性地，可以采用表格2的分组方式，表格2与表格1的差异在于对咨询请求的分类，具体而言，表格2中可以对咨询请求的内容按照不同垂类划分咨询队列，例如购买服装类的咨询队列、购买电子产品类的咨询队列、购买食品类的咨询队列等。

咨询请求	类型
		咨询请求1	售前类型
咨询请求2	售前类型
		……	……
咨询请求n	售后类型

表格1

咨询请求	类型
		咨询请求1	电子产品类
咨询请求2	食品类
		……	……
咨询请求n	服装类

表格2

此外，结合表格3所示，对于售前、售后和投诉三个类型，还可以进一步进行细化。例如，可以根据发起咨询请求的使用者的级别，对类型进行细化。例如，对于售前类型，可以拆分为高优先级用户对应的第一售前类型、中优先级用户对应的第二售前类型和低优先级用户对应的第三售前类型。对应的，处理第一售前类型的咨询请求的客服资源的数量可以多于处理第二售前类型的咨询请求的客服资源的数量。同理，对于售后类型和投诉类型，也可以通过细化的方式进行拆分。由此，通过将类型进行拆分的方式实现咨询队列的去中心化，从而缩短每个咨询队列的查询时间，满足查询的时效性要求。

咨询请求	类型	咨询请求优先级	细化结果
				咨询请求1	售前类型	高优先级	第一售前类型
咨询请求2	售前类型	中优先级	第二售前类型
				……	……	……	……
咨询请求n	售后类型	低优先级	第三售后类型

表格3

将咨询请求添加至对应的目标咨询队列后，会在目标咨询队列中为咨询请求分配一个号码，该号码可以对应图1中的取号，即咨询请求在目标咨询队列中的号码。在查询过程中，可以根据目标咨询队列中的叫号和咨询请求的取号，快速计算出咨询请求在目标咨询队列中的排序结果。进一步的，咨询请求在目标咨询队列中的号码可以是动态变化的。例如，当排在咨询请求之前的其他咨询请求在排队过程中离开时，咨询请求的号码会对应前移。所谓目标咨询队列中的叫号指的是在目标咨询队列中正占用客服资源的咨询请求所对应的号码。每个咨询请求进入目标咨询队列，均会被分配一个号码，由此，可以将目标咨询队列中正占用客服资源的咨询请求的最大号码作为目标咨询队列中的叫号。咨询请求的取号与标咨询队列中的叫号的差值，即为该咨询请求在目标咨询队列中的排序结果。由此，对于每个咨询请求的排队结果的查询只需要查询两个数值，通过简单的减法即可得到排队人数。即便在购物节等咨询请求激增的场景，也可以快速确定出每个查询请求所需要等待的情况，性能极高。通过配置查询时间，例如10秒一次查询，每次得到的排序结果都是实时情况，几乎没有任何延迟。示例性地，查询时间可以根据查询请求的数量动态配置。例如，基准时间为10秒一次查询，对应的查询请求的数量为500万人。如果查询请求的数量到达千万级别时，可以15秒查询一次，如果查询请求的数量到达两千万级别时，可以20秒查询一次。由此，可以缓解服务器的压力。尤其在购物节咨询请求数量激增的场景下，每一个咨询请求的排序结果的确定过程都可以作为一个单独的任务，而每个单独任务只需要进行一次两个数据的获取以及计算，计算简便性能极高，几乎没有延时。对于客户端而言，客户端可以及时接收到客服系统确定出的排序结果。用户通过客户端，可以查看排序的结果，例如，查看前面还有多少人等待或者查看等候的时长等，从而可以缓解用户的焦虑情绪，在便于等候的时间段可以安排其他事情。

本申请实施例提供了一种咨询队列显示方法，如图2所示为本申请一实施例的咨询队列显示方法的流程图，对应第一实施例，执行主体为即时通讯客户端，该方法可以包括：

步骤S201：将咨询请求发送至客服系统。

以电商平台的咨询请求为示例，咨询请求通常是用户在目标商品的相关页面通过指令触发的。例如，可以是点击咨询图标触发，也可以是语音唤醒触发等。目标商品的相关页面可以包括目标商品的购物页面、目标商品的物流信息页面、目标商品的评价页面、目标商品的退款/售后页面等。在用户通过目标商品的相关页面通过指令触发咨询请求后，即时通讯客户端即可将咨询请求发送至客服系统。对应的，上述场景可以是即时通讯客户端运行阿里小蜜、阿里旺旺等即时通讯软件时对应的场景。

步骤S202：将接收到的客服系统反馈的排序结果进行提示，排序结果是根据第一号码和第二号码确定的；第一号码是咨询请求在目标咨询队列中的号码，第二号码是目标咨询队列中排在咨询请求之前的正在占用客服资源的其他咨询请求的号码。

例如，在触发咨询请求后，可以在用户端显示咨询交互页面。当客户端接收到客服系统反馈的排序结果后，可以在咨询交互页面中进行提示。提示可以包括文字提示或语音提示等。排序结果可以是客服系统定期反馈的。定期可以是每间隔10秒钟反馈一次，也可以是每间隔1分钟反馈一次等，具体时间间隔可以依据客服系统的配置执行。排序结果的形式可以是等候时长，或者是在先的排队的咨询人数等。对于客服系统对于排序结果的确定过程，可以参照后续第二实施例中表述的具体过程，在此不再赘述。

每间隔指定时长，客户端即可接收到客服系统反馈的排序结果。该排序结果可以在咨询交互界面向用户进行文字或语音提示。结合图3所示，图3中左侧为第i个时刻客户端接收到的排序结果，i为正整数。在第i个时刻客户端发出的咨询请求排在428号。咨询请求被分配在售前队列。在该咨询请求之前，等候人数为50。所谓等候人数表示在售前队列中，还有50个其他咨询请求排在当前咨询请求之前。预计等候时间为50分钟。图3中右侧为第i+n个时刻客户端接收到的排序结果，n为正整数。在第i+n个时刻客户端发出的咨询请求排在420号，相比于428号前进了8位，这是由于客服系统检测到排在咨询请求之前的8个其他咨询请求出现退出排队的情况，从而改变当前咨询请求的序号，即，使得客户端对应的咨询请求前进了8位。而在先等候人数由50变为46，表示客服已完成了4个其他咨询请求的处理。等候时长可以是根据每个咨询请求的处理时长估算的。

通过上述过程，用户在发起咨询请求后，便可定期接收到客服系统主动发来的排序结果。通过排序结果的实时显示，可以在一定程度上缓解用户在排队过程中的焦虑。

在一种实施方式中，步骤S201所涉及的咨询请求的生成过程，可以包括：

步骤S2011：响应于咨询请求的触发指令，获取用户的标识信息。

标识信息可以包括咨询请求对应的用户注册的名称信息或订单编号中的至少一个。示例性地，由于咨询请求通常是用户在目标商品的相关页面通过指令触发的，而相关页面包括目标商品的物流信息页面、目标商品的评价页面、目标商品的退款/售后页面等，上述页面均已表征用户已购买过目标商品。因此，可以从上述页面中获取与目标商品相关的订单编号。

此外，咨询请求还可以是在目标商品的购物页面通过咨询触发指令触发的，该页面表征用户可能尚未购买目标商品，由此可以获取用户在电商平台的所注册的名称信息。

步骤S2012：利用标识信息，生成咨询请求。

可以将标识信息作为生成咨询请求的附加信息。例如，可以在咨询交互界面中显示订单编号或者名称信息，以使得客服系统可以基于标识信息进行咨询请求对应的类别的确定，进而根据类别，将咨询请求添加至对应的目标咨询队列。

在一种实施方式中，排序结果包括目标咨询队列中排在咨询请求之前的处于等候状态的其他咨询请求的数量、咨询请求的等候时长中的至少一种。

客服系统所发送的排序结果可以包括两类，第一类是数量，第二类是时间。所谓数量即对应目标咨询队列中排在咨询请求之前的处于等候状态的其他咨询请求的数量，也就是图3中的在先等候人数。时间可以是客服系统基于指定时间段的咨询请求处理效率预估出来的。指定时间段的咨询请求处理效率可以是当日客服对每个咨询请求处理的平均时长，也可以是历史同期客服对每个咨询请求处理的平均时长。所谓历史同期可以是指，将一天按照小时平均划分为24或48个时间段，根据咨询请求发生的时间段，确定出的过去3天或者过去7天的同一时间段。在确定出客服对每个咨询请求处理的平均时长为1分钟的情况下，目标咨询队列中尚有50个其他咨询请求排在前面的情况，可以预估出等候时间信息为50分钟。

本申请实施例提供了一种咨询请求队列管理方法，如图4所示为本申请一实施例的咨询请求队列管理方法的流程图，执行主体为即时通讯客服系统，对应第二实施例，该方法可以包括：

步骤S401：对接收到的咨询请求进行解析，得到解析结果。

本申请的执行主体可以是客服系统，客服系统在接收到客户端的咨询请求后，向客户端提供针对该咨询请求的排队信息。客服资源可以对咨询请求进行处理，客服资源是由多个客服组成的，每个客服可以包括人工客服。客服用于解决客户端的售前咨询、投诉、售后等相关问题。客服资源的分配可以通过客服调配系统实现，调配过程后文详述。客户端可以是电商平台的使用者，示例性地，使用者可以包括消费者、商家、快递员等。接收咨询请求的渠道可以包括咨询请求交互页面等。

以电商平台为咨询请求发生的场景为示例，通常而言，咨询请求是基于某件商品的，因此，如果使用者未购买该商品，则可以利用简便的解析方式确定为属于售前咨询的解析结果。如果使用者已购买该商品，如果是未确收的状态，则可以利用简便的解析方式确定为属于售后咨询的解析结果，如果是已确收的状态，则可以利用简便的解析方式确定为投诉咨询的解析结果。此外，简便的解析方式还可以基于使用者的身份或等级进行，以得到解析结果。以身份为示例，解析结果可以是消费者、商家、快递员等。使用者的身份在使用者登录客服系统时即可完成确认。以等级为示例，解析结果可以是普通会员、付费会员、VIP会员等。

步骤S402：将咨询请求添加至目标咨询队列，目标咨询队列是依据解析结果，从多个候选咨询队列中选择的。

在确定出解析结果后，即可根据解析结果，将咨询请求添加至目标咨询队列。目标咨询队列是从候选咨询队列中选择的，候选咨询队列可以是预先构建的，根据不同的场景可以构建多个候选咨询队列。

如果是电商平台场景，候选咨询队列可以包括售前咨询队列、售后咨询队列、投诉咨询队列等。此外，对于每个咨询队列，还可以进一步细分。例如，对于售前咨询队列，还可以细分为第一售前咨询队列、第二售前咨询队列、第三售前咨询队列等。示例性地，第一售前咨询队列可以对应VIP会员，第二售前咨询队列可以对应普通注册会员，第三售前咨询队列可以对应非会员。

例如，咨询请求的解析结果为VIP会员针对收货时间的咨询时，根据收货时间的咨询可以将候选咨询队列的范围缩减，缩减至售后咨询队列。进一步的，根据VIP会员的属性，可以在售后咨询队列中将第三售后咨询队列确定为目标咨询队列，从而将咨询请求添加至第三售后咨询队列。此时，可以根据第三售后咨询队列中已有的排队人数进行号码分配，得到第一号码。所谓已有排队人数可以是在咨询请求加入第三售后咨询队列时，第三售后咨询队列已有的人数。在先已有的人数可以每24小时进行一次清零，即，可以在0点时更新队列的排队人数。

步骤S403：确定并反馈排序结果；其中，排序结果是根据第一号码和第二号码确定的；第一号码是咨询请求在目标咨询队列中的号码，第二号码是目标咨询队列中排在咨询请求之前的正在占用客服资源的其他咨询请求的号码。

目标咨询队列中的咨询请求在添加至目标咨询队列后会被分配第一号码，目标咨询队列中占用客服资源的其他咨询请求对应第二号码。第二号码可以对应正在被客服资源服务的咨询请求对应的号码。排序结果可以基于第一号码和第二号码的差值确定。例如，第一号码和第二号码的差值为10，可以表示目标队列中尚有10个其他咨询请求在前面排队。在确定出排序结果后，该排序结果即可实时发送给客户端，以便在客户端向用户进行排序结果的提示，方便用户第一时间获悉排队情况。此外，排序结果还可以是等候时间的信息。例如，在基于第一号码和第二号码的差值确定目标咨询队列中尚有10个其他咨询请求排在前面的情况，可以基于指定时间段的咨询请求处理效率，预估出等候时长。指定时间段的咨询请求处理效率可以是当日客服资源对每个咨询请求处理的平均时长，也可以是历史同期客服资源对每个咨询请求处理的平均时长。所谓历史同期可以是指，将一天按照小时平均划分为24或48个时间段，根据咨询请求发生的时间段，确定出过去3天或者过去7天等的同一时间段。例如，在确定出客服资源对每个咨询请求处理的平均时长为2分钟的情况下，目标咨询队列中尚有10个其他咨询请求排在前面的情况，可以预估出等候时间信息为20分钟。

第一号码的变化情况可以是在出现消号时导致的。例如，如果第一号码前的其他咨询请求出现退出排队的情况，则第一号码可以根据消号的发生而变化。第二号码是占用服务资源的号码，随着前一个咨询的结束，第二号码也会随之变化。

由此，在确定排序结果时，由于目标咨询队列是从多个候选咨询队列中选择的，使得整个过程是去中心化的，即便目标咨询队列出现单点问题，也不会影响全局的其他队列中的排序结果的计算，稳定性会提高。此外，排序结果的确定无需进行号码遍历而只需要获取第一号码和第二号码两个数字进行减法计算即可快速确定出排序结果，消耗的资源会更少，得到计算结果的时间也会更短，即便在购物节等咨询请求激增的场景，也可以快速确定出每个查询请求所需要等待的情况，效率方便会有保障。此外，由于第一号码和第二号码是动态变化的，使得根据第一号码和第二号码计算出的排序结果更为准确。

在一种实施方式中，步骤S401中涉及的解析结果的确定方式，可以包括：

步骤S4011：预测咨询请求对应的类别。

对于预测出的咨询请求对应的类别，可以采用多个维度表示，也可以采用多个维度中的任一维度表示。结合表格4所示，例如，维度可以是与咨询请求的阶段相关的(对应表格4中的以阶段划分类别)，也可以是与使用者的身份相关的(优先级)，还可以是与咨询请求的对象相关的(对应表格4中的以内容划分类别)。以阶段划分类别可以是售前类别、售后类别或者投诉类别等。以内容划分类别可以是不同的商品，如电子产品类、服装类、食品类等。示例性地，以内容划分类别可以通过对咨询请求的内容进行识别而实现解析。对咨询请求的内容进行识别可以通过自动化的形式完成，例如，可以预先配置引导内容，从而基于咨询请求中对引导内容的答复确定咨询请求对应的类别。引导内容可以包括“请问您想咨询哪一类问题，售前类、售后类还是投诉类”。或者，对咨询请求的内容进行识别可以通过语音识别技术或文字识别技术等，通过关键词的抓取实现类别的确定。

咨询请求	以阶段划分类别	以内容划分类别	优先级
				咨询请求1	售前类别	电子产品类	高优先级
咨询请求2	售后类别	食品类	中优先级
				……	……	……	……
咨询请求n	投诉类别	服装类	低优先级

表格4

步骤S4012：确定咨询请求对应的优先级。

咨询请求对应的优先级可以基于用户的身份进行确定。仍然结合表格4所示，例如，用户的身份可以包括普通注册会员、非会员、VIP会员等。不同的身份可以配置与身份对应的优先级。例如，VIP会员可以对应高优先级、普通注册会员可以对应中优先级、非会员可以对应低优先级。使用者身份在使用者登录电商平台后即可获取。

步骤S4013：根据类别和优先级，确定解析结果。

在确定出咨询请求对应的优先级、咨询请求的类别等解析结果后，即可基于解析结果确定目标咨询队列。例如，可以先根据咨询请求的类别进行候选咨询队列的一次范围缩减、再根据使用者的身份进行二次范围缩减，最终确定目标咨询队列。

在一种实施方式中，步骤S4011中涉及的预测咨询请求对应的类别，包括：

步骤S40111：从咨询请求中获取用户的标识信息；标识信息包括咨询请求对应的用户注册的名称信息或订单编号中的至少一个。

以电商平台的咨询请求为示例，咨询请求通常是在目标商品的相关页面触发的。目标商品的相关页面可以包括目标商品的购物页面、目标商品的物流信息页面、目标商品的评价页面、目标商品的退款/售后页面等。由此，可以将咨询请求与目标物品建立关联，此外，还可以从目标商品的相关页面获取目标商品的商品信息、物流信息、用户的评论信息等。商品信息可以包括商品参数等。

在接收到咨询请求后，可以从咨询请求中获取用户的标识信息。例如，接收到用户在目标商品的相关页面触发的咨询请求，可以将用户在电商平台注册的名称信息作为用户的标识信息。又例如，接收到用户在目标商品的物流信息页面、目标商品的评价页面、目标商品的退款/售后页面等相关页面触发的咨询请求，可以将订单编号作为用户的标识信息。

步骤S40112：根据标识信息确定分类参照信息，分类参照信息包括用户是否已购买目标商品、用户是否确认收到目标商品、确认收到目标商品的时间中的至少一种。

根据标识信息，可以对用户的购物记录进行查询。例如，查询结果可以包括用户是否已购买目标商品，对应的，查询结果可以包括用户未购买目标商品，或者用户已购买目标商品。

对于用户已购买目标商品的情况，根据标识信息可以查询到该用户的订单，从而基于订单即可获取到对应的物流信息。也就可以查询到用户是否已确认收到目标商品。

对于用户已确认收到目标商品的情况，还可以进一步基于物流信息，确定用户确认收到目标商品的时间。

步骤S40113：根据分类参照信息，预测咨询请求对应的类别。

如果分类参照信息为用户未购买目标商品，则可以预测咨询请求对应的类别为售前类别。

如果分类参照信息为用户已购买商品，但尚未确认收货，则可以预测咨询请求对应的类别为售后类别。

如果分类参照信息为用户已购买商品，且已确认收货。收货时刻距离收到咨询请求的时刻短于指定时长，则可以预测咨询请求对应的类别为售后类别或投诉类别。指定时长可以是根据历史经验确定的，如7天、14天等。

如果分类参照信息为用户已购买商品，且已确认收货。收货时刻距离收到咨询请求的时刻长于指定时长，则可以预测咨询请求对应的类别为投诉类别。

此外，对于咨询请求对应的类别的预测，还可以基于对咨询请求进行语义识别进行。通过语义识别可以得到咨询请求的识别结果，进而基于识别结果预测咨询请求对应的类别。或者，对于咨询请求对应的类别的预测，还可以基于前文述及的通过用户对引导内容的选择或答复进行。

在一种实施方式中，步骤S403中涉及的排序结果的确定方式，可以包括：

步骤S4031：执行为咨询请求配置的查询任务；查询任务是在咨询请求添加至目标咨询队列后配置的，包括查询目标、查询时间间隔和查询停止条件；查询目标包括第一号码和第二号码。

将咨询请求添加至目标咨询队列后，即可为咨询请求配置查询任务。配置查询任务至少需要包括配置查询目标、配置查询时间间隔以及配置查询停止条件。

查询目标即为第一号码和第二号码。即，根据第一号码和第二号码的差值即可确定出排序结果。

查询时间间隔可以对应查询周期。配置查询时间间隔可以通过延迟消息的方式实现。例如，可以在消息队列中注册延迟消息，延迟消息对应的延迟时间以及延迟消息的发送周期可以根据具体情况进行配置。示例性地，延迟时间和发送周期的配置可以相同，例如可以配置为10秒、20秒等。即可以理解为每间隔10秒或每间隔20秒，将延迟消息周期性地发送至消息队列，在10秒或20秒后，收到延迟消息的回调。由此即可实现查询周期的配置。

配置停止条件可以是咨询请求被分配客服资源。前已述及，查询任务是周期性执行的。由此，需要设置查询任务停止的触发条件。具体而言，查询任务停止的触发条件可以是咨询请求被分配客服。当咨询请求被分配客服后，即可停止对该咨询请求的查询任务。

如果咨询请求未被分配客服资源，即该咨询请求仍处于排队等待的阶段，那么就表示需要继续执行该咨询请求的查询任务。前已述及，查询任务是通过延迟消息的方式执行的。因此，将咨询请求添加至目标咨询队列后即可注册延迟消息。在到达延迟时间时会收到延迟消息的回调。响应于延迟消息的回调，可以从存储设备中获取查询目标，也就是获取第一号码和第二号码。此处的存储设备可以是缓存也可以是数据库。较佳的，存储设备可以是缓存。即，咨询请求添加至目标咨询队列时所获取的第一号码，以及目标咨询队列中占用客服资源的其他咨询请求对应的第二号码，都会存储至缓存中。

步骤S4032：利用执行查询任务获得的查询目标，确定排序结果。

前已述及，查询目标包含咨询请求对应的第一号码，以及目标咨询队列中占用客服资源的其他咨询请求对应的第二号码。因此，可以计算第一号码与第二号码的差值，该差值即可表征咨询请求在目标咨询队列中的排序结果。示例性地，如果该差值为10，则表示在该咨询请求前还有10个其他咨询请求在排队等待。另外，也可以根据过完一段时间已经结束咨询的每个咨询请求的咨询时长，计算平均时长。利用差值和平均时长的乘积，可以得到预估的等候时长。预估的等候时长也可以作为排序结果。

通过上述过程，可以实现周期性的更新排序结果，从而满足实时性的要求。此外，由于排序结果的确定只需要依赖第一号码和第二号码两个参数，计算过程更为简便。

在一种实施方式中，步骤S403中涉及的第一号码是动态调整的，调整过程可以包括：

步骤S4033：响应于检测指令，由第二号码向后进行遍历，对是否存在消号进行检测；检测指令是以指定时间间隔生成，或是检测到的客服资源的分配情况发生变更生成的。

检测指令可以是以指定时间间隔触发生成的，例如，指定时间间隔可以是10秒钟、1分钟等。此外，检测指令也可以是客服资源的分配情况发生变更生成的。示例性地，如果目标咨询队列中排序在第i位的咨询请求结束咨询，将客服分配给排序在第i+1位的咨询请求，即可以对应客服资源的分配情况发生变更，i为正整数。

第二号码为目标咨询队列中正占用客服资源的其他咨询请求对应的号码，即第二号码可以理解为已被叫号的号码。响应于检测指令，可以对是否存在消号进行检测。由于使用者在提交咨询请求后，可能存在在排队过程中离开的情况，由此，可以在接收到检测指令后，便由第二号码向后进行遍历，对是否存在消号进行检测，从而可以提高排序结果更新的准确性。所谓向后进行遍历是指，如果第二号码是2，则依次遍历号码3、号码4等在后的号码是否存在消号的情况。

消号是使用者触发的，因此在使用者退出目标咨询队列时，客服系统会接收到咨询请求取消的相关信息。结合图1中的投诉排队队列所示，以第二号码更新为遍历的触发指令为例进行说明，在2号咨询请求的咨询结束，为排在3号的咨询请求分配客服资源时可以作为第二号码的更新，即此时第二号码由2号变更为3号。此时，可以对3号后面的其他号码对应的咨询请求进行遍历，以检测是否存在消号。在图1所示的情况中，存在号码6消号的情况。

步骤S4034：在检测结果为存在消号的情况下，根据消号的数量，对第一号码进行调整。

如果未检测到消号，则第一号码的数值无需进行调整。反之，若检测到存在消号时，可以首先确定消号的数量。例如图5中只有6号消号的情况下，消号的数量为1。由此可以对第一号码进行调整。仍以图5中的投诉排队队列为示例，投诉排队队列中，当前的咨询请求对应的第一号码为8号。投诉排队队列中的第二号码为3号。在检测结果为存在6号消号的情况下，可以对应将第一号码由8号调整为7号。不难理解，如果是将第一号码调整为7号，则原有的7号也会顺应调整为6号。即，对于消号的情况，则将被消除号码后的其他号码根据消号的数量依次向前顺延调整。不难理解，如果图5中存在4号、6号消号的情况下，消号的数量为2。对于原来的5号而言，5号前向有1个消号，则5号调整为4号。对于7号、8号而言，7号、8号前向均有2个消号，则7号调整为5号，8号调整为6号。

由此，通过由第二号码向后进行遍历，可以对可能出现的消号情况进行及时了解。从而及时对第一号码进行调整，便于排序结果的准确更新。

在一种实施方式中，步骤S403中涉及的第二号码是动态调整的，调整过程可以包括：

步骤S4035：在目标咨询队列中，检测到客服资源的分配情况在新的咨询请求被分配客服资源的发生变更的情况下，比较被分配客服资源的各其他咨询请求所对应号码的大小。

理想情况下，咨询请求是按照号码排序从小到大的顺序被分配客服资源的，在客服资源的分配情况发生变更情况后，即可生成一条资源分配消息。资源分配消息可以作为第二号码调整的依据。例如，图1中投诉排队队列中的3号作为新的咨询请求被分配客服资源后，资源分配消息用于表征客服资源的分配情况发生变更，即出现3号被分配客服资源的事件。对应的，资源分配消息也是基于号码排序从小到大依次生成的以及送达的。在实际场景中，可能会同时有多个咨询请求被分配客服资源，但由于可能存在的网络不稳定、系统抖动、或者补充客服资源等情况。对此，可能会先接收到排序大的号码对应的资源分配消息，后接收到排序大的号码对应的资源分配消息。以图5中的投诉排队队列为示例，客服资源的分配情况发生变更情况对应号码2和号码3对应的咨询请求几乎同时被分配客服资源，由于发生网络不稳定的情况，号码3对应的资源分配消息先于号码2对应的资源分配消息生成或到达，由此，虽然号码2和号码3对应的咨询请求都被分配客服资源，但是需要比较号码2和号码3的大小。

步骤S4036：根据比较的结果，对第二号码进行调整。

前已述及，理想情况下，咨询请求是按照号码排序从小到大的顺序被分配客服资源的，对应的，资源分配消息也是基于号码排序从小到大依次生成的以及送达的。例如，图5中号码1结束咨询后，客服资源的分配情况发生变更情况对应号码2和号码3对应的咨询请求几乎同时被分配客服资源，由于发生网络不稳定的情况，号码3对应的资源分配消息先于号码2对应的资源分配消息生成或到达。由此，在号码2对应的资源分配消息生成或到达后，比较结果为号码2小于号码3，则无需再更新第二号码。仍然可以参考图5，对应另一个示例，如果号码2至号码4先后被叫号，号码2至号码4对应的咨询请求几乎同时被分配客服资源，号码2和号码4对应的资源分配消息同时生成或到达，则根据比较结果，号码4大于号码2，由此将号码4确定为第二号码。此后，号码3对应的资源分配消息生成或到达，根据比较结果，号码3小于号码4，则无需更新第二号码，仍将号码4确定为第二号码。

通过上述比较已分配客服资源的各咨询请求所对应号码的大小的过程，可以保障第二号码的准确性。由于网络不稳定、系统抖动、或者补充客服资源等情况发生时，第二号码的频繁变更。

在一种实施方式中，还可以包括：

第一号码和第二号码存储于缓存数据库中，缓存数据库基于目标咨询队列中的咨询请求的数量分配缓存资源。

在本申请实施方式中，第一号码和第二号码存储于缓存数据库。缓存数据库中的资源分配可以基于令牌桶进行管理。令牌桶中的令牌数量和在咨询队列中排队的咨询请求的数量是正相关的。如果咨询队列中排队的咨询请求的数量多，则可以对应多分配令牌。如果咨询队列中排队的咨询请求的数量少，则可以对应少分配令牌。相比于基于经验值或其他方式预先分配缓存数据库的资源造成的浪费或者需要不断调控，本申请的方式使得缓存数据库的资源与实际需求挂钩，根据实际需求对缓存数据库所需资源进行管理，不存在浪费或者不断调控的弊端。

本申请实施例提供了一种客服资源管理方法，如图6所示为本申请一实施例的客服资源管理方法的流程图，应用于即时通讯客服调配系统，对应第三实施例，该方法可以包括：

步骤S601：获取目标咨询队列的排序结果，排序结果是根据第一实施例中涉及的方法确定的。

目标咨询队列可以是一个队列，也可以是多个队列。例如，在邻近春节阶段，目标咨询队列可以是购买食品的售前咨询队列。在邻近国庆节阶段，目标咨询队列可以选择购买旅游产品的售前咨询队列。在电子产品购物节阶段，目标咨询队列可以选择电子产品的售前咨询队列、售后咨询队列和投诉队列。上述目标咨询队列可以是根据咨询队列的实时排队情况，或者咨询队列的历史同期排队情况确定的。

步骤S602：利用排序结果以及客服的处理能效，对客服资源进行调配。

目标咨询队列的排序结果可以反应目标咨询队列的热度。对应的，可以预置排序结果阈值。排序结果阈值可以是多个，分别对应队列非常拥挤、一般拥挤、不拥挤等。如果排序结果超过非常拥挤对应的阈值，可以表示队列中的等待人数非常多。利用排序结果，可以进行增加客服资源，减少客服资源或维持客服资源不变等调配。

客服的处理能效可以表征客服在未来一段时间可处理的咨询请求的数量。客服的处理能效是根据客服对咨询请求的处理历史和客服上报的可处理的咨询请求的数量中的至少一种确定的，示例性地，可以根据客服过去一段时间处理的咨询请求的数量确定处理能效。也可以根据客服上报的可处理的咨询请求的数量，确定处理能效。例如，第一客服过去1小时处理52个咨询请求，上报的未来1小时可处理的咨询请求的数量为50个，在计算处理能效时，可以基于平均值，确定第一客服未来一小时可以处理51个咨询请求。第二客服，过去1小时处理60个咨询请求，上报的未来1小时可处理的咨询请求的数量为30个，可以基于平均值，确定第二客服未来一小时可以处理40个咨询请求。上述采用平均值计算仅是一个计算示例，另外，也可采用加权平均值的方式进行计算，即，为客服的服务历史数据分配第一权重，为客服上报的可处理的咨询请求的数量分配第二权重，从而进行加权平均值的方式确定处理能效。利用处理能效，可以对分配给每个客服的资源请求的数量进行调配。

此外，还可以基于处理能效和排序结果，进行增加客服人数，减少客服人数等调配。例如，基于处理能效，检测出未来一段时间仍然存在较多排队等候的咨询请求，由此，可以增加客服资源。

通过上述过程，可以依据目标咨询队列的排序结果实现对于客服资源的自动化、精准化调整。根据实际情况安排客服资源，以实现客服资源的最优配置。

在一种实施方式中，还可以包括以下步骤：

步骤S603：检测待分配客服的咨询请求的咨询历史。

对于电商咨询而言，经常会发生用户间歇性的发起咨询请求。例如，用户在完成第一次咨询后，间隔半小时又再次发起咨询请求。对于用户方而言，两次咨询的对象相同，都是目标商品的客服。然而对于客服调配系统而言，可进行调配的客服人员通常会有多个。因此，最理想的情况而言是使得同一客服，对接同一用户的前后两次咨询，从而可以使得用户有较好的服务体验。基于此，对于待分配客服的咨询请求，可以首先检测该咨询请求的咨询历史。

步骤S604：根据咨询历史，确定目标客服；目标客服为根据咨询历史确定的处理前次咨询的客服。

如果存在咨询历史，可以基于前次咨询请求进行客服分配。例如，如果前次咨询请求距离本次咨询请求的时长未超过预定时长间隔，可以将处理前次咨询请求的客服作为目标客服。预定时长间隔可以是1天、2天等。即，如果在较短时间内，客服通常对处理的咨询请求有一定印象，由此在进行分配时可以使同一客服，对接同一用户的前后两次咨询。从而降低用户的二次沟通成本，以及提高客服的处理效率。

步骤S605：将待分配客服的咨询请求分配给目标客服。

将待分配客服的咨询请求分配给目标客服，一方面可以使目标客服继续跟进在先的咨询请求，另一方面可以降低用户的二次沟通成本，给用户更好的咨询体验。

本申请实施例提供了一种客服资源管理方法，如图7所示为本申请一实施例的咨询请求的处理方法的流程图，应用于即时通讯客服端，对应第四实施例，该方法可以包括：

步骤S701：获取已分配咨询请求在目标咨询队列的排序结果，排序结果是根据第一实施例中涉及的方法确定的。

目标咨询队列可以是一个队列，也可以是多个队列。例如，在邻近春节阶段，目标咨询队列可以是购买食品的售前咨询队列。在邻近国庆节阶段，目标咨询队列可以选择购买旅游产品的售前咨询队列。在电子产品购物节阶段，目标咨询队列可以选择电子产品的售前咨询队列、售后咨询队列和投诉队列。上述目标咨询队列可以是根据咨询队列的实时排队情况，或者咨询队列的历史同期排队情况确定的。

步骤S702：根据已分配咨询请求在目标咨询队列的排序结果，确定已分配咨询请求的处理优先级。

理想情况下，客服每次可以处理一个咨询请求，对于每个咨询请求进行串行处理。所谓串行处理可以是结束当前咨询请求的处理后，再处理下一个咨询请求。但在咨询量极大的情况下，客服也存在着同时处理多个咨询请求的情况。结合图8所示，图8中，客服正在同时处理3个咨询请求。3个咨询请求在目标咨询队列的排序结果分别为18、19和20。即，客服调配系统在进行咨询请求的分配后，客服端可以根据被分配来的咨询请求的排序结果，确定已分配咨询请求的处理优先级。

可以以排序结果中数值最小的咨询请求所对应的处理优先级最高。在同时接到排序结果分别为18、19和20的三个用户的咨询问题后，可以率先依据排序结果，处理18号咨询请求的的咨询问题。

由此，利用排序结果作为处理优先级，在同时处理多个咨询请求的场景下，可以区分轻重缓急，根据优先级处理已分配的咨询请求，对于客服端处理咨询请求的先后顺序提供建议。

与本申请实施例提供的方法的应用场景以及方法相对应地，本申请实施例还提供一种咨询队列显示装置。如图9所示为本申请一实施例的咨询队列显示装置的结构框图，该咨询请求队列显示装置可以包括：

发送模块901，用于将咨询请求发送至客服系统；

提示模块902，用于将接收到的客服系统反馈的排序结果进行提示，排序结果是根据第一号码和第二号码确定的；第一号码是咨询请求在目标咨询队列中的号码，第二号码是目标咨询队列中排在咨询请求之前的正在占用客服资源的其他咨询请求的号码。

在一种实施方式中，发送模块901，可以包括：

标识信息获取子模块，用于响应于咨询请求的触发指令，获取用户的标识信息；

咨询请求生成子模块，用于利用标识信息，生成咨询请求。

在一种实施方式中，排序结果包括目标咨询队列中排在咨询请求之前的处于等候状态的其他咨询请求的数量、咨询请求的等候时长中的至少一种。

与本申请实施例提供的方法的应用场景以及方法相对应地，本申请实施例还提供一种咨询请求队列管理装置。如图10所示为本申请一实施例的咨询请求队列管理装置的结构框图，该咨询请求队列管理装置可以包括：

解析模块1001，用于对接收到的咨询请求进行解析，得到解析结果；

咨询请求添加模块1002，用于将咨询请求添加至目标咨询队列；目标咨询队列是根据解析结果，从多个候选咨询队列中选择的；

排序结果反馈模块1003，用于确定并反馈排序结果；其中，排序结果是根据第一号码和第二号码确定的；第一号码是咨询请求在目标咨询队列中的号码，第二号码是目标咨询队列中排在咨询请求之前的正在占用客服资源的其他咨询请求的号码。

在一种实施方式中，解析模块1001，可以包括：

类别确定子模块，用于确定咨询请求对应的类别；

优先级确定子模块，用于确定咨询请求对应的优先级；

解析结果确定子模块，用于根据类别和优先级，确定解析结果。

在一种实施方式中，类别确定子模块，可以包括：

标识信息获取单元，用于从咨询请求中获取用户的标识信息；

分类参照信息确定单元，用于根据标识信息确定分类参照信息，分类参照信息用于表征用户是否已购买目标商品、用户是否确认收到目标商品、确认收到目标商品的时间中的至少一种；

类别确定执行单元，用于根据分类参照信息，预测咨询请求对应的类别。

在一种实施方式中，排序结果反馈模块1003，可以包括：

查询任务执行子模块，用于执行为咨询请求配置的查询任务；查询任务是在咨询请求添加至目标咨询队列后配置的，包括查询目标、查询时间间隔和查询停止条件；查询目标包括第一号码和第二号码；

排序结果确定执行子模块，用于利用执行查询任务获得的查询目标，确定排序结果。

在一种实施方式中，排序结果反馈模块1003，还可以包括：

消号检测子模块，用于响应于检测指令，由第二号码向后进行遍历，对是否存在消号进行检测；检测指令是以指定时间间隔生成，或是检测到的客服资源的分配情况发生变更生成的；

第一号码调整子模块，用于在检测结果为存在消号的情况下，根据消号的数量，对第一号码进行调整。

在一种实施方式中，排序结果反馈模块1003，还可以包括：

号码比较单元，用于在目标咨询队列中，检测到客服资源的分配情况在新的咨询请求被分配客服资源的发生变更的情况下，比较被分配客服资源的各其他咨询请求所对应号码的大小；

第二号码调整子模块，用于根据比较的结果，确定第二号码。

在一种实施方式中，第一号码和第二号码存储于缓存数据库中，缓存数据库基于目标咨询队列中的咨询请求的数量分配缓存资源。

与本申请实施例提供的方法的应用场景以及方法相对应地，本申请实施例还提供一种客服资源管理装置。如图11所示为本申请一实施例的客服资源管理装置的结构框图，该装置可以包括：

排序结果获取模块1101，用于获取目标咨询队列的排序结果，排序结果是根据第一实施例中涉及的方法确定的；

客服资源调配模块1102，用于利用排序结果以及客服的处理能效，对客服资源进行调配。

在一种实施方式中，该装置还可以包括：

咨询历史检测模块，用于检测待分配客服的咨询请求的咨询历史；

目标客服确定模块，用于根据咨询历史，确定目标客服；目标客服为根据咨询历史确定的处理前次咨询的客服；

分配模块，用于将待分配客服的咨询请求分配给目标客服。

与本申请实施例提供的方法的应用场景以及方法相对应地，本申请实施例还提供一种咨询请求的处理装置。如图12所示为本申请一实施例的咨询请求的处理装置的结构框图，该装置可以包括：

排序结果获取模块1201，用于获取已分配的咨询请求在目标咨询队列的排序结果，排序结果是根据第一实施例中涉及的方法确定的；已分配的咨询请求为分配给客服端的多个咨询请求。

优先级确定模块1202，用于根据已分配的咨询请求在目标咨询队列的排序结果，确定已分配的咨询请求的处理优先级。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

本申请实施例各装置中的各模块的功能可以参见上述方法中的对应描述，并具备相应的有益效果，在此不再赘述。

图13为用来实现本申请实施例的电子设备的框图。如图13所示，该电子设备包括：存储器1310和处理器1320，存储器1310内存储有可在处理器1320上运行的计算机程序。处理器1320执行该计算机程序时实现上述实施例中的方法。存储器1310和处理器1320的数量可以为一个或多个。

该电子设备还包括：

通信接口1330，用于与外界设备进行通信，进行数据交互传输。

如果存储器1310、处理器1320和通信接口1330独立实现，则存储器1310、处理器1320和通信接口1330可以通过总线相互连接并完成相互间的通信。该总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(PeripheralComponent Interconnect，PCI)总线或扩展工业标准体系结构(Extended IndustryStandard Architecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图13中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器1310、处理器1320及通信接口1330集成在一块芯片上，则存储器1310、处理器1320及通信接口1330可以通过内部接口完成相互间的通信。

本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现本申请实施例中提供的方法。

本申请实施例还提供了一种芯片，该芯片包括处理器，用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的通信设备执行本申请实施例提供的方法。

本申请实施例还提供了一种芯片，包括：输入接口、输出接口、处理器和存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处理器用于执行存储器中的代码，当代码被执行时，处理器用于执行申请实施例提供的方法。

应理解的是，上述处理器可以是中央处理器(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(FieldProgrammable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器(Advanced RISC Machines，ARM)架构的处理器。

进一步地，可选的，上述存储器可以包括只读存储器和随机访问存储器。该存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以包括只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以包括随机访问存储器(RandomAccess Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM均可用。例如，静态随机访问存储器(Static RAM，SRAM)、动态随机访问存储器(Dynamic RandomAccess Memory，DRAM)、同步动态随机访问存储器(SynchronousDRAM，SDRAM)、双倍数据速率同步动态随机访问存储器(Double Data Rate SDRAM，DDRSDRAM)、增强型同步动态随机访问存储器(Enhanced SDRAM，ESDRAM)、同步链接动态随机访问存储器(Sync link DRAM，SLDRAM)和直接内存总线随机访问存储器(Direct RambusRAM，DR RAM)。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生依照本申请的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

流程图中描述的或在此以其他方式描述的任何过程或方法可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。

在流程图中描述的或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。

应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。

以上所述，仅为本申请的示例性实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请记载的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (14)

1.一种咨询队列显示方法，其特征在于，应用于即时通讯客户端，包括：

将咨询请求发送至客服系统；

将接收到的所述客服系统反馈的排序结果进行提示，所述排序结果是根据第一号码和第二号码确定的；所述第一号码是所述咨询请求在目标咨询队列中的号码，所述第二号码是所述目标咨询队列中排在所述咨询请求之前的正在占用客服资源的其他咨询请求的号码。

2.根据权利要求1所述的方法，其特征在于，所述咨询请求的生成过程，包括：

响应于咨询请求的触发指令，获取用户的标识信息；

利用所述标识信息，生成所述咨询请求。

3.根据权利要求1所述的方法，其特征在于，所述排序结果包括所述目标咨询队列中排在所述咨询请求之前的处于等候状态的其他咨询请求的数量、所述咨询请求的等候时长中的至少一种。

4.一种咨询请求队列管理方法，其特征在于，应用于即时通讯客服系统，包括：

对接收到的咨询请求进行解析，得到解析结果；

将所述咨询请求添加至目标咨询队列；所述目标咨询队列是根据所述解析结果，从多个候选咨询队列中选择的；

确定并反馈排序结果；其中，所述排序结果是根据第一号码和第二号码确定的；所述第一号码是所述咨询请求在所述目标咨询队列中的号码，所述第二号码是所述目标咨询队列中排在所述咨询请求之前的正在占用客服资源的其他咨询请求的号码。

5.根据权利要求4所述的方法，其特征在于，所述对接收到的咨询请求进行解析，得到解析结果，包括：

确定所述咨询请求对应的类别；

确定所述咨询请求对应的优先级；

根据所述类别和所述优先级，确定所述解析结果。

6.根据权利要求5所述的方法，其特征在于，所述确定所述咨询请求对应的类别，包括：

从所述咨询请求中获取用户的标识信息；

根据所述标识信息确定分类参照信息，所述分类参照信息用于表征用户是否已购买目标商品、用户是否确认收到目标商品、确认收到目标商品的时间中的至少一种；

根据所述分类参照信息，确定所述咨询请求对应的类别。

7.根据权利要求4所述的方法，其特征在于，所述排序结果的确定方式，包括：

执行为所述咨询请求配置的查询任务；所述查询任务是在所述咨询请求添加至所述目标咨询队列后配置的，包括查询目标、查询时间间隔和查询停止条件；所述查询目标包括所述第一号码和所述第二号码；

利用所述执行所述查询任务获得的查询目标，确定所述排序结果。

8.根据权利要求1所述的方法，其特征在于，所述第一号码是动态调整的，调整过程包括：

响应于检测指令，由所述第二号码向后进行遍历，对是否存在消号进行检测；所述检测指令是以指定时间间隔生成，或是检测到的客服资源的分配情况发生变更生成的；

在检测结果为存在消号的情况下，根据消号的数量，对所述第一号码进行调整。

9.根据权利要求4、7、8中任一所述的方法，其特征在于，所述第二号码是动态调整的，调整过程包括：

在所述目标咨询队列中，检测到客服资源的分配情况在新的咨询请求被分配客服资源的发生变更的情况下，比较被分配客服资源的各其他咨询请求所对应号码的大小；

根据所述比较的结果，对所述第二号码进行调整。

10.根据权利要求4至8中任一所述的方法，其特征在于，所述第一号码和所述第二号码存储于缓存数据库中，所述缓存数据库基于所述目标咨询队列中的咨询请求的数量分配缓存资源。

11.一种客服资源管理方法，其特征在于，应用于即时通讯客服调配系统，包括：

获取目标咨询队列的排序结果，所述排序结果是根据权利要求4至10中任一方法确定的；

利用所述排序结果以及客服的处理能效，对客服资源进行调配。

12.根据权利要求11所述的方法，其特征在于，还包括：

检测待分配客服的咨询请求的咨询历史；

根据所述咨询历史，确定目标客服；所述目标客服为根据所述咨询历史确定的处理前次咨询的客服；

将所述待分配客服的咨询请求分配给所述目标客服。

13.一种咨询请求的处理方法，其特征在于，应用于即时通讯客服端，包括：

获取已分配的咨询请求在目标咨询队列的排序结果，所述排序结果是根据权利要求4至10中任一方法确定的；所述已分配的咨询请求为分配给所述客服端的多个咨询请求；

根据所述已分配的咨询请求在目标咨询队列的排序结果，确定已分配的咨询请求的处理优先级。

14.一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，所述处理器在执行所述计算机程序时实现权利要求1-13中任一项所述的方法。