CN110324238A - 在线客服方法、装置和设备 - Google Patents

Abstract

本申请涉及一种在线客服方法、装置和设备。上述方法包括：获取任一渠道发送的在线客服请求；根据在线客服请求生成会话；根据在线客服请求对应的运单号属性，基于预设的路由匹配策略将会话路由至预设网点；获取客户通过会话发送的问题信息并返回回复信息，以执行本次在线客服服务；当检测到用于停止会话的预设的停止指令时，结束本次在线客服服务。应用本申请提供的技术方案，不同渠道的客户均可以从各自的渠道直接咨询客服，在线客服系统能自动生成会话并根据运单号属性等路由匹配策略将其路由至特定的客服网点，实现会话的快速接入，从而能够提高在线客服系统的服务效率和服务质量。

Description

在线客服方法、装置和设备

技术领域

本申请涉及客服领域，尤其涉及一种在线客服方法、装置和设备。

背景技术

随着电商平台的发展，快递业务量暴增，通过在线客服的业务咨询、投诉也越来越多。作为快递行业，成千上万的网点都需要有自己的客服技能组，客服管理员实时监控会话情况，及时调整会话分配策略以提高服务质量。

然而市面上的在线客服产品功能单一，无法结合快递行业的属性进行灵活的会话分配和路由，从而会影响客服服务效率。而随着公司业务线越来越多，单租户的在线客服也已无法满足使用需求，此外，市面上的在线客服产品也无法应对多渠道类型的接入支持，从而导致在线客服服务质量较低。

也就是说，相关技术中的在线客服系统存在客服服务效率低和服务质量低的问题。

发明内容

本申请提供一种在线客服方法、装置和设备，以至少在一定程度上解决相关技术中的在线客服系统存在的客服服务效率低和服务质量低的问题。

本申请的上述目的是通过以下技术方案实现的：

第一方面，本申请实施例提供一种在线客服方法，包括：

获取任一渠道发送的在线客服请求；

根据所述在线客服请求生成会话；

根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点；

获取客户通过所述会话发送的问题信息并返回回复信息，以执行本次在线客服服务；

当检测到用于停止所述会话的预设的停止指令时，结束本次在线客服服务。

可选的，所述运单号属性包括：运单号的物流状态；

所述根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点，包括：

根据所述运单号的物流状态，若运单未到达派件网点，则将所述会话路由至收件网点；若运单已到达派件网点，则将所述会话路由至派件网点。

可选的，所述运单号属性还包括：运单号的渠道信息；

所述根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点，包括：

根据所述运单号的渠道信息，将所述会话路由至中心网点或总部网点；所述中心网点为所述收件网点或所述派件网点的上级网点，所述总部网点为所述中心网点的上级网点。

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

在将所述会话路由至任一网点前，检测该网点是否存在客服；

当该网点不存在客服时，将所述会话路由至上级网点；

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

当该网点存在客服时，检测客服的在线状态；

当客服为隐身状态时，将所述会话路由至上级网点。

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

当客服为空闲状态时，检测客服的剩余接线量；所述剩余接线量为预设的每个客服的当日总接线量与已完成接线量的差值；

当客服的剩余接线量为0时，将所述会话路由至上级网点。

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

当客服的剩余接线量不为0时，将所述会话加入排队队列，并检测所述会话在所述排队队列中的序号；

当所述序号超出所述排队队列的最大排队人数时，将所述会话路由至上级网点。

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

当所述序号未超出所述排队队列的最大排队人数时，判断所述会话的预计排队时间；

当所述预计排队时间超出预设的最大排队时间时，将所述会话路由至上级网点。

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

对所有操作生成实时报表和历史报表，以便于各网点的管理人员进行查看。

第二方面，本申请实施例还提供一种在线客服装置，包括：

获取模块，用于获取从任一渠道发送的在线客服请求；

生成模块，用于根据所述在线客服请求生成会话；

路由模块，用于根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点；

执行模块，用于获取客户通过所述会话发送的问题信息并返回回复信息，以执行本次在线客服服务；

处理模块，用于当检测到用于停止所述会话的预设的停止指令时，结束本次在线客服服务。

第三方面，本申请实施例还提供一种在线客服设备，包括：

存储器和与所述存储器相连接的处理器；

所述存储器，用于存储程序，所述程序至少用于执行上述的在线客服方法；

所述处理器，用于调用并执行所述存储器存储的所述程序。

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

在应用本申请实施例提供的技术方案时，当获取到客户从任一渠道发送的在线客服请求时会自动生成会话，并查询本次在线客服请求对应的运单号属性；之后基于预设的路由匹配策略将生成的会话路由至特定网点的客服；随后即可通过所述会话实现客户和客服人员的交流沟通；最后根据预设的策略结束本次在线客服。如此设置，相对于市面上现有的在线客服产品，不同渠道的客户均可以从各自的渠道直接咨询客服，在线客服系统能自动生成会话并根据运单号属性等路由匹配策略将其路由至特定的客服网点，实现会话的快速接入，从而能够提高在线客服系统的服务效率和服务质量。

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

附图说明

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

图1为本申请实施例提供的一种在线客服方法的流程图；

图2为本申请实施例提供的一种在线客服方法的整体示例流程图；

图3为本申请实施例提供的一种在线客服方法中会话路由流程图；

图4为本申请实施例提供的一种在线客服方法中会话分配流程图；

图5为本申请实施例提供的一种在线客服装置的结构示意图；

图6为本申请实施例提供的一种在线客服设备的结构示意图。

具体实施方式

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

虽然以下实施例中所描述的技术方案均是针对快递行业进行说明的，但本领域技术人员应当理解的是，虽然本申请的技术方案最适用于快递行业，但并不意味着只能应用于快递行业，将本申请的技术方案中的一些与快递行业相关的技术特征进行适应性修改后也可以应用于其他行业。

实施例一

请参阅图1，图1为本申请实施例提供的一种在线客服方法的流程图。如图1所示，该方法包括以下步骤：

S101：获取任一渠道发送的在线客服请求；

具体的，所说的渠道一般指的是客户接入在线客服的媒介，例如微信、支付宝、网页、Rest集成等多种渠道。客户购物时在商家发货后可以通过上述的各种渠道输入快递运单号查询货物详情，并通过设置的相应途径联系客服。在现有的客服产品中，不同的渠道应用需要采用不同的技术、架构设计和开发人员来完成，并只能为来自该渠道的客户服务，因此一定程度上加大了应用的开发和管理难度，也比较容易影响客户的体验，有鉴于此，本申请的技术方案中通过多渠道整合技术，将多个渠道的客服服务进行整合，无论用户在哪个渠道联系在线客服，都可以由同一在线客服系统进行接收和处理。如此设置，能够减少在线客服应用的开发和管理难度，同时客户在任一渠道都可咨询客服。

S102：根据所述在线客服请求生成会话；

一些实施例中，后台系统获取到在线客服请求后，会自动生成聊天窗口，并通过聊天窗口推送预设的欢迎语等信息。

S103：根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点；

具体的，预设的路由匹配策略包括：1.根据运单号策略匹配客服网点/中心。

在该匹配策略中，运单号属性包括：运单号的物流状态；

所述根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点，包括：

根据所述运单号的物流状态，若运单未到达派件网点，则将所述会话路由至收件网点；若运单已到达派件网点，则将所述会话路由至派件网点。

其中，运单未达到派件网点的物流状态具体包括：运单取件中、运单到达收件网点和运单发件中等；运单已到达派件网点的物流状态具体包括：运单派件中和运单已签收等。

需要注意的是，所述的收件网点在特定情况下也可以等同于发件网点，即快递公司员工收件后从同一网点发件。发件网点不同于派件网点，在发件网点是运单从该网点发往目的地，在派件网点则是运单到达目的地后由快递员派送至客户手中。

此外，预设的路由匹配策略还可以包括：2.根据渠道策略匹配客服网点；

在该匹配策略中，运单号属性还包括：运单号的渠道信息；

所述根据所述在线客服请求对应的运单号属性，基于预设的路由策略将所述会话路由至预设网点，包括：

根据所述运单号的渠道信息，将所述会话路由至中心网点或总部网点；所述中心网点为所述收件网点或所述派件网点的上级网点，所述总部网点为所述中心网点的上级网点。

也就是说，根据运单号的渠道信息的不同进行区别对待，对于来自特定渠道的客户可以直接将会话路由至级别高于普通网点的中心网点或更高级的总部网点等。

在实际场景中，可以将快递网点等级由上至下设定为：总部网点、中心网点、一级网点、二级网点……当然，也可以根据实际需要进行不同的设定，在此不做限制。

此外，预设的路由匹配策略还可以包括：

3.根据省份/市区匹配客服网点；

4.根据订单信息策略匹配客服网点；

5.根据网点策略匹配客服网点；

6.根据租户和渠道匹配客服网点；

7.根据租户随机策略匹配客服网点；

8.根据租户匹配客户网点。

上述的多种路由匹配策略中运单号属性均可以包括对应的信息，对于在不同路由匹配策略下如何选择路由网点可以根据实际需要进行设定和调整，此处不再一一详细说明。

S104：获取客户通过所述会话发送的问题信息并返回回复信息，以执行本次在线客服服务；

具体的，在实际场景中，客服人员通过聊天窗口与客户进行交流和沟通，为客户解决疑问和问题。

S105：当检测到用于停止所述会话的预设的停止指令时，结束本次在线客服服务。

具体的，实际应用时，所述的预设的停止指令例如可以是客服人员在取得客户同意后触发特定的虚拟按键、预设的时间内客户未输入任何信息等方式。在在线客服结束后即可关闭相应的会话。

此外，在在线客服结束后、关闭会话前还可以推送邀请客户对该次客服进行评价的提示信息。

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

在应用本申请实施例提供的技术方案时，当获取到客户从任一渠道发送的在线客服请求时会自动生成会话，并查询本次在线客服请求对应的运单号属性；之后基于预设的路由匹配策略将生成的会话路由至特定网点的客服；随后即可通过所述会话实现客户和客服人员的交流沟通；最后根据预设的策略结束本次在线客服。如此设置，相对于市面上现有的在线客服产品，不同渠道的客户均可以从各自的渠道直接咨询客服，在线客服系统能自动生成会话并根据运单号属性等路由匹配策略将其路由至特定的客服网点，实现会话的快速接入，从而能够提高在线客服系统的服务效率和服务质量。

为了对本申请技术方案的实际应用情况进行更好的说明，本申请实施例还提供以下扩展方案。所有的扩展方案都是在上述实施例一的基础上做出的。

一些实施例中，上述方法还可以包括：在将所述会话路由至任一网点前，检测该网点是否存在客服；当该网点存在客服时，将所述会话路由至该网点；当该网点不存在客服时，将所述会话路由至上级网点。

在实际应用场景中，对于一些小的收件或派件网点，可能并未设置客服人员，因此，这种情况下需要将会话路由至该网点的上级网点进行处理。

一些实施例中，上述方法还可以包括：当该网点存在客服时，检测客服的在线状态；当至少存在一个客服为空闲状态时，将所述会话路由至该网点；当客服均为隐身状态时，将所述会话路由至上级网点。

在实际应用场景中，客户申请在线客服时可能是下班时间且该网点未设置客服人员值班，则这种情况下需要将会话路由至该网点的上级网点进行处理。

一些实施例中，上述方法还可以包括：当至少存在一个客服为在线状态时，检测客服的剩余接线量；所述剩余接线量为预设的每个客服的当日总接线量与已完成接线量的差值；当客服人员的剩余接线量不为0时，将所述会话路由至该网点；当客服人员的剩余接线量为0时，将所述会话路由至上级网点。

在实际应用场景中，为了保证公平原则，可以为每个客服人员设置一个每日总接线量(即每日需服务的客户总数)，当其实际接线量达到该总接线量时，不在为其分配新的客户，进一步的，若该网点的所有客服人员的剩余接线量均为0时，则这种情况下需要将会话路由至该网点的上级网点进行处理。

一些实施例中，上述方法还可以包括：当客服的剩余接线量不为0时，将所述会话加入排队队列，并检测所述会话在所述排队队列中的序号；当所述序号未超出所述排队队列的最大排队人数时，将所述会话维持在所述排队队列中进行排队；当所述序号超出所述排队队列的最大排队人数时，将所述会话路由至上级网点。

在实际应用场景中，可能存在虽然网点客服的剩余接线量不为0但排队等待客户人数过多的情况，为了避免客户等待过长的时间，需要将会话路由至该网点的上级网点进行处理。

一些实施例中，上述方法还可以包括：当所述序号未超出所述排队队列的最大排队人数时，判断所述会话的预计排队时间；当所述预计排队时间未超出预设的最大排队时间时，将所述会话维持在所述排队队列中进行排队；当所述预计排队时间超出预设的最大排队时间时，将所述会话路由至上级网点。

在实际应用场景中，可以根据之前已完成的在线客服服务所花费的时间等信息来估计新加入排队的会话被接起的预计时间，如果预计的时间过长，为了提高客户的体验，需要将会话路由至该网点的上级网点进行处理。

需要注意的是，以上所说的将会话路由至上级网点进行处理指的是若不符合该步骤的相应条件时，重复执行类似的操作，直至将会话路由至总部网点(即最高一级网点)，总部网点必定设置了足够的客服人员进行相应处理。

此外，本申请还提供基于大数据的实时数据报表和历史数据报表，各网点的管理人员可以根据当前权限进行查看，从而能够完善客服监控体系、优化会话的路由分配方案。

为了对本申请的技术方案进行更全面的介绍，以下将通过一个具体示例来对本申请提供的在线客服方法的整体流程进行说明。

实施例二

请参阅图2，图2为本申请实施例提供的一种在线客服方法的整体示例流程图。如图2所示，该流程包括：

首先，客户打开在线客服页面并发起聊天后，判断客户发送的消息内容是否是“转人工”，如果是非转人工，会话被在线客服机器人接起，系统推送欢迎语“您好，很高兴为您服务”，客户和机器人开始聊天。

如果消息内容是“转人工”，则开始进入转人工流程。首先判断是否上班时间，如果不在上班时间，推送不在工作时间提示语“亲亲，现在是下班时间，无法转人工。客服mm在线服务时段：9:00-21:00(周一至周日)给您比心哟～”并结束会话。如果在上班时间，通过路由策略计算出技能组，判断技能组是否需要排队，如果不需要排队，进入接起会话流程。系统推送会话接起提示语“正在为您转接客服.....”，会话被人工客服接起。接着系统推送欢迎语“您好，很高兴为您服务”，客户和客服开始聊天。其中，所说的“技能组”指的是根据特定逻辑划分的、负责特定范围的相关客服的功能组织。

如果技能组需要排队，推送客户排队提示信息“排队时间X和排队人数Y”。当某个会话结束或者有新客服上线时，系统自动触发会话分配，判断会话是否可以被接起，如果会话被接起，进入接起会话流程。当会话排队时间超过2分钟，系统推送“当前排队人数较多，继续等待请回复1”，如果客户回复“1”，则继续排队，如果客户回复不是“1”或1分钟之内未回复，系统推送排队超时提示语“客服繁忙，暂时无法接待您；给您带来不便，如需继续处理您的问题建议您再次联系我司客服mm喲～～～”，之后会话结束。

其中，客户和客服或者机器人聊天过程中，需要开启计时器，记录未收到新消息的时间，如果超过2分钟未收到消息，系统推送会话即将关闭提示语“亲亲，您已经很久没有发送消息了，本次会话即将关闭，如您还需要咨询请发送消息即可哟～”，如果在1分钟之内仍然未收到客户新的消息，系统推送会话结束语“亲亲，小通将结束本次会话了，随时欢迎您再次咨询，祝您生活愉快！”，之后会话结束。

需要注意的是，以上实施例中涉及的各种提示语和客户回复信息均是示例性的，并非对本申请的限制，实际应用时可以根据用户需要进行设置。

此外，为了对本申请的技术方案进行更全面的介绍，以下将通过一个具体示例来对本申请提供的在线客服方法的会话路由流程进行说明。

实施例三

在线客服系统支持多种路由匹配策略同时使用，并可以通过配置化达到不同路由匹配策略按照指定优先级执行。比较常用的策略有：租户号路由策略、渠道路由策略、运单路由策略、订单路由策略等。其中，

1)租户号路由策略：由于实际产品定位是多租户使用，故在路由管理中，可以根据租户路由到指定技能组，此功能主要用于兜底。

多租户技术(multi-tenancy technology)或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。本实施例中所述的根据租户路由到指定技能组，可以进行兜底，即来自任何渠道任何场景的客户请求客服时，都存在技能组对其负责，保证无一客户被遗漏。

2)渠道路由策略：根据不同的业务场景，可根据指定渠道路由到固定的技能组编码。不同业务场景，即普通快件、加急快件、担保快件以及密送快件等不同的场景，可以根据特定业务场景将会话路由至特定客服技能组。

3)运单路由策略：快递业务场景中，为提高客服会话的处理效率，需将不同的运单路由到不同的技能组中。例如：需将运单当前所在的轨迹状态，路由到不同的技能组，收取、发件、到达状态路由到收件网点技能组，派件、签收状态路由到派件网点技能组。

4)订单路由策略：根据订单号的收件网点，路由到客服系统的所在技能组。当通过以上策略已路由到指定网点技能组，而当此技能组被禁用或在客服系统中不存在时，则需查询此网点在整个组织架构中的上级网点技能组，直到查询到可用技能组为止。

通过以上路由策略计算出排队的技能组，排队时，可以通过排队规则实现会话溢出的功能(会话溢出到其他技能组)，例如：根据排队时间溢出、排队人数溢出、在线人数溢出等。

请参阅图3，图3为本申请实施例提供的一种在线客服方法中会话路由流程图。如图3所示，该流程包括：

基于多种路由策略将会话路由至指定网点时，检测该网点是否存在可用技能组，如果不存在可用技能组，则递归查询上级网点所在的技能组(直到查询到可用技能组)，并开始尝试排队；如果存在可用技能组，则直接开始尝试排队。

在尝试排队过程中，检测是否存在在线的客服，如果不存在在线的客服，则溢出到上级技能组(直到溢出到总部技能组)，并开始正式排队；如果存在在线的客服，则检测客户排队人数是否少于排队人数限制，如果不少于排队人数限制，则溢出到上级技能组(直到溢出到总部技能组)，并开始正式排队，如果少于排队人数限制，则开始正式排队。

在正式排队过程中，检测会话排队一分钟内是否被接起，如果未被接起，则溢出到上级技能组(直到溢出到总部技能组)；如果会话被接起，则结束会话路由，客服和客户开始聊天。

此外，为了对本申请的技术方案进行更全面的介绍，以下将通过一个具体示例来对本申请提供的在线客服方法中会话分配至客服的流程进行说明。

实施例四

本实施例所述的会话分配至客服主要指的是当确定网点技能组中存在客服时的会话分配，即在将会话路由至某网点之后如何根据该网点的客服状态决定将会话分配给哪一个客服。

请参阅图4，图4为本申请实施例提供的一种在线客服方法中会话分配流程图。如图4所示，该流程包括：

首先判断当前技能组是否有在线客服，若无在线客服则向客户推送排队提示信息。否则继续判断在线并且未超过最大接待的客服是否超过1，若超过1个客服则计算出空闲率最大的客服。然后计算最大的空闲率的客服是否超过1，若超过1个客服则就算出当日接待量最少的客服。若最少的当日接待量仍然有多个客服，则按照随机算法计算出一个客服负责接待任务。其中关联的分配指标有两个：空闲率、当日工作量。

1)空闲率：空闲率的计算规则是(最大接待-实时接待)/最大接待，空闲反应了客服实时的可接待能力，此指标有利于最快的分配到用接待的客服。

2)当日工作量：即当日已经接待了多少客户，此指标有利于尽量按照均匀的策略分配当日会话，达到公平的原则。

为了对本申请的技术方案进行更全面的介绍，对应于本申请上述实施例提供的在线客服方法，本申请实施例还提供一种在线客服装置。

请参阅图5，图5为本申请实施例提供的一种在线客服装置的结构示意图。如图5所示，该装置包括：

获取模块51，用于获取从任一渠道发送的在线客服请求；

生成模块52，用于根据所述在线客服请求生成会话；

路由模块53，用于根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点；

执行模块54，用于获取客户通过所述会话发送的问题信息并返回回复信息，以执行本次在线客服服务；

处理模块55，用于当检测到用于停止所述会话的预设的停止指令时，结束本次在线客服服务。

具体的，上述各个功能模块的具体实现方式请参照上述在线客服方法中的相关内容来实现，在此不再详述。

为了对本申请的技术方案进行更全面的介绍，对应于本申请上述实施例提供的在线客服方法，本申请实施例还提供一种在线客服设备。

请参阅图6，图6为本申请实施例提供的一种在线客服设备的结构示意图。如图6所示，该设备包括：

存储器61和与所述存储器61相连接的处理器62；

所述存储器61，用于存储程序，所述程序至少用于执行上述的在线客服方法；

所述处理器62，用于调用并执行所述存储器61存储的所述程序。

具体的，上述程序的功能的具体实现方式请参照上述在线客服方法中的相关内容来实现，在此不再详述。

可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

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

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

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

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种在线客服方法，其特征在于，包括：

获取任一渠道发送的在线客服请求；

根据所述在线客服请求生成会话；

根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点；

获取客户通过所述会话发送的问题信息并返回回复信息，以执行本次在线客服服务；

当检测到用于停止所述会话的预设的停止指令时，结束本次在线客服服务。

2.根据权利要求1所述的方法，其特征在于，所述运单号属性包括：运单号的物流状态；

所述根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点，包括：

根据所述运单号的物流状态，若运单未到达派件网点，则将所述会话路由至收件网点；若运单已到达派件网点，则将所述会话路由至派件网点。

3.根据权利要求2所述的方法，其特征在于，所述运单号属性还包括：运单号的渠道信息；

所述根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点，包括：

根据所述运单号的渠道信息，将所述会话路由至中心网点或总部网点；所述中心网点为所述收件网点或所述派件网点的上级网点，所述总部网点为所述中心网点的上级网点。

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

在将所述会话路由至任一网点前，检测该网点是否存在客服；

当该网点不存在客服时，将所述会话路由至上级网点；

当该网点存在客服时，检测客服的在线状态；

当客服为隐身状态时，将所述会话路由至上级网点。

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

当客服为空闲状态时，检测客服的剩余接线量；所述剩余接线量为预设的每个客服的当日总接线量与已完成接线量的差值；

当客服的剩余接线量为0时，将所述会话路由至上级网点。

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

当客服的剩余接线量不为0时，将所述会话加入排队队列，并检测所述会话在所述排队队列中的序号；

当所述序号超出所述排队队列的最大排队人数时，将所述会话路由至上级网点。

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

当所述序号未超出所述排队队列的最大排队人数时，判断所述会话的预计排队时间；

当所述预计排队时间超出预设的最大排队时间时，将所述会话路由至上级网点。

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

对所有操作生成实时报表和历史报表，以便于各网点的管理人员进行查看。

9.一种在线客服装置，其特征在于，包括：

获取模块，用于获取从任一渠道发送的在线客服请求；

生成模块，用于根据所述在线客服请求生成会话；

路由模块，用于根据所述在线客服请求对应的运单号属性，基于预设的路由匹配策略将所述会话路由至预设网点；

执行模块，用于获取客户通过所述会话发送的问题信息并返回回复信息，以执行本次在线客服服务；

处理模块，用于当检测到用于停止所述会话的预设的停止指令时，结束本次在线客服服务。

10.一种在线客服设备，其特征在于，包括：

存储器和与所述存储器相连接的处理器；

所述存储器，用于存储程序，所述程序至少用于执行如权利要求1-8任一项所述的在线客服方法；

所述处理器，用于调用并执行所述存储器存储的所述程序。