用于预测顾客行程应用程序中的工作负荷需求的方法和系统

背景技术

本发明整体涉及电信系统和方法，以及联系中心人员配置。更具体地讲，本发明涉及针对联系中心人员配置的资源的工作负荷预测。

相关专利申请的交叉引用

本申请要求于2018年9月11日提交于美国专利商标局的名称为“用于预测顾客行程应用程序中的工作负荷需求的方法和系统(METHOD AND SYSTEM TO PREDICT WORKLOADDEMAND IN A CUSTOMER JOURNEY APPLICATION)”的美国临时专利申请号62/729,856的权益，该临时专利申请的内容并入本文。

发明内容

本发明提供了一种用于预测顾客行程应用程序中的工作负荷需求的系统和方法。使用来自行程分析的历史信息，可通过各个阶段聚合行程时刻。概率分布向量可针对连接该阶段的各种路径进行近似。此类概率分布的稳定性可通过统计方法来确定。在起始阶段应用时间序列预报算法之后，可通过递归算法来确定对通过该阶段进展的未来量的预测。一旦在每个阶段预报了未来量，就可估计未来工作负荷以进行资源的更好容量规划和调度来处理此类需求，从而沿着成本函数实现性能度量。

在一个实施方案中，本发明提供了一种用于预测联系中心环境中的资源规划的工作负荷需求的方法，该方法包括：从数据库中提取历史数据，其中该历史数据包括多个阶段级别，该多个阶段级别表示联系中心资源为顾客行程中的阶段级别提供服务所花费的时间；预处理该历史数据，其中该预处理还包括针对每个阶段级别导出邻接图、导出序列零以及导出阶段历史；使用所预处理的历史数据来确定阶段预测并构建预测模型；以及使用所构建的模型来导出预测的工作负荷需求。

该阶段级别包括该顾客行程的焦点以及从该顾客行程中的每个阶段的转变。该提取由以下项中的一者触发：用户动作、调度作业和来自另一个服务的队列请求。该邻接图对阶段之间的图连接进行建模。序列零包括序列进展链的第一阶段。阶段历史包括每个阶段的属性，该属性包括历史向量计数、放弃率和概率向量矩阵。

该阶段预测还包括以下步骤：运行刷新算法，该刷新算法运行该历史数据的迭代以通过多个阶段和周期来刷新量；保留历史数据的一部分以进行验证，从而产生剩余部分；使用该剩余部分来构建和训练该预测模型；以及校准该预测模型。刷新量包括从预报开始日期向后减去一个周期工作，以及在每个重复使每个周期增加一的情况下重复。

该预测的工作负荷需求包括随着顾客通过该顾客行程中的阶段进展而从交互量生成的工作负荷，包括预测的放弃。该预测的工作负荷需求还包括处理该预测的工作负荷以递送该联系中心的KPI度量目标所需的资源。

在另一个实施方案中，本发明提供了一种用于预测联系中心环境中的资源规划的工作负荷需求的方法，该方法包括：从数据库中提取历史数据，其中该历史数据包括多个阶段级别，该多个阶段级别表示联系中心资源为顾客行程中的阶段级别提供服务所采取的动作；预处理该历史数据，其中该预处理还包括针对每个阶段级别导出邻接图、导出序列零以及导出阶段历史；使用所预处理的历史数据来确定阶段预测并构建预测模型；以及使用所构建的模型来导出预测的工作负荷需求。

在另一个实施方案中，本发明提供了一种用于预测联系中心环境中的资源规划的工作负荷需求的系统，该系统包括：处理器；和存储器，该存储器与该处理器通信，该存储器存储指令，该指令在由该处理器执行时致使该处理器：从数据库中提取历史数据，其中该历史数据包括多个阶段级别，该多个阶段级别表示联系中心资源为顾客行程中的阶段级别提供服务所花费的时间；预处理该历史数据，其中该预处理还包括针对每个阶段级别导出邻接图、导出序列零以及导出阶段历史；使用所预处理的历史数据来确定阶段预测并构建预测模型；以及使用所构建的模型来导出预测的工作负荷需求。

在另一个实施方案中，本发明提供了一种用于预测联系中心环境中的资源规划的工作负荷需求的系统，该系统包括：处理器；和存储器，该存储器与该处理器通信，该存储器存储指令，该指令在由该处理器执行时致使该处理器：从数据库中提取历史数据，其中该历史数据包括多个阶段级别，该多个阶段级别表示联系中心资源为顾客行程中的阶段级别提供服务所采取的动作；预处理该历史数据，其中该预处理还包括针对每个阶段级别导出邻接图、导出序列零以及导出阶段历史；使用所预处理的历史数据来确定阶段预测并构建预测模型；以及使用所构建的模型来导出预测的工作负荷需求。

附图说明

图1是示出通信基础设施的实施方案的图。

图2是示出劳动力管理架构的实施方案的图。

图3是示出用于创建用于工作负荷需求预测的模型的过程的实施方案的流程图。

图4A是行程的实施方案的有向图表示。

图4B是邻接图形表示的实施方案。

图4C是邻接图形表示的实施方案。

图5是示出用于导出序列零的过程的实施方案的流程图。

图6是示出用于导出阶段历史的过程的实施方案的流程图。

图7是示出用于需求刷新的过程的实施方案的流程图。

图8A是示出计算设备的实施方案的图。

图8B是示出计算设备的实施方案的图。

具体实施方式

为了促进理解本发明原理的目的，现在将参考附图中示出的实施方案，并且将使用特定语言来描述这些实施方案。然而，应当理解，由此不旨在限制本发明的范围。如本发明所涉及的领域的技术人员通常会想到的，设想了所述实施方案中的任何改变和进一步修改，以及如本文所述的本发明原理的任何进一步应用。

联系中心环境中的顾客交互管理包括管理各方之间的交互，例如，顾客和代理之间的交互、顾客和机器人程式之间的交互或两者的混合。这可跨联系中心中的任何数量的信道发生，从而基于技能和/或任何数量的参数跟踪并瞄准最佳可能资源(代理或自动服务)。可实时以及以历史方式对信道交互进行报告。顾客采取的与相同服务、需要或目的相关的所有交互可被描述为顾客的行程。关于顾客行程的分析在本文中和本领域中可称为“行程分析”。例如，如果顾客正在浏览公司A的电子商店网站，以其凭证登录，进行购买，并且然后在从该在线购买动作开始的特定时段内呼叫公司A的顾客支持线路，则顾客很有可能关于该在线购买而进行呼叫(例如，询问物品为何尚未运输、升级到夜间运输、取消订单等)。在该示例中，顾客所进行的所有交互构成一个行程。“行程分析”平台可用于分析在一定时间段内的与给定实体(例如，网站、业务、联系中心、IVR)的全部交互期间的顾客的端到端行程。

预先确定通过顾客支持线路进行的大部分呼叫是否与运输查询有关的能力可为公司A提供采取主动动作诸如经由信道(例如，电子邮件、SMS、回调电话等)向顾客发送通知的机会。在该示例中，公司A可发送订单确认、跟踪号码和/或升级运输方法的可能方案。

认识到顾客行程中的时刻并主动采取动作可提供更好的顾客服务和结果。对于通过预报资源的需求和工作负荷来规划其资源的业务而言，对在视觉上和统计上报告随着顾客通过阶段进展的事件继续的需要也是重要的。

图1是示出大体以100指示的通信基础设施的实施方案的图。例如，图1示出了用于在提供联系中心服务时支持联系中心的系统。联系中心可以是业务或企业的内部设施，以用于在相对于通过企业可得的产品和服务执行销售和服务功能时服务于企业。在另一个方面，联系中心可由第三方服务提供方操作。在一个实施方案中，联系中心可作为混合系统操作，其中联系中心系统的一些部件被托管在联系中心楼宇处并且其他部件被远程托管(例如，在基于云的环境中)。联系中心可被部署在专用于企业或第三方服务提供方的装备上，和/或部署在远程计算环境中，诸如具有用于为多个企业支持多个联系中心的基础设施的私有或公共云环境。联系中心系统的各种部件也可分布在各种地理位置和计算环境中，并且不一定包含在单个位置、计算环境或甚至计算设备中。

大体以100指示的通信基础设施的部件包括：多个最终用户设备105A、105B、105C；通信网络110；交换机/媒体网关115；呼叫控制器120；IMR服务器125；路由服务器130；存储设备135；统计服务器140；包括工作仓146A、146B、146C的多个代理设备145A、145B、145C，其中一者可与联系中心管理员或监管员145D相关联；多媒体/社交媒体服务器150；web服务器155；iXn服务器160；UCS 165；报告服务器170；以及媒体服务175。

在一个实施方案中，联系中心系统管理资源(例如，人员、计算机、电信装备等)以使得能够经由电话或其他通信机制递送服务。此类服务可取决于联系中心的类型而变化，并且其范围可从顾客服务到帮助台、紧急响应、远程营销、接订单等。

期望从联系中心接收服务的顾客、潜在顾客或其他最终用户(统称为顾客或最终用户)可经由最终用户设备105A、105B和105C(统称为105)发起到联系中心的入站通信(例如，电话呼叫、电子邮件、聊天等)。最终用户设备105中的每一者可以是本领域中常规的通信设备，诸如电话、无线电话、智能电话、个人计算机、电子平板电脑、膝上型电脑等(列举一些非限制性示例)。操作最终用户设备105的用户可发起、管理和响应于电话呼叫、电子邮件、聊天、文本消息、web浏览会话和其他多媒体交易。虽然为简单起见在100处示出了三个最终用户设备105，但可存在任何数量的最终用户设备。

来自和到达最终用户设备105的入站通信和出站通信可遍历网络110，这取决于正在使用的设备的类型。网络110可包括电话、蜂窝和/或数据服务的通信网络，并且还可包括专用或公共交换电话网络(PSTN)、局域网(LAN)、专用广域网(WAN)和/或公共WAN诸如互联网(列举非限制性示例)。网络110还可包括无线运营商网络，该无线运营商网络包括码分多址(CDMA)网络、全球移动通信系统(GSM)网络或本领域中常规的任何无线网络/技术，包括但不限于3G、4G、LTE等。

在一个实施方案中，联系中心系统包括耦接到网络110的交换机/媒体网关115以用于在最终用户和联系中心之间接收和传输电话呼叫。交换机/媒体网关115可包括电话交换机或通信交换机，其被配置为用作用于中心内的代理级别路由的中心交换机。交换机可以是硬件交换系统或经由软件实现的软交换机。例如，交换机115可包括自动呼叫分配器、专用交换分机(PBX)、基于IP的软件交换机和/或具有专用硬件和软件的任何其他交换机，该专用硬件和软件被配置为从顾客接收互联网来源的交互和/或电话网络来源的交互，并且将那些交互路由到例如代理电话或通信设备。在该示例中，交换机/媒体网关通过例如在顾客的电话设备和代理电话设备之间建立连接来建立呼叫顾客和代理电话设备之间的语音路径/连接(未示出)。

在一个实施方案中，交换机耦接到呼叫控制器120，该呼叫控制器可例如用作交换机与联系中心的路由、监测和其他通信处理部件的其余部分之间的适配器或接口。呼叫控制器120可被配置为处理PSTN呼叫、VoIP呼叫等。例如，呼叫控制器120可被配置有用于与交换机/媒体网关和联系中心装备接合的计算机电话集成(CTI)软件。在一个实施方案中，呼叫控制器120可包括用于处理SIP呼叫的会话发起协议(SIP)服务器。呼叫控制器120还可提取关于顾客交互的数据，诸如呼叫者的电话号码(例如，自动号码识别(ANI)号码)、顾客的互联网协议(IP)地址或电子邮件地址，并且在处理交互时与系统100的其他部件通信。

在一个实施方案中，系统100还包括交互式媒体响应(IMR)服务器125。IMR服务器125也可被称为自助系统、虚拟助理等。IMR服务器125可类似于交互式语音响应(IVR)服务器，不同的是IMR服务器125不限于语音并且另外可覆盖各种媒体信道。在示出语音的示例中，IMR服务器125可被配置有IMR脚本以用于向顾客查询其需求。例如，银行的联系中心可经由IMR脚本告知顾客如果他们希望检索其账户余额，则“按下1”。通过与IMR服务器125继续交互，顾客可以能够完成服务而无需与代理说话。IMR服务器125还可询问开放式问题，诸如“我怎样可以帮助您？”，并且顾客可说出或以其他方式输入联系该联系中心的原因。路由服务器130可使用顾客的响应以将呼叫或通信路由到适当的联系中心资源。

如果要将通信路由到代理，则呼叫控制器120与路由服务器(也称为编排服务器)130交互以找到用于处理交互的适当代理。用于路由入站交互的适当代理的选择可基于例如路由服务器130所采用的路由策略，并且进一步基于有关例如由统计服务器140提供的代理可用性、技能和其他路由参数的信息。

在一个实施方案中，路由服务器130可查询顾客数据库，该顾客数据库存储关于现有客户端的信息，诸如联系信息、服务级别协议(SLA)要求、先前顾客联系的性质以及联系中心为解决任何顾客问题而采取的动作等。数据库可以是例如Cassandra或任何NoSQL数据库，并且可存储在大容量存储设备135中。数据库也可以是SQL数据库并且可由任何数据库管理系统管理，诸如Oracle、IBM DB2、Microsoft SQL服务器、Microsoft Access、PostgreSQL等(列举一些非限制性示例)。路由服务器130可经由ANI从顾客数据库查询顾客信息或查询由IMR服务器125收集的任何其他信息。

一旦适当代理被识别为可用于处理通信，就可在顾客与所识别代理的代理设备145A、145B和/或145C(统称为145)之间建立连接。虽然为简单起见在图1中示出了三个代理设备，但可存在任何数量的设备。所收集的关于顾客的信息和/或顾客历史信息也可被提供给代理设备以用于辅助代理更好地服务于通信，并且另外被提供给联系中心管理员/监管员设备145D以用于管理联系中心(包括调度工作人员以处理工作负荷)。就这一点而言，每个设备145可包括适于常规电话呼叫、VoIP呼叫等的电话。设备145还可包括用于与联系中心的一个或多个服务器通信并执行与联系中心操作相关联的数据处理，以及用于经由语音和其他多媒体通信机制与顾客进行交互的计算机。

联系中心系统100还可包括多媒体/社交媒体服务器150以用于参与除与最终用户设备105和/或web服务器155的语音交互之外的媒体交互。媒体交互可与例如电子邮件、语音邮件(通过电子邮件的语音邮件)、聊天、视频、文本消息收发、网络、社交媒体、共同浏览等相关。多媒体/社交媒体服务器150可采用本领域中常规的具有用于接收、处理和转发多媒体事件的专用硬件和软件的任何IP路由器的形式。

web服务器155可包括例如最终用户可订阅的各种已知社会交互站点(诸如Facebook、Twitter、Instagram等，列举几个非限制性示例)的社会交互站点主机。在一个实施方案中，尽管web服务器155被描绘为联系中心系统100的一部分，但web服务器也可由第三方提供和/或保持在联系中心楼宇之外。web服务器155还可为正由联系中心系统100支持的企业提供网页。最终用户可浏览网页并获取关于企业的产品和服务的信息。网页还可提供用于经由例如网络聊天、语音呼叫、电子邮件、网络实时通信(WebRTC)等来联系该联系中心的机制。小程序可被部署在托管在web服务器155上的网站上。

在一个实施方案中，除实时交互之外，还可将可延期的交互/活动路由到联系中心代理。可延期的交互或活动可包括后台工作或可离线执行的工作，诸如对电子邮件、信件的响应，参加训练，或不需要与顾客的实时通信的其他活动。交互(iXn)服务器160与路由服务器130进行交互以用于选择适当的代理来处理活动。一旦被分配给代理，活动就可被推送给代理，或者可作为要由代理完成的任务出现在代理的工作仓146A、146B、146C(统称146)中。代理的工作仓可经由本领域中常规的任何数据结构(诸如链接列表、阵列等)来实现。在一个实施方案中，工作仓146可例如保持在每个代理设备145的缓冲存储器中。

在一个实施方案中，大容量存储设备135可存储与代理数据(例如，代理配置文件、计划表等)、顾客数据(例如，顾客配置文件)、交互数据(例如，与顾客的每个交互的细节，包括但不限于：交互的原因、处置数据、等待时间、处理时间等)等相关的一个或多个数据库。在另一个实施方案中，一些数据(例如，顾客配置文件数据)可保持在托管于大容量存储设备135或其他地方的顾客关系管理(CRM)数据库中。大容量存储设备135可采用如本领域中常规的硬盘或磁盘阵列的形式。

在一个实施方案中，联系中心系统可包括通用联系服务器(UCS)165，其被配置为检索存储在CRM数据库中的信息并引导将信息存储在CRM数据库中。UCS 165还可被配置为有利于保持顾客偏好历史和交互历史，并且捕获和存储关于来自代理的评论、顾客通信历史等的数据。

联系中心系统还可包括报告服务器170，其被配置为根据由统计服务器140聚合的数据生成报告。此类报告可包括与资源状态有关的近实时报告或历史报告(诸如平均等待时间、放弃率、代理占用等)。报告可自动生成或响应于来自请求者(例如，代理/管理员、联系中心应用程序等)的特定请求而生成。

联系中心系统还可包括劳动力管理(WFM)服务器180。WFM服务器自动同步化配置数据，并且充当WFM客户端的主要数据和应用程序服务源和定位器。WFM服务器180支持GUI应用程序，可从代理设备145和联系中心管理员/监管员设备145D中的任一者访问该GUI应用程序以用于管理联系中心，包括访问联系中心的行程分析平台。WFM服务器180与统计服务器140通信并且还可与配置服务器通信以用于设置目的(未示出)。在一个实施方案中，WFM服务器180还可与数据聚合器184、构建器185、web服务器155和守护进程182通信。这在下面的图2中更详细地描述。

图1的各种服务器可各自包括执行计算机程序指令并且与用于执行本文所述的各种功能的其他系统部件进行交互的一个或多个处理器。计算机程序指令存储在使用标准存储器设备诸如随机存取存储器(RAM)来实现的存储器中。计算机程序指令还可存储在其他非暂态计算机可读介质(诸如CD-ROM、闪存驱动器等)中。虽然每个服务器的功能被描述为由特定服务器提供，但本领域的技术人员应当认识到，在不脱离本发明的实施方案的范围的情况下，各种服务器的功能可被组合或集成到单个服务器中，或者特定服务器的功能可分布在一个或多个其他服务器上。

在一个实施方案中，术语“交互”和“通信”可互换使用，并且通常是指使用任何通信信道的任何实时和非实时交互，包括但不限于电话呼叫(PSTN或VoIP呼叫)、电子邮件、语音邮件、视频、聊天、屏幕共享、文本消息、社交媒体消息、WebRTC呼叫等。

媒体服务175可提供音频和/或视频服务以支持联系中心特征，诸如IVR或IMR系统的提示(例如，音频文件的回放)、保持音乐、语音邮件/单方记录、多方记录(例如，音频和/或视频呼叫的多方记录)、语音识别、双音多频(DTMF)识别、传真、音频和视频转码、安全实时传输协议(SRTP)、音频会议、视频会议、教程(例如，支持教练收听顾客和代理之间的交互以及支持教练在顾客未听到评论的情况下向代理提供评论)、呼叫分析和关键字定位。

在一个实施方案中，基于楼宇的平台产品可通过呈现在代理设备145A-145C上的用户界面(UI)提供对系统100的部件的访问和控制。在基于楼宇的平台产品内，可集成图形应用程序生成器程序，其允许用户在基于楼宇的平台产品内写入控制各种交互处理行为的程序(处理程序)。

如上所述，联系中心可作为混合系统操作，其中一些或所有部件被远程托管，诸如在基于云的环境中。为了方便起见，下面将相对于将模块化工具从基于云的环境提供到容纳在楼宇内的部件来描述本发明的实施方案的各方面。

图2是示出大体指示的劳动力管理架构的实施方案的图。部件可包括：监管员设备145D、代理设备145、web服务器155、WFM服务器180、守护进程181、API 182、数据聚合器183、构建器184、存储设备135和统计服务器140。

web服务器155包括服务器应用程序，该服务器应用程序可托管在小服务程序容器上并且为多个基于web浏览器的用户界面提供内容(例如，一个UI可用于代理并且另一个UI可用于监管员)。适当的界面在登录之后打开。监管员UI允许监管员访问如日历管理、预报、调度、实时代理依从性、联系中心性能统计、电子邮件通知的配置和报告的特征。代理UI允许代理分配调度信息(例如，经理向员工)并且向代理提供主动调度能力，诸如输入调度偏好、规划休假、调度投标、交易等。

WFM服务器180自动同步化配置数据，并且充当WFM客户端的主要数据和应用程序服务源和定位器。WFM服务器180是集线器，其连接到架构中的其他部件。

WFM守护进程181是可配置为向代理和监管员发送电子邮件通知的守护进程。API182可有利于web服务器155与WFM服务器180之间的集成、对象改变和信息检索。

数据聚合器183收集来自统计服务器140的历史数据，并且经由WFM服务器180向监管员设备145D提供实时代理依从性信息。通过数据聚合器183与统计服务器140的连接，其提供WFM架构和联系中心100之间的单个交互点。构建器184使用来自数据聚合器183的信息来构建计划表。

web服务器155为基于web浏览器的GUI应用程序提供内容，并且根据来自监管员设备145D的用户的请求生成报告。WFM服务器180、守护进程181、数据聚合器183、构建器184和web服务器155支持GUI应用程序。数据库135存储所有相关配置、预报、调度、代理依从性、性能和历史数据。WFM架构的部件可直接连接到数据库或通过WFM服务器180间接连接到数据库，如图2所示。WFM架构可以在单站点环境中或跨多站点企业操作。

图3是示出大体以300指示的用于创建用于工作负荷需求预测的模型的过程的实施方案的流程图。模型可由WFM服务器180使用以生成对联系中心环境100的工作负荷需求的预测，以及由监管员/管理员使用以在联系中心分配资源的输出。

在操作305中，提取历史数据。提取可通过被写入以输出期望数据的代码来执行。提取器代码从劳动力管理应用程序(图2)内工作，并且可通过用户界面中的按钮来利用。提取器从数据库135提取阶段信息文档对象(类似于数据库中的表格)。提取器所使用的过滤器与上文用户所指定的过滤器相同。数据提取器可由前端上的用户动作触发(如所述的)，或者也可从后端触发。例如，提取器可作为批服务驻留在由经调度CRON作业触发的后端上，并且待提供的数据可存储在终点诸如云对象存储装置(如Amazon S3)处。在另一个示例中，提取器可作为批服务驻留在由来自另一个服务的排队请求触发的后端上。

历史数据具有若干要求。例如，阶段级别必须是代理工作负荷的最接近代理，因为需求预报的最终目标是容量规划，包括：随着顾客通过阶段进展将从交互量生成的工作负荷，以及处理工作负荷以递送某些KPI度量目标(例如，服务界别、NPS、放弃)所需的资源(例如，全时等效(FTE)代理)。在一个实施方案中，要提取的行程分析数据必须处于过滤器级别，该过滤器级别输出的阶段紧密地代理了代理在服务于这些阶段实际花费的时间。这可处于平台或事件类型并且可由用户通过用户界面指定。阶段级别可由管理员预定义并且是用户可定制的。在一个实施方案中，阶段级别是顾客行程的焦点以及其从行程中的每个状态的转变。它们可取决于从顾客行程中收集什么信息的目标。行程内也可存在多个路径。预定义阶段还可包括动作分组并且任何数量的动作可在阶段内。在一个实施方案中，提取的阶段级别可能不与代理的时间绑定。相反，提取的阶段级别可与在阶段内采取的动作绑定。例如，当顾客通过阶段进展时，动作可以是在完成行程中的阶段时向该顾客发送产品样品。

历史数据应包含所需的数据元素，包括：行程类型名称、行程类型ID、顾客ID、阶段、序列、状态日期、结束日期和时间流逝。行程类型名称是描述行程类型的字符串数据类型，例如“加载请求”。行程类型ID是包括识别行程类型的唯一ID的字符串数据类型。顾客ID是包括识别顾客的唯一ID的字符串数据类型。阶段是包括阶段名称的字符串数据类型。该字段可以是动态的，这取决于由用户选择的标记策略的过滤器。序列是包括顾客所处的阶段的编号的整数数据类型。例如，第一阶段可以零开始并且下一个阶段为一。

阶段可以是顾客行程的可基于行程的感兴趣的已识别部分针对企业进行定制的部分(例如，以某种形式填充、运行信用检查、应用程序处理、支付等)，并且以可取决于偏好按顺序变化的编号序列发生。阶段可以是一个行程中的中间阶段，但在另一个行程中，相同阶段可以是“序列零”。

开始日期是包括顾客开始特定阶段时的开始日期/时间的日期数据类型，例如12/23/15 00:00或01/19/16 14:20。结束日期是包括顾客结束/退出特定阶段时的结束日期/时间的日期数据类型，例如01/06/16 00:00或01/24/16 18:56。时间流逝可以是包括结束日期和开始日期之间的秒数的整数数据类型。这必须是正数，因为结束日期总是大于或等于开始日期。

在一个实施方案中，历史数据输出可能以具有编码UTF-8的CSV格式或JSON文件/流，并且必须能够恢复回到Python和Java类。

历史数据还应包括当顾客在特定阶段放弃行程时的不同标签。控制行进到操作310并且过程300继续。

在操作310中，对历史数据进行预处理。预处理包括针对历史数据执行的若干初步计算。预处理步骤的输出用于阶段预测过程算法。预处理包括导出邻接图、导出序列零(包括计算放弃率并生成针对每个序列零阶段的量预报)以及导出阶段历史。

在第一预处理步骤中，导出邻接图。为了捕获行程时刻之间的关系，可使用对平台中的阶段之间的连接进行建模的图形表示。每个行程时刻是顾客从开始到结束进展通过的序列或阶段。图4A是大体以400指示的行程的实施方案的有向图表示。在图4A中，整个行程的起始阶段表示为v0，而结束阶段表示为v5。中间(或转变)阶段表示为顾客可在行程期间进入的v1、v2、v3和v4。放弃状态也与每个阶段相关联以汇集在特定时间段之后被假定为放弃行程并退出该阶段的顾客。阶段之间的箭头表示分析中的连接并且可利用邻接图进行建模。邻接图针对相对于特定阶段的紧邻边缘和节点(邻接前和邻接后)进行建模。每个邻接前节点将使其自身的邻接前节点和邻接后节点连接到其。邻接后节点也具有其自身的邻接前节点和邻接后节点的连接。图中的所有连接可通过以下方式来推断：迭代通过邻接图列表，从最左侧的邻接前阶段开始，然后到其邻接后节点，到下一个邻接后节点等。图4B和图4C是来自图4A所示的顾客行程的邻接图的示例。在图4B中，对于阶段v0没有邻接前节点并且这是空的。对于v0的邻接后节点为v1和v2。在图4C中，表示阶段v3、v1是邻接前节点。对于v3的邻接后节点为v4和v5。虽然为了简单起见仅示出了两个邻接图，但在行程400中其他邻接图也是可能的。在来自顾客行程400的其他示例中，阶段v1可具有作为邻接前节点的v0和作为邻接后节点的v3。阶段v2可具有作为邻接前节点的v0和作为邻接后节点的v4。阶段v4可具有作为邻接前节点的阶段v2和v3以及作为邻接后节点的v5。阶段v5可具有作为邻接前节点的阶段v3和v4并且不具有邻接后节点。可为行程中的每个阶段填充邻接图。

在另一个预处理步骤中，导出序列零。序列零可被描述为顾客开始他们的行程的阶段。这是序列进展中的第一阶段。阶段可以是一个行程中的中间阶段，但在另一个行程中，相同阶段可以是序列零。因此，作为序列零阶段并不排除成为中间阶段的可能性。图5是示出大体以500指示的用于导出序列零的过程的实施方案的流程图。如下从所提取的历史数据导出序列零及其信息。

在502处，设置期望时间段的预报长度T。这包括预先期望预报的程度。从历史数据中识别所有不同的“序列＝0”并将其保存在序列零列表中。在504处，针对序列零列表中的每个阶段，获得来自历史数据的呼叫/交互的时间戳并将其保存为时间序列。同时，在506处，根据历史数据，针对序列零列表中的每个阶段，在所有交互中确定在该阶段中花费的顾客的平均持续时间。然后，在508处，针对序列零列表中的每个阶段，确定在该阶段中花费的顾客的标准偏差持续时间。然后，在510处，针对序列零列表中的每个阶段确定“放弃持续时间阈值”。这可使用以下来确定：

其中k可以是介于1.0到正无穷大之间的任何值，这取决于积极算法需要如何将已经等待“太久”的交互(来自常规交互池)分类/标记为放弃。

在512处，针对序列零列表中的每个阶段，标记具有大于设定“放弃阈值持续时间”的持续时间的交互。被标记的这些交互被计数为“放弃”。然后，在514处，针对序列零列表中的每个阶段，对标记为放弃的交互的总数进行计数。

在516处，接下来针对序列零列表中的每个阶段确定放弃率。这可表示为如下：

针对序列零列表中的每个阶段，使用以下来确定净总量历史(518)：

阶段i的净量历史＝阶段i的总量历史*(1-阶段i的放弃率)

最后，在520处，可使用净总量作为历史(预报模型的训练数据)来运行需求预报引擎。针对序列零列表中的每个阶段，获得序列零量时间序列预报结果。在522处，存储计算结果作为序列零。引擎采用历史时间序列数据以进行预报(例如，交互量)并且对数据执行特征工程，包括数据汇总和聚合、数据清理(缺失数据设算、前导零和尾随零等)、异常值检测、模式检测，以及在给定所找到的通过交叉验证最小化预报误差的模式下选择要使用的最佳方法。

可预报时间维度的多个分级结构以便获得更好的准确度，即，每周、每天、每小时和5/15/30分钟的粒度。较低粒度预报(例如，每周)通过分配用作较高粒度预报的基线，诸如使用连接低至高粒度级别数据的预报分配来将预报值分配为每天、每小时和后续较高粒度。可连同定制的专有方法一起考虑许多常用的统计预报方法(诸如ARIMA或Holt-Winter’s)。使用具有多个折叠的交叉验证来选择最佳方法。要使用的标准可基于顾客评分，即作为准确度和总体水平准确度的组合。

在另一个预处理步骤中，从所提取的历史数据导出阶段历史。每个阶段具有由以下组成的其自身阶段历史属性：历史向量计数、放弃率和概率向量矩阵。所有阶段具有“进入”和/或“退出”每一个单个阶段的历史量，这可汇总在量计数的矩阵或向量表示中。每个阶段还可具有进入该阶段但不进展到后续邻接阶段的其历史量的百分比。这被计入对该阶段的放弃。图6是示出大体以600指示的用于导出阶段历史的过程的实施方案的流程图。

在602处，识别不同阶段。在604处，针对每个阶段填充每日量时间序列。在606处，针对每个阶段确定平均持续时间。在608处，每个阶段确定所有交互持续时间的标准偏差。在610处，针对每个阶段确定放弃持续时间阈值。在612处，标记具有大于设定“放弃阈值持续时间”的持续时间的交互。在614处，针对每个阶段确定总放弃。然后，在616处，针对每个阶段计算放弃率。这可使用以下来进行：

在618处，针对从阶段到阶段的每个组合填充每日量时间序列。因为进入和退出阶段的这些量可随时间(例如，每天)发生，所以这些量可表示为时间序列数据。概率向量(620)使用以下来确定：

向量和放弃率被存储为行程中的每个阶段的阶段历史。向量用于使用较早确定的邻接图结果来针对整个行程中的从阶段到阶段的每个组合填充概率向量矩阵。控制行进到操作315并且过程300继续。

在操作315中，执行刷新算法。必须在可执行操作315之前执行操作310。参考图4A，示例性行程可包括阶段v0、v1、v3和v5。概率向量可以从这样的行程导出，例如：

向量A可以是从阶段v0到阶段v1的表示。向量B可以是从阶段v1到阶段v3的表示。向量C可以是从阶段v3到阶段v5的表示。从阶段v0到阶段v1，交互可能在其100％移动到阶段v1之前已经等待1天。从阶段v1开始，在一天中没有交互移动到阶段v3。相反，100％的交互在第二天移动到阶段v3。从阶段v3开始，在一天中没有交互移动到阶段v5。50％的交互可在第二天从阶段v3移动到阶段v5，并且50％的交互可在第三天移动。图7是示出大体以700指示的用于需求刷新的过程的实施方案的流程图。在702处，首先确定预报长度。在该示例中，生成9天的预报。在704处，然后设置预报开始日期，对于该示例，该开始日期从日期索引0开始到日期索引8。在706处，设置迭代i＝0。刷新算法的迭代可如下示出：

迭代#0：在708处，在序列零算法期间从预报引擎运行所有预处理阶段以获得阶段v0的预测量。在一个实施方案中，针对每个序列零阶段，从序列零获得量预测和量预测净放弃。在710处，使用阶段v0、v1、v3和v5中的每一者的五天历史数据来获得阶段的预测。阶段预测被设置有来自序列零的值。

确定是否已针对预报长度运行了所有迭代。在该示例中它们没有，因此在714处，使迭代增加一，并且在732处，处理所有阶段，其中在718处将下一个未处理阶段设置为当前处理阶段。在720a处，获得来自先前迭代的阶段预测并将其克隆到迭代的阶段预测，并且在722a处，然后针对迭代中的每个阶段确定量预测净放弃。在720b处，同时获得阶段历史的历史向量(来自预处理算法)，并且在722b处，利用所获得的历史向量来循环通过所有阶段历史。在724处，从阶段历史获得概率向量。然后，在726a处，循环通过量预测净放弃的每个时间序列点，并且将流逝时间确定为时间序列时间戳与预报开始日期之间的差值。如果流逝时间匹配概率向量时间索引并且目的地匹配当前阶段，则在728a处通过将量值乘以概率值来刷新量。同时，在726b处也使用历史向量来确定流逝时间，并且在728b处刷新量以便确定流逝时间，循环通过历史向量的每个时间序列点，并且将流逝时间确定为时间序列时间戳与预报开始日期之间的差值。如果该值已经等待长达特定时间段并且量的部分(如果不是全部的话)有资格被刷新(由概率向量分布确定)，则刷新该值。在730处，将当前迭代的刷新值存储在阶段预测矩阵中。如果已经处理所有阶段(732)，并且已经运行通过预报长度中的所有迭代(712)，则在734处获得最终阶段预测矩阵。最终阶段预测矩阵应包含从预报日期开始的整个预报周期内的所有阶段的量的最终状态。继续以上示例，下面将迭代的处理描述为与行程400有关。

迭代#1：交互在日期#0到达阶段v0。

迭代#2：根据概率向量A，交互以100％的比例从日期#0处于阶段v0流动到日期#1处于阶段v1。填充阶段v0的预报值作为序列零阶段。

迭代#3：根据概率向量A，交互以100％的比例从日期#1处于阶段v0流动到日期#2处于阶段v1。针对日期#2填充阶段v0的预报值作为序列零阶段。

迭代#4：根据概率向量A，交互以100％的比例从日期#2处于阶段v0流动到日期#3处于阶段v1。针对日期#3填充阶段v0的预报值作为序列零阶段。由于概率向量B，在日期#1处于阶段v1(在该阶段花费了两天)的交互现在有资格完全流动到阶段v3。

迭代#5：根据概率向量A，交互以100％的比例从日期#3处于阶段v0流动到日期#4处于阶段v1。针对日期#4填充阶段v0的预报值作为序列零阶段。由于概率向量B，在日期#2处于阶段v1(在该阶段花费了两天)的交互现在有资格完全流动到阶段v3。

迭代#6：根据概率向量A，交互以100％的比例从日期#4处于阶段v0流动到日期#5处于阶段v1。针对日期#5填充阶段v0的预报值作为序列零阶段。由于概率向量B，在日期#3处于阶段v1(在该阶段花费了两天)的交互现在有资格完全流动到阶段v3。由于概率向量C，在日期#3处于阶段v3(在该阶段花费了两天)的交互现在有资格以50％流动到阶段v5。

迭代#7：根据概率向量A，交互以100％的比例从日期#5处于阶段v0流动到日期#6处于阶段v1。针对日期#6填充阶段v0的预报值作为序列零阶段。由于概率向量B，在日期#4处于阶段v1(在该阶段花费了两天)的交互现在有资格完全流动到阶段v3。由于概率向量C，在日期#4处于阶段v3(在该阶段花费了两天)的交互现在有资格以50％流动到阶段v5。另外，由于概率向量C，在日期#3处于阶段v3的交互(其50％在该阶段花费了三天)的50％现在也有资格流动到v5。

迭代#8：根据概率向量A，交互以100％的比例从日期#6处于阶段v0流动到日期#7处于阶段v1。针对日期#7填充阶段v0的预报值作为序列零阶段。由于概率向量B，在日期#5处于阶段v1(在该阶段花费了两天)的交互现在有资格完全流动到阶段v3。由于概率向量C，在日期#5处于阶段v3(在该阶段花费了两天)的交互现在有资格以50％流动到阶段v5。另外，由于概率向量C，在日期#4处于阶段v3的交互(其50％在该阶段花费了三天)的50％现在也有资格流动到v5。

迭代#9：根据概率向量A，交互以100％的比例从日期#7处于阶段v0流动到日期#8处于阶段v1。针对日期#7填充阶段v0的预报值作为序列零阶段。由于概率向量B，在日期#6处于阶段v1(在该阶段花费了两天)的交互现在有资格完全流动到阶段v3。由于概率向量C，在日期#6处于阶段v3(在该阶段花费了两天)的交互现在有资格以50％流动到阶段v5。另外，由于概率向量C，在日期#5处于阶段v3的交互(其50％在该阶段花费了三天)的50％现在也有资格流动到v5。

为了简单起见，针对迭代0至9呈现的上述示例忽略日期0之前(在预报开始日期之前)的历史数据以便传达通过多个阶段和周期刷新量的想法。对于日期#0之前的历史数据，每次迭代还必须考虑来自历史数据序列的量，并且对那些量执行相同的“量刷新”过程：开始于从预报开始数据向后减去一个周期，然后减去两个周期，减去三个周期等。以相同概率向量为准。

控制行进到操作320并且过程300继续。

在操作320中，验证模型。为了验证，一部分历史数据被截留。例如，可截留10％。历史数据的另外90％将用于训练/构建模型。然后使用模型来生成预测，该预测将与截留数据进行比较。可确定平均预测误差并将其用作KPI。预测可被确定为从预测值中减去实际值。这是针对每个数据点进行的。然后对所有数据点取平均值以获得平均预测误差。执行交叉验证，其中截留历史数据来自不同的周期或范围，并且训练数据来自不同周期的子集。还针对交叉验证场景中的每一者确定平均预测误差。也可呈现误差的标准偏差。控制行进到操作325并且过程300继续。

在操作325中，校准模型，并且过程结束。一旦已经完成验证步骤，就将执行预测模型的重新校准以最小化预测误差。这可使用本领域已知的任何标准程序来执行。

在一个实施方案中，模型包括随着顾客通过阶段进展而从交互量生成的工作负荷，并且包括在顾客行程内的预测放弃。使用该模型来进行的预测包括处理工作负荷以便为联系中心递送KPI度量目标(例如，服务级别、NPS、放弃)所需的资源(例如，全时等效代理)。模型可应用于联系中心的行程分析平台。

在一个实施方案中，所述附图中的各种服务器、控件、交换机、网关、引擎和/或模块(统称为服务器)中的每一者经由硬件或固件(例如，ASIC)来实现，如本领域的技术人员将理解的。各种服务器中的每一者可以是在一个或多个计算设备(例如，图8A、图8B)中的一个或多个处理器上运行的过程或线程，其执行计算机程序指令并与用于执行本文所述的各种功能的其他系统部件进行交互。计算机程序指令存储在存储器中，该存储器可使用标准存储器设备(诸如RAM)在计算设备中实现。计算机程序指令还可存储在其他非暂态计算机可读介质中，诸如CD-ROM、闪存驱动器等。本领域的技术人员应当认识到，计算设备可经由固件(例如，专用集成电路)、硬件，或软件、固件和硬件的组合来实现。本领域的技术人员还应当认识到，在不脱离本发明的示例性实施方案的范围的情况下，各种计算设备的功能可组合或集成到单个计算设备中，或者特定计算设备的功能可分布在一个或多个其他计算设备上。服务器可为软件模块，其也可简称为模块。联系中心中的该组模块可包括服务器和其他模块。

各种服务器可在与联系中心的代理相同的物理位置处位于现场的计算设备上，或者可在地理上不同的位置处(例如，在远程数据中心中)位于现场外(或在云中)，该地理上不同的位置经由网络(诸如互联网)连接到联系中心。此外，服务器中的一些服务器可在联系中心处位于现场的计算设备中，而其他服务器可位于现场外的计算设备中，或者提供冗余功能的服务器可经由现场计算设备和现场外计算设备两者提供以提供更大的故障容限。在一些实施方案中，由位于现场外的计算设备上的服务器提供的功能可通过虚拟专用网络(VPN)来访问和提供，就像此类服务器在现场一样，或者可使用软件即服务(SaaS)来提供功能以使用各种协议来通过互联网提供功能，诸如通过使用以可扩展标记语言(XML)或JSON编码的数据来交换数据。

图8A和图8B是示出大体以800指示的可在本发明的实施方案中采用的计算设备的实施方案的图。每个计算设备800包括CPU 805和主存储器单元810。如图8A所示，计算设备800还可包括存储设备815、可移除介质接口820、网络接口825、输入/输出(I/O)控制器830、一个或多个显示设备835A、键盘835B和指向设备835C(例如，鼠标)。存储设备815可包括但不限于用于操作系统和软件的存储装置。如图8B所示，每个计算设备800还可包括附加的任选元件，诸如存储器端口840、桥接器845、一个或多个附加的输入/输出设备835D、835E，以及与CPU 805通信的高速缓存存储器850。输入/输出设备835A、835B、835C、835D和835E在本文中可统称为835。

CPU 805是响应并处理从主存储器单元810获取的指令的任何逻辑电路。其可例如以集成电路实现，以微处理器、微控制器或图形处理单元的形式实现，或者以现场可编程门阵列(FPGA)或专用集成电路(ASIC)实现。主存储器单元810可以是能够存储数据并允许中央处理单元805直接访问任何存储位置的一个或多个存储器芯片。如图8A所示，中央处理单元805经由系统总线855与主存储器810通信。如图8B所示，中央处理单元805还可经由存储器端口840与主存储器810直接通信。

在一个实施方案中，CPU 805可包括多个处理器，并且可提供用于同时执行多个指令或用于对多于一条数据同时执行一个指令的功能。在一个实施方案中，计算设备800可包括具有一个或多个核的并行处理器。在一个实施方案中，计算设备800包括共享存储器并行设备，其具有多个处理器和/或多个处理器核，从而访问所有可用存储器作为单个全局地址空间。在另一个实施方案中，计算设备800是具有多个处理器的分布式存储器并行设备，每个处理器仅访问本地存储器。计算设备800可具有共享的某个存储器以及可仅由特定处理器或处理器子集访问的某个存储器两者。CPU 805可包括多核微处理器，该多核微处理器将两个或更多个独立处理器组合成单个封装，例如，组合成单个集成电路(IC)。例如，计算设备800可包括至少一个CPU 805和至少一个图形处理单元。

在一个实施方案中，CPU 805提供单指令多数据(SIMD)功能，例如，对多条数据同时执行单个指令。在另一个实施方案中，CPU 805中的若干处理器可提供用于对多条数据(MIMD)同时执行多个指令的功能。CPU805还可在单个设备中使用SIMD和MIMD核的任何组合。

图8B描绘了其中CPU 805经由第二总线(有时称为背侧总线)与高速缓存存储器850直接通信的实施方案。在其他实施方案中，CPU 805使用系统总线855来与高速缓存存储器850通信。高速缓存存储器850通常具有比主存储器810更快的响应时间。如图8A所示，CPU805经由本地系统总线855与各种I/O设备835通信。各种总线可用作本地系统总线855，包括但不限于视频电子标准协会(VESA)本地总线(VLB)、工业标准架构(ISA)总线、扩展工业标准架构(EISA)总线、微信道架构(MCA)总线、外围部件互连(PCI)总线、PCI扩展(PCI-X)总线、PCI-Express总线或NuBus。对于其中I/O设备为显示设备835A的实施方案，CPU 805可通过高级图形端口(AGP)与显示设备835A通信。图8B示出了计算机800的实施方案，其中CPU805与I/O设备835E直接通信。图8B还描绘了混合本地总线和直接通信的实施方案：CPU 805使用本地系统总线855来与I/O设备835D通信，同时直接与I/O设备835E通信。

多种I/O设备835可存在于计算设备800中。输入设备包括一个或多个键盘835B、鼠标、触控板、轨迹球、麦克风和绘图表(列举几个非限制性示例)。输出设备包括视频显示设备835A、扬声器和打印机。例如，如图8A所示的I/O控制器830可控制一个或多个I/O设备，诸如键盘835B和指向设备835C(例如，鼠标或光学笔)。

再次参考图8A，计算设备800可支持一个或多个可移除介质接口820，诸如软盘驱动器、CD-ROM驱动器、DVD-ROM驱动器、各种格式的磁带驱动器、USB端口、安全数字或紧凑型FLASH

可移除介质接口820可例如用于安装软件和程序。计算设备800还可包括用于存储操作系统和其他相关软件以及用于存储应用软件程序的存储设备815，诸如一个或多个硬盘驱动器或硬盘驱动器阵列。任选地，可移除介质接口820也可用作存储设备。例如，操作系统和软件可从可自引导介质(例如，可自引导CD)运行。

在一个实施方案中，计算设备800可包括或连接到多个显示设备835A，每个显示设备可具有相同或不同的类型和/或形式。因此，I/O设备835和/或I/O控制器830中的任一者可包括任何类型和/或形式的合适硬件、软件或硬件和软件的组合，以支持、启用或提供计算设备800对多个显示设备835A的连接和使用。例如，计算设备800可包括任何类型和/或形式的视频适配器、视频卡、驱动器和/或库以便接合、通信、连接或以其他方式使用显示设备835A。在一个实施方案中，视频适配器可包括多个连接器以接合到多个显示设备835A。在另一个实施方案中，计算设备800可包括多个视频适配器，其中每个视频适配器连接到显示设备835A中的一者或多者。在其他实施方案中，显示设备835A中的一者或多者可由经由网络连接到例如计算设备800的一个或多个其他计算设备提供。这些实施方案可包括被设计和构造成使用另一个计算设备的显示设备作为计算设备800的第二显示设备835A的任何类型的软件。本领域的普通技术人员将认识到并理解计算设备800可被配置为具有多个显示设备835A的各种方式和实施方案。

在图8A和图8B中大体指示的计算设备的实施方案可在操作系统的控制下操作，该操作系统控制任务的调度和对系统资源的访问。计算设备800可运行任何操作系统、任何嵌入式操作系统、任何实时操作系统、任何开源操作系统、任何专有操作系统、移动计算设备的任何操作系统或能够在计算设备上运行并执行本文所述的操作的任何其他操作系统。

计算设备800可以是任何工作站、台式计算机、膝上型计算机或笔记本计算机、服务器机器、手持式计算机、移动电话或其他便携式远程通信设备、媒体播放设备、游戏系统、移动计算设备，或能够通信并且具有足够的处理器功率和存储器容量以执行本文所述的操作的任何其他类型和/或形式的计算、电信或媒体设备。在一些实施方案中，计算设备800可具有与设备一致的不同处理器、操作系统和输入设备。

在其他实施方案中，计算设备800是移动设备。示例可包括支持Java的蜂窝电话或个人数字助理(PDA)、智能电话、数字音频播放器或便携式媒体播放器。在一个实施方案中，计算设备800包括设备的组合，诸如与数字音频播放器或便携式媒体播放器组合的移动电话。

计算设备800可以是由网络连接的多个机器中的一者，或者其可包括如此连接的多个机器。网络环境可以包括一个或多个本地机器、客户端、客户端节点、客户端机器、客户端计算机、客户端设备、端点或端点节点，其经由一个或多个网络与一个或多个远程机器(其通常也可以被称为服务器机器或远程机器)通信。在一个实施方案中，本地机器具有用作寻求对由服务器机器提供的资源的访问的客户端节点，以及用作为其他客户端提供对托管的资源的访问的服务器机器的能力。网络可以是LAN或WAN链路、宽带连接、无线连接或上述任何或全部的组合。可使用多种通信协议来建立连接。在一个实施方案中，计算设备800经由任何类型和/或形式的网关或隧道协议(诸如安全套接层(SSL)或传输层安全(TLS))与其他计算设备800进行通信。网络接口可包括内置网络适配器(诸如网络接口卡)，其适于将计算设备接合到能够通信并执行本文所述的操作的任何类型的网络。I/O设备可以是系统总线和外部通信总线之间的桥接器。

在一个实施方案中，网络环境可以是虚拟网络环境，其中网络的各种部件被虚拟化。例如，各种机器可以是被实现为在物理机器上运行的基于软件的计算机的虚拟机。虚拟机可共享相同的操作系统。在其他实施方案中，可在每个虚拟机实例上运行不同的操作系统。在一个实施方案中，实现了“虚拟机管理程序”类型的虚拟化，其中多个虚拟机在相同主机物理机器上运行，每个虚拟机的作用就好像其具有自身的专用盒一样。虚拟机还可在不同的主机物理机器上运行。

还设想了其他类型的虚拟化，诸如网络(例如，经由软件定义联网(SDN))。功能(诸如会话边界控制器的功能和其他类型的功能)也可被虚拟化，诸如经由网络功能虚拟化(NFV)。

在一个实施方案中，使用LSH来自动发现大量预先连接的音频记录中的载波音频消息可应用于联系中心环境的媒体服务的支持过程。例如，这可有助于联系中心的呼叫分析过程，并且消除了让人类收听大量音频记录以发现新载波音频消息的需要。

虽然在附图和上述描述中详细示出和描述了本发明，但应将其视为示例性的而非限制性的，应当理解，仅示出和描述了优选的实施方案，并且期望保护落入如本文所述和/或所附权利要求所述的本发明的实质内的所有等同物、改变和修改。

因此，本发明的适当范围应仅由所附权利要求的最广泛解释来确定，以便涵盖与附图中所示和说明书中所述的那些等同的所有此类修改以及所有关系。