CN104956330A - 具有资源感知的工作量分配 - Google Patents

Abstract

一种用于联络中心的工作量分配的方法，包括以下步骤：根据指定的分配标准识别用于分配的工作项；识别为所述工作项规定路线的目标；判断该目标的可用性；响应于判断该目标可用，为该工作项传送路由请求到路由服务器，并且响应于该请求，路由服务器被配置为独立地判断该工作项的有效性以路由该工作项到上述目标；和响应于判断该目标不可用，停止传送工作项的路由请求到路由服务器。

Description

具有资源感知的工作量分配

技术领域

本发明涉及一种用于联络中心工作量分配的系统和方法，更具体地，涉及一种使用资源感知分配工作项的联络中心工作量分配的系统和方法。

背景技术

许多企业使用由客户服务代理(也称为客户服务代表或客服专员)提供人员的客户联络中心与客户交互并提供客户支持。联络中心可以用作客户服务交互的一个网关，并且该企业还可以使用联络中心外部的资源(例如，一组后台员工)来处理该交互。在某些情况下，后台组可能比联络中心组大很多，并且可能包括支付较高薪水的熟练工作人员。这些熟练工作人员(称为知识工作者)一般具有培训的和专门技术来处理客户交互，例如，满足客户服务请求。

然而，联络中心的服务请求处理和工作量分配技术往往导致多种低效现象。例如，根据基础要素(例如，员工当前是否可用)将工作随机分配给员工。此外，当该企业的员工(例如，主管)设定工作节奏和管理优先次序时，可能存在人工延迟。例如，工作由主管人工分配可能导致低效现象，这是因为时间被花费在手动选择任务并将这些任务在许多员工的工作框(workbin)之间进行分配。由于员工“自我报告”数据的不准确性和主观性，经理和主管还可能会遇到洞察资源可用性和工作分配的困难。有限的洞察力阻碍了工作量分配的持续改进。此外，长等待时间和低效的客户服务可能造成客户失望。企业不能满足客户预期和承诺(如，到期日期和响应时间)可能导致客户结束业务关系。

此外，由于不能响应客户交互中产生的市场机遇，可能会导致企业缺乏业务灵活性。例如，企业可能希望针对特定产品或服务(无论是内部的或者跨部门或者跨品牌的)向某些客户直接报价，但是标准的交互处理系统缺乏使用客户交互来抓住这些市场机遇的能力。

因此，需要减少工作流程中的人为延迟，优化在利用率和技能/能力方面对员工的使用，增加资源和可用性方面的可视性，提高客户成果的质量，并且提高业务灵活性。

此外，会需要根据企业的业务需要来改变限定企业业务逻辑的规则。然而，做出改变后并不存在有效的方法来测试这些规则以保证这些规则的正确操作。

发明内容

根据本发明的实施例，一种用于联络中心工作量分配的方法包括以下步骤：根据分派的分配标准识别用于分配的工作项；识别为该工作项规划路线的目标；判定该目标的可用性；响应于判定该目标可用，将该工作项的路由请求传送至路由服务器，并且响应于该请求，路由服务器被配置为独立判定该工作项的有效性以将该工作项路由至上述目标；和响应于该目标不可用的判定，停止将该工作项的路由请求发送至路由服务器。

分配标准可以包括工作项的优先级值、商业价值、创建日期或者到期日期中的至少一个。

识别为该工作项规划路线的目标的步骤可以包括接收对特定目标的请求。

识别为该工作项规划路线的目标的步骤可以包括评估与占用、技能或目标位置相关的信息。

该方法可以进一步包括评估所判定的可用性，以识别路由工作项的目标。

上述判定目标可用性的步骤可以包括识别该目标处理当前工作项的能力。

工作项可以处于第一服务器中的队列状态，并且响应于请求，该工作项可以从第一服务器中的队列状态转移，并可以被放置在路由服务器中的队列状态。

第一服务器和路由服务器可以通过局域网连接。

响应于目标为不可用的判定，修改工作项的分配标准。

修改分配标准的步骤可以包括修改工作项的优先级。

工作项可以是与终端用户的非电话交互。

根据本发明的另一个实施例，一种联络中心工作量分配的系统包括：处理器和存储器。在一个实施例中，存储器存储指令，当该指令由处理器执行时，使得处理器：根据指定分配标准识别待分配的工作项；识别为该工作项规划路线的目标；判定该目标的可用性；响应于该目标可用的判定，为工作项传送路由请求到路由服务器，并响应于该请求，路由服务器别配置为独立地判定该工作项的有效性以将该工作项路由至目标；和响应于该目标不可用的判定，不将该工作项的该路由请求传送至路由服务器。

该分配标准可以包括工作项的优先级值、商业价值、创建日期或者到期日期中的至少一个。

识别为该工作项规划路线的目标的步骤可以包括接收对特定目标的请求。

识别为该工作项规划路线的目标的步骤可以包括评估与占用、技能或目标位置相关的信息。

处理器可以进一步评估所判定的可用性以识别为该工作项规划路线的目标。

判定目标可用性的步骤可以包括识别该目标处理该工作项的能力。

工作项可以处在第一服务器的队列状态中，并且响应于上述请求，该工作项可以被从第一服务器中的队列状态中移出，并且可以设置在路由服务器的队列状态中。

第一服务器和路由服务器可以通过局域网连接。

响应于目标不可用的判定，为该工作项修改分配标准。

修改分配标准的步骤可以包括修改工作项的优先级。

工作项可以是与终端用户的非电话交互。

本发明的实施例还涉及验证用于联络中心的规则，包括：配置规则的一个或更多个参数；接收指令以测试该规则；识别用于测试该规则的数据集；根据该数据集执行该规则并且接收测试结果；对比该测试结果与预期结果；和响应于测试结果满足预期结果，将该规则部署到规则引擎。

根据一个实施例，上述一个或多个参数包括业务属性、员工组、员工列表和技能组中的至少一个。

根据一个实施例，上述一个或多个参数中的每一个具有参数类型，该参数类型是从包括整数、整数集、数值、字符串、日期、时间和枚举类型组成的群组中选择的。

根据一个实施例，上述枚举类型是从预定义列表中选择的静态值。

根据一个实施例，上述枚举类型是从外部源中获得的动态值。

根据一个实施例，上述配置所述规则的一个或多个参数的步骤进一步包括配置功能，并且该配置的参数和功能用于定义规则的条件和操作。

根据一个实施例，上述数据集包括给定值和预期值。

根据一个实施例，上述识别用于测试规则的数据集的步骤进一步包括：识别阶段、业务层级、模拟日期、模拟时间和时区中的至少一个。

根据一个实施例，上述根据数据集执行规则的步骤和接收测试结果的步骤包括：映射上述一个或多个参数到事实模型的一个或多个变量。本发明的实施例涉及一种用于评估改变联络中心的规则而造成的影响的方法。该方法包括：配置该规则的一个或多个参数；接收指令以评估该规则；检索过去终端用户与联络中心交互的日志，其中，历史交互的日志反映了部署该规则前的交互情况；根据该规则处理一个或更多个历史交互；模拟该一个或更多个历史交互的结果；和根据该模拟部署或者不部署该规则到规则引擎。

根据一个实施例，历史交互的日志包括与历史交互的流量、活跃的技能和交互处理时间相关的信息。

根据一个实施例，分析历史交互日志以评估联系中心效率。

根据一个实施例，该方法包括：确定新的规则变化，其中，该新的规则变化调整分配工作项的路由策略。

根据一个实施例，该新规则变化是根据上述模拟步骤以及联络中心效率评估。

本发明的实施例还涉及一种用于评估联络中心中规则变化造成的影响的系统。该系统包括：一个或多个处理器，和与该一个或多个处理器相连接、用于存储程序指令的一个或多个存储装置，由该一个或多个处理器执行该程序指令时，使得该一个或多个处理器：配置该规则的一个或更多个参数；接收指令以评估该规则；检索终端用户与联络中心之间的历史交互日志，其中，该历史交互日志反映了该规则部署前的交互情况；根据该规则处理一个或多个历史交互；模拟该一个或多个历史交互的结果；和根据模拟步骤部署或者不部署该规则到规则引擎。

本发明的实施例还涉及修改联络中心规则，包括以下步骤：配置规则的一个或多个参数；接收指令以测试该规则；识别用于测试该规则的数据集；根据该数据集执行该规则并接收测试结果；比较该测试结果与预期戒网；和响应于测试结果满足预期结果，将该规则部署到规则引擎。

根据一个实施例，上述一个或多个参数包括业务属性、员工组、员工列表和技能组中的至少一个。

根据一个实施例，上述一个或多个参数中的每一个具有参数类型，并且该参数类型是从整数、整数集、数值、字符串、日期、时间和枚举类型组成的群组中选择的。

根据一个实施例，上述枚举类型是从预定义列表中选择的静态值。

根据一个实施例，上述枚举类型是从外部源中获得的动态值。

根据一个实施例，上述配置规则的一个或多个参数的步骤进一步包括：配置功能，并且该配置的参数和功能用于定义该规则的条件和操作。

根据一个实施例，上述数据集包括给定值和预期值。

根据一个实施例，上述识别用于测试规则的数据集的步骤进一步包括：识别阶段、业务阶层、模拟日期、模拟时间以及时区中的至少一个。

根据一个实施例，上述根据数据集和接收的测试结果执行规则的步骤包括：映射一个或多个参数到事实模型的一个或多个变量。

附图说明

图1是根据本发明一个示例性实施例的用于支持联络中心的系统的示意框图；

图2是根据本发明一个示例性实施例的图1中一些用于提供iWD方案和规则生成/处理的部件的更详细的示意框图。

图3是是根据本发明一个示例性实施例的报表应用程序生成的报表的屏幕截图。

图4是根据本发明一个示例性实施例的iWD流的流程图。

图5A-5D示出了未完成任务的报表，这些报表分别是根据业务流程和优先级、到期时间、仅业务流程和商业价值进行组织的。

图6是根据本发明一个示例性实施例的用于分配工作项到分配目标的过程的流程图。

图7A-7C是根据本发明一个示例性实施例的描述终端用户通过企业网站提交服务请求的示例性过程的截图。

图8A-8F是根据本发明一个示例性实施例的描述企业员工管理交互和任务的过程的截图。

图9A-9I是根据本发明实施例的图2中所述iWD管理员/服务器的截图。

图10是根据本发明实施例的允许定制员工权限的安全策略的截图。

图11A-11D描述了根据本发明实施例的在任务生命周期中该任务可以呈现的多种状态的流程图。

图12是根据本发明实施例的显示规则系统的高层体系构架(称为GRS)和该规则系统的客户应用程序的功能框图。

图13是根据本发明实施例的创建业务模板和业务规则的过程的流程图。

图14A-14F是根据本发明实施例的描述完善业务规则模板的过程的屏幕截图。

图15A-15R是根据本发明实施例的描述配置、测试和部署业务规则的过程的屏幕截图。

图16A-16I是根据本发明实施例的描述使用GRS排列优先次序、重新排列优先次序和根据技能分配任务的屏幕截图。

图17是根据本发明实施例的描述用户第一次使用单点登录的图解。

具体实施方式

本发明的实施例涉及一种用于将延迟的媒体交互(也可以称为非实时交互)、任务和/或其它工作项分配到联络中心资源的系统和方法。交互、任务和工作项这些术语在本文中可以互换使用。工作项的分配通常称为智能工作量分配(iWD)。根据示例性实施例，智能工作量分配基于资源认知，该资源认知提供传输到例如路由服务器的效率。

本发明的实施例还涉及一种用于生成和调用部署之前测试的业务规则的系统和方法。该业务规则可以被调用，例如用于工作量分配以保证任务被路由至最适合处理任务的资源。根据一个实施例，这种测试的结果可以与预期目标(例如，业务目标)进行比较，以确定部署之前是否改变该规则的属性。

在本公开文本中，术语“员工”和“代理”用于指代联络中心代理(可以在联络中心建筑中或者他自己的家里工作)、前台员工、后台员工、知识员工或者企业的外包合作伙伴。

图1是根据本发明一个示例性实施例的用于支持联络中心的系统的示意框图。在一个实施例中，该系统被配置为将与终端用户(也被称为客户)相关的信息和任务(也被称为工作)分配给企业员工。联络中心可以是企业的内部设施，并且可以通过执行销售和与该企业可用产品和服务相关的服务的功能来为该企业工作。在另一方面，该联络中心可以是第三方服务提供商。该联络中心可以设置在专用于该企业或者第三方服务提供商的设备中，和/或设置在远程计算环境中，例如具有用于支持多个企业的多个联络中心的基础设施的私人或公用云环境。

根据一个示例性实施例，该联络中心包括资源(例如，人员、计算机和通信设备)用以通过电话或其它通信机制交付服务。这些服务可以根据联络中心类型变化，并且可以做出从客户服务到帮助台、应急响应、电话推销、接收订单等的变化。

希望从联络中心接收服务的客户、潜在客户或者其它终端用户(统称为终端用户)可以通过他们的终端用户装置10a-10c(统称为10)发起到联络中心的入站呼叫。每一个终端用户装置10都可以是本领域传统的通信装置，例如电话、无线电话、智能手机、个人计算机、电子输入板和/或类似通信装置。

根据正在使用的设备类型，从终端用户10发出的入站呼叫和到终端用户10的出站呼叫可以穿过电话、蜂窝式网络和/或数据通信网络14。例如，该通信网络14可以包括：专用或公共交换电话网(PSTN)、局域网(LAN)、专用广域网(WAN)和/或公共广域网(例如，因特网)。通信网络14还可以包括无线运营商网络，该无线运营商网络包括分码多址访问(CDMA)网络、全球移动通信系统(GSM)网络和/或本领域传统的任何3G或4G网络。

根据一个示例性实施例，联络中心包括连接到用于接收和发送终端用户与联络中心之间的呼叫的通信网络14的转换/媒体网关12。转换/媒体网关12可以包括电话交换机，该电话交换机配置为用作用于中心内的代理层路由的中央交换机。据此，转换网关12可以包括自动呼叫分配器、专用交换分机(PBX)、基于IP的软件交换机和/或任何其它配置为接收来自因特网的呼叫和/或来自电话网络的呼叫的交换机。根据本发明的一个示例性实施例，该交换机连接到呼叫服务器16，该呼叫服务器16可以例如用作交换机与联络中心的路由、监测和其它呼叫处理系统的其余部分之间的适配器或者接口。

根据本发明的一个示例性实施例，交换机12连接到交互式语音应答(IVR)服务器34。IVR服务器34被配置有例如IVR脚本以用来询问客户他们的需求。例如，如果呼叫者希望知道账户余额，则用于银行的联络中心可以通过IVR脚本告诉呼叫者“按1”。如果是这种情况，通过与IVR的连续交互可以不需要客户与代理通话即可完成服务。

如果将该呼叫路由至代理，则该呼叫将被传送至呼叫服务器16，该呼叫服务器16与路由服务器(称为通用路由服务器)20交互以找到处理该呼叫的最合适的代理或员工。呼叫服务器16可以配置为处理PSTN呼叫、VoIP呼叫和类似呼叫。例如，呼叫服务器16可以包括用于处理SIP呼叫的会话发起协议(SIP)服务器。

在一个实施例中，当正在定位代理直到这种代理可用时，呼叫服务器可以将该呼叫放在呼叫队列中。呼叫队列可以通过本领域传统的任意数据结构实现，例如链表、阵列和/或类似数据结构。该数据结构可以保持在例如呼叫服务器16提供的缓冲存储器中。

一旦合适的代理被定位并且可用于处理呼叫，该呼叫被从呼叫队列中移出并发送至相应的代理装置38a-38b。所收集的关于该呼叫者的信息和/或呼叫者的历史信息也可以提供给代理装置，以用于辅助代理更好地服务该呼叫。上述信息还可以提供给管理员装置38c以用于监测和训练的目的。在这方面，每个代理/管理员装置38a-c可以包括适用于常用的电话呼叫、VoIP呼叫和类似呼叫的电话。代理和管理员装置38a-c还可以包括用于与联络中心的一个或多个服务器通信并执行与联络中心操作相关的数据处理的计算机。

用于路由入站交互(例如，电话呼叫或其它多媒体交互)的适当代理的选择可以根据例如路由服务器20采用的路由策略，并且还根据与代理可用性、技能、代理位置和由例如统计服务器22提供的其它路由参数相关的信息。例如，统计服务器22可以收集关于位置、代理和位置/代理组的信息，将该数据转换成统计上可用的信息，并且将计算结果发送到其它软件应用程序。根据一个实施例，统计服务器22可以依据代理正在处理的交互、交互的媒体类型等向路由服务器提供与代理能力相关的信息。

路由服务器20采用的示例性路由策略可以是在向特定代理、代理组或部门发出请求时，一旦该被请求的实体可用即将该交互路由至被请求的代理、代理组或部门。如果没有请求特定代理，则一旦具有所请求的技能的代理可用即可以将该交互路由至这些代理。如果没有请求特定代理组或部门，则该交互被从路由服务器队列中移出并路由至处理后台工作的代理组或部门。该交互可以被放在队列中或用于延迟媒体，该交互可以被放在与后台代理或部门相关联的工作框中。在一些实施例中，该呼叫可以直接路由至代理用于即时处理。据此，可以提高路由服务器20的用于管理分配给企业员工的后台/离线活动的功能。这些活动包括例如回复电子邮件和信件、参加培训讲座或者执行不涉及同步、与终端用户实时通信的任何其它活动(与联络中心相关联或不相关)。例如，可以路由到知识员工的非联络中心活动可以填写企业表格、处理权利等等。一旦工作项被分配到代理，该工作项会出现在代理的工作框26a-26b(统称为26)中作为代理的待完成任务。代理的工作框可以使用本领域常用的数据结构实现，例如链表、阵列和/或类似数据结构。该工作框被保持在例如每个代理的计算机装置的缓冲存储器中。

根据一个示例性实施例，联络中心还可以包括连接到通信网络14的多种多媒体/社交媒体服务器24，用以与终端用户装置10和/或网站服务器32进行除电话呼叫(PSTN或VoIP)以外的媒体交互。该媒体交互可以与例如电子邮件、聊天、文本消息、社交消息、网站交互等相关。

网站服务器32可以包括例如用于多种公知社交网站的社交网站主机，终端用户可以订阅例如脸谱、微博等等。网站服务器还可以为联络中心支持的企业提供网页。终端用户可以浏览网页并获得与该企业的产品和服务相关的信息。网页还可以通过例如网页聊天、语音呼叫、电子邮件、网页实时通信(WebRTC)、网页表格提交等提供用于联络联络中心的机制。

根据本发明的一个示例性实施例，多媒体/社交媒体服务器24连接到交互服务器40，所述交互服务器是为联络中心管理除电话呼叫以外的多媒体/社交媒体交互以及离线(异步的，非实时的)任务的集线器。交互服务器40与路由服务器20通信以将多媒体交互和任务路由至代理或其它员工。

图1中的系统还包括规则系统44，所述规则系统用于为联络中心生成、部署和调用多种规则集。这种规则可以是业务规则，该业务规则可以根据例如业务企业想要提供的推销而随时间改变。所述规则还可以与需要分配到员工的多种任务的优先级分配相关联。根据一个实施例，规则系统集成了其它工作流分配的规则，从而消除了生成独立规则的需求。

根据本发明的一个示例性实施例，联络中心还包括一个或多个大容量存储装置30，所述大容量存储装置用于存储与联络中心操作相关的数据，例如与代理、客户、客户交互等相关的信息。大容量存储器可是本领域常用的硬盘或磁盘阵列的形式。

联络中心还可以包括配置为由统计服务器22聚集的数据生成报告的报告服务器18。这种报告可以包括与资源状态相关的近实时报告或历史报告，例如平均等待时间、放弃率、代理占用率等等。该报告可以自动生成或者响应于具体请求而生成(例如，来自代理/管理员、联络中心应用程序等的请求)。

图1的多种服务器和系统中的每一个都可以包括一个或多个处理器，所述处理器处理计算机程序指令并与用于执行在此所述的各种功能的其它系统部件交互。计算机程序指令存储在使用标准存储装置(例如，随机存取存储器(RAM))实现的存储器中。该计算机程序指令还可以存储在其它的非暂时性计算机可读介质中，例如CD-ROM、闪存驱动器或类似介质。此外，尽管每个服务器的功能被描述为由特定服务器提供，但是本领域技术人员应当理解，在不背离本发明的实施例的范围的情况下，各种服务器的功能可以合并或者集成在单个服务器中，或者特定服务器的功能可以分布在一个或多个服务器之间。

图2是根据本发明一个示例性实施例的图1中用于提供iWD方案和规则生成/处理的部分部件的更详细的示意图。如图2所示的实施例所述，交互服务器40包括多种集成的捕获适配器(称为捕获点)162，所述捕获适配器提供用于从一个或多个工作资源系统172-180接收工作的接口。该工作资源系统可以例如设置在联络中心的外部。例如，第三方客户关系管理系统172、业务过程管理系统174或者不同的媒体服务器可以通过集成捕获点向联络中心提供工作。要路由至代理的示例性工作项可以涉及例如保险索赔处理。另一个工作项可以是例如，技术服务请求。根据本发明的实施例，任何任务始发系统都可以将工作提供给用于路由至企业员工的交互服务器。

根据一个实施例，捕获适配器为双向的，并且帮助确保工作资源系统172-180中的变化由交互服务器40进行了更新。该捕获适配器可以支持多个不同类型的接口，例如网站服务器、可扩展标记语言(XML)文件、企业服务总线或者数据库。例如，网站服务器可以向任何可以通过网站服务器通信的企业应用程序展示iWD功能。当使用XML文件时，任务可以以批处理模式从例如实时网站服务或企业服务总线连接不可用的销售点系统或外部业务伙伴提交到交互服务器40。通过使用企业服务总线，例如IBM电子商务平台软件MQ或JMS，现有消息可以被传送到交互服务器40以创建、更新和删除任务。

根据一个实施例，所述捕获点包括内置转换服务，使得客户不再需要创建iWD特定消息表格。该转换服务允许交互服务器40接收现有信息格式，并且以相同的格式传送回来。此外，数据库连接可以被支持用于自定义应用程序或者不支持网页服务或服务总线的旧版应用程序。

交互服务器40还从多种多媒体/社交媒体服务器24接收多媒体交互以路由至联络中心资源(例如，IVR、代理或类似资源)。多媒体/社交媒体服务器24可以包括一个或多个短信服务器182、聊天服务器184、电子邮件服务器186、社交消息服务器188和其它多媒体服务器/适配器190。根据一个实施例，所接收的交互被记录在交互数据库156中。由系统生成的其它事件也被记录在例如事件数据库158中。

根据一个示例性实施例，交互服务器40包括优化模块41和分类模块43。这些模块可以通过存储在交互服务器的存储器中的计算机程序指令实现，这些程序指令由处理器执行以为各种任务和交互规划到联络中心资源的路线。本领域技术人员应当理解，所述模块中的全部或部分还可以通过固件(例如，ASIC)、硬件或软件、固件和/或硬件的组合实现。此外，尽管在上述描述中模块由交互服务器40托管，但是本领域技术人员应当理解，所述模块可以由一个或多个其它应用程序服务器托管。例如，分类模块43可以由单独的分类服务器192托管。

根据一个示例性实施例，交互服务器40可以访问用于智能地将任务路由至目标目的地的各种联络中心服务器和资源。例如，通用联络服务器194被配置为保持并提供联络文件，包括客户联系信息(例如，姓名、地址、电话号码)、联系历史(先前与不同联系人的交互)以及处理交互中使用的其它数据，例如标准的回应和筛选规则。统计服务器22提供联络中心内的交互和资源使用的实时可见，包括例如代理在其处理的交互数量方面的能力、交互的媒体类型以及类似信息。路由服务器20与统计服务器22交互，以根据适当的路由策略路由工作项。

根据一个示例性实施例，交互服务器40能够访问其他系统部件，使得交互服务器40具有对资源可用性和利用率的可视性。例如，交互服务器40可以连接到用于获得代理调度信息的劳动力管理系统118。根据一个示例性实施例，交互服务器40可以在联络中心内将该可视性功能使用在资源可用性与利用率上，以确定是否将路由请求发送至路由服务器20。因此，代替根据例如先前信息盲目地请求将当前工作项路由至路由服务器20，交互服务器40可以在例如特定资源不可用时推迟发出请求。

在一个实施例中，iWD系统42包括但不限于配置数据库148、iWD数据库150和iWD管理员/服务器146。根据一个实施例，图2的系统提供多种iWD应用程序，包括例如iWD管理员/服务器146，从而允许管理员监测工作量分配、与规则系统44的接口以创制规则、生成报告、执行关于任务的各种操作和类似操作。根据一个实施例，iWD管理员/服务器146是托管在管理员装置38c中的应用程序。根据一个实施例，iWD管理员/服务器146访问配置数据库148以检索配置数据(例如，定义iWD操作所需的对象，例如部门、程序、Java服务、服务类型、客户群、组织层级、技能、用于控制路由百分比的部分参数和类似数据)和统计数据(例如，哪些用户过去更改了特定iWD配置对象，以及这些更改是什么时候发生的)。

iWD管理员/服务器146还可以访问iWD数据库150用以根据联络中心活动进行报告。例如，在一个实施例中，iWD数据库150提供根据部门和业务过程组织的数据结构，并且还提供与联络中心外部活动相关的信息，例如后台(即，非代理)工作量分布。管理员可以访问iWD数据库150中的数据，从而确定他的部门内外的工作量。

图3是根据本发明一个实施例的报告应用程序(例如，CCPulse+)根据iWD数据库中的信息生成的报告的屏幕截图。在其它实施例中，可以根据从其它数据源得来的信息生成报告。如图3所示，可以根据特定部门将信息做成报告。ACME销售部门的列表201总结了活动任务和保持的任务的数量、过去15分钟内的过期的和待处理的任务的数量以及过去15分钟、30分钟和60分钟内完成的和新增的任务的数量。虽然是柱形图的形式，但图表203显示了与列表201中相同的信息。然而，本发明的实施例并不限于所述方式，所述数据可以以任意数量的方式呈现。

再次参照图2，联络中心的规则生成和处理通过规则系统44执行。通过规则系统生成的规则可以供多种联络中心客户使用，包括例如交互服务器40。根据一个实施例，该规则系统44包括规则开发工具166，所述规则开发工具允许用户(例如，技术使用者)创建并管理规则模板。根据一个实施例，规则模板提供一种将基础数据模型映射为商业用户可以理解的业务语言的方法。

规则系统44进一步包括规则创制工具170，规则创制工具170可以被例如非技术(例如，业务)使用者访问，以访问规则开发工具166限定的规则模板并创建特定业务规则。就此而言，规则创制工件提供了可以在例如网站浏览器中运行的可交互的图形用户界面(GUI)。规则模板使得商业用户能够创建降低用户错误的业务驱动规则，同时允许技术人员(例如，信息技术人员)集中精力在涉及生成模板的技术任务中。

一旦根据特定模板生成规则，该规则可以存储在规则库168中。根据一个实施例，该规则库168是存储有规则开发和创制信息的数据库。例如，该规则库168可以包括业务规则、模板、测试例和其它在多用户环境中管理的资产。

规则系统44还包括规则引擎164，根据一个实施例，该规则引擎164是由规则创制工件170定义的规则的执行平台。规则和规则包可以根据业务用户的指定部署到规则引擎164。当规则引擎164被告知将要部署规则或规则包时，规则引擎从规则库168中检索该规则或规则包。

图4是根据本发明实施例的iWD流的流程图。该过程可以以根据存储在存储器中的计算机程序指令由一个或多个处理器执行的软件程序的方式进行描述。然而，本领域技术人员应当认识到，所述程序可以通过硬件、固件或软件、固件和/或硬件的组合来执行。此外，所述过程中的步骤的顺序不是固定的，而是可以由本领域技术人员所认识的修改为任何所需的顺序。

在步骤200中，例如通过集成的捕获点162(图2)从多个工作源中获得(例如，以电子形式)新任务。根据一个实施例，可以调用分类模块43来对所述任务进行分类。就此而言，分类模块可以配置为调用规则引擎164以根据业务过程、部门、优先级或所应用的规则指定的任何其它标准来对所述任务进行分类。

根据一个实施例，交互服务器40根据所捕获的任务创建全局任务列表(GTL)。该GTL是所有系统和工作框的任务清单。工作源可以是整个企业的多种应用程序和业务支持系统中的任意数量的系统或者这些系统的组合，例如图2的工作源系统172-180的任意组合。然而，本发明的实施例并不限于此，还可以由其它旧版/主机系统、企业服务总线系统或任何其它媒体服务器(特定的iWD或非iWD)捕获任务。每个工作源可以与集成的捕获点162相连接，以创建由交互服务器40管理的任务的GTL。

在步骤202中，交互服务器40调用用于根据规则引擎164提供的业务规则计算任务优先级和任务分配的优先级模块41。例如，交互服务器40根据规则引擎164提供的规则可以识别服务水平值，例如任务截止日期、业务价值和优先级。具体的服务水平值可以取决于例如服务级别协议(SLA)的要求。使用所述数值，交互服务器40可以将任务按照优先级从最重要到最不重要的次序进行排列，并且监测和管理任务以确保符合服务等级目标。

根据一个实施例，交互服务器40按照优先级或者重要性顺序来排列GTL，并且可以基于为捕获任务的特定捕获点配置的业务规则、与所述任务相关联的业务过程或者联络/部门等级，跨越所有业务过程。

根据本发明的一个方面，在利用当前企业网站服务收集辅助的任务相关信息方面，业务规则促进更灵活的优先判定。例如，规则可以被配置为使得当捕获到新的客户订单时，该规则检索该客户的当前信用评分。该评分(例如“差”)接着与该任务相关联，并且可在下游被其它业务规则用于设置优先级，或者被路由服务器20用于判定该任务应当被路由到哪里(例如，信用授权部门)。

再次参照图2以说明技术人员使用规则开发工具166创建模板，以及业务用户使用规则创制工具170配置关于优先级和截止日期的业务规则。配置完成后，规则被存储在规则库168中。查询时，规则引擎164将评价存储在规则库168中的业务规则，以判断是否有合适当前处理任务的规则。也就是说，业务规则可以提供用于区分优先级任务和对于特定任务确定动作过程。

例如，业务用户可以配置业务规则以指定对于具有特定区域代码的终端用户，工作项应被定向到特定代理组。作为另一个示例，业务用户可以规定如果所捕获的交互的表单ID(例如，图7B中的表单ID 304)与服务请求类型相关联，则该工作项应当发送至特定部门。

在应用适用规则(如果有的话)后，可以再次调用规则引擎164以重新排列队列中其余任务的优先次序。例如，对于存储在交互服务器40中的低优先级的工作项，交互服务器40会定期地询问规则引擎164是否将该优先级更新到更高(或更低)优先级。

在步骤204中，选择任务以分配到员工(包括客户服务代理、前台资源、后台资源、知识员工或外包合作伙伴)。在一些实施例中，交互服务器被配置为利用资源和技能感知来将任务分配到合适的资源(例如，通过在合适的时间推送或拖拉到合适的资源)。这种资源和技能感知可以由例如统计服务器22、劳动力管理服务器118和/或类似服务器来提供。

在其它实施例中，可以在iWD水平考虑资源和技能感知并且并入到规则中。例如，iWD系统42可以从劳动力管理服务器118获得员工安排信息，并且保持给定任务直到具有所需技能的员工被安排工作。还可以使用实时资源感知，例如，若具有所需技能的可用代理的数量大于限定的下限阀值，则提交任务以供路由。作为进一步的实施例，iWD系统42可以配置为直接保留代理，以确保当给定交互被路由至被识别的目标代理时该代理没有被其它任务占用。就此而言，不会有新的任务被分配到被保留的代理直到给定交互被路由至该代理。

分配可以通过例如分配点(或目标)实现，该分配点限定任务将被路由以用于处理的位置。根据一个实施例，图2的系统被配置为支持多个分配点，进一步增强了工作分配。例如，企业可以选择将通过SLA规则确定的较低值任务路由到低成本区域，例如第三方业务处理器或企业的外包合作伙伴。

在一个实施例中，根据推送模块将工作分配到目标，其中工作项一次一个地被推送到员工。例如，工作项可以在特定代理装置38上显现或“突然出现(pop up)”。在一个实施例中，根据拖拉模块(或“工作框模式”)将工作分配到目标，其中多个任务(或批次)可以被分配到工作框或类似位置。根据一个实施例，一次分配到工作框的工作项的数量是可以配置的。工作可以被分配到独立的私人工作框或者分配到组工作框(即，到公共工作框的共享访问)。在一个实施例中，由分配阀值限定的每个批次的大小被设置为短期内(例如，在接下来的4到6个小时内)可以完成的任务的数量。任务通过分配点的初始分配之后，在一定的时间间隔内，交互服务器可以被配置为以下一个最高优先级的任务自动更新或结束。

在步骤206内，由iWD管理员/服务器146(图2)管理任务。根据一个实施例，iWD管理员/服务器146访问GTL以向业务用户提供与不同业务范围相关联的任务列表以及每个任务的细节和历史的视图。IWD管理员/服务器146提供图形用户界面(GUI)，从而允许业务用户执行手动任务操作，例如保持、恢复、取消和修改。该GUI还允许更新任务属性，例如客户段或优先级。通过限定过滤器标准并选择显示哪些任务属性，GUI还可以允许用户使用过滤器来优化视图中可见的任务列表。例如，当任务处于“已分配”状态(即，在代理桌面上打开)时，用户可以通过GUI取消、重启或者保持该任务。另外，当任务处在“保持”状态时，通过GUI，用户还可以取消、重启、恢复或更新该任务。根据本发明的实施例的一个方面，iWD管理员/服务器146向用户提供了可视化的工作量分配、可用性和员工效率。通过允许业务用户管理积压待办的任务、优先事项、SLA、资源和技能，iWD管理员/服务器146因此改进了资源的管理。

在步骤208中，可以根据例如统计服务器22收集的数据由基于任务的统计生成报告。该报告可以以许多不同的方式呈现数据(例如，SLA依从性、性能、利用率、未完成率、过期工作、特定时期内完成的工作量以及特定代理完成任务的时长)。例如，如图5A-5D所示，任务可以通过以下方式来组织和报告：根据业务过程和优先级(图5A)；通过到期日和时间(包括那些过期数)(图5B)；仅根据业务过程(例如，更改地址、回叫请求、投诉)(图5C)；和通过分配给每个任务的商业数字价值(图5D)。该数据可以实时(例如，通过当前天数统计)以及基于历史情况来报告。

根据本发明的实施例的多个方面，这些报告可以提供对业务绩效的深度了解，并且允许业务用户对报告的度量与业务用户定义的关键绩效指标进行比较。业务用户还可以利用任务积压信息来改进劳动力规划。

图6是根据本发明一个实施例的用于分配工作项到分配目标的过程的流程图。该过程可以描述为由交互服务器40(或者iWD服务器)中的一个或多个处理器根据存储在存储器中的计算机程序指令执行的软件程序。然而，本领域技术人员应当理解，上述过程可以通过硬件、固件或者软件、固件和/或硬件的组合来执行。此外，上述过程的步骤顺序不是固定的，而可以改变为本领域技术人员所认识到的任何所需的顺序。

该过程启动，在步骤800中，交互服务器(或者iWD服务器)识别一个或多个工作项以分配。该工作项可以是从存储在例如由交互服务器保持的工作流分配队列中的全局任务列表中检索到的。在这方面，交互服务器(或者iWD服务器)可以配置为周期性地访问全局任务列表，并且识别一个或多个入列的工作项以便分配。该工作下可以根据例如一个或多个分配标准进行选择。该分配标准可以是例如根据规则引擎164提供的规则指定给多个工作项的优先级。在一些实施例中，该分配标准可以是规则引擎指定的业务价值。业务价值可以反映追加销售的可能性、交叉销售的可能性或其它与客户有关的业务可能性。该分配标准还可以是该交互的创建日期、工作项的到期日期等类似信息。

根据一个示例性实施例，首先选择一个或多个优先级最高的工作项进行分配。

根据一些实施例，可以在交互服务器(或者iWD服务器)水平应用资源感知。在这些实施例中，交互服务器(或iWD服务器)可以作为iWD系统42和资源状态信息资源(例如，劳动力管理系统118和统计服务器22)之间的代理或协议集线器操作。例如，在步骤802中，交互服务器(或iWD服务器)识别分配目标。分配目标的识别还可以由iWD系统42完成，其中iWD系统42熟悉联络中心资源。在接下来的实施例中，与预期目标相关的信息将与给定的任务一起被传送到路由服务器。

该分配目标可以是例如特定的代理、代理组、工作框、自动响应系统和/或联络中心的任意的其它资源。分配目标的识别可以根据例如由规则引擎164根据一个或多个规则的应用程序返回的数据。例如，如果工作项是处理由客户通过网站提交的订单，则交互服务器40(或者iWD服务器)可以被配置为访问规则引擎164，以获得该工作的优先级值分配以及可能与该交互关联的任何其它业务规则。在访问规则引擎中，交互服务器40(或者iWD服务器)可以被配置为发送与该交互相关的特定参数，例如用于填写订单请求的表单的表单ID。规则引擎存储的与该表单ID相关联的规则可以返回与该工作项将被路由到的分配目标(例如，订单处理代理组)相关的数据。分配目标信息可以附属于该工作项数据并且存储在全局任务列表中，直到准备用于分配。

根据一个实施例，根据分配目标的识别，在步骤804中，交互服务器40(或者根据实施例可以是iWD服务器)确定是否存在与该分配目标相关联的一个或多个可用资源。例如，如果分配目标是具有特定技能集的代理组，则可以根据该代理组中符合接收交互的每个代理的能力设置来确定可用性。代理的能力可以被设置成指示代理在任意时间点可以被分配同时处理的任务的数量或者类型(例如，同时处理三个电子邮件回复、两个聊天会话或者两个订单处理活动)。为每个代理建立的工作表可以指示该代理的能力以及与该代理相关联的技能类型和技能水平。该信息还可以由统计服务器22提供。根据一个实施例，工作表可以由能访问劳动力管理系统118的联络中心管理员设置。

根据一个实施例，交互服务器(或者iWD服务器)访问代理的工作表和/或正在由该代理处理的活动的实时可见性。根据该信息，如果交互服务器(或iWD服务器)判定有一个或多个代理具有用于处理工作项的当前(或预计的)能力、技能等，则在步骤806中，交互服务器(或者iWD服务器)发送路由请求到路由服务器20。据此，该工作项可以被从实施全局任务列表的队列中移除，并且放置在由路由服务器20保持的路由队列中。该路由请求可以在连接交互服务器(或者iWD服务器)与路由服务器的数据通信网络(例如，局域网)中传输。路由请求可以包括例如由路由引擎返回的特定数据(例如，分配目标数据)。响应于该请求和/或附属于该请求的数据，路由服务器识别合适的可用代理并将工作项推送到该代理。据此，该工作项可以被推送到代理的装置或者放置在代理的工作框26中。

再次参看步骤804，如果交互服务器(或者iWD服务器)判定当前或者在可预期的未来(根据预期代理可用的时间的计算值)内没有可用代理，则交互服务器(或者iWD服务器)停止将路由请求传送至路由服务器20。据此，路由服务器并不负载因缺乏资源而不能被路由的路由工作项请求。这有助于避免连接交互服务器(或者iWD服务器)与路由服务器的数据通信网络中的不必要的阻塞以及避免判定代理可用性中路由服务器不必要的处理。

如果已准备好分配的工作项被停止分配，则交互服务器20(或iWD服务器)在步骤810中可以对例如与工作项相关联的分配标准做出修改。例如，工作项的优先级可以被提高，工作项的截止日期可以被改变和/或其它类似修改。

根据一个实施例，代替由交互服务器(或者iWD服务器)判定代理的可用性，该判定可以合并到规则引擎提供的例如为工作项分配优先级的规则中。例如，该规则可以将优先级的分配基于代理可用性信息，其中为不可用资源的工作项分配较低的优先级。当交互服务器(或者iWD服务器)根据优先级数据选择分配的工作项时，代理不可用并因此具有较低优先级的工作项不会立即被选择以进行分配。

图7A-7C是根据本发明一个示例性实施例的显示终端用户通过企业的由例如网站服务器32托管的网站提交服务请求的示例性过程的屏幕截图。该服务请求是提供到交互服务器40的交互，用以最终路由至联络中心资源。该屏幕截图显示了终端用户遇到的示例性图形用户界面屏幕，该图形用户界面屏幕可以实现为基于网页的用户界面。根据示例性实施例，如图7A所示，终端用户首先导航到名称为Acme的公司的企业网站300。如图7A所示，选择终端用户所在国家后，该终端用户被提示填写图7B中所示的在线服务请求表单302。服务请求表单302包括个人信息字段(例如，终端用户的姓名和联系号码)和请求信息(例如，请求类型、主题、注释和电子邮件地址)。表单识别号(ID)304在服务请求表单302底部显示在“提交表单”图标之下。表单ID 304可以与特定类型请求相关联，例如服务请求，或者更具体地为地址变更请求。尽管在网站上为现有客户提供了登陆链接306，如图7B所示，但是填写服务请求表单302之前，填写表单的终端用户并不需要登陆。终端用户提交他的请求之后，如图7C所示，与输入的终端用户信息一起在屏幕上提供确认号码308。在一些实施例中，屏幕上还可以显示估计的响应时间。终端用户的服务请求被提交到交互服务器，所述交互服务器检索存储的与该客户相关的信息。交互服务器判定该请求不能被自动响应满足，该请求将被发送到企业员工以进一步关注。

图8A-8F是根据本发明一个实施例的显示企业员工管理交互和任务的过程的屏幕截图。在示例性实施例中，该企业员工可以是客户服务代理或者知识工作者。如图8A所示，员工可以使用单独的交互工作空间应用程序402管理任务和交互。根据示例性实施例，交互工作空间应用程序402根据本发明的一个实施例是由代理装置38托管的应用程序，用以为企业员工提供不同的功能。如图8B所示，企业员工可以使用交互工作空间应用程序402指示他的可用性状态。例如，该员工可以从选项的下拉列表404中选择状态名称，例如“就绪”、“未就绪”以及“请勿打扰”。

在一个示例性实施例中，当企业用户变为可用时，适当的话，交互服务器与路由服务器一起可以推送下一个最高优先级的任务到该员工。作为一个实例，在图8C中，根据图7A-7C的终端用户交互的任务被从交互服务器40推送到该员工。根据一些实施例，这些与该代理的技能和可用性最匹配的任务被推送到该代理。任务呈现在该员工的桌面上，如事件信息窗口406所示。事件信息窗口406显示与任务相关的信息，包括来源、优先级、请求类型和对象。该员工可以通过点击事件信息窗口406中的“接受”或“拒绝”图标来接受或拒绝该任务。

如图8D所示，一旦任务被接受，事件信息窗口406显示计时器408，所述计时器显示企业员工处理该任务所用的时长。通过点击事件信息窗口406中的“完成”图标410，该员工可以标记该任务已完成。图8E中的历史菜单418显示了该任务先前的历史，包括状态、主题、开始日期、结束日期以及该任务曾由谁处理。在图8E所示的实例中，处理栏包含处理过该任务的代理的ID a1001。在图8F中，状态指示器420显示了该员工状态的详细信息，例如，该员工已经处在当前状态多长时间、该员工的登陆时间、该员工的装置(如p1001显示，所述装置是将该员工关联到他正在处理交互的物理装置的相关对象)以及该员工处理来自其它工作源的交互的可用性。

图9A-9I是根据一个实施例的图2的iWD管理员/服务器146的屏幕截图。图9A是呈现给员工的登陆界面。如图所示，iWD管理员/服务器146可以使用基于网站的接口访问。一旦员工登陆，根据该员工的权限，该员工能够访问图9B中所示的用户界面502的全部或一部分。例如，特定部门内的员工仅能够访问分配到该部门的任务。如图9B所示，用户界面502可以呈现为两个窗形方格之间的分割窗口。左边的窗形方格503包括选项的控制面板504和导航面板506，所述控制面板包括“常规”、“模块&组件”、“服务”、“部门和流程”、“规则创制”和“全局任务列表”，导航面板506显示了与从控制面板504中所选择的选项相对应的导航层次结构或者菜单树。右边的窗形方格505包括显示与所选择的选项相关联的信息的详细视图。在图9B中，例如，在控制面板504中选择“常规”选项，在导航面板506中的下拉菜单中选择企业名称，在本实施例中为“ACME”。

本发明的实施例的一些方面还在iWD管理员/服务器146和图2的规则创制工具170之间提供SSO。例如，参照图9B，用户可以点击控制面板504中的规则创制图标509，以登录到规则创制工具，例如下文中参照图15B-15R和图16A-16I所描述。在示例性实施例中，规则创制图标509用作到规则创制工具的链接。可以使用配置数据库148来验证尝试登录到iWD管理员/服务器以及规则创制工具的用户。终端用户可以通过超文本传输协议(HTTP)使用网站浏览器来使用iWD管理员/服务器和规则创制工具。在一个实施例中，SSO实现的第一次迭代是基于GRS方法。GRS希望通过HTTP GET方法传递登陆名和密码。

图17是根据本发明实施例的显示用户第一次使用SSO的视图。该视图是在SSO实现的第二次迭代中iWD要求的SSO时序图。用户610尝试登录iWD管理员/服务器146，iWD管理员/服务器146根据存储在配置数据库148中的数据验证用户610。当iWD管理员/服务器146从配置数据库148接收积极的响应时，所述iWD管理员/服务器会创建基于用户特定数据的令牌并将该令牌存储在数据库中。接着，iWD管理员/服务器146响应于用户610使用登陆通信并将用户名和令牌存储在用户计算机上的cookie中。用户610然后可以点击图9B中所示的iWD管理员/服务器用户界面中的规则定制图标509以链接到规则定制工具。然后，用户610被重新定向到规则定制工具用户界面。该规则定制工具搜索具有用户名和令牌的cookie，然后验证该令牌。如果验证成功，该用户610将不会被提示登录。在用户610后续每次使用SSO中，将不需要生成新的令牌。相反，执行查找以在数据库中搜索该令牌。

在图9C中，在控制面板504中选择“全局任务列表”选项。导航面板506反映出与该GTL相对应的菜单的层级结构。该菜单是依据部门和请求类型组织的。例如，财务部门具有由请求类型组织的分类列表，包括催款和退款。销售部门具有由请求类型组织的分类列表，包括地址变更、回叫请求、目录请求、投诉、信息咨询、订购和服务请求。

在图9D中，销售部门被选中。销售部门的所有工作项的列表显示在右侧窗形方格505的上部中。关于工作项的其它详细信息显示在列508-526中，包括：列508中的工作项ID；列510中的捕获ID；列512中的状态；列514中的图标；列516中的媒体类型；列518中的过程；列520中的创建日期和时间(D/T)；列522中的商业值；列524中的优先级；和列526中的任务到期D/T。

根据一个实施例，列508中的工作项ID是由交互服务器40生成的ID，捕获ID可以由企业设置或者从企业工作源输入，该企业工作源例如是图2中所示的CRM系统172、BPM系统174、工作流系统176、文件管理系统178或者传真服务器180。列512中的状态是该工作项的状态。例如，工作项可以被指定为“完成”、“暂停”、“排队”或者“取消”。图9E中所示的工作项的状态为“完成”，因此如在属性部分中所示，该工作项在iWD完成队列中。“排队”状态指示该工作项在积压待办队列中并等待被分配。列514中的图标是代表了该工作项的视觉指示器。例如，传真图标可以用于进入的传真。列516中的媒体类型以图形或其它方式显示与该交互相关的媒体类型(例如，电子邮件、社交消息、聊天，等等)。列518中所列的过程为与该工作项相关的业务过程。根据一个实施例，企业定义它自己的业务过程的组织层级。列520中的创建D/T指示交互服务器创建该工作项的日期。根据一个实施例，列522中的商业价值和列524中的优先级是由企业的业务用户分配给该工作项的数值。列526中的任务到期D/T可以是由业务用户设置的日期或者由任务组织系统(TOS)(即，发起任务的工作源)设置的日期。

当选择特定任务时，如图9E和9F所示，该任务有关的详细信息显示在位于右侧窗形方格505的下部中的任务细节区507的属性选项卡中。例如，属性部分可以显示从第三方系统(例如，TOS)获得的信息。属性字段还可以定制为包括终端用户的输入数据，例如图9F中所示的终端用户的联络号码。因此，在属性部分中提供的信息向查看任务的业务用户提供背景信息。

根据另一个方面，业务用户(例如，管理员)可以根据企业的具体业务需要添加或者修改属性字段，按顺序安排工作项优先级。回顾工作项并且具有适当权限的用户可以通过选择图9F中所示的任务详细节区507上方的“修改”图标528来修改属性信息。例如，企业用户可以创建名称为“客户群”的属性字段，以输入指示特定客户在黄金客户群中的信息。该业务用户接下来可以配置业务规则，使得当客户在黄金客户群中时，该客户必须在10分钟内收到响应。

在一个示例性实施例中，业务用户可以向显示在右侧窗形方格505内的工作项列表提供过滤器。在图9G中，过滤器530的下拉列表允许用户仅显示待定、完成、过期、暂停或已分配的工作项、放置在错误队列中的工作项或者根据一些预先定义的业务逻辑的状态、或者从社交媒体工作源捕获的工作项。但是，本发明的实施例并不限于此，企业用户可以使用导航面板506中的过滤器创建新过滤器或者修改当前过滤器。例如，图9H-9I显示了称为“6小时内的到期工作”的新过滤器的创建。企业用户从过滤器标准532的下拉列表中选择以添加到过滤器。在图9I中，已经选择标准“到期日期”，并且业务用户指定限定过滤器的参数。使用下拉列表和指定的输入变量降低了用户输入错误的风险并且提高了该过滤器成功实施的机会。例如，如图9I所示，该用户可以仅在字段534中输入整数。一旦该过滤器参数被指定，企业用户可以通过点击“保存”或者“保存&关闭”图标来保存过滤器。因此，业务用户可以使用动态的、不断改变的GTL视图以评估一天之内的工作量分配和效率。

根据本发明的一些实施例，企业可以设置它自己的安全策略，这样不是所有的企业员工都有相同的编制规则的权限。例如，如图10所示，安全策略工具600允许特定员工的权限的定制。在图10中，具有“iWD监管员”的身份的业务用户可以对GTL有完全访问权限，如任务管理权限区602中所示，其中该任务管理权限区602中所有复选框都被选中了，但是没有访问规则定制工具的能力，如应用程序权限区604中所示，其中在应用程序权限区604中没有选中该复选框。

根据本发明的其它方面，属性区的详细任务信息可以被提供到规则系统44，以驱动工作项的排序和重新排序。图11A-11D显示了根据一个实施例的任务在其生命周期中可能呈现的多种状态的流程图。

首先，如图11A的状态762所示，交互在捕获点处被捕获，其中可以包括多种工作源。在状态764中，该交互被指定为新任务。然后该任务移动至分类状态766，在此期间，调用规则系统44以根据业务过程、部门、优先级或规则系统44指定的任何其它标准来对任务进行分类。然后该任务在状态768中被指定为捕获的任务，并且移动至优先级次序状态770，此时可以再次调用规则系统44以向该任务提供附加业务规则。在优先次序状态770后，该任务被放置在排队状态772中。可能有成千上万的交互在排队状态772中等待被分配或重置优先级。

如果任务还没有被分配，则所述任务被重新传递回到规则引擎164进行重置优先级。重新设置优先级涉及iWD排队状态中该任务的用户定义条件的应用程序。重新设定优先次序的时序可以由业务用户确定。在图11B显示的实例中，该业务用户已经设定了特定的重新设定优先次序日期和时间。通过向该任务提供窗口778中所示的状态，交互服务器检查以查看是否已经经过了重新设定优先次序的日期和时间。当多种当前时间()与iWD重新设定优先次序日期相同时，该任务将被传送回到优先次序状态770以重新设定优先次序。但是，本发明的实施例并不限于此，可以使用其他条件来判定何时重新设定任务的优先级。例如，业务用户可以设定仅有到期时间在接下来的两周内的任务可以被重新设定优先级的条件。这些条件可防止规则引擎146被iWD排队状态中的大量任务过度负载或者造成阻塞。

如果任务已准备好被分配，如图11C所示，该任务将被移动至分配状态774以在状态776中被传送至多个动态目标。根据示例性实施例，处理任务以便长期的任务归档。例如，如图11D所示，当任务满足特定归档标准时(例如，该任务在三个队列中的一个—iWD_拒绝780、iWD_取消782或者iWD_完成784—并且该任务的截止日期已经经过)，可以基于规则系统44中的业务规则在归档786中存储该任务。一旦该任务被归档，用户可以通过来自规则系统44的业务规则配置任务归档期限，并在归档期限后自动清除归档任务及与其相关的事件。如果任务在三个队列(iWD_拒绝780、iWD_取消782或iWD_完成784)中的一个中并且截止日期已经过去，该任务在状态788中被标记为完成。没有在上述三个队列(iWD_拒绝780、iWD_取消782或iWD_完成784)中的一个中的任务，即没有“归档”任务，被作为“当前”任务来处理。在一个实施例中，GTL包括两个预定义的过滤器，一个用于查看“当前”交互，另一个用于查看“归档”交互。

在一个实施例中，可以向企业提供数据性能指南表，包括数据可以保持存档的时长的参数、给出任务和当前存储的事件的数量。企业可以根据该数据性能指南表设置清除归档数据的规则。

根据本发明的实施例，当企业接收到交互时，不仅该交互应当被路由至合适的部门以进行处理，而且还可以有用于处理该交互的附加商业需求(例如，临时需求)。例如，该企业可能希望根据特定终端用户的收入水平向该终端用户呈现特定的广告宣传。企业还可能希望根据客户的群组(例如，金、银或铜群组客户)将特定交互路由至专门的24小时服务部门。这种业务需求特定用于特定企业。根据一个实施例，交互服务器44访问规则系统44以帮助满足这些附加商业需求。规则系统可以分派在iWD系统的业务层级的各个层次可以施加的规则，例如解决方案、部门、过程和捕获点级别。

规则系统

图12是根据本发明实施例的显示规则系统的高层体系结构以及该规则系统的客户端应用程序的示意框图。规则系统944可以与图1和2中所示的规则系统44相似。多种客户端应用程序，例如自动语音应答系统902、iWD系统942、交互服务器940、编制/路由服务器904，可以访问规则系统944以申请可应用到当前交互的任意规则。在一个实施例中，iWD系统942具有业务环境管理服务，所述业务环境管理服务用作交互服务器940和/或编制/路由服务器904与路由引擎964之间的层。当有交互进入时，业务环境管理服务添加特定iWD数据并且将请求的数据传送至规则引擎964。规则引擎964响应于业务环境管理服务与处理的交互，该业务环境管理服务将处理的交互发送回交互服务器940和/或编制/路由服务器904。该交互服务器940、编制/路由服务器904以及路由系统944可以与图1和2的交互服务器40、路由服务器20以及规则系统44相似。

图13是根据本发明实施例的创建业务模板和业务规则的过程的流程图。该过程可以描述为由一个或多个处理器根据存储在存储器中的计算机程序指令执行的软件程序。但是，本领域技术人员应当理解，该过程可以通过硬件、固件或软件、固件和/或硬件的组合来执行。此外，该过程的步骤的顺序不是固定的，而是如本领域技术人员所理解的可以调整为任意需要的顺序。

根据一个实施例，在步骤990中，技术用户使用设计工具906为业务规则开发了模板。根据一个实施例，该设计工具结合了规则开发工具908，技术用户可以使用该规则开发工具908开发模板并将该模板发布到规则库968(图12)。该规则开发工具908和规则库968可以与图2的规则开发工具166和规则库168相似。

在步骤992中，业务用户使用与图2的规则创制工具170相似的规则创制工具970配置业务规则的参数。根据一个实施例，该规则创制工具包括规则创制客户912和规则创制服务器914。在本发明的示例性实施例中，该业务用户根据该企业的特定商业需求配置规则参数。如图12中所示，规则创制工具970可以是基于网页的界面。配置规则参数后(例如，设置规则模板中的全部条件和动作)，该业务用户可以发布或者部署该规则(或者规则包)到应用程序服务器963中的规则引擎964。就此而言，业务用户可以根据企业的商业需求开发规则和路由逻辑。如果企业的商业需求发生变化，该业务用户通过规则创制工具修改例如规则参数来改变该规则逻辑，并且将该改变发布到规则库968。因此，规则参数可以更容易地改变。

在该规则已经发布后，在步骤996中，该业务用户可以使用规则创制工具970修改该业务规则。这些修改可以随时进行。此外，附加的逻辑变化可以立即发布也可以在设定的时间发布，这取决于该业务用户的选择。

在步骤998中，当多种客户端应用程序(例如，GVP/ICFD 902、iWD系统942、交互服务器940、编制/路由服务器904或者客户写的任何其它应用程序)呼叫规则系统944时，应用存储在应用程序服务器964中的业务规则。例如，应用于企业业务不同方面的多个规则包可以设置在应用程序服务器963上，从而通过不同客户端应用程序服务于请求。如在此所用的，术语“规则包”代表部署到应用程序服务器964的可执行项，包括一个或多个规则、事实模型以及任何功能或者使得该规则包成为可以由规则引擎964执行的独立项的其它项。该规则通过应用编程接口(API)部署在客户端应用程序，在一些实现中可以使用表述性状态转移(REST)或外部服务协议(ESP)。管理员916为应用程序，所述应用程序由系统管理员使用以配置必要性能和多个系统部件(例如，规则引擎964、设计工具906、规则创制工具970以及类似部件)的连接。

图14A-14F是根据本发明实施例的显示为业务规则开发模板的过程的屏幕截图。在一个实施例中，每个模板有多个部分供技术用户编程，包括活动、条件、枚举(enum)、事实模型、函数和参数。条件可以是“何时”的表达，例如，“何时{到期时间}是在{x}{时间区间}。”{到期时间}、{x}和{时间区间}是由业务用户确定的参数。活动可以是“然后”的表达，例如，“然后指定{优先级}。”{优先级}是由业务用户确定的参数。同样地，参数可以同时用在条件和活动中。函数也可以同时用在条件和活动中以获得值。函数可以由技术用户使用例如Java或Groovy写成。

根据本发明的一个方面，模板被命名为参数、函数、条件和活动的集合。模板为创建规则提供了自然语言界面，从而允许非技术的业务用户更简单地理解并创建规则。业务用户可以访问模板以选择哪些条件和活动将用于创建规则，然后该规则可以用于特定的业务场景。

图14A描述了根据一个实施例的规则模板的条件编辑器1000。该规则模板命名为“与女儿约会”，这里描述为简单目的描述了生成允许某人与他的女儿约会的模板。当然，联络中心的模板可以允许生成与销售、交叉销售、任务优先级和类似目标相关的规则，以适用于联络中心支持的企业的业务。如图所示，技术用户可以生成由规则引擎964评价的多个条件1002。如在条件细节区1004中所示的，技术用户为每个条件指定语言表达1006将呈现给业务用户。该语言表达1004识别由业务用户输入的参数(使用方括号指示)，并且设置参数类型限制。例如，参数类型可以是整数或整数范围、数字值、字符串、日期、时间或者从项目下拉列表中选择的列举类型。因此，该业务用户将不能输入错误的参数类型，从而降低业务用户配置规则时出现错误的概率。该参数还可以来源于配置(Config)服务器918，包括例如业务属性、代理组、代理列表或者技能组。参数可以在不同的条件和活动中重复使用。作为模板开发的一部分，该技术用户还为规则语言映射1008指定开源业务规则管理系统，其中规则语言映射1008将输入参数映射到调用的函数的变量或者规则引擎966。

在图14A中，“与女儿约会”模板的年龄条件在语言表达1006中表示为“年龄至少是{年龄_低}但是不高于{年龄_高}。”在图14B的参数编辑器1001中，技术用户指定整数为参数的参数值类型。因此，技术用户必须仅能向{年龄_低}和{年龄_高}参数输入整数值。该整数的下界和上界也被规定。

如图14A的规则语言映射区1008中所示，调用前景功能(也可以称为事实)以将{年龄_低}和{年龄_高}参数映射到函数的合适变量。图14C的事实模型编辑器1003通过交互服务器检索与交互数据库156(图2)相关的数据，并且将该数据打包到事实(显示在图14C中性能项下面)中以被传送到规则引擎964用于与输入的参数进行比较。事实模型编辑器1003可以以例如XML或者JavaScrip对象符号(JSON)字符串格式打包该数据。因此，业务用户可以使用规则创制工具970修改业务规则，而不需要改变编制/路由服务器904。

业务规则模板还可以具有用于指定与特定交互相关的活动的活动编辑器。图14D示出了根据一个实施例的活动编辑器2005。如图所示，技术用户可以创制由规则引擎964应用的多个活动2010。设置激活时间活动在语言表达2006中被表述为“设置激活时间’{时间}’。”如规则语言映射区2008中所示，调用设置字符值函数以将{时间}参数映射到调用的函数的合适变量。

图14E描述了根据一个实施例的规则模板的列举编辑器1007。如图所示，多种活动可以以列举方式表示。列举可以是显示在预定义列表中的静态值。例如，称为爸爸的活动可以与列在值区1012中的任意列举的活动相关联。

在图14F中，iWD模板的商业价值状况在语言表述1006中被表述为“商业价值是‘{商业价值_起点}’到‘{商业价值_终点}。’”因此，该业务用户为‘{商业价值_起点}’和‘{商业价值_终点}’指定整数值。如在规则语言映射区1008中所示，调用串演算函数，‘{商业价值_起点}’和‘{商业价值_终点}。’参数被映射到合适的变量，并且与值“IWD_商业价值”相比较以判定结果。

在另一个实施例中，上述参数可以是具有阀值的运行参数，所述阀值可以在一天(例如，终端用户等待时间)内变化。例如，由动态值组成的列举可以从诸如配置服务器列表对象的外部源获得。在这些实施例中，该运行参数值可以在每次运行时间进行重新检查。

根据一个示例性实施例，图14A和14F中的变量“以年计算年龄”和“IWD_商业价值”从多种客户端应用程序传送至规则引擎964。例如，编制/路由服务器904可以从图2中的统计服务器22检索信息(例如，“以年计算年龄”和“IWD_商业价值”)并且将该数据发送至规则引擎964。这样，规则引擎964自己不需要从客户端应用程序检索上述数据。因此，由于规则引擎964不会陷入附加过程的处理，可以提高性能。

根据一个实施例，在技术用户已经在设计工具906中完成模板后，该技术用户通过HTTP界面将该模板发布到网站应用程序服务器，存储该模板。然后该模板就可以与多个规则包一起加以使用。

图15A-15D是说明根据本发明实施例的配置、测试和部署业务规则的过程的屏幕截图。在一个示例性实施例中，业务规则基于企业的业务层级，所述业务层级被组织成不同部门和在这些部门中的业务流程。该业务规则可以是可应用于整个业务的全局规则，或者它们可以应用到该层级的特定区域或层次。

首先，业务用户可以使用图15A中的登陆界面登陆到规则定制工具970。可选地，业务用户可以通过点击图9B中所示的“规则创制”图标经由iWD管理员/服务器146中的控制面板504来访问规则创制工件970。该业务用户可以在企业的层级的任何位置，并且多个业务用户可以同时工作于相同或不同工作包。如图15B所示，具有创建模板权限的系统管理员可以使用图15B所示的屏幕导入或导出整个模板库。例如，当将模板和规则包从一个系统转移至另一个系统时，管理员可以使用这个功能。

每个企业可以访问它的公司解决方案，每个公司解决方案包括基于该企业的业务层级的一个或多个规则包。例如，企业可以具有用于整个业务的一个大的规则包或者用于业务不同方面的多个小的规则包。当在运行时间执行规则包时，客户端应用程序(例如，由编制/路由服务器904调用的路由应用程序)将数据传送至规则引擎964，并且可以依据传送的数据触发一个或多个规则。图15C和15D显示与每个规则包的版本号一起关于两个现存的规则包(与女儿约会和iwd)有关的信息。

图15E的与女儿约会规则包中的规则显示与图15F的iwd规则包中的规则显示不同，这是因为规则包所依据的规则模板不同。为了创建新的规则包，如图15G中所示，从下拉菜单1020中选择包类型。在模板区22显示了可用模板。根据示例性实施例，解决方案中的每个规则具有相同的层级。也就是说，在整体水平，可以有一个或多个将被最先执行的规则。可以为不同部门和过程生成附加规则。当该业务用户运行该规则包时，她可以指定正在将该规则运行在哪个部门或过程。因此，不是所有规则必须可以被同时运行。相反，规则的执行是根据用户当前访问的业务区。换句话说，调用规则包时，用户可以指定处理部门。此外，不同用户可以访问不同规则，并可以同时工作于不同规则。例如，业务用户可以工作于客户服务部门规则，同时另一个业务用户工作于销售部门规则，二者互不干扰。

在一个实施例中，规则包可以包括两种类型的规则：线性和决策表。线性规则规定，当某条件为真时，执行指定活动。在规则包内也可以有绑定于业务操作的不同阶段的特定阶段规则。图15H中示出了特定阶段规则的实施例，其表明当年龄至少是18但不多于22，并且候选人为非吸烟者时，然后做出的决定是OK并且执行冷淡对待的动作。进一步地，该规则的应用程序取决于三个阶段—第一次约会、第二次约会和第三次约会。因此，该规则可以根据阶段被过滤。绑定于第一次约会阶段的规则在图15H中示出，同时绑定于第二次约会阶段的不同规则组在图15I中示出。

如图15J所示，业务用户可以修改业务规则，并且添加另外的条件或活动到该业务规则。在图15J中，已经添加了“失败者至少做1000”的条件，并且模板中还有两个活动可以可选择地添加。保存修改的规则时，如图15K中所示可以添加注释，该注释指示做了哪些变化(例如，修改或添加了哪些条件)。在下次运行期间可以部署该规则。另外，在图15L中，审计跟踪1024具有用于管理上述业务规则的版本控制机制。在一个实施例中，审计跟踪1024提供信息：每个规则的开发ID和版本、执行了与该规则相关的什么类型活动以及由谁执行，以及该用户做的任何注释。还包括还原选项1026，以返回到规则的上一个版本。

当有多排数据时可以使用判定表，在为每排数据单独生成规则时，该判定表可能会繁琐。该判定表包含可以填入数据的多个了列，并且该判定表可以作为电子数据表被导出，从而可以在外部应用程序(例如，Microsoft Excel)中对其进行编辑，然后再次导入到规则创制工件970。

进一步地，根据一些实施例，如图15M所示，可以在规则创制工件970中实现一个或多个日历。该日历可用于指定工作日、节假日和异常调度日。这种功能可以用于为业务规则评价基于时间的条件。例如，业务规则可以指定将工作日下班后呼叫的终端用户(客户)转接至外包部门。因此，需要工作日日历来定义工作日时间表，并且判定“下班后”的条件是真还是假。

在业务用户已经完成业务规则的配置后，该规则被保存(也被称为发布)在规则库968中。为了将规则部署到应用程序服务器963，业务用户可以点击图15N中所示的部署规则链接，从而将该规则推送到应用程序服务器963。下次调用规则引擎964时，将应用该新的或更新版本的规则。在一些实施例中，在网络中可以具有多于一个规则引擎964，或者在负载平衡器后可以有一组规则引擎964，并且该规则可以被部署到该组规则引擎上。根据示例性实施例，如图15O所示，业务用户可以在部署该业务规则前添加注释，并且可以如图15O所示安排该部署稍后进行。如图15P所示，业务用户还可以查看他们的部署历史。

根据本发明的实施例的其它方面，部署前可以由业务用户对新的或修改过的业务规则进行测试。根据实施例，规则测试允许业务用户为每个测试方案创建、描述和查看摘要和细节结果。业务用户可以创建测试方案，每个测试方案包括与待测试的值一起添加业务环境和用于提交的阶段数据的能力。例如，该业务用户可以管理给定值(用于测试当前业务规则中的条件的值)和预期值(当前业务规则中呈现的预期结果值)，并且查看所提交的用于测试、部署之前的每组值的摘要和细节结果。

根据一个实施例，对于每个规则包，规则创制工具970允许业务用户定义一个或多个测试方案。该测试方案可以与规则包一起存储在规则库968中。在一些实施例中，业务用户可以建立一系列可执行的测试方案，以保证该规则包的性能与规定的一样，并且改变该规则包时不会影响预期的性能。

例如，测试方案可以用于规则包包括上百个处于企业的业务层级的不同层级或节点的规则的情况。可以运行回归测试以验证添加或修改规则的条件不会导致另一规则发生故障。通过回归测试，检查规则包变更后相对于该变更之前的旧性能而有的新性能。在示例性实施例中，测试方案模拟呼叫规则引擎并向该规则引擎传送数据的客户端应用程序，该规则引擎返回结果。当创建规则时，业务用户可以向测试方案输入给定的值(也称为测试数据)以查看所得结果是否与预期相同。然后，修改该规则后，该业务用户可以再次运行相同的测试方案以确认仍然返回所预期的结果。

该业务用户还可以为测试方案制定阶段和业务层级，并且可以为时效性规则指定时间和日期。例如，该业务用户可能希望模拟仅在特定的开始和结束日期执行的业务规则(例如，信用卡提供仅在未来的一个特定时期内有效)。该业务用户可以通过模拟该未来的日期和时间来测试该规则。

图15Q是根据一个实施例的测试方案的示例。如在左侧的窗形方格1027所示，测试方案可以通过导航树上的标记为“测试方案”的节点进行管理。根据一个实施例，当用户点击该测试方案节点时，他们会在右上部的窗形方格1030中看到测试方案列表，并且当他们点击所列出的测试方案时，他们会在右下部的窗形方格1028中看到该测试方案的详情。

在图15Q所示的测试方案概括屏幕中，业务用户可以创建新的测试例来运行单个的测试方案(或者全部测试方案)。就此而言，工具栏1029可以包含新测试方案、运行测试方案和运行全部的图标。通过修改测试方案，用户能够变更多个属性，包括：名称(该测试方案的描述性名称)；描述；阶段(用户希望执行该测试方案的阶段)；和业务层级(用户可以从业务层级的层次的下拉列表中选择以运行该测试，例如，在“通过/包层次”运行或者在特定部门或过程下运行)；模拟日期(例如，具有开始和结束时间或者业务日历的规则)；模拟时间(例如，具有业务日历的规则)；和时区。该用户还可以具有删除该测试方案的选择。

在图15Q中，下部窗形方格1028中的{年龄}和{吸烟者}栏中示出了业务用户为测试方案提供的值。根据实施例，该给定值代表了传递到规则包的数据。对于每组给定值，用户可以添加一个或多个预期的结果，所述结果表示从规则执行产生的结果。根据所述组的给定值，{日期决定}和{爸爸活动}栏示出了用户希望业务规则包返回的结果。结果栏显示了当前测试方案的最终执行结果，该结果可能是成功(通过复选标记指示)或者是不成功(由X图标指示)。

如图所示，给定数据和预期数据(统称为测试数据)都可以是模板参数的格式。在一个实施例中，在规则中使用的编辑器也用在测试方案中。例如，如果将该值定义为整数、字符串、浮点数或者从列举向、配置服务器、数据库等产生的列举列表，该下拉值将被提供为规则编辑器中已经完成的格式。

根据一个实施例，当用户运行测试方案时，每一排测试数据都可以作为单个测试被分开传送。当测试执行完毕时，规则创制工具970将该参数值映射到底层事实模型。该映射可以由了解参数与事实模型之间的关系的技术用户辅助完成。因此，在示例性实施例中，GRDT 908允许技术用户将参数映射回到该底层事实模型。例如，{年龄}参数可以与前景事实模型的变量“以年计算年龄”相关。如果业务用户将{年龄}设置为25，那么当执行该测试时，规则创制工具970分配前景事实并设置变量“以年计算年龄”为25。

在一个实施例中，当运行测试方案时，结果会显示在摘要和细节视图中。在图15Q中，通过X图标表明该测试方案失败，这是因为业务用户添加了新参数，但是没有为该参数传送任何测试数据。根据示例性实施例，该用户可以点击结果栏中的图标以显示该测试运行的细节视图。这可以辅助技术用户，例如，当规则与预期性能不同时调试问题。

根据另一个实施例，规则测试方案可以导入和导出到电子表格。例如，在一些实施例中，全部规则包可以与辅助的测试方案和测试数据一起导入或导出。在一些实施例中，用户还可以导入或导出单个的测试方案。例如，将单个测试方案导出为XLS格式，使得用户在电子表格中编辑测试数据的行，或者从另外的源生成测试套件数据(例如，编写工具以从外部数据库中提取真实的客户数据并建立XLS文件)。

根据本发明的一个方面，企业可以使用规则测试为联络中心建立模拟系统，以评估联络中心规则变更而产生的影响。该评估的影响可以与联络中心性能(例如，代理占用、代理日程表与通信量之间的配合、放弃率等)、业务影响等类似信息相关联。在一个实施例中，该联络中心可以使用例如细节报表或者应用程序日志来捕获历史交互流量的细节(例如，昨天的入站呼叫)。还可以获得相同时期的员工日程表细节(可能包括分配的活动和活跃的技能)，并且可以对其更新以反映现实的依从性。单个的员工文件也可以获得，该文件可以显示处理时间特征(包括平均时间、方差等类似信息)。

就此而言，联络中心将与历史交互相关的数据(例如，相关联的客户群组、该交互请求的服务类型、该交互发生的时间、平均处理时间、该客户被保持的平均时间，等等)、与处理交互的员工相关的数据(例如，技能设置、日程信息、处理时间)、路由策略和响应于该交互的业务规则(例如，与向上销售或交叉销售报价相关的规则)以及运行模拟可用的其它数据存储在一个或多个大容量存储装置30中。

根据一个实施例，该信息可以用于建立模拟系统，其中自动呼叫通信量是根据之前记录的通信量生成。在这方面，联络中心管理员可以从他/她的装置38c中调用模拟应用程序，并通过该装置提供一个或多个模拟参数以生成该模拟系统。例如，该管理员可以选择：过去通信量较大的时间段用以模拟、时间分布用以模拟、服务类型以及客户群。根据一个实施例，该管理员可以对该模拟做更多的细节控制，并且可以模拟例如客户耐心、代理在向上/交叉销售报价方面的成功率以及类似细节。根据一个实施例，该管理员还可以选择该模拟为之运行的单个规则、规则集或者规则包。所选择的规则(规则集、规则包)是在历史交互没有应用的规则，需要对这些规则进行模拟以评估将该规则部署到规则引擎上的效果。

然后，响应于用户指令调用该模拟系统。该指令可以是例如根据模拟参数评估选定的规则包。响应于该指令，从上述一个或多个存储装置中检索历史交互的日志，并且根据该历史交互的日志生成通信量。该模拟系统可以调用代理模拟应用程序(例如，软件)以响应于上述模拟的交互(例如，回应呼叫)。该代理模拟器可以配置为复制单个代理特征，并且可以根据捕获的日程数据被激活。该系统可以与前一天的操作所使用的一样的联络中心路由逻辑、IVR脚本和类似数据。可以做进一步的改进，例如建模单个客户耐心(例如，客户在队列中等待的时长)以及单个员工抓住商业机会的成率，例如，跨部门或品牌的交叉销售的处理或者对某些客户的向上销售的处理。

一旦该模拟系统建成后，根据示例性实施例，该企业可以以不同规则集执行测试，并且对比结果。联络中心性能和效率可以根据一些标准进行评估，例如，员工的占用、任务调度与通信量流量之间的关系、放弃率和业务成果(例如，交叉/向上销售处理量)。根据该模拟和评估，该模拟和评估分析的特定规则包被部署或者不部署。

根据另一方面，可以由模拟系统为联络中心测试其它相关属性。例如，用户能够激活以及不激活在交互路由中使用的特定雇员技能。同样的，调整技能分配可以提高效率。例如，雇员通常具有不同熟练程度的多种技能。如果雇员被分配到适于他的辅助技能的任务，处理过程可能较长，并且该雇员也不能处理适于他的主要技能的任务。另一方面，需要交叉技能激活，因为它允许联络中心处理适于特定技能的临时高峰通信量，而不需要雇用更多的员工。技能分配还可以通过修改进入的交互类型到雇员技能的映射规则进行行政上的改变。

根据本发明的另一个方面，可以使用模拟环境创建联络中心的缺陷的目录，同时创建相应的解决方案或处理方法。根据本发明实施例的规则测试提高了联络中心建立类似模拟系统和环境的能力，因为它降低了改变路由策略的要求，而改变路由策略较困难且需要专门软件知识。相反，业务用户可以处理更加简易的配置规则来评估联络中心效率和性能。

图15R是根据本发明实施例的搜索窗口的屏幕截图。业务用户会使用一个或多个条件搜索。这种搜索是非常有益的，例如，如果业务用户通过测试判定某参数(例如，年龄参数)没有正确配置。该用户可以接着搜索所有包括年龄参数的业务规则，如图15R所示，从而识别出所有可能返回错误信息的业务规则。

根据本发明的另一方面，从工作源捕获的数据可以用于规则系统进行设定优先级、重新安排优先测序以及根据技能分配任务。图16A-16I是根据本发明实施例的描述使用GRS根据技能设定优先级、重置优先级和分配任务的屏幕截图。图16A是为智能工作流分配而创建的业务规则的描述。根据一个实施例，企业网站上的每个网页表格都有网页表格ID。例如，图7C中所示的网页表格具有网页表格ID 4717，是与服务请求相关联的网页表格ID。图16A中，根据网页表格ID 4714，该规则系统判定请求类型为服务请求，该请求类型属于销售部门处理，然后将该任务分配到销售部门。选择销售部门链接后，如图16B所示，显示另一组规则。这里，对于任务来说只有当给定业务流程之后，业务用户才可以为该任务设定到期日期和业务任务和优先级值。在图16C中，业务流程和请求类型都已经给定，该业务用户能够为该任务设定到期日期和业务任务和优先级值。

根据本发明的一个方面，业务用户可以通过向规则添加条件配置更多具有更高性能的规则。如图16D所示，业务用户可以通过从附加条件下拉菜单中选择来添加到给定规则中。例如，在图16E中，业务用户添加了“客户群”条件，这样，当该业务流程是销售部门中的服务请求时，该请求类型是地址变更，客户群是黄金，任务到期日期设置为10分钟并且该业务任务和优先级值均设置为655。在图16F中示出了另一种可能的情况，显示了将条件信道添加到规则中。如图16G所示，信道条件作为下拉菜单选项显示给业务用户。因此，业务用户可以根据交互来自哪个信道给该交互分配不同的到期日期、商业值和优先级值。例如，从电子邮件接收的任务相对于从信件来的任务分配较高的优先级，从而鼓励使用电子邮件而非信件。

根据另一方面，可以使用规则系统为任务重置优先级。例如，在图16H中，示出了为没有过期的任务重置优先级的规则。根据一个规则，对于到期时间在4分钟到9分钟之间的任务，每过3分钟优先级增加1。因此，该任务每3分钟被重置一次优先级。随着到期日期的靠近，该任务可以被更频繁地重置优先级。

此外，可以向业务规则添加活动。如图16I所示，业务用户点击了添加活动图标并且从下拉列表中选取活动。在该实施例中，该业务用户指定该业务规则判断完成任务需要哪些目标技能，并且将请求具有所需的特定技能(例如，某种语言或某种产品知识)的员工。

因此，如图16A-16I所示，业务规则的参数和条件可以使用从外部源获得的数据，从而对任务设定优先级、重置优先级并且判断需要哪种技能。根据其它实施例，业务用户可以根据完成任务的过程的复杂程度来设定任务优先级。例如，需要3个步骤完成的任务相对于仅需要1个步骤完成的任务可以设定更高的优先级。

正如本发明在这里通过示例性实施例所描述的，很多修改和变化对本领域技术人员来说都是显而易见的。因此，应当理解这里所描述的发明可以具体呈现为这里特定描述以外的形式。

例如，尽管这里所描述的系统和方法用于分配延迟媒体(例如，电子邮件、信件、传真、社交媒体或内部生成的任务)，但是本发明的实施例的各方面可以扩展到实时媒体(例如，语音呼叫或者聊天回话)。

Claims (34)

1.一种用于联络中心的工作量分配的方法，所述方法包括以下步骤：

根据分派的分配标准识别用于分配的工作项；

识别用于为所述工作项规定路线的目标；

判定所述目标的可用性；

响应于判定所述目标可用，为所述工作项传送路由请求到路由服务器，其中响应于所述请求，所述路由服务器被配置为独立地判定所述工作项的可用性以将所述工作项路由至所述目标；和

响应于判定所述目标不可用，停止为所述工作项将所述路由请求传送至所述路由服务器。

2.根据权利要求1所述的方法，其中，所述分配标准包括所述工作项的优先级值、商业价值、创建日期或者到期日期中的至少一个。

3.根据权利要求1所述的方法，其中，为路由所述工作项而识别所述目标的步骤包括接收对特定目标的请求。

4.根据权利要求1所述的方法，其中，为路由所述工作项而识别所述目标的步骤包括评估与目标的占用、技能或位置相关的信息。

5.根据权利要求1所述的方法，进一步包括：

评估所述判定的可用性以识别用于为所述工作项规定路线的所述目标。

6.根据权利要求1所述的方法，其中，所述判定所述目标的可用性的步骤包括识别所述目标处理所述工作项的能力。

7.根据权利要求1所述的方法，其中，所述工作项在第一服务器中处于排队状态，并且其中，响应于所述请求，所述工作项被从所述第一服务器中的所述排队状态中移除并被放置于所述路由服务器中的排队状态。

8.根据权利要求7所述的方法，其中，所述第一服务器和所述路由服务器通过局域网连接。

9.根据权利要求1所述的方法，其中，响应于对所述目标不可用的判定，为所述工作项修改分配标准。

10.根据权利要求9所述的方法，其中，所述修改所述分配标准的步骤包括修改所述工作项的优先级。

11.根据权利要求1所述的方法，其中，所述工作项是与终端用户的非电话交互。

12.一种用于联络中心的工作量分配的系统，所述系统包括：

处理器；和

存储器，其中所述存储器存储指令，所述指令在由所述处理器执行时使得所述处理器：

根据分派的分配标准识别用于分配的工作项；

识别用于为所述工作项规定路线的目标；

判定所述目标的可用性；

响应于所述目标可用的判定，传送所述工作项的路由请求到路由服务器，其中响应所述请求，所述路由服务器被配置为独立地判定所述工作项的有效性以路由所述工作项到所述目标；和

响应于判定所述目标不可用，停止将所述工作项的所述路由请求传送至所述路由服务器。

13.根据权利要求12所述的系统，其中，所述分配标准包括所述工作项的优先级值、商业价值、创建日期或者到期日期中的至少一个。

14.根据权利要求12所述的系统，其中，所述识别为所述工作项规定路线的所述目标的步骤包括接收用于特定目标的请求。

15.根据权利要求12所述的系统，其中，所述识别为所述工作项规定路线的所述目标的步骤包括评估与目标的占用、技能或位置相关的信息。

16.根据权利要求12所述的系统，进一步包括：

评估所述判定的可用性以识别用于为所述工作项规定路线的所述目标。

17.根据权利要求12所述的系统，其中，所述判定所述目标的可用性的步骤包括识别所述目标处理所述工作项的能力。

18.根据权利要求12所述的系统，其中，所述工作项在第一服务器中处于排队状态，并且其中，响应于所述请求，所述工作项被从所述第一服务器中的所述排队状态移除并被放置于所述路由服务器中的排队状态。

19.根据权利要求18所述的系统，其中，所述第一服务器和所述路由服务器通过局域网连接。

20.根据权利要求12所述的系统，其中，响应于判定所述目标不可用，为所述工作项修改所述分配标准。

21.根据权利要求20所述的系统，其中，所述修改所述分配标准的步骤包括修改所述工作项的优先级。

22.根据权利要求12所述的系统，其中，所述工作项是与终端用户的非电话交互。

23.一种用于评估联络中心中的规则变化的影响的方法，所述方法包括以下步骤：

配置所述规则的一个或多个参数；

接收评估所述规则的指令；

检索终端用户与所述联络中心之间的历史交互的日志，其中所述历史交互的日志反映所述规则部署前的交互；

根据所述规则处理所述历史交互中的一个或多个；

模拟所述一个或多个历史交互的结果；和

根据所述模拟部署或者不部署所述规则到规则引擎。

24.根据权利要求23所述的方法，其中，所述历史交互的日志包括与历史交互的通信量、活跃的技能和交互处理时间相关的信息。

25.根据权利要求23所述的方法，进一步包括：

分析所述历史交互的日志以评估联络中心效率。

26.根据权利要求23所述的方法，进一步包括：

判定新规则变化，其中所述新规则变化调节用于分派工作项的路由策略。

27.根据权利要求26所述的方法，其中，所述新规则变化基于所述模拟以及所述联络中心效率评估。

28.一种用于评估联络中心中的规则变化的影响的系统，所述系统包括：

一个或多个处理器；和

一个或多个存储装置，所述一个或多个存储装置连接到所述一个或多个处理器且存储程序指令，所述程序指令在由所述一个或多个处理器执行时使得所述一个或多个处理器：

配置所述规则的一个或多个参数；

接收评估所述规则的指令；

检索终端用户与所述联络中心之间的历史交互日志，其中所述历史交互日志反映所述规则部署前的交互；

根据所述规则处理所述历史交互中的一个或多个；

模拟所述一个或多个历史交互的结果；和

根据所述模拟部署或者不部署所述规则到规则引擎。

29.根据权利要求28所述的系统，其中，所述历史交互日志包括与所述历史交互通信量、活跃技能和交互处理时间相关的信息。

30.根据权利要求28所述的系统，其中，所述历史交互日志提供了用于评估联络中心效率的信息。

31.根据权利要求28所述的系统，其中，所述规则系统被配置为定义新规则变化，其中所述新规则变化调节用于分派工作项的路由策略。

32.根据权利要求31所述的系统，其中，所述新规则变化基于所述模拟和所述联络中心效率评估。

33.一种参照附图基本上如前所述的系统。

34.一种参照附图基本上如前所述的方法。