客服代表的推送方法、装置、设备及介质与流程

本公开涉及计算机技术领域，尤其涉及一种客服代表推送方法、装置、设备及介质。

背景技术：

客户服务(customerservice)，主要体现基于能够使得客户满意为导向的价值观，整合及管理在预先设定的最优成本-服务组合中的客户界面的所有要素。换言之，任何能提高客户满意度的内容都属于客服范围。

通常，客服可分为人工客服和电子客服，其中人工客服由真实业务人员(即客服代表)为用户(即客户)提供业务服务，根据人工客服的实现形式又可细分为文字客服、视频客服和语音客服三类。文字客服是指主要以打字聊天的形式进行的客户服务；视频客服是指主要以语音视频的形式进行客户服务；语音客服是指主要以移动电话的形式进行的客服服务，例如电话客服，电话客服是客服代表通过电话与用户进行沟通交流的方式，在用户使用产品或业务过程中遇到的相关问题、建议或意见，以及服务提供方对用户主动发起的提醒、通知等都可以通过电话客服迅速建立起与客户直接沟通的渠道，方便快捷，在日常生活中为客户和服务提供方都提供了极大的便利性。

在人工客服的应用场景下，为确保为用户所提供的服务业务质量，客服代表通常会在特定场景中，主动与用户联系，将与用户协议相关的业务情况以文字、视频或语音的方式告知用户，如银行业务中涉及的动帐通知、到期换卡、问卷调研、产品营销、风险提示、贷款延期等场景。另外，用户也会在特定业务需要的情况下，主动联系客服代表以获取专业的业务指导，如银行业务中涉及的订单存在疑问，账户使用存在问题，产品的咨询问题，办理账户冻结等金融业务等情况。因此，在客服业务进行过程中，业务提供方需要将对应业务的客服代表推送给用户，并建立二者之间的联系以为用户提供相应的业务服务。

技术实现要素：

(一)要解决的技术问题

为解决现有技术中，客服代表与用户之间为实现推送沟通所存在的技术问题中至少之一，本公开提供了一种客服代表推送方法、装置、设备及介质。

(二)技术方案

本公开的一方面提供了一种客服代表推送方法，其中，包括：根据用户的业务办理请求，调取与用户相关的客服事件信息；通过客服事件信息确定与业务办理请求相对应的客服代表；以及将客服代表推送给用户，以实现客服代表与用户之间的直接业务沟通；其中，在通过客服事件信息确定与业务办理请求相对应的客服代表中，包括：通过客服事件信息确定用户在预设时间范围内的业务办理记录；根据业务办理记录确定客服代表。

根据本公开的实施例，在根据用户的业务办理请求，获取与用户相关的客服事件信息之前，该方法还包括：建立与用户之间的至少一业务办理记录；根据至少一业务办理记录，确定客服事件信息。

根据本公开的实施例，在根据用户的业务办理请求，调取与用户相关的客服事件信息中，包括：基于业务办理请求，生成交互申请选择；根据交互申请选择，调取客服事件信息。

根据本公开的实施例，在通过客服事件信息确定与业务办理请求相对应的客服代表中，还包括：通过客服事件信息确定客服代表的当前服务状态；根据当前服务状态确定客服代表。

根据本公开的实施例，在通过客服事件信息确定与业务办理请求相对应的客服代表中，还包括：根据当前服务状态，生成客服流程选择；根据客服流程选择更新客服代表。

根据本公开的实施例，在将客服代表推送给用户，以实现客服代表与用户之间的直接业务沟通中，包括：建立客服代表与用户之间的事件沟通关系；根据事件沟通关系，将客服代表推送给用户。

根据本公开的实施例，在根据事件沟通关系，将客服代表推送给用户之后，还包括：根据事件沟通关系，生成客服交互选择；基于客服交互选择，实现客服代表与用户之间的直接业务沟通。

本公开的另一方面提供了一种客服代表推送装置，其中，包括信息调取模块、客服确定模块和客服推送模块。信息调取模块用于根据用户的业务办理请求，调取与用户相关的客服事件信息；客服确定模块用于通过客服事件信息确定与业务办理请求相对应的客服代表；客服推送模块用于将客服代表推送给用户，以实现客服代表与用户之间的直接业务沟通；其中，客服确定模块包括记录确定单元和客服确定单元。记录确定单元用于通过客服事件信息确定用户在预设时间范围内的业务办理记录；客服确定单元用于根据业务办理记录确定客服代表。

根据本公开的实施例，该装置还包括记录建立模块和信息确定模块。记录建立模块用于在根据用户的业务办理请求，获取与用户相关的客服事件信息之前，建立与用户之间的至少一业务办理记录；信息确定模块用于根据至少一业务办理记录，确定客服事件信息。

根据本公开的实施例，信息调取模块包括交互选择生成单元和信息调取单元。交互选择生成单元用于基于业务办理请求，生成交互申请选择；信息调取单元用于根据交互申请选择，调取客服事件信息。

根据本公开的实施例，客服确定模块还包括状态确定单元，状态确定单元用于确定客服代表的当前服务状态；其中，客服确定单元还用于根据当前服务状态确定客服代表。

根据本公开的实施例，客服确定模块还包括流程选择单元和客服更新单元。流程选择单元用于根据当前服务状态，生成客服流程选择；客服更新单元用于根据客服流程选择更新客服代表。

根据本公开的实施例，客服推送模块包括关系建立单元和客服推送单元。关系建立单元用于建立客服代表与用户之间的事件沟通关系；客服推送单元用于根据事件沟通关系，将客服代表推送给用户。

根据本公开的实施例，客服推送模块还包括客服选择单元和沟通建立单元。客服选择单元用于根据事件沟通关系，生成客服交互选择；沟通建立单元用于基于客服交互选择，实现客服代表与用户之间的直接业务沟通。

本公开的另一方面提供了一种电子设备，包括一个或多个处理器和存储器；存储器用于存储一个或多个程序，其中，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器实现本公开实施例的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，上述指令在被执行时用于实现本公开实施例的方法。

本公开的另一方面提供了一种计算机程序，上述计算机程序包括计算机可执行指令，上述指令在被执行时用于实现本公开实施例的方法。

(三)有益效果

本公开提供了一种客服代表推送方法，其中包括：根据用户的业务办理请求，调取与用户相关的客服事件信息；通过客服事件信息确定与业务办理请求相对应的客服代表；以及将客服代表推送给用户，以实现客服代表与用户之间的直接业务沟通；其中，在通过客服事件信息确定与业务办理请求相对应的客服代表中，包括：通过客服事件信息确定用户在预设时间范围内的业务办理记录；根据业务办理记录确定客服代表。因此，能够进一步提高用户与客服代表之间的沟通效率。此外，本公开还提供了一种客服代表的推送装置、电子设备及计算机可读存储介质。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了根据本公开实施例的可以应用客服代表的推送方法的示例性系统架构；

图2a示意性示出了根据本公开一实施例的客服代表的推送方法的流程图；

图2b示意性示出了根据本公开一实施例的客服代表确定方法的流程图；

图3a示意性示出了根据本公开一实施例的客服事件信息的确定方法的流程图；

图3b示意性示出了根据本公开一实施例的客服事件信息的确定方法的一应用场景图；

图3c示意性示出了根据本公开一实施例的客服事件信息的确定方法的另一应用场景图；

图3d示意性示出了根据本公开一实施例的客服事件信息的确定方法的另一应用场景图；

图4a示意性示出了根据本公开一实施例的客服事件信息的调取方法的流程图；

图4b示意性示出了根据本公开一实施例的客服代表的更新方法的流程图；

图4c示意性示出了根据本公开一实施例的客服代表的沟通方法的流程图；

图4d示意性示出了根据本公开一实施例的客服代表的确定-沟通方法的应用场景图；

图5示意性示出了根据本公开一实施例的客服代表的推送装置的示例性架构；

图6a示意性示出了根据本公开另一实施例的客服代表的推送方法的流程图；

图6b示意性示出了根据本公开另一实施例的客服代表确定方法的流程图；

图7示意性示出了根据本公开另一实施例的客服事件信息的确定方法的流程图；

图8a示意性示出了根据本公开另一实施例的业务优先级的确定方法的流程图；

图8b示意性示出了根据本公开另一实施例的客服事件信息的调取方法的流程图；

图8c示意性示出了根据本公开另一实施例的客服代表的更新方法的流程图；

图8d示意性示出了根据本公开另一实施例的客服代表的沟通方法的流程图；

图9示意性示出了根据本公开另一实施例的客服代表的推送装置的示例性架构；

图10示意性示出了根据本公开实施例的电子设备的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了上述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读存储介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。

在现有技术中，对于人工客服而言，针对代表服务提供方的客服代表主动联系用户和用户主动联系客服代表进行业务相关处理的场景，通常会出现如下问题：

(1)对于客服代表给用户进行主动沟通(如拨打的电话、发送短信提醒等)，用户难以辨别真伪。如果信任电话中的内容，可能会遭遇软件改号诈骗，造成用户资产损失；如果不信任电话中的内容，在客服通话提到的账户风险确实存在，同样会造成用户资产损失。

(2)在客服代表给用户进行主动业务沟通的过程中，常会发生用户漏接电话或信息漏看等情况，用户无法得知客服来电的目的，回拨后也难以接通到当初主动；联系通知的客服代表，造成客服沟通效率降低。

(3)如果用户和客服代表在沟通联系期间发生意外，如电话挂断或网络断开等，用户难以迅速联系到原始为自己服务的客服代表，会与新的客服代表重复描述和前述沟通相同的问题，导致客服沟通效率较差。

(4)如果用户和客服代表有过多次联系或反馈过多个问题，用户难以迅速联系到原始为自己服务的客服代表，同时难以让客服高效的定位到自己要反馈的问题，会与客服重复描述和沟通相同的问题，导致沟通效率较差。

为解决现有技术中，客服代表与用户之间为实现推送沟通所存在的技术问题中至少之一，提高客服代表与用户之间的沟通效率，改善用户体验，本公开提供了一种客服代表推送方法、装置、设备及介质。

需要说明的是，本公开实施例的客服代表推送方法和装置可以应用于信息安全技术领域和物联网技术领域，也可以应用于除信息安全技术领域和物联网技术领域之外的任意领域，如金融服务领域，本公开实施例的客服代表推送方法和装置的应用领域不作具体限定。

图1示意性示出了根据本公开实施例的可以应用客服代表的推送方法的示例性系统架构；

需要注意的是，图1所示仅为可以应用本公开实施例的应用示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例的客服代表的推送方法的不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括数据请求系统110，以及与该数据请求系统110建立数据通信的服务器系统120，其中服务器系统中包括与数据请求系统110建立客服代表的推送通道的服务器m、121、122、123、124以及125，其中服务器m为主访问服务器，可以获取来自用户的指令信息。服务器121、122、123、124以及125为副访问服务器，数据请求系统110与服务器m、121、122、123、124以及125可以基于一个内部云端网络服务器c实现。或者，服务器m、121、122、123、124以及125中的主服务器m为一网络服务器时，即与其他终端设备111、112、113、114以及115的内网相对，服务器系统120的主服务器m可以位于一外网中。此时，云端网络服务器c此处用以其他终端设备111、112、113、114以及115之间提供通信链路的介质。服务器系统120与多个终端设备之间的客服代表的推送通道具体可以通过各种通信连接类型实现，例如有线、无线通信链路或者光纤电缆等等。

需要说明的是，根据本公开实施例，服务器121、122、123、124以及125可以实现无密互联。

用户可以使用终端设备111、112、113、114以及115与服务器系统120交互，以接收或发送消息等是实现客服代表的推送或处理，具体涉及对服务器系统中主服务器m中的数据库的访问。例如，终端设备111向终端设备112发送业务数据，服务器系统120在接收到终端设备111的数据请求后，会对相应的业务数据执行转发处理，并在特定的需要下对业务数据进行加密，以使得最终到达终端设备112的业务数据得到安全保障。终端设备111、112、113、114以及115上可以安装有各种通讯客户端应用，例如管理类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备111、112、113、114以及115可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机以及各类应用服务器等等。

服务器系统120可以包括提供各种服务的各类型防火墙，例如对用户利用终端设备111、112、113、114以及115所浏览的网站提供支持的过滤型防火墙(仅为示例)。过滤型防火墙可以对接收到的用户请求等数据进行分析等处理，并基于数据源头的地址以及协议类型等标志特征进行分析，确定是否可以通过，从而将不安全因素过滤或阻挡。

需要说明的是，本公开实施例所提供的客服代表的推送方法一般可以由服务器系统120执行。相应地，本公开实施例所提供的客服代表的推送装置一般可以设置于服务器系统120中。本公开实施例所提供的客服代表的推送方法也可以由不同于服务器系统120且能够与终端设备111、112、113、114以及115和/或服务器系统120通信的其他服务器系统120执行。相应地，本公开实施例所提供的客服代表的推送装置也可以设置于不同于服务器系统120且能够与终端设备111、112、113、114以及115和/或服务器系统120通信的其他服务器系统中。

应该理解，图1中的终端设备和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、服务器。

实施例1

以下结合图2a-图5和图10，对本公开一实施例提供的客服代表的推送方法、客服代表的推送装置、电子设备及计算机可读存储介质作进一步的详细说明。

图2a示意性示出了根据本公开一实施例的客服代表的推送方法的流程图；图2b示意性示出了根据本公开一实施例的客服代表确定方法的流程图。

如图2a和图2b所示，本公开的一方面提供了一种客服代表推送方法，其中，包括步骤s201-步骤s203。

步骤s201中，根据用户的业务办理请求，调取与用户相关的客服事件信息；

步骤s202中，通过客服事件信息确定与业务办理请求相对应的客服代表；

步骤s203中，将客服代表推送给用户，以实现客服代表与用户之间的直接业务沟通。

业务办理请求可以是用户向服务提供方主动发起的业务办理相关的请求信息，如账户办理冻结、业务办理咨询以及电话联系请求等。其中，业务办理请求也可以包括为实现业务办理而进行的软件技术相关的请求信息，如转账页面无法打开、应用程序账户登录超时等。

客服事件信息为与该用户在该业务办理请求之前所发生的相关的业务办理信息，可以理解为业务办理的记录信息的汇总内容，如历史客户服务明细。若该用户的业务办理请求为首次业务联系沟通，则其客服事件信息为空。此外，用户也可以借此实现通过对客服事件信息的查询来验证客服主动沟通的真伪。

用户为确保自己的业务办理能够顺利完成，并达到预期的业务办理成效，可以通过如图1所示数据请求系统110中终端设备111、112、113、114或115的应用程序软件(如app、小程序、公众号等)向如图1所示的服务器系统120发起数据请求，即业务办理请求。该服务器系统120在接收到用户的业务办理请求之后，可以依据该用户的账户信息(如姓名、身份证号码等)对其相关的客服事件信息进行调取。其中，服务器系统120需要执行步骤s201-s203中的流程内容，在此不作赘述。

客服代表为能够代表服务提供方与用户进行直接业务沟通(如电话、文字以及视频的沟通形式)，实现用户的业务办理请求的业务人员、技术人员等专业人员，即人工客服。基于用户对应的客服事件信息，确定相应的客服代表，该客服代表可以更好地实现用户的业务办理请求相关的办理工作，以更好地实现用户的业务办理期望，提高用户的体验。其中，在客服事件信息为空的情况下，可以基于业务办理请求中业务需求对客服代表进行确定，如推送与业务办理请求的业务类型相关的客服代表。

最后，基于相应地预设推送机制，将所确定的客服代表推送给用户，实现客服代表与用户之间的直接业务沟通。

其中，如图2b所示，在步骤s202通过客服事件信息确定与业务办理请求相对应的客服代表中，包括步骤s210-步骤s220。

步骤s210中，通过客服事件信息确定用户在预设时间范围内的业务办理记录；

步骤s220中，根据业务办理记录确定客服代表。

客服事件信息可以由至少一个业务办理记录逐步累积构成，业务办理记录是区别于当前业务办理请求，基于历史记录中的至少一个而业务办理请求而完成或进行中的业务办理相关的记录信息，如在一次业务办理事件中所产生的与该业务办理相关业务类型、摘要、详细信息、沟通或办理时间、办理状态、客服代表的编号以及录音等所构成的记录内容。其中，录音可以实现文字识别，以记录沟通详情。

具体地，该业务办理记录还可以包括客服代表对用户性格、态度、语气等的用户评价信息，以便于匹配于该用户的用户评价信息相适应的客服代表，以提高客服沟通满意图，改善用户体验。

预设时间范围可以是相对当前业务办理请求所处的时间预先设定的历史业务办理时间的选择范围，如根据相对当前业务办理请求所处的时间，确定24小时内所记录的与该用户的业务办理相关的业务办理记录，则该24小时即可以作为一预设时间范围，其中该预设时间范围还可以是一个周内、一个月内乃至一年内，具体可以根据该客服时间信息在相应时间范围内是否为空来设定。即，当所述客服时间信息在设定的时间范围内为空，则自动扩展其预设时间范围的大小。

根据该预设时间范围内的业务办理记录，可以确定历史记录中与该用户进行业务沟通办理的客服代表，并据此可以将该历史客服代表的推送给用户，使得用户可以与之继续进行业务办理沟通。

其中，需要说明的是，业务办理记录还可以包括用户针对历史客服代表的客服评价信息，如对历史客服代表的满意度、意见、建议以及态度、性格等相关的评价内容，因此，基于该客服评价信息，即使在确定了历史客服代表的情况下，也可以由用户自主选择是否由历史客服代表进行当前业务办理请求的处理，也可以自动为用户选择历史客服代表和新客服代表进行处理，如用户所留客服评价信息并不太好的情况下，优先推送其他客服代表给用户，而非是历史客服代表。其中，历史客服代表为之前与用户发生过业务办理沟通联系的客服代表。

因此，本公开的上述客服代表的推送方法，能够通过如历史客户服务明细等客服事件信息的查询、调取，以定位历史沟通情况，则在通过查看或选择相应记录再次发起业务办理请求沟通的情况下，可以提供用户验证来电真伪，并支持发起用户与历史客服代表之间的再次交互，提高用户与客服代表之间的沟通效率，改善用户体验。

图3a示意性示出了根据本公开一实施例的客服事件信息的确定方法的流程图；图3b示意性示出了根据本公开一实施例的客服事件信息的确定方法的一应用场景图；图3c示意性示出了根据本公开一实施例的客服事件信息的确定方法的另一应用场景图；图3d示意性示出了根据本公开一实施例的客服事件信息的确定方法的另一应用场景图。

如图3a-图3c所示，根据本公开的实施例，在步骤s201根据用户的业务办理请求，获取与用户相关的客服事件信息之前，该方法还包括步骤s301-步骤s302。

在步骤s301中，建立与用户之间的至少一业务办理记录；

在步骤s302中，根据至少一业务办理记录，确定客服事件信息。

与用户之间建立业务办理记录具有如下两种情况：

(1)用户首次主动联系客服代表，具体可以参照如图3b所实现的应用场景，其中包括流程步骤s311-步骤s316，具体以电话沟通为例。

在步骤s311中，在用户有联系客服代表(即服务提供方)的需求情况下，如订单存在疑问、账户使用存在问题、产品的咨询问题以及办理账户冻结等金融业务等，会出现首次主动拨打用户服务电话的场景。此时，即服务提供方的服务器系统将接收到用户的首次业务办理请求。

在步骤s312中，在首次业务办理请求的过程实现中，服务提供方接听用户电话相当于接收到首次业务办理请求，根据语音提示等方式，依据咨询业务问题业务类型分类，分配客服代表并接通。

在步骤s313中，服务器系统建立用户来电的记录信息，即形成业务办理记录的基本信息，如来电时间、客服代表id等。

在步骤s314中，客服代表接听用户来电建立与用户之间的沟通联系，了解用户的需求，向用户提供并完成相应的业务服务。

在步骤s315中，在沟通联系的过程中，或者在完成沟通联系之后，客服代表可以在上述业务办理记录的基本信息中进一步完善用户来电的情况，包括来电的类型、主要内容的摘要、详细信息等，形成一条业务办理记录。

在步骤s316中，服务器系统记录完整的电话沟通信息，建立起客服事件信息以实现对该次通话记录中所涉及的完整信息的记录，该客服事件信息可以包含用户来电或办理号码、沟通时间和时长、业务办理状态、客服代表编号、电话类型、涉及主要内容的摘要、详细信息、录音等信息，其中，通过录音进行文字识别，可以记录沟通详情。其中，该客服事件信息可以根据上述记录内容形成该首次业务办理记录的原始客服事件id，原始客服事件id作为该业务办理记录的标识，可以实现与其他业务办理记录的区分，具体如下述表1所示。其中，该表1所示信息内容，可以仅提供于客服代表进行查询。

表1

(2)客服代表首次主动联系用户，具体可以参照如图3c所实现的应用场景，其中包括流程步骤s321-步骤s326，具体以电话沟通为例。

在步骤s321中，在服务提供方有主动联系用户的需求情况下，如动帐通知、到期换卡、问卷调研、产品营销、风险提示、贷款延期等金融业务的指定条件，会出现服务提供方首次主动联系用户的场景。

在步骤s322中，在用户的业务信息满足上述指定条件的特定场景下，服务提供方可以将与用户协议相关的业务情况通过电话方式告知用户，同时生成电话沟通请求，形成待拨打电话记录。

在步骤s323中，客服代表获取服务器系统分配的待拨打电话记录。

在步骤s324中，根据待拨打电话记录，客服代表拨打对应用户的电话，同时记录电话情况，如来电的类型、主要内容的摘要、详细信息等，形成一条首次业务办理记录。

在步骤s325中，用户接到客服代表拨打的电话，并建立电话沟通联系。

在步骤s326中，服务器系统记录完整的电话沟通信息，建立起客服事件信息以实现对该次通话记录中所涉及的完整信息的记录，该客服事件信息可以包含用户来电或办理号码、沟通时间和时长、业务办理状态、客服代表编号、电话类型、涉及主要内容的摘要、详细信息、录音等信息，其中，通过录音进行文字识别，可以记录沟通详情。其中，该客服事件信息可以根据上述记录内容形成该首次业务办理记录的原始客服事件id，以作为该业务办理记录的标识，实现与其他业务办理记录的区分，具体如上述表1所示。

根据如步骤s3211-s316和步骤s321-s326中的首次联系沟通的实现场景，可以建立与用户之间的首次业务办理记录，若重复该相应过程，则可以实现多次业务办理记录。根据每次业务办理记录可以获得多条客服事件id，由该多条客服时间id及其对应的业务办理记录的记录内容可以形成客服事件信息，以实现该客服事件信息的确定。

如图3c所示，基于上述流程步骤s321-步骤s326，可以实现客服代表主动联系用户的应用场景，但在此场景中也会出现客户漏接电话的情况，也即在步骤s325中用户和客服代表并未建立电话沟通联系。其中，也会发生用户对步骤s325中的电话沟通的真伪表示质疑的情况。

此时，对于用户而言，用户无论接到电话或漏接电话后，都有对该客服代表的来电进行真伪判断的需要。基于该需要，可以形成如图3d所示的应用场景，其中包括流程步骤s331-s334，具体仍以电话沟通为例。

在步骤s331中，如果用户在接听电话或漏接电话后，对电话内容有所怀疑，可发起真伪查询的查询验证请求。用户可以直接通过如app、小程序、公共号等应用程序渠道登陆服务器系统，查询客服沟通记录，获取到用户查询和申请界面的关键信息。

在步骤s332中，服务器系统会接收到用户的查询验证请求。

在步骤s333中，服务器系统向用户展示用户电话沟通列表，如前述表1所示的客服事件信息的具体内容，如可以包含电话日期、具体来电时间、客服代表编号、来去电标志、电话类型、摘要等具体信息。

在步骤s334中，用户可根据展示的记录判断电话的真伪，同时可以根据来电的类型初步判断出服务提供方联系的目的，并点击客服服务明细旁边提供的按钮，发起交互申请，选择“立即联系客服代表”，“请联系我”。整体流程可以参考步骤s311-s316和步骤s321-步骤s326。

其中，在客服代表主动联系用户的场景下，即便是用户漏接电话，服务器系统也会记录完整的电话沟通信息，建立起如上所示客服事件id等信息形成业务办理记录。

因此，在步骤s302根据至少一业务办理记录，确定客服事件信息中，还包括：根据至少一业务办理记录和查询验证请求，确定客服事件信息，具体可以确定其真伪情况。借此，本公开实施例的上述方法可以实现相应的业务办理过程中的真伪验证，确保用户数据安全，提升用户体验。

图4a示意性示出了根据本公开一实施例的客服事件信息的调取方法的流程图；图4b示意性示出了根据本公开一实施例的客服代表的更新方法的流程图；图4c示意性示出了根据本公开一实施例的客服代表的沟通方法的流程图；图4d示意性示出了根据本公开一实施例的客服代表的确定-沟通方法的应用场景图。

其中，图4d所示应用场景中包括流程步骤s411-步骤s4110，可以用于说明如图4a-图4c中对应图2a和图2b所示方法流程，具体仍以电话沟通为例。

如图4a所示，根据本公开的实施例，在步骤s201根据用户的业务办理请求，调取与用户相关的客服事件信息中，包括步骤s401-步骤s402。

在步骤s401中，基于业务办理请求，生成交互申请选择；

在步骤s402中，根据交互申请选择，调取客服事件信息。

其中，图4d所示应用场景中流程步骤s411-步骤s415和步骤s418，可以用于说明书如图4a中所示方法流程。

在步骤s411中，用户通过app、小程序和公众号等渠道登陆服务器系统查询与客服代表之间的业务办理记录，获取到用户查询和申请界面的关键信息。

在步骤s412中，服务器系统获取到用户的查询请求，并据此作为用户的业务办理请求。

在步骤s413和步骤s414中，服务器系统向用户展示其电话沟通的业务办理记录形成的沟通列表，并提供相应的客服服务明细，并根据该客服服务明细和业务办理记录在用户的终端设备的交互界面上形成交互信息(即交互申请选择)，如选择按钮或文字连接，以使得用户可以主动发起交互申请选择，如“联系客服代表”或“联系我”，即该交互申请选择可以是如文字、按钮等形式体现的交互申请的选择信息，如下述表2所示，可以仅提供于用户进行查询。

表2

在步骤s415和步骤s418中，基于该交互申请选择，服务器系统根据对历史业务办理记录进行倒序排列形成的客服事件信息，其中可以包含历史业务办理记录过程中的办理日期、具体时间、客服代表编号、来去电标志、电话类型、摘要等信息。

借此，可以实现对客服事件信息的确定，使得后续所确定的客服代表能够与该用户的业务办理请求更加匹配相关。

如图4b所示，根据本公开的实施例，在步骤s202通过客服事件信息确定与业务办理请求相对应的客服代表中，还包括步骤s410-步骤s420。

在步骤s410中，通过客服事件信息确定客服代表的当前服务状态；

在步骤s420中，根据当前服务状态确定客服代表。

其中，图4d所示应用场景中流程步骤s415-步骤s416，可以用于说明如图4b中所示方法流程。

在步骤s415中，服务器系统根据用户的交互申请选择，可以登记用户的即将来电和客服事件信息中的客服事件id建立关系，也即确定与该用户的业务办理相关的原客服代表，如表1所示，若匹配的客服事件id为2021020712345600001，则该对应的客服代表的客服代表编号为123456。同时依据该关系将该用户的与该业务办理相关的信息(电话号码、业务类型以及客服事件信息等)匹配给该与用户有前述类似业务或其他类似信息联系、客服事件id匹配的客服代表，使得客服代表可以提前主动回顾相关事件情况。此外，服务器系统通过app、小程序或公众号等渠道可以同步调用用户终端设备的电话拨打程序，发起用户给客服的电话。

因此，可以实现将原有客服代表确定给该用户，并确保客服代表能够迅速对用户的历史业务办理情况进行快速把握，以进一步提高在实际沟通过程中的联系效率。

此外，在通过客服事件信息确定客服代表的客服代表编号之后，还需要确定该客服代表编号对应的客服代表的当前服务状态，如“忙碌”、“离职”、“忙线”以及“空闲”等状态，该当前服务状态可以根据每个客服代表的工作状态进行实时更新。

当确认与业务办理记录对应的该客服代表编号的客服代表之后，根据该客服代表的当前服务状态，可以确定是否由该客服代表继续进行联系沟通。例如，若处于“空闲”的待机状态，则可以直接确定该客服代表，若处于“忙线”的状态，则可以确定该客服代表并执行等待操作，若处于“离职”状态，则需要切换并更新新的客服代表安排给用户。

在步骤s416中，在一可设定的时间范围内，接到客户来电，根据系统登记的“用户号码和客服事件id的关系”，优先匹配关联的客户服务代表。其中，第一优先级为用户及其业务办理请求所关联的原客服代表，该客服代表在历史业务办理记录中与该用户发生过沟通，或办理过类似业务事件。

借此，不仅可以将与用户业务办理请求相关的历史沟通的客服代表确定，还可以同时考虑该客服代表的当前服务状态，使得用户的选择更加丰富，体验更佳。

如图4b所示，根据本公开的实施例，在步骤s202通过客服事件信息确定与业务办理请求相对应的客服代表中，还包括步骤s430-步骤s440。

在步骤s430中，根据当前服务状态，生成客服流程选择；

在步骤s440中，根据客服流程选择更新客服代表。

其中，图4d所示应用场景中流程步骤s416-步骤s418，可以用于解释如图4b中所示方法流程。

参照上述步骤s416，相对于上述第一优先级，第二优先级为用户所选择id通过关联id所查询到的其他客服代表，如客服代表均忙线，则提示用户可以选择“等待”、“转其他客服代表”或“待客服代表空闲时间再联系用户”。

在步骤s417中，如在前述步骤未能顺利接通原客服代表，则进入客服流程选择的程序，如继续等待及客服代表更新选择的流程，根据客户的选择“等待接通原客服代表”、或“转其他客服代表”，或“待客服代表空闲时间联系用户”等相应选择内容，实现转其他客服代表的过程，完成对新客服代表的更新确定。其中，在更新过程中，仍然根据用户业务处理请求所关联的事件类型，进行最优客服代表匹配。

在步骤s418中，若根据用户选择的客服流程选择，如“待客服代表空闲时联系我”，则会在原客服代表的当前服务状态更新为“空闲”时，由该原客服代表继续联系该用户。

借此，可以使得用户的客服代表的确定具有更加多样的选择，有效提高用户与客服代表(包括确定的更新的客服代表和原客服代表)之间的沟通效率，改善用户体验。

如图4c所示，根据本公开的实施例，在步骤s203将客服代表推送给用户，以实现客服代表与用户之间的直接业务沟通中，包括步骤s403-步骤s404。

在步骤s403中，建立客服代表与用户之间的事件沟通关系；

在步骤s404中，根据事件沟通关系，将客服代表推送给用户。

其中，图4d所示应用场景中流程步骤s419，可以用于解释如图4c中所示方法流程。

在步骤s419中，若确定原客服代表或新客服代表接通电话或主动向用户拨打电话，服务器系统主动将与业务办理请求对应的客服事件信息的客服事件id与该用户和对应客服代表相关联以建立事件沟通关系，同时将所查询的该客服事件id的详细信息，推送给客服代表，以使得客服代表能够提前主动回顾并掌握用户需求，提供高效的、有针对性的服务。并将该客服代表依据事件沟通关系推送给用户，由用户选择是否进一步与该推送的客服代表进行联系沟通。

其中，事件沟通关系用于确定该用户的业务办理请求和确定的客服代表之间的对应关系，明确客服代表和用户之间的确定沟通内容，便于客服代表和用户之间的相互了解，使得客服代表在联系沟通之前能够快速明确用户的业务办理请求的相关内容，提高沟通效率。

如图4c所示，根据本公开的实施例，在步骤s404根据事件沟通关系，将客服代表推送给用户之后，还包括步骤s405-步骤s406。

在步骤s405中，根据事件沟通关系，生成客服交互选择；

在步骤s406中，基于客服交互选择，实现客服代表与用户之间的直接业务沟通。

在本公开的另一实施例中，根据前述所定义的事件沟通关系，确定了客服代表和用户之间的沟通联系，为进一步提高客服沟通效率，还可以考虑为客服代表提供一客服交互选择，如更新后的新客服代表需要对用户的历史业务办理记录进行浏览需要一定的时间，则，该客服交互选择可以是“稍等五分钟”或者“需要确认信息”，对应反馈给用户，使得用户得知新客服代表的当前沟通进度。进一步地，可以依据该客服交互选择，实现客服代表和用户之间的直接业务沟通。

需要进一步说的是，如图4a-图4d所示，在步骤s4110中，客服代表提供业务沟通服务，并同时进行业务办理请求相关的当前业务办理记录的登记，同时对如表1所示的客服事件信息进行更新，具体涉及建立新的客服事件id及其对应的完整信息，包含来电号码、沟通时间、客服代表编号、电话类型、摘要、详细信息、录音等信息。

因此，服务器系统根据用户的选择，登记用户的业务办理请求和客服事件信息建立关系，服务器系统据此发起自动通知到关联的客服代表，如用户选择了“联系我”或者“待客服代表空闲时间联系用户”，则系统主动将待拨打电话请求推送给客服代表，并将与用户关联的客服事件id的相关信息推送给客服代表以建立事件沟通关系，待客服代表空闲时发起电话联系。其中，优先由原客服代表联系用户，如该原客服代表的当前服务状态为如离职、已下班、已休假等客观情况，则服务器系统需要自动分配相关专业的新客服代表，并将用户关联的客服事件id关系推送给新客服代表。因此，无论是原客服代表或新客服代表，都可以根据客服事件id对应的客服事件信息提前主动回顾并掌握用户业务办理请求的对应需求，提供高效、有针对性的业务沟通服务。

图5示意性示出了根据本公开一实施例的客服代表的推送装置的示例性架构；

需要注意的是，图5所示仪为可以应用本公开实施例的系统架构500的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

本公开的另一方面提供了一种客服代表推送装置500，其中，包括信息调取模块510、客服确定模块520和客服推送模块530。信息调取模块510用于根据用户的业务办理请求，调取与用户相关的客服事件信息；客服确定模块520用于通过客服事件信息确定与业务办理请求相对应的客服代表；客服推送模块530用于将客服代表推送给用户，以实现客服代表与用户之间的直接业务沟通；其中，客服确定模块520包括记录确定单元和客服确定单元。记录确定单元用于通过客服事件信息确定用户在预设时间范围内的业务办理记录；客服确定单元用于根据业务办理记录确定客服代表。

其中，信息调取模块510、客服确定模块520和客服推送模块530分别可以用于实现如图2a所示流程步骤s201、s202和s203的方法，记录确定单元和客服确定单元则可以用于实现如图2b所示流程步骤s210和s220的方法，在此不作赘述。

根据本公开的实施例，该装置还包括记录建立模块和信息确定模块。记录建立模块用于在根据用户的业务办理请求，获取与用户相关的客服事件信息之前，建立与用户之间的至少一业务办理记录；信息确定模块用于根据至少一业务办理记录，确定客服事件信息。

其中，记录建立模块和信息确定模块则可以用于实现如图3a所示流程步骤s301和s302的方法，在此不作赘述。

根据本公开的实施例，信息调取模块510包括交互选择生成单元和信息调取单元。交互选择生成单元用于基于业务办理请求，生成交互申请选择；信息调取单元用于根据交互申请选择，调取客服事件信息。

其中，交互选择生成单元和信息调取单元则可以用于实现如图4a所示流程步骤s401和s402的方法，在此不作赘述。

根据本公开的实施例，客服确定模块520还包括状态确定单元，状态确定单元用于确定客服代表的当前服务状态；其中，客服确定单元还用于根据当前服务状态确定客服代表。

其中，状态确定单元和客服确定单元则可以用于实现如图4b所示流程步骤s410和s420的方法，在此不作赘述。

根据本公开的实施例，客服确定模块520还包括流程选择单元和客服更新单元。流程选择单元用于根据当前服务状态，生成客服流程选择；客服更新单元用于根据客服流程选择更新客服代表。

其中，流程选择单元和客服更新单元则可以用于实现如图4b所示流程步骤s430和s440的方法，在此不作赘述。

根据本公开的实施例，客服推送模块530包括关系建立单元和客服推送单元。关系建立单元用于建立客服代表与用户之间的事件沟通关系；客服推送单元用于根据事件沟通关系，将客服代表推送给用户。

其中，关系建立单元和客服推送单元则可以用于实现如图4c所示流程步骤s403和s404的方法，在此不作赘述。

根据本公开的实施例，客服推送模块530还包括客服选择单元和沟通建立单元。客服选择单元用于根据事件沟通关系，生成客服交互选择；沟通建立单元用于基于客服交互选择，实现客服代表与用户之间的直接业务沟通。

其中，客服选择单元和沟通建立单元则可以用于实现如图4c所示流程步骤s405和s406的方法，在此不作赘述。

需要说明的是，客服代表的推送装置部分的实施例方式与客服代表的推送方法部分的实施例方式对应类似，并且所达到的技术效果也对应类似，在此不再赘述。

实施例2

以下结合图6a-图10，对本公开另一实施例提供的客服代表的推送方法、客服代表的推送装置、电子设备及计算机可读存储介质作进一步的详细说明。

图6a示意性示出了根据本公开另一实施例的客服代表的推送方法的流程图；图6b示意性示出了根据本公开另一实施例的客服代表确定方法的流程图。

如图6a和图6b所示，本公开的一方面提供了一种客服代表推送方法，其中，包括步骤s601-步骤s603。

步骤s601中，根据用户的业务办理请求，调取与用户相关的客服事件信息；

步骤s602中，通过客服事件信息确定与业务办理请求相对应的客服代表；

步骤s603中，将客服代表推送给用户，以实现客服代表与用户之间的直接业务联系；其中，在步骤s602通过客服事件信息确定与业务办理请求相对应的客服代表中，包括步骤s610和步骤s620。

业务办理请求可以是用户向服务提供方主动发起的业务办理相关的请求信息，如账户办理冻结、业务办理咨询以及电话联系请求等。其中，业务办理请求也可以包括为实现业务办理而进行的软件技术相关的请求信息，如转账页面无法打开、应用程序账户登录超时等。

客服事件信息为与该用户在该业务办理请求之前所发生的相关的业务办理信息，可以理解为业务办理的记录信息的汇总内容，如历史客户服务明细。若该用户的业务办理请求为首次业务联系沟通，则其客服事件信息为空。此外，用户也可以借此实现通过对客服事件信息的查询来验证客服主动沟通的真伪。

用户为确保自己的业务办理能够顺利完成，并达到预期的业务办理成效，可以通过如图1所示数据请求系统110中终端设备111、112、113、114或115的应用程序软件(如app、小程序、公众号等)向如图1所示的服务器系统120发起数据请求，即业务办理请求。该服务器系统120在接收到用户的业务办理请求之后，可以依据该用户的账户信息(如姓名、身份证号码等)对其相关的客服事件信息进行调取。其中，服务器系统120需要执行步骤s201-s203中的流程内容，在此不作赘述。

客服代表为能够代表服务提供方与用户进行直接业务沟通(如电话、文字以及视频的沟通形式)，实现用户的业务办理请求的业务人员、技术人员等专业人员，即人工客服。基于用户对应的客服事件信息，确定相应的客服代表，该客服代表可以更好地实现用户的业务办理请求相关的办理工作，以更好地实现用户的业务办理期望，提高用户的体验。其中，在客服事件信息为空的情况下，可以基于业务办理请求中业务需求对客服代表进行确定，如推送与业务办理请求的业务类型相关的客服代表。

最后，基于相应地预设推送机制，将所确定的客服代表推送给用户，实现客服代表与用户之间的直接业务沟通。

步骤s610中，根据客服事件信息确定用户的业务办理请求的业务优先级；

步骤s620中，根据业务优先级确定客服代表。

客服事件信息可以由至少一个业务办理记录逐步累积构成，业务办理记录是区别于当前业务办理请求，基于历史记录中的至少一个而业务办理请求而完成或进行中的业务办理相关的记录信息，如在一次业务办理事件中所产生的与该业务办理相关业务类型、摘要、详细信息、沟通或办理时间、办理状态、客服代表的编号以及录音等所构成的记录内容。其中，录音可以实现文字识别，以记录沟通详情。

在本公开的实施例中，每个业务办理事件都具有相应地业务优先级，具体可以根据该业务办理事件对应业务办理请求对应的业务类型、处理状态对其所建立的业务优先信息，如与该业务办理请求对应的一系列业务办理记录均为同一业务类型且该业务类型的处理状态处于“处理中”时，则确定该对应的业务办理请求的业务优先级为高，否则为低。

借此，可以依据该业务办理请求的业务优先级高低，优先匹配相应的客服代理给该用户，该客服代理一般可以根据该一系列业务办理记录所形成的主记录中的业务办理记录次数对该用户进行优先匹配，其中，该一系列业务办理记录中的每个业务办理记录为该主记录中的子记录，若该新的业务办理请求的业务类型也与该主记录中的业务类型一致，则该业务办理请求对应的业务办理记录作为该主记录中的一个子记录，对该主记录进行更新。其中，关于主记录与子记录之间的关系可以参照如下述表3的内容。

通常，对应当前业务办理请求对应的该主记录中的子记录数量为大于1时，且其中主记录的处理状态为处理中时，判断该业务办理请求的优先级为高，优先匹配该主记录中所对应的办理次数最多的客服代表，即原客服代表。

因此，本公开的上述推送方法可以提供历史客户服务明细查询功能，通过综合沟通次数、处理状态以及对应业务类型等情况，对历史服务记录进行智能排序，在用户查询、客服查询、用户拨打电话等业务办理请求的实现环节，优先匹配原始服务的客服代表，并关联相应的事件记录，提高业务办理的沟通效率，改善用户体验。

图7示意性示出了根据本公开另一实施例的客服事件信息的确定方法的流程图。

如图7所示，根据本公开的实施例，在步骤s601根据用户的业务办理请求，获取与用户相关的客服事件信息之前，还包括步骤s701和步骤s702。

在步骤s701中，建立与用户之间的至少一业务办理记录；

在步骤s702中，根据至少一业务办理记录，确定客服事件信息。

其中，步骤s701和步骤s702所实现的方法流程，具体可以参照前述如图3a-图3d所述的内容，在此不作赘述。

根据如步骤s3211-s316和步骤s321-s326中的首次联系沟通的实现场景，可以建立与用户之间的首次业务办理记录，若重复该相应过程，则可以实现多次业务办理记录。根据每次业务办理记录可以获得多条客服事件id，由该多条客服时间id及其对应的业务办理记录的记录内容可以形成客服事件信息，以实现该客服事件信息的确定。

此外，在步骤s702根据至少一业务办理记录，确定客服事件信息中，还包括：根据至少一业务办理记录和查询验证请求，确定客服事件信息，具体可以确定其真伪情况。借此，本公开实施例的上述方法可以实现相应的业务办理过程中的真伪验证，确保用户数据安全，提升用户体验。

图8a示意性示出了根据本公开另一实施例的业务优先级的确定方法的流程图。

如图8a所示，根据本公开的实施例，在步骤s610根据客服事件信息确定用户的业务办理请求的业务优先级中，包括步骤s801和步骤s802。

在步骤s801中，获取业务办理请求的业务事件类型；

在步骤s802中，根据业务事件类型和优先级规则，确定业务办理请求的业务优先级。

对应于该业务办理请求，可以确定用户所需要的业务事件类型，业务事件类型可以是具体的业务办理内容，如订单咨询、账户使用存在问题、产品的咨询问题以及办理账户冻结等金融业务等。根据该业务事件类型对该业务办理请求对应的业务办理记录进行归类，具体可以归类为主记录或对应主记录下的子记录。

相应地，优先级规则可以为设定的或生成的优先级判断规则，以决定该业务办理请求的具体优先级。若优先级为高，则优先确定原客服代表给该用户对应处理器业务办理请求。

如图8a所示，根据本公开的实施例，在步骤s610根据客服事件信息确定用户的业务办理请求的业务优先级中，还包括步骤s810和步骤s820。

在步骤s810中，获取客服事件信息中至少一业务办理记录中每个业务办理记录的业务处理状态；

在步骤s820中，依据每个业务办理记录的业务处理状态，对至少一业务办理记录进行优先级排序，以确定优先级规则。

优先级规则为能够针对业务事件类型进一步提供业务办理请求优先级确定的设定规则。具体地，在客服代表和用户进行客服事件信息查询时，服务器系统能够根据用户的id和相关身份信息，查询历史电话沟通记录，依据处理状态和业务类型，优先返回处理状态为“处理中”的业务办理记录，其中，该处理状态即对应业务办理记录的业务处理状态。对于同时存在子记录的主记录，根据来电次数进行优先级排序，优先返回主记录处理状态为处理中，并且子记录更多的记录。

用户拨打客服电话时，系统根据用户的id和鉴别信息，查询历史来电记录，优先返回处理状态为“处理中”的记录，对于同时存在子记录的沟通的记录，根据来电次数进行优先级排序，优先返回主记录处理状态为处理中，并且子记录更多的记录。智能定位到的客服服务id，优先匹配该客服服务id所关联的客户服务代表，第一优先级为用户选择id所关联的客服代表，第二优先级为用户所选择id通过关联id所查询到的其他客服代表，如客服代表均忙线，则提示用户可以选择“等待”、“转其他客服代表”或“待客服代表空闲时间再联系用户”；如客服代表已下班，离开无法等待，则提示用户可以选择“转其他客服代表”。

其中，当该业务办理请求对应业务事件类型在该用户的客服事件信息中为首次出现的业务类型，则可以将该业务办理请求对应业务办理记录归类为主记录，如下述表3所示主记录1和主记录2，同时记录其相应的处理状态，若为当前处理则为处理中，若为已处理则可以处理中或处理完结。当该业务办理请求对应的业务事件类型在该用户的客服事件信息中为非首次出现的业务类型，则可以将其归类为前述已出现的业务办理记录的子记录，前述已出现的业务办理记录为主记录，如下述表3所示，主记录1的子记录1、子记录2和子记录3。

表3

图8b示意性示出了根据本公开另一实施例的客服事件信息的调取方法的流程图；图8c示意性示出了根据本公开另一实施例的客服代表的更新方法的流程图；图8d示意性示出了根据本公开另一实施例的客服代表的沟通方法的流程图。

如图8b所示，根据本公开的实施例，在步骤s601根据用户的业务办理请求，调取与用户相关的客服事件信息中，包括步骤s803-步骤s804。

在步骤s803中，基于业务办理请求，生成交互申请选择；

在步骤s804中，根据交互申请选择，调取客服事件信息。

其中，步骤s803和步骤s804所实现的方法流程，具体可以参照前述如图4a所述的步骤s401-步骤s402的内容，在此不作赘述。

如图8c所示，根据本公开的实施例，在步骤s602通过客服事件信息确定与业务办理请求相对应的客服代表中，还包括步骤s830-步骤s840。

在步骤s830中，通过客服事件信息确定客服代表的当前服务状态；

在步骤s840中，根据当前服务状态确定客服代表。

其中，步骤s830和步骤s840所实现的方法流程，具体可以参照前述如图4b所述的步骤s410-步骤s420的内容，在此不作赘述。

如图8c所示，根据本公开的实施例，在通过客服事件信息确定与业务办理请求相对应的客服代表中，还包括步骤s850-步骤s860。

在步骤s850中，根据当前服务状态，生成客服流程选择；

在步骤s860中，根据客服流程选择更新客服代表。

其中，步骤s850和步骤s860所实现的方法流程，具体可以参照前述如图4b所述的步骤s430-步骤s440的内容，在此不作赘述。

如图8d所示，根据本公开的实施例，在步骤s603将客服代表推送给用户，以实现客服代表与用户之间的直接业务沟通中，包括步骤s805和步骤s806。

在步骤s805中，建立客服代表与用户之间的事件沟通关系；

在步骤s806中，根据事件沟通关系，将客服代表推送给用户。

其中，步骤s805和步骤s806所实现的方法流程，具体可以参照前述如图4c所述的步骤s403-步骤s404的内容，在此不作赘述。

如图8d所示，根据本公开的实施例，在步骤s603根据事件沟通关系，将客服代表推送给用户之后，还包括步骤s807和步骤s808。

在步骤s807中，根据事件沟通关系，生成客服交互选择；

在步骤s808中，基于客服交互选择，实现客服代表与用户之间的直接业务沟通。

其中，步骤s807和步骤s808所实现的方法流程，具体可以参照前述如图4c所述的步骤s405-步骤s406的内容，在此不作赘述。

图9示意性示出了根据本公开另一实施例的客服代表的推送装置的示例性架构；

需要注意的是，图9所示仅为可以应用本公开实施例的系统架构900的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

本公开的另一方面提供了一种客服代表推送装置900，其中，包括信息调取模块910、客服确定模块920和客服推送模块930。信息调取模块910用于根据用户的业务办理请求，调取与用户相关的客服事件信息；客服确定模块920用于通过客服事件信息确定与业务办理请求相对应的客服代表；客服推送模块930用于将客服代表推送给用户，以实现客服代表与用户之间的直接业务联系；其中，客服确定模块920包括优先确定单元和客服确定单元，优先确定单元用于根据客服事件信息确定用户的业务办理请求的业务优先级；客服确定单元用于根据业务优先级确定客服代表。

其中，记录建立模块和信息确定模块则可以用于实现如图6a-图6b所示流程步骤s601和步骤s602和步骤s610和步骤s620的方法，在此不作赘述。

根据本公开的实施例，该装置还包括记录建立模块和信息确定模块，记录建立模块用于建立与用户之间的至少一业务办理记录；信息确定模块用于根据至少一业务办理记录，确定客服事件信息。

其中，记录建立模块和信息确定模块则可以用于实现如图7所示流程步骤s701和s702的方法，在此不作赘述。

根据本公开的实施例，优先确定单元包括事件获取子单元和优先确定子单元。事件获取子单元用于获取业务办理请求的业务事件类型；优先确定子单元用于根据业务事件类型和优先级规则，确定业务办理请求的业务优先级。

其中，获取子单元和优先确定子单元则可以用于实现如图8a所示流程步骤s801和s802的方法，在此不作赘述。

根据本公开的实施例，优先确定单元还包括状态获取子单元和规则建立子单元。状态获取子单元用于获取客服事件信息中至少一业务办理记录中每个业务办理记录的业务处理状态；规则建立子单元用于依据每个业务办理记录的业务处理状态，对至少一业务办理记录进行优先级排序，以确定优先级规则。

其中，状态获取子单元和规则建立子单元则可以用于实现如图8a所示流程步骤s810和s820的方法，在此不作赘述。

根据本公开的实施例，信息调取模块910包括交互选择生成单元和信息调取单元，交互选择生成单元用于基于业务办理请求，生成交互申请选择；信息调取单元用于根据交互申请选择，调取客服事件信息。

其中，交互选择生成单元和信息调取单元则可以用于实现如图8b所示流程步骤s803和s804的方法，在此不作赘述。

根据本公开的实施例，客服确定模块920还包括状态确定单元，状态确定单元用于通过客服事件信息确定客服代表的当前服务状态；其中，客服确定单元还用于根据当前服务状态确定客服代表。

其中，状态确定单元和客服确定单元则可以用于实现如图8c所示流程步骤s830和s840的方法，在此不作赘述。

根据本公开的实施例，客服确定模块920还包括流程选择单元和客服更新单元。流程选择单元用于根据当前服务状态，生成客服流程选择；客服更新单元用于根据客服流程选择更新客服代表。

其中，流程选择单元和客服更新单元则可以用于实现如图8c所示流程步骤s850和s860的方法，在此不作赘述。

根据本公开的实施例，客服推送模块930包括关系建立单元和客服推送单元。关系建立单元用于建立客服代表与用户之间的事件沟通关系；客服推送单元用于根据事件沟通关系，将客服代表推送给用户。

其中，关系建立单元和客服推送单元则可以用于实现如图8d所示流程步骤s805和s806的方法，在此不作赘述。

根据本公开的实施例，客服推送模块还包括客服选择单元和沟通建立单元。客服选择单元用于根据事件沟通关系，生成客服交互选择；沟通建立单元用于基于客服交互选择，实现客服代表与所述用户之间的直接业务沟通。

其中，客服选择单元和沟通建立单元则可以用于实现如图8d所示流程步骤s807和s808的方法，在此不作赘述。

需要说明的是，客服代表的推送装置部分的实施例方式与客服代表的推送方法部分的实施例方式对应类似，并且所达到的技术效果也对应类似，在此不再赘述。

图10示意性示出了根据本公开实施例的电子设备的框图。

本公开的另一方面提供了一种电子设备，包括一个或多个处理器和存储器；存储器用于存储一个或多个程序，其中，当上述一个或多个程序被上述一个或多个处理器执行时，使得上述一个或多个处理器实现本公开实施例的方法。

图10示意性示出了根据本公开实施例的电子设备的框图。图10示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，根据本公开实施例的计算机系统1000包括处理器1001，其可以根据存储在只读存储器(rom)1002中的程序或者从存储部分1008加载到随机访问存储器(ram)1003中的程序而执行各种适当的动作和处理。处理器1001例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))，等等。处理器1001还可以包括用于缓存用途的板载存储器。处理器1001可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在ram1003中，存储有系统1000操作所需的各种程序和数据。处理器1001、rom1002以及ram1003通过总线1004彼此相连。处理器1001通过执行rom1002和/或ram1003中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom1002和ram1003以外的一个或多个存储器中。处理器1001也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统1000还可以包括输入/输出(i/o)接口1005，输入/输出(i/o)接口1005也连接至总线1004。系统1000还可以包括连接至i/o接口1005的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1006；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分1007；包括硬盘等的存储部分1008；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至i/o接口1008。可拆卸介质1011，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1010上，以便于从其上读出的计算机程序根据需要被安装入存储部分1008。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1009从网络上被下载和安装，和/或从可拆卸介质1011被安装。在该计算机程序被处理器1001执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom1002和/或ram1003和/或rom1002和ram1003以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，上述指令在被执行时用于实现本公开实施例的方法。

具体地，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。

上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的客服代表的推送方法。

或者，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。

上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

本公开的另一方面提供了一种计算机程序，上述计算机程序包括计算机可执行指令，上述指令在被执行时用于实现本公开实施例客服代表的推送方法。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。