CN106797382B - 用于呼叫中心的预期动态客户分组的系统和方法 - Google Patents

Abstract

本发明公开了一种用于与单个交互路由相对的基于事件的路由的系统和方法。处理器打开客户数据库中的事件。事件与具有预期为该事件执行的步骤的工作流相关联。处理器识别工作流的第一步骤和第二步骤，并进一步识别具有用于处理第一步骤和第二步骤的技能的代理。处理器生成用于处理工作流的至少第一步骤的任务，并发送指令以将该任务路由到识别的代理。

Description

用于呼叫中心的预期动态客户分组的系统和方法

背景技术

以客户为中心的组织需要将它的操作和它的客户智能无缝地集成，以确保对客户的完整且可控的360度观看。每次交互通常被看作是通过出众的服务提高客户体验的机会，从而产生更高的满意度、忠诚度和保留。如果做得恰当，这既能在基于营利的也能在基于非营利的企业和服务中产生更大的成功。

为此，本领域公知的是提供基于云的、基于预设条件的或者混合的(云-预设条件)客户交互管理平台，其可以处理与各种类型资源(例如，呼叫中心代理、后台、专家/知识工作者、分支机构、自助操作、外包操作，等等)的多种类型的入站和出站交互(例如，传统语音、IP语音、电子邮件、网页聊天/IM、SMS/MMS、视频、传真、自助服务的其它工作项目，等等)。客户可以通过该平台与不同类型的工作人员(例如，呼叫中心代理、知识工作者、后台工作者，等等)及横跨多个信道(例如，呼叫中心/IVR、主动参与、网页、社交媒体、移动终端，等等)进行交互。

在一个实施例中，客户交互管理平台集成了呼叫中心、代理站以及可选地还集成客户关系管理(CRM)服务器。典型地，呼叫中心、(多个)代理站以及客户关系管理服务器通过一个或多个网络连接，该网络可以是互联网、专用网络或者电话网络。客户关系管理服务器可以物理上位于呼叫中心内且通过第三方维护，或者远离该呼叫中心定位并仍由第三方操作。呼叫管理的终端用户交互例如被从CRM服务器路由，用以通过呼叫中心代理处理。在一个典型的操作方案中，呼叫中心实现并维护基于对象的代理状态模型，该状态模型包括如代理识别、工作流分配、媒体性能说明以及与通信和媒体单元相关的状态要素之类的数据。当代理继续接收或者发起交互以及使用一个或多个多媒体应用程序与终端用户通信时，该代理状态模型的要素被动态地并实时地更新。

交互的路由通常涉及发送控制信号(与通常不被路由的交互自身的媒体部分相对照)到一个或多个代理队列。可以存在与各种类型的交互相关联的队列，也可以存在与代理的技能或者其它属性相关联的专用队列。通常，路由逻辑根据配置逻辑，例如最长空闲代理、最小占用代理、技能等级等等，将交互分配到代理。在可选的方案中，交互被路由到代理队列，其中所述交互被与其相关联的可用代理拾取，并且该代理具有合适的技能等级和可用性以提供与该客户的所需的通信。可以实现混合的方案，其中代理具有与其关联的个人工作框，可延期的交互(例如电子邮件，或者例如答复客户信件、主动联系客户等的其它任务)可以被放入该工作框内；在这种模式中，代理通常有一定的自由决定他或她下一个要处理的任务。代理使用工作框存储他们已经开始处理的以及期望稍后继续处理的交互。交互还可以通过路由服务器被分配到工作框。尽管工作框通常与特定的代理相关联，但是工作框像保存有交互的队列。共享组工作框可以被一组或者相同位置中的多个代理使用。代理可以查看工作框中的内容并以任意顺序从其中提取交互。因此，在代理具有选择交互的灵活性的方案中，通常该代理可以查看关于包含被分配给他们处理的全部交互的队列的一些细节(例如，队列中交互的数量或者平均等待时间的统计，或者服务等级，等等)。尽管代理可以具有与被识别的或可见的交互进行交互的机会，但是队列中的交互的处理通常是自动的。在后一种情况中且当给定选择(可能由服务等级或其它策略限制)时，代理可以选择拾取最容易解决的交互或者他或她最熟悉的联系人。通常，代理为特定的活动/任务受到训练，对于其中一些活动/任务，代理可以根据例如在给定的时间点可用或不可用的指定的“技能”属性安排处理。此外，当特定客户交互进行时，由于第一代理不能处理客户的需求或者由于其它原因，客户可以从一个代理被交接到另一个或者如业务处理工作流规定的那样。尽管有时需要代理切换，但是需要避免或者降低环境切换的影响，尤其是给定代理知道先前的呼叫历史并且还可以处理预期的后续步骤的情况中。

在传统的交互中，呼叫中心代理分配逻辑优选地将入站交互路由到系统判定为“最佳”或者目标代理的代理。该代理通常是根据一个或多个标准，例如可用性、占用率、静态的客户分组、优先级、处理给定媒体类型交互的所需技能、代理能力、客户交互历史(例如，最后的代理路由)以及其它标准，例如向上行销或交叉行销的机会、代理技能以及类似标准被选择或者限定的。

尽管这些技术运行良好，但是期望提供增强的呼叫中心路由策略。

发明内容

本发明的实施例涉及一种用于呼叫中心中的基于事件的路由的系统和方法。处理器在客户数据库中打开事件。事件与具有预期为事件执行的步骤的工作流相关联。处理器识别工作流的第一步骤和第二步骤，还识别具有用于处理第一步骤和第二步骤的技能的代理。处理器生成用于处理工作流的至少第一步骤的任务，并发送指令以将任务路由到识别的代理。

根据一个实施例，事件为包括出现在事件中的交互的历史的记录。

根据一个实施例，事件与事件ID相关联，并且用于路由任务的指令包括事件ID。

根据一个实施例，处理器根据事件ID检索与事件关联的交互的历史，并且为识别的代理在代理装置上显示交互的历史。

根据一个实施例，处理器生成用于处理工作流的第二步骤的第二任务，并且传送指令以将第二任务路由到识别的代理。

根据一个实施例，处理器监测触发事件，其中任务的生成步骤是根据检测到触发事件的出现。

根据一个实施例，触发事件是在两个工作流步骤之间经过设定的时间段。

根据一个实施例，触发事件是预设的日期。

根据一个实施例，处理器检索与事件关联的客户所属于的第一客户分组的识别。第一客户分组与呼叫中心的第一目标相关联。处理器预测代理根据第一客户分组处理任务的结果。处理器还根据预测的结果识别第二客户分组，并且将客户重新关联到第二客户分组。根据一个实施例，第二客户分组与不同于第一目标的呼叫中心的第二目标相关联。随后根据第二目标而非第一目标来处理该任务。

根据一个实施例，处理器识别呼叫中心的第一目标和第二目标，其中第一目标被识别为比第二目标对呼叫中心更重要。处理器确定代理具有用于实现第一目标的技能，并确定第一代理实现第一目标的成功可能性。处理器还识别用于处理第二目标的第二代理，其中第二代理也具有用于处理与该事件关联的工作流的第一步骤和第二步骤的技能。处理器确定第二代理实现第二目标的成功可能性，其中通过第二代理实现第二目标的成功可能性高于通过代理实现第一目标的成功可能性。处理器发送指令，以将任务路由到第二代理，并提示第二代理继续处理第二目标。

本发明的上述和其它特征、方面和优点将结合下面的详细说明、所附的权利要求以及附图得到更完整的理解。当然，通过所附的权利要求限定本发明的实际范围。

本发明实施例涉及一种用于增强呼叫中心中的交互处理的系统和方法。据此，处理器检测与客户的待处理交互。响应于检测到待处理交互，处理器检索客户所属于的第一客户分组的识别。第一客户分组与呼叫中心的第一目标相关联。处理器预测待处理交互的结果，并且根据预测的结果识别第二客户分组。处理器将客户重新关联到第二客户分组，其中第二客户分组与不同于第一业务目标的呼叫中心的第二目标相关联。处理器根据第二目标而非第一目标来处理待处理交互。

根据一个实施例，预测待处理交互的结果的步骤包括通过处理器预测呈现给客户的业务机会的结果。业务机会可以是产品或者服务的交叉行销机会或者向上行销机会。

根据一个实施例，处理器评估与待处理交互相关联的多个因素，其中第二客户分组的识别步骤是根据评估的因素。

根据一个实施例，待处理交互的预期的结果与第二客户分组的标准组相匹配。

根据一个实施例，预期的结果与呼叫中心的第二目标相关。

根据一个实施例，第二目标包括不包括在第一目标中的业务机会。

根据一个实施例，待处理交互用于实现与事件相关联的工作流的步骤，其中为处理待处理交互选择的代理是具有处理工作流的下一个步骤的技能的代理。

根据一个实施例，第二客户分组还与第三目标相关联，其中第二目标被识别为比第三目标对呼叫中心更重要。处理器识别用于处理第二目标的第一代理，并且确定第一代理实现第二目标的成功可能性。处理器识别用于处理第三目标的第二代理，并且确定第二代理实现第三目标的成功可能性。在通过第二代理实现第三目标的成功可能性高于通过第一代理实现第二目标的成功可能性的情况下，处理器发送指令以将待处理指令路由到第二代理。处理器还提示第二代理继续处理第二目标。

本发明的上述和其它特征、方面和优点将结合下文的详细说明、所附的权利要求和附图得到更完整的理解。当然，通过所附的权利要求限定本发明的实际范围。

本发明的实施例涉及一种用于增强呼叫中心中的交互处理的系统和方法。处理器检测与客户的待处理交互。响应于检测到待处理交互，处理器识别呼叫中心的第一目标和第二目标，其中第一目标被识别为比第二目标对呼叫中心更重要。处理器识别用于处理第一目标的第一代理，并且确定第一代里实现第一目标的成功可能性。处理器识别用于处理第二目标的第二代理，并且确定第二代理实现第二目标的成功可能性。在通过第二代理实现第二目标的成功可能性高于通过第一代理实现第一目标的成功可能性的情况中，处理器发送指令以将待处理交互路由到第二代理。处理器还提示第二代理继续处理第二目标。

根据一个实施例，第一目标与第一业务结果相关联，第一业务结果被确定为比与第二目标相关联的第二业务结果对呼叫中心更可取。

根据一个实施例，业务结果与呼叫中心的利润、税收或者销售相关。

根据一个实施例，业务结果与客户满意度相关。

根据一个实施例，根据对第一代理或第二代理与第一目标和第二目标相关的历史表现的分析确定第一代理或第二代理实现第一目标或第二目标的可能性。

根据一个实施例，第二目标与呈现给客户的业务机会相关联。业务机会可以是产品或者服务的交叉行销机会或者向上行销机会。

根据一个实施例，待处理交互用于实现与事件关联的工作流的步骤，并且为处理待处理交互选择的代理是具有处理工作流的下一个步骤的技能的代理。

根据一个实施例，响应于检测到待处理交互，处理器检索客户所属于的第一客户分组的识别，其中第一客户分组与呼叫中心的第三目标相关联。处理器预测待处理交互的结果，并且根据预测的结果识别第二客户分组。处理器将客户重新关联到第二客户分组。根据一个实施例，第二客户分组与第二目标相关联。

本发明的上述和其它特征、方面和优点将结合下面的详细说明、所附的权利要求以及附图得到更完整的理解。当然，通过所附的权利要求限定本发明的实际范围。

附图说明

为了对公开的主题及其优点更完整的理解，参考结合附图的下述说明，其中：

图1为本文说明的技术可以在其中实施的客户交互管理平台的框图；

图2为根据本发明的一个实施例的呼叫中心系统的框图；

图3为本文说明的技术可以在其中实施的基于电话的计算基础设施(例如呼叫中心)的框图；

图4为在其中使用客户交互管理平台的可选的基于SIP环境的框图；

图5为一个实施例中的本发明的技术可以在其中一个环境中实施的混合(预设-云)环境的详细框图；

图6为本发明的技术可以在其中实施的另一个基于混合云的通信系统的详细框图；

图7为显示根据本发明的动态客户分组路由方案的流程图；

图8A-8B为根据本发明的用于自适应业务目标路由的过程的流程图；

图9为显示根据本发明的事件路由方案的视图；

图10为显示如何同时或者顺序地执行两个或更多个路由策略以增强呼叫中心代理分配逻辑的流程流；

图11A为根据本发明的一个实施例的计算装置的框图；

图11B为根据本发明的一个实施例的计算装置的框图；

图11C为根据本发明的一个实施例的计算装置的框图；

图11D为根据本发明的一个实施例的计算装置的框图；和

图11E为根据本发明的一个实施例的包括多个计算装置的网络环境的框图。

具体实施方式

概括地说，本发明的实施例涉及客户交互管理平台，所述平台使用一组一个或多个交互路由策略确定哪个代理应当接收并处理特定的呼叫。该平台包括代理分配机制，该机制被扩大为实现一组路由方案中的一个或多个。第一路由方案主动调整代理分配机制针对其执行的客户服务级别。第二路由方案在给定交互期间使用该代理分配机制运行，以自动调整应当由可用代理处理哪一组业务目标。第三路由方案向代理分配机制提供与促进该分配的方案相关联的一个或多个参数。这些路由策略可以全部或者部分地同时或顺序地实施。

所述一个或多个路由策略可以包括“动态客户分组”策略，该策略提供对客户的现有客户分组(例如，金牌、银牌、铜牌，等等)的评估或者先验的重新评估，然后根据该分析和处理给定客户交互的预期结果确定该客户的(对于新的交互)客户分组关联性应当被升级还是降级。如果，例如，该预期的结果将客户升级到下一个更高的分组，那么可以根据该更高等级分组的策略处理当前交互。客户分组关联性的升级或降级可能依赖于环境，并且在每个交互基础上或者跨多个交互时期实施。

另一个路由策略实现“自适应业务目标”策略，通过该策略代理分配部分地基于代理分配处理期间调整业务目标(BO)而非依赖于预先定义或配置的固定或静态业务目标。在该方法中，业务目标由两个部分组成：交互原因(可能通过IVR对话改进)，以及根据已知的客户配置文件变化的一组业务机会(例如，交叉/向上行销意图)。考虑这些因素，随后为客户限定一组业务目标。在代理选择过程期间，路由逻辑试图找到用于处理两个部分的最佳匹配代理，并且从第一(最佳)业务目标开始。如果找不到这种代理，则将使用下一个最佳BO，依此类推直到根据该(潜在调整的)BO找到合适的代理处理该交互为止。随后根据特定代理处理特定BO的成功可能性来对BO-代理对进行排名。根据一个实施例，选择具有最高排名的代理，并且将交互路由到该代理以处理关联的BO。

另一个路由策略实现至少部分地基于与交互关联的“事件记录”确定的“事件路由”策略，例如(但不限于)来自CRM的交互。CRM系统或服务器或者任何其它客户数据库系统(统称为CRM系统)可以是呼叫中心的部件或者与其关联，其将(它的一个客户与系统之间的)客户支持交互模型化为“事件”。事件(或者“任务”)具有关联的包含识别事件的给定信息的事件记录、事件类型、(通过一组限定的或有序的步骤)潜在决议的预期工作流、预期定时、逐步升级路径以及类似物。根据事件来源的CRM系统，事件可以根据客户支持问题的性质与特定模板关联。事件路由中，与事件关联的事件记录用于影响应当识别呼叫中心中的一组代理中的哪个代理处理该事件。非限制地，根据一个或多个因素选择最佳代理或者目标代理，所述因素例如为(通过事件工作流限定的)事件的处理中特定的下一个交互或步骤的特性、(例如，基于根据工作流的预定步骤、和/或根据特定步骤的预期结果的动态调整，等等)给定事件的一个或多个预期的未来交互并且该未来交互优选地由相同代理处理、该事件的一个或多个先前执行的交互的存在，包括是否有任何这种交互被重新打开、保留该事件的完成时间以及类似物。

根据本发明的特征，上述路由技术既可以单独使用也可以一起使用。因此，在一个实施例中，动态客户分组策略与自适应业务目标策略或事件路由相关联地实现。在另一个实施例中，自适应业务目标策略与事件路由关联地实现。另一个可替换方案是关联(合并)上述全部三个策略。这些路由策略可以全部或者部分地同时(同步地)或者顺序地(异步地)执行。

图1显示可以基于云、基于预定条件或者混合实现的客户交互管理平台100。该平台可以通过专用服务提供商操作，但这不是必须的。通常，平台100处理全部类型的交互，无论是入站或者出站的。如上文的说明，这些交互包括、但不限于语音、电子邮件、网页、聊天/IM、SMS、视频、传真/工作项以及其它。交互涉及多种来源，例如呼叫中心、外包商、后台、专家(知识工作者)、分支机构、自助功能或者类似项。优选地，该平台实现框架，该框架包括一组操作层，例如提供配置、数据完整性控制、访问控制和运行时间通知的配置层、允许客户监控在该平台中执行的应用程序的行为和状态(例如，方案控制、报警处理、故障诊断以及故障管理)的管理层、提供外部接口、使应用程序能够独立切换以及提供数据分配的媒体层，以及提供状态和统计的服务层。

图2为根据本发明的一个示例性实施例的用于支持呼叫中心提供呼叫中心服务的系统的示意性方框图。呼叫中心可以是企业或公司的内部设备，用于在执行与通过该企业可获得的产品和服务相关的销售和服务功能来服务于该企业。在另一方面中，呼叫中心也可以是第三方服务提供商。呼叫中心可以部署在专用于该企业或者第三方服务提供商的设备中和/或部署在远程计算环境中，例如，举例来说，具有用于支持多个企业的多个呼叫中心的基础设施的私人或公共云环境。呼叫中心的多种部件还可以被分布在多个地理位置和计算环境，而不必须包含于单个位置、计算环境甚至计算装置中。

根据一个示例性实施例，呼叫中心包括能够通过电话或其它通信机制传送服务的资源(例如，人员、计算机和电信设备)。这些服务可以根据呼叫中心类型进行改变，并且范围可以从客户服务到帮助台、应急响应、电话销售、订单处理以及类似服务。

期望从呼叫中心接收服务的客户、潜在客户或其他终端用户(统称为客户)可以通过他们的终端用户装置10a-10c(统称为10)向呼叫中心发起入站呼叫。终端用户装置10中的每一个可以是本领域常用的通信装置，举例来说，例如电话、无线电话、智能电话、个人电脑、电子输入平板和/或类似装置。操作终端用户装置10的用户可以发起、管理以及响应电话呼叫、电子邮件、聊天、文本消息、网页浏览会话以及其它多媒体事务。

来自终端用户装置10的入站呼叫和送至终端用户装置10的出站呼叫可以根据正在使用的装置的类型穿过电话、蜂窝网和/或数据通信网络14。例如，通信网络14可以包括私人或公共交换电话网络(PSTN)、局域网(LAN)、私人广域网(WAN)和/或公共广域网，举例来说，例如互联网。通信网络14还可以包括无线载波网络，所述无线载波网络包括码分多址(CDMA)网络、全球移动通信系统(GSM)网络和/或本领域常见的任意3G或4G网络。

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

呼叫中心还可以包括多媒体/社交媒体服务器，用于进行与终端用户装置10和/或网络服务器32的语音交互以外的媒体交互。媒体交互可以与例如电子邮件、语音邮件(通过电子邮件发送的语音邮件)、聊天、视频、文本消息、网页、社交媒体、浏览共享以及类似形式相关。网络服务器32可以包括例如社交交互网站主机，用于终端用户可以订阅的各种已知的社交交互网站，举例来说，例如Facebook、Twitter以及类似网站。网站服务器还可以为呼叫中心正在支持的企业提供网页。终端用户可以浏览网页并获得关于企业的产品和服务的信息。网页还可以通过例如网页聊天、语音呼叫、电子邮件、网页实时通信(WebRTC)或类似方法提供用于联络呼叫中心的机制。

根据本发明的一个示例性实施例，交换机连接到交互式媒体应答(IMR)服务器34，该IMR服务器还可以被称为自助系统、虚拟助手或类似名称。除了IMR服务器不受限于语音之外，IVR服务器34可以与交互式语音应答(IVR)服务器相似，但是可以覆盖包括语音在内的多种媒体信道。然而，以语音为例，IMR服务器可以与IMR脚本一起配置用于询问发出呼叫的客户的需求。例如，银行呼叫中心可以通过IMR脚本告诉呼叫者，如果他们希望获得账户余额，则“按1”。如果是这种情况，客户可以通过与IMR的持续交互完成服务而不需要与代理通话。IMR服务器34还可以提出开放式问题，举例来说，例如“我可以帮忙做些什么？”，客户可以说出或者以其它方式输入原因以与呼叫中心联络。用户的回应接着可以由路由服务器20使用，以将该呼叫路由到合适的呼叫中心资源。

如果呼叫将被路由到代理，则呼叫被传送到呼叫服务器18，该呼叫服务器与路由服务器20交互以找到用于处理该呼叫的合适的代理。呼叫服务器18可以被配置为处理PSTN呼叫、VoIP呼叫以及类似呼叫。例如，呼叫服务器18可以包括会话初始化协议(SIP)服务器以处理SIP呼叫。根据一些示例性实施例，呼叫服务器18可以例如提取与客户交互相关的数据，例如呼叫者的电话号码(通常称为自动号码识别(ANI)号码)或者客户的互联网协议(IP)地址或电子邮件地址。

在一些实施例中，路由服务器20可以查询客户数据库，该客户数据库存储有与现有客户相关的信息，例如联络信息、服务等级协议(SLA)需求、先前客户联络的种类和呼叫中心处理任意客户问题所采用的动作以及类似信息。该数据库可以由本领域常用的任意数据库管理系统管理，例如Oracle、IBM DB2、微软SQL服务器、Microsoft Access、PostgreSQL、MySQL、FoxPro以及SQLite，并且可以存储在大容量存储装置30中。路由服务器20可以通过ANI从客户数据库查询客户信息或者查询由IMR 34收集的任何其它信息，并通过呼叫服务器18发送到路由服务器。

一旦有合适的代理可以处理呼叫，则在呼叫者与被识别的代理的代理装置38a-38c(统称为38)之间建立连接。收集的关于呼叫者的信息和/或呼叫者的历史信息也可以被提供给代理装置以帮助代理更好地服务呼叫。就此而言，每一个代理装置38都可以包括适用于普通电话呼叫、VoIP呼叫以及类似呼叫的电话。代理装置38还可以包括计算机，所述计算机用于与呼叫中心的一个或多个服务器通信并执行与呼叫中心操作相关联的数据处理以及用于通过语音或其它多媒体通信机制与客户相连接。

对用于路由入站呼叫的合适代理的选择可以根据例如路由服务器20采用的路由策略，还可以依据与代理可用性、技能和其它由例如统计服务器22提供的路由参数相关的信息。

呼叫中心还可以包括被配置为由统计服务器22聚集的数据生成报表的报表服务器28。这种报表可以包括关于资源状态的近实时报表或历史报表，举例来说，例如平均等待时间、放弃率、代理占用率以及类似报表。报表可以自动地或响应于请求者(例如，代理/管理员、呼叫中心应用程序和/或类似请求者)的特别请求生成。

根据本发明的一个示例性实施例，路由服务器20因具有用于管理分配给代理的后台/离线活动的功能而得到增强。这种活动可以包括例如答复电子邮件、答复信件、参加培训班或者不需要与客户实时通信的任意其它活动。一旦分配给代理，活动可以被推送给该代理或者可以显示在该代理的工作框26a-26c(统称为26)中以作为要由该代理完成的任务。该代理的工作框可以通过本领域常用的任意数据结构实现，举例来说，例如链表、阵列和/或类似数据结构。该工作框可以保持在例如每一个代理装置38的缓存中。

根据本发明的一个示例性实施例，(多个)大容量存储装置30可以存储与代理数据(例如，代理配置文件、进度表，等等)、客户数据(例如，客户配置文件)、交互数据(例如，与客户的每个交互的细节，包括交互原因、处置数据、保持时间、处理时间，等等)以及类似数据相关的一个或多个数据库。根据一个实施例，所述数据中的一部分(例如，客户配置文件数据)可以由第三方数据库提供，举例来说，例如第三方客户关系管理(CRM)数据库。大容量存储装置可以采用本领域常用的硬盘或盘阵列的形式。

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

在多个实施例中，术语交互一般用于指使用任意通信信道(包括，但不限于，电话呼叫(PSTN或者VoIP呼叫)、电子邮件、语音邮件(通过电子邮件发送的语音邮件)、视频、聊天、屏幕共享、文本消息、社交媒体消息、网页实时通信(例如，网页RTC呼叫)以及类似信道)的任何实时和非实时的交互。

图3示出了根据本发明另一个实施例的与电话基础设施(例如PSTN 252)交互操作的传统客户交互管理平台250。在本实施例中，平台250包括交换机254、IVR 256、电话服务器258和一组代理工作台260。

图4示出了根据本发明一个实施例的IP语音实施例，其中客户交互管理平台300与PSTN 302和VoIP网关304交互操作，并且该实施例包括SIP服务器306、IVR 308以及基于IP的硬电话309或者基于IP的软电话310。

尽管图中没有示出，但是通常客户交互管理平台包括全部类型的标准媒体的本地支持，例如语音(TDM/VoIP)、电子邮件、聊天、浏览共享、网页形式以及其它。

图5示出了客户交互管理平台的混合的基于预设条件和基于云的实例。在本实施例中，有三个(3)预设位置402、404和406，并且这些位置中的每一个都与控制服务器408关联，其中与平台关联的代理可以与控制服务器408连接。客户通过网络交换机410连接到该台。控制服务器408与网络交换机相关联，并且被连接到执行用于交互路由的路由策略的全局路由器414。数据库服务器416提供到一个或多个数据库418的接口。交互式语音应答(IVR)单元412与网络交换机410相关联，并且IVR可以由它自己的控制服务器415控制。中央网络路由元件通常位于路由器414内，所述路由器随后可以(通过服务器408)引导网络交换机发送呼叫到IVR；一旦IVR完成呼叫，则该呼叫可以被终止或者被转发到代理。然而，也可能该呼叫被无条件地发送到IVR，在这种情况中，IVR控制服务器415决定是终止所述呼叫还是转发到代理。前一种情况有时被称为IVR后置交换机，而后一种情况被称为IVR前置。每一个控制服务器408通常提供多种控制功能，例如代理电话状态传播、呼叫控制和监测、呼叫模型统一、站点间会话协商(例如，呼叫转接、会议，等等)以及为其它应用程序提供公共消息总线。全局路由器414中的路由引擎提供策略驱动的交互流控制，该策略驱动的交互流控制在本文中称为路由策略。每一个预设条件都可以具有与其相关联的“状态”服务器420，“状态”服务器420向该平台提供全局代理状态/性能数据以及实时标准计算。配置服务器424提供动态配置管理。管理层426提供用于应用程序监测与控制、集中记录、警报和类似功能。尽管该图显示了到代理的直接网络级路由，但这并不是必须的，还可以存在多步路由(例如，从网络到站点，在站点级通过站点级路由器到代理)。

图6为本发明的技术可以在其中执行的通信环境的更详细的架构视图。在本实施例中，提供了一种集成呼叫中心、代理站和客户关系管理(CRM)服务器的系统。这仅为代表性环境，不应该作为限制。在本实施例中，通信环境200包括公共交换电话网(PSTN)202、互联网网络207以及通信或呼叫中心210。PSTN网络202可以是另一种类型或配置的电话网络。例如，网络202可以是无线网络或者无线与有线网络的组合。同样地，网络202可以是私人或公共电话网络。如果该网络是公共PSTN网络，则所述网络可以包括交换机203，交换机203可以用作服务控制点(SCP)。如果该网络是私人网络，则所述网络可以包括本地电话交换机(LSW)203，用于接收并路由该网络中的电话呼叫。LSW 203可以是自动呼叫分配器(ACD)、专用小交换机(PBX)或者也可以用作服务控制点(SCP)的一些其它呼叫交换硬件。在该实施例中，LSW 203具有通过电话中继线205到通信中心210的连接。另外，在本示例中，LSW 203通过运行电话服务器(T-S)实例的计算机-电话集成(CTI)处理器204来增强。处理器204向LSW203提供智能电话和交互能力。示例包括智能外设实时交互式语音应答系统以及其它类似性能。运行在处理器204上的电话服务器T-S的实例提供一个阵列的智能路由服务，所述服务可以与CTI和智能外设功能集成。

通信中心210具有交换机(CSW)211(例如，PBX或者ACD)，所述交换机设置在所述通信中心中且适用于从PSTN 202接收进入的电话呼叫，用于到通信中心人员和自动帮助或服务系统的内部路由的目的。当然，CSW 211也适用于出站呼叫。CSW 211可以是PBX或上文中结合LSW 203提到的其它类型的电话交换机。CSW 211通过电话中继线205连接到LSW。与LSW203类似，CSW 211也连接到运行T-S服务器实例的CTI处理器215。

优选地，处理器215使用单独的数据网络206与处理器204通信。这样，智能路由程序可以在PSTN级生成并实现，从而能够在网络级实现内部呼叫路由性能。由呼叫者请求的数据可以在实际电话呼叫之前通过使用网络206和连接的CTI处理器和T-S实例被转发到中心210。代理级路由随后可以在网络级执行并且可以通过中心210控制。

优选地，中心210具有设置在其中的局域网(LAN)218，LAN 218用于将多个工作站和系统连接在一起以用于通信。在本示例中，代理工作站522和代理工作站523被示为具有LAN连通性。工作站522包括用于通信的典型的代理设备，不限于具有视频显示单元(VDU)(例如，计算机监视器)的个人连接LAN的计算机227和代理电话226。电话226具有通过内部电话线217到CSW 211的连通性。工作站523适用于以与通过LAN连接的计算机225的方式和通过代理电话224的方式的站点522类似、但不必须完全相同的方式通信。另外的通信设备类型可以表示在站523和522内；这些通信设备类型包括、但不限于传真机、自动应答系统、其它处理终端以及其它能够使用这种网络的设备类型。代理可以是在家工作代理(在他或她的家里工作的人员)并且例如通过IP语音连接连接到呼叫中心。在一个实施例中，电话224和226可以是作为终端设备连接到各自的计算机主机的数据电话。还存在许多配置可能性以及可能的设备差异。

优选地，CTI处理器215具有LAN连接，以使具有管理权的监管员能够修改或创建新的路由程序等。处理器215和204内的T-S的功能取决于到达电话服务器库(T-服务器库)220的可达性，在本示例中，T-服务器库220连接到LAN218。优选地，库550包括所有的对象、描述符及构造以实现集成的CTI/事务智能呼叫处理。典型地，该库是使用该库用于与其它网络单元通信的服务器的嵌入部分。

非限制性的，互联网网络207是通信环境200的一部分。互联网207可以是另一种类型的广域网(WAN)。例如，网络207可以是企业或私人WAN或者城域网(MAN)。互联网网络207具有穿过其延伸的主干网209，主干网209代表将互联网网络组成为整体的设备、线路和接入点中的全部或者部分，包括任何连接的子网。如上所述，不旨在做任何地理或逻辑的限制。

在互联网207内提供或者以其它方式示出客户关系管理(CRM)服务器208，并且CRM服务器208适用于管理涉及与一个或多个企业(例如，以一个主机通信中心210为例)相关的一个或多个客户群的客户关系。CRM系统或服务208可以由第三方企业提供。第三方CRM方案可以从包括第三方客户管理服务的第三方企业的基础实现。同样地，CRM服务器208可以是客户端设备(CPE)方案的一部分，由此客户基础的全部或者特定部分与主管企业相关并且在诸如中心210的特定通信中心处内部服务。在后一种情况中，CRM服务器208可以被托管在中心210的物理区域内并连接到LAN 218。在另一个实施例中，CRM系统208可以适用于服务于同一企业的多个地域性分布的呼叫或者通信中心相关的客户基础设施。在这种情况中，可以在互联网207的区域中提供单独的但中央集中的设备，这样可以根据在每个中心处建立的策略和规则管理多个中心的客户。

在本示例中，中心210为具有互联网连通性以与客户和企业单位联络和交互的多媒体功能的通信中心。互联网协议路由器(IPR)221被设置在中心210内且具有与LAN 218的连接。IPR 221适用于从互联网207接收多媒体和通信事件，并且将这些事件通过LAN 218路由到例如为站222或223的代理站。多媒体事件可以包括电子邮件事件、网页形式的交互、IP语音交互、网页消息交互、多媒体功能或者文本聊天会话、语音邮件交互、网络会议会话以及IP电话会话。因此，有组织的信道(媒体信道)和路由系统可以适当地用于处理这些类型的网络交互或事件。在另一个实施例中，CRM系统并不直接访问代理(端点)，而是通过CRM适配器连接到服务提供商的媒体服务(例如，用于语音的

T-Server^TM、用于多媒体的

Interaction Server^TM)。同样地，可以提供一个或多个互联网服务器(图中未示出)以管理类似聊天或者网页会议的特定网络交互。这些服务器可以被假设存在于本示例中并设置在互联网207的区域内，当在线连接时，互联网207包括LAN 218。

在其它服务中，CRM系统208可以适用于提供自动的自助服务器、网页形式的服务、电子邮件服务、自动传真服务以及其它多媒体服务。同样地，来自CRM系统的后端数据可以包括历史信息；统计信息；还包括呼叫信息；以及到其它资源的链接。

在本实施例中，CC/CRM适配器系统214被设置在通信中心210内，并适用于在代理工作站或桌面等级整合CRM功能与代理和呼叫控制/管理功能。CC/CRM系统适配器214适用于使用一个或多个动态代理状态模型213提供CRM系统208和CRI-T-S功能(处理器215)之间的集成。如上所述，模型213表示代表单个代理的代理模型的集合，以及代理能力和分布在系统214的区域内的这些代理(或者在这种情况中为通过呼叫通信中心210可获得的代理)的工作任务分配。

在系统214内，优选地，呼叫中心功能和管理与CRM服务功能和管理相同被抽象化，这样使它们可以在代理级别具有图像显示功能的方便的代理用户界面中被同时管理并监测。CRM适配器系统214具有与分配至代理站的客户应用程序通信的父应用程序(图中未示出)。交互控制/代理控制(IC/AC)和CRM客户端界面228a的实例被提供在代理工作站223的区域内，并且可执行为例如来自计算机223的桌面的软件实例。IC/AC/CRM 228b的相似实例被提供在站223的区域内，并且可执行为例如来自计算机557的软件实例。

通过执行并运行实例IC/AC/CRM实例228a，在站223处操作的代理可以接收语音和媒体事件，并且同时以随从该特定代理的代理状态模型的方式向主叫方或者交互参与方提供CRM服务。站223的代理状态模型限定代理以及优选地该代理的全部(或至少一些)通信功能，包括可用于该代理的客户以及与这些客户相关的代理的CRM服务。另外，代理的模型优选地包括动态呼叫和会话管理，包括当前代理状态和在包括实时语音信道的多个媒体信道中的出现。客户端实例228a采用手动和在某些实例中自动的方式有效地将CRM和CTI相关的服务桥接到代理模型、客户定义和事件目的，以选择并提供用于增强代理和主叫方的转发经验所需的服务和数据。

在例如站223处操作的代理可以通过经由CSW 211和内部电话线路217的路由从PSTN 202接收电话语音呼叫事件。这些呼叫在系统中的出现被注意并记录在CTI/T-S处理器215，其中CTI/T-S处理器215具有通过LAN与CC/CRM适配器214的连接。在一个实施例中，可以在CTI/T-S处理器215与适配器214之间提供直接数据链接(桥接)。当与代理站223相关的通信事件被路由时，CC/CRM适配器214提示CRM系统208。

路由期间，通常在电话呼叫被拾取之前，该电话呼叫被路由到代理电话224，而与该呼叫相关的数据通过LAN 218被路由到计算机225并被显示。先前通过CTI/T-S处理器215对CRM 208的提示或请求可以是使用超文本传输协议/简单对象访问协议(HTTP/SOAP)询问CRM 208准备好使用HTTP协议在本实例中通过访问线路216和LAN 218以及(路由该连接)IPR 221限定的网络访问路径向代理桌面225发送关于主叫方的数据的初始机器对机器请求。CRM 108可以处于监视状态，或者总是连接到主系统，其中到代理桌面的连接是自动的。

在典型的操作方案中，CRM 208准备好并等待来自代理操作站223的请求。在这种方案中，关于呼叫和主叫方的数据可以在该呼叫在电话224处被拾取之前到达计算机225。当代理拾取呼叫时，代理可以随后使用IC/AC/CRM实例发送特定服务和/或可以在桌面获得的数据的请求。CTI电话呼叫转移服务和多方连接可以被用作例如通过CRM服务器208提供的CRM服务方案的示例。可以提示CRM服务器208传送在CSW 211处实现的方案，例如多方桥接的连接或者会议，其中代理发起连接并随后退出以处理下一个呼叫。

在另一个实施例中，数据网络电话(DNT)主叫方可以使用软件电话(基于IP的)或者能够使用互联网的蜂窝电话、智能电话、平板电脑或者其它类似装置联络中心210。在这些方案中，可以有更多的媒体信道可用于类似短信息、聊天、电子邮件等的交互。在纯DNT意义上，IPR 221可以使用主机服务器(图中未示出)通知站223事件(例如，视频会议)的CC/CRM适配器。CRM还可以为代理的会议建立初始空间和格式，并且代理可以添加通过CRM服务器208提供的特定内容，该特定内容在代理的桌面界面上的交互列表中可以看到。代理可以交互，并且可以动态地向即时交互添加新的媒体信道和功能。

优选地，代理状态模型213在活动期间被更新，并且当相关联的代理不可用于通信时，代理状态模型213呈现为非活动或不可访问的状态。当代理上线时，他或她的状态模型被激活且他随后准备好交互。CC/CRM适配器114和IC/AC/CRM 228a的代理实例例如均被通过报告状态数据到合适的目的地来管理。

代理站223和223不需要位于呼叫中心内。如所示，只要远程代理的电话呼叫从CSW211被路由，该远程代理可以使用他或她的电话线和互联网或常用的WAN或MAN连接。漫游代理229在本示例中被示出与到230LAN 218无线连接。代理229还可以使用他或她的到LAN218的无线访问连接和蜂窝电话来实现本发明。再次，优选地，所有的电话呼叫通过CSW 211或者类似的CTI-增强交换机路由。

适配器214可以是运行在CTI-S处理器215或IPR 221或一些其它连接的主机中的软件适配器。另外，CRM系统208可以作为第三方服务或者CPE设备来提供。

通常，呼叫中心包括适于提供通信中心数据和关于任意特定代理的CTI数据的抽象化的代理交互层。抽象数据用于提供并更新代理状态，该代理状态以对象模型的形式呈现在CC/CRM适配器214内。

如上所述的技术平台的一个或多个功能可以在“基于云的”架构中实现。云计算是服务传送模型，用于实现请求式网络访问可配置计算资源(例如，网络、网络带宽、服务器、处理、内存、存储器、应用程序、虚拟机和服务)的共享池，所述计算资源可以通过最小的管理付出和与服务提供者的交互来快速提供和释放。可以全部或部分使用的可用服务模型包括：软件即服务(SaaS)(运行在云基础设施上的提供商的应用程序)；平台即服务(PaaS)(可以使用提供商工具在云基础设施上生成的客户部署应用程序)；基础设施即服务(IaaS)(客户规定其自己的处理、存储、网络和其它计算资源，并且可以部署并运行操作系统和应用程序)。基于云的平台可以包括在同一地点的硬件和软件资源，或者物理上、逻辑上、实质上和/或地理上独立的资源。用于向平台服务或者从平台服务通信的通信网络可以是基于包的、非基于包的以及安全的或者不安全的或者上述类型的一些组合。

更普遍地，使用一组一个或多个计算相关的实体(系统、机器、进程、程序、库、功能或者类似实体)提供了本文说明的技术，这些实体一起辅助或提供上文说明的所述功能。在典型实现方式中，在其上执行软件的代表性机器包括商品软件、操作系统、应用程序运行环境以及一组应用程序或进程和相关联的数据、网络技术，等等，这些一起提供给定系统或子系统的功能。如上所述，该功能可以在独立的机器上或者横跨一组分布式机器上实现。

如上所述，上述基础设施的前端还代表常规的网站(例如，根据标记语言格式化的一组一个或多个页面)。

如上所述的客户端设备访问服务提供商基础设施检索包括HTML、媒体播放器、视频内容和其它对象的内容。典型的客户端装置是个人计算机、笔记本电脑、移动装置、平板电脑或类似装置。代表性的移动装置是苹果

或iPad5、iPad mini、基于安卓^TM的智能电话或平板电脑、基于

的智能电话或平板电脑或类似装置。这种类型的装置通常包括CPU(中央处理单元)(例如任何基于Intel或AMD(或者其它)的芯片)、计算机内存304(例如，RAM)和闪存驱动器。装置软件包括操作系统(例如，苹果IOS、

安卓^TM或者类似系统)和通用支持应用程序和实用程序。该装置还可以包括图形处理单元(GPU)和被配置为从用户的触摸接收输入的触摸感测装置或界面。触摸感测装置典型的为触摸屏。移动装置包括合适的程序，以便以本领域公知的形式辅助基于手势的控制。客户端不限于移动装置，它还可以是传统的台式机、膝上型电脑或其它可访问互联网的运行网页浏览器(例如，互联网Explorer、FireFox、Safari、Chrome或其它浏览器)的机器。为客户端检索的内容可以在浏览器中、手机应用程序或其它呈现引擎内呈现。

增强的路由技术

在呼叫中心环境(或者，更通常地，客户交互管理平台)中，路由通常指发送交互到目标的过程。路由“策略”指示在不同的环境下如何处理以及引导交互到哪里。除了选择目标之外，路由的目的还可以包括确定交互的特性，例如类型(语音、电子邮件、聊天，等等)、优先级、客户分组、服务类型、目标SLA，等等。路由策略可以在开发环境中使用例如为

交互路由设计(IRD)的工具生成，其中用户可以测试、修改以及下载路由策略。Genesys通用路由服务器(URS)是执行这种开发的路由策略且更具体的使用路由策略指令的服务器。以下的技术可以实现为呼叫中心代理分配逻辑或者与呼叫中心代理分配逻辑相关联。更通常地，呼叫中心代理分配机制可以实现一个或多个多种代理机制，包括、但不限于基于技能的路由、基于业务优先级的路由、基于通过服务级别共享代理的路由、基于费用的路由以及其它已知机制。呼叫中心代理分配机制可以接着被扩张为包括本公开中说明的增强的路由技术中的一个或多个。代表性的、但非限制性的实现这种代理分配功能的平台是

编配服务器(ORS)。该服务器提供基于会话的路由，并将该路由和其它后端呼叫中心功能与其它呼叫中心系统、服务器、程序和进程进行集成。

在此所述的功能中的任意一个都可以在企业环境中、基于云的环境中或者混合环境(云和企业的结合)环境中实现。

下文中说明根据本发明的可以实现为提供增强的代理分配(或者，更通常地，增强这种现有代理分配机制)的多种路由(呼叫至代理分配)方法或策略。如上文所述，这些路由方法本文中有时可以称为“动态客户分配”、“自适应业务目标路由”以及“事件路由”。这些术语仅提供为说明性目的，而不应被视为限制性的。如本领域技术人员应当理解的，上述路由技术中的两个或更多个可以与彼此一同使用。因此，在一个实施例中，动态客户分组策略与自适应业务目标策略或事件路由相关联地实现。在另一个实施例中，自适应业务目标策略与事件路由相关联地实现。而另一个实施例是将上述全部三个策略相关联(结合)。路由策略可以全部或部分地实现，或者同时或顺序地实现。更具体地，这些路由策略中的两个或更多个可以相对于彼此异步地实现，或者相对于彼此同步地实现。这些可以使用例如上文所述的开发/配置工具进行配置或指定。

预期的动态客户分组路由

众所周知，当客户寻求与呼叫中心取得联系时，通常该呼叫中心根据当前客户分组(或联合)，例如金牌、银牌、铜牌或类似分组(不考虑可以指定该分组的方式)，来应用策略。根据一个实施例，客户分组反应了客户对该公司的“价值”，其中更高的排名通常意味着优先的/更高的关心或服务级别(“服务级别”)。就此而言，客户分组识别可以被认为是期望为属于该客户分组的客户提供的服务级别的识别。例如，银牌客户的呼叫可以被连接到IVR系统，而金牌客户的呼叫可以被直接连接到现场代理。另外，根据客户分组识别，可以为客户的交互识别不同的业务目标。这种业务目标可以与客户满意度和/或业务结果相关。例如，银牌客户的业务目标可以是获得特定的NPS分数和/或关闭提供给银牌客户的在特定业务机会上的待遇。金牌客户的业务目标可以实现更高的NPS分数和/或关于提供给金牌客户的在业务机会上的待遇。

例如如上所述的呼叫中心中的当前客户分组是相对静态的，并且通常考虑对该公司的当前和潜在的未来的客户价值。在现有系统中，如果完全对客户分组关联进行评估，则通常是在事后对客户分组关联进行检查(并做可能地调整)；特别地是根据给定(过去)的交互的结果。根据这种现有系统，任何新的分组关联随后对未来交互变得有效。

根据本发明实施例的根据动态客户分组的方案，客户服务级别在例如特定的新交互(或一组新交互)之前或在交互本身期间实时地被潜在地主动调整。根据一个实施例，响应于检测到与客户的当前交互，调用动态客户分组进程。该交互可以是独立交互或者与特定情况相关的交互。在主动调整客户服务级别中，可以考虑一个或多个静态和/或动态因素。例如，可以考虑一个或多个静态和/或动态因素以推进(促进)客户从(例如，存储在客户记录中的)当前分组状态到一些更高的(例如，下一个更高的)分组状态。

根据一个实施例，待处理的交互的预期结果可以根据例如一个或多个动态因素进行预测，以在交互处理开始时推进或者不推进相关联的客户分组。例如，作出关于是否将例如银牌客户作为例如金牌客户的先前决定，很可能导致实际上符合客户的金牌分类的标准的结果(例如，与业务机会相关联的申请的接收)。如果成功的机会高于特定的阀值，则银牌客户可以被作为金牌客户对待，并且根据对金牌客户的业务目标设置将向其提供业务机会，在一些实例中，该业务机会将不会提供给作为银牌客户的他/她。

重新评估客户分组中可以考虑的静态因素可以包括例如以下因素中的一个或多个：客户配置文件中的变化、客户的一组业务中的变化、该业务施行的标准中的变化、根据个人与呼叫中心的先前交互或网页监测历史等对个人(对社交媒体交互)预期的实际影响，以及其它。例如，在他或他的社交媒体网络中具有高影响的潜力的客户可以在他的客户分组中被提高。

对于客户配置文件中的变化，客户可以已经搬迁到例如更繁华的地理位置，可以最近买了房子，可以已经改变了他/她的婚姻状况和/或可以已经改变他的工作/薪资，所有这些都可以作为在客户分组中将客户上移或者下移的考虑因素。

对于客户的一组业务的变化，企业可以改变用于访问客户分组的客户模型内的标准/属性的列表。例如，企业可以添加或者移除作为要考虑的因素的“影响力分数(kloutscore)”(社交媒体受欢迎度/影响力)和/或移除例如“拥有电视机”的因素(这是因为这种因素已经不再是给予不同对待的区分)。

对于确定客户分组中由业务提供的标准中的变化，企业可以根据规定(例如，巴塞尔3银行规则)或者先前标准的重新评估(例如，先前坏的/高风险的生活位置可能逐渐变好)或者新的统计发现(例如，性别/年龄和车辆驾驶安全之间的不同相关性)对不同的客户分组(金牌、银牌和铜牌)有新的标准/规则。

为重新评估客户分组可以考虑的示例性的动态因素可以包括、但不限于给定客户可能感兴趣的(多个)新业务提议、给定交互期间的交叉/向上行销机会(这可能取决于交互/媒体信道)、用于交叉/向上行销的(例如，高)技能代理的可用性同时为给定客户好的匹配、以及给定交互的其它副作用，例如对社交媒体社区或类似物的可见性。对于新的业务提议，可以在当前交互期间识别特定客户感兴趣的对金牌/银牌/铜牌客户具有相关联的标准的特定服务或产品。例如，客户可以明显地指示对服务或产品的兴趣。根据对这种产品和/或相关联的标准的识别，客户可以被重新分配到客户分组。该重新分配可以是例如通常的重新分配或者在每个(子)信息集合提议上的重新分配。

对于交叉/向上行销机会，仅当客户被看作属于更高的分组(例如，被看作金牌客户的银牌客户)时，代理与客户之间的会话才可能进行得顺利并且可以打开承诺交叉/向上行销的意外的机会。在这种情况中，客户可以被动态地重新分配到更高的客户分组。

对于交叉/向上行销的(例如，高)技能代理的可用性，这些代理可以被留作用于处理来自金牌客户的呼叫。被保留的代理中的特定的一个可以被认为很好地适合于处理与特定银牌客户的当前交互。这种情况中，银牌客户可以被看作金牌客户，并且该客户的待处理的交互可以被路由到被保留的代理。

根据一个实施例，在确定与客户的新交互应当如何处理之前，该新交互可以根据上述静态和/或动态因素中的一个或多个触发客户分组的重新评估。虽然通常动态客户分组的主要使用情况是“升级”——通过这种途径客户被升级到下一个更高的客户分组，但是这些触发物(通常是动态原因)中的一个或多个可以是将客户降级到一些比为该客户在他或她的客户记录中存储的分组状态更低的(例如，下一个更低的)分组状态的原因。降级的动态原因可以包括例如知道当前可用于服务该客户的代理由于当前客户分组不是很合适、队列中预备好代替给定客户的客户的高交互率、对给定客户的最佳匹配媒体信道的不可用性和/或其它。

在一个实施例中，客户分组中的降级的一个结果可以是与更高客户分组相关联的业务机会被绕开。因此，如果不很好地适合当前客户分组的代理处理与客户的交互，则在这种代理处理该交互之前将该客户降级到更低的客户分组，可以防止代理呈现业务机会，如果由该特定代理呈现所述业务机会可能结果不会成功。

根据一个实施例，对于进入交互，响应于收到该进入交互，路由策略开始于客户分组的主动重新分配。根据结果，在一些时间段内，动态确定的分组的处理随后被应用到一些可配置交互集合，等等。如上所述，重新分配(或者初始分配)可以考虑(与给定的(多个)新交互不相关的)一个或多个静态因素和/或一个或多个动态因素(给定交互的特定情况)或者它们的组合。

在一个实现方法中，处理重要的交互之前的客户分组评估包括对给定交互的所有(或者限定的子集)的可能业务结果的可能性的计算。如果将客户放到更高排名的分组中的业务结果的可能性高于配置的阀值，那么该交互按照该更高排名的分组处理。一旦该可能性被处理，则客户的服务级别因此被调整(升级或降级)。如上文所述，客户服务级别的升级或降级可以是基于每个交互的或者是基于更长时间的交互的。服务级别调整可以既应用到(由客户发起的)入站交互又应用到(呼叫中心发起的)出站交互，还可以应用到不同的媒体信道(例如，语音、电子邮件、聊天、网页浏览和社交媒体)。另外，一旦升级(或降级)到客户分组，则可以在选择代理处理交互中评估新的客户分组的第一和第二业务目标。根据一个实施例，相对于具有更低的处理第二业务目标的成功可能性的第二代理，会选择具有更高的处理第一业务目标的成功可能性的代理，即使第一业务目标的价值低于第二业务目标的价值也是如此。

图7为根据本发明一个实施例的动态客户分组的过程的流程图。该过程可以通过处理器根据存储在内存中的指令实现。然而，本领域技术人员应当理解的是，该过程可以通过硬件、软件(例如，通过ASIC)或者软件、固件和/或硬件的任意组合来执行。此外，该过程的步骤的顺序并不是固定的，而是如本领域技术人员所理解的可以修改为任何需要的顺序。

过程开始，并且在步骤600中，处理器检测到与客户相关联的待处理交互，并检索该客户的现有客户分组服务级别评估。根据一个实施例，对待处理交互的检测作为检索客户分组服务级别的触发物。现有分组信息可以存储在例如对该客户的客户配置文件记录中。

在步骤602，处理器执行测试以确定是否要执行客户分组指定的重新分配。该测试可以周期性地执行或者根据检测特定事件，举例来说，例如根据新的交互请求的接收而实时地执行。例如，响应于来自呼叫服务器18的路由待处理交互的请求的接收，确定需要重新评估的测试可以通过路由服务器20执行。

如果步骤602的测试结果是否定的，则程序返回并循环。然而，如果步骤602中的测试的结果是肯定的，则程序继续到步骤604，以上文所述的方式执行重新评估。该重新评估可以使用静态或动态因素中的一个或多个或者一些组合，并且可以根据客户将要参与的待处理交互的预期结果。就此而言，执行重新评估中，处理器可以配置为用于确定成功达到业务目标的可能性，其中所述业务目标可以是当前客户分组、下一个更高排名的分组和/或更低排名的分组的业务目标。根据一个实施例，调用一个规则或一组规则以重新评估客户分组服务级别。该规则可以考虑静态和/或动态因素，以便执行重新评估。

在步骤606，执行测试以确定是否需要服务级别调整。如果不需要，则程序返回到步骤602。然而，如果由于重新评估而需要客户分组服务级别调整，则程序继续到步骤608以发起调整(升级到给定客户分组服务级别、降级到给定客户分组服务级别、现有服务级别的属性修改，等等)。程序接着继续到步骤610，以存储新的客户分组服务级别。重新评估的客户分组数据可以被临时存储(例如，不修改客户记录中的客户分组信息)。在另一个实施例中，使用重新评估的客户分组数据替换客户记录中的当前客户分组信息。

根据一个实施例，客户分组服务级别的调整引起与客户的交互(例如，独立的交互或者与事件相关联的任务)以与调整之前的处理相比被不同地处理。例如，处理该交互的代理技能组可以不同，该交互被处理的优先级可以不同，呈现给客户的业务机会可以不同和/或类似不同之处。

根据一个实施例，如果重新评估是临时的，则在当前交互(或者不连续数量的交互)结束后，客户返回到客户记录中存储的客户分组。

自适应业务目标路由

典型的当前呼叫中心交互路由(代理分配)假定为给定交互/活动要实现的业务目标(BO)在交互处理的初始阶段被分析并限定以及固定。使用现有的固定BO，代理路由逻辑通常尝试为特定BO找到最匹配的代理。如果最匹配的代理不可用，则匹配要求被放宽直到找到可用的代理为止。这种方法的一个缺点是，BO(例如，向上/交叉行销)可能被以低水平处理(即，由较低资格的代理处理)，并且因此可能导致客户不满(BO失败或者与特定客户的未来交互成功的可能性降低)。

根据一个实施例，取代在代理分配过程中依靠固定的BO，自适应业务目标路由策略在必要的地方调整业务目标，以便在适当技能的代理不可用于处理入站交互的事件中最小化客户不满意的机会。根据一个实施例，业务目标可以由多个元素或因素组成：(1)交互的主要原因，通常由选择的交互信道确定(正如可能通过IVR对话细化)；和(2)一组业务机会(例如，交叉/向上行销提议)。

根据一个实施例，交互原因可以根据多种机制被显明地或隐含地识别。例如，可以根据客户与IMR服务器34(图2)的交互推测呼叫原因。例如，IMR服务器34可以配置为用于询问客户开放式问题，以引出该呼叫的原因的信息。例如，IMR服务器34可以配置为询问“我可以帮您做什么？”客户可以通过说出呼叫的原因来回答，举例来说，例如“我符合升级我的电话的条件吗？”根据一个实施例，客户说出的短语被语音分析模块40分析，然后该呼叫被归类到特定类别，举例来说，例如“升级资格”类。在其他实施例中，通过IMR服务器34询问的问题不是开放式的，而是将呼叫者的回答限定到例如特定的对象。当然，IMR服务器34还可以配置为起到传统IVR的作用，其中向客户提供呼叫原因列表，并且客户按下与他或她的呼叫原因相匹配的数字。呼叫原因可以从客户按下的特定数字推断。

在其他实施例中，呼叫原因也可以根据其它形式推断，举例来说，例如客户使用其它通信信道的交互，举例来说，例如网页、零售店、电子邮件、聊天信道、移动应用程序、社交媒体信道以及类似信道。多信道分析方案，举例来说，例如由Genesys电信实验室有限公司提供的Genesys文本分析，可以用于在连接当前呼叫到呼叫中心代理之前分析客户的先前参与以识别先前问题和/或需要。例如，当客户选择“与代理通话”选项时，该客户可能正在浏览与“带宠物飞行政策”相关的公司网页。正在浏览的页面上的信息可以和与代理通话的请求一起传送，并且从传送的信息可以推测客户想要与代理通话的原因与“带宠物飞行”相关。

对于识别业务机会为识别呼叫中心业务目标的一部分，这种业务机会可以根据标准来识别，所述标准举例来说、例如为客户信息、当前业务目标以及类似标准。示例性业务机会可以包括信用卡增销、续约增销和/或类似机会。根据一个实施例，特定客户的业务机会根据客户的配置文件和最近可用的匹配业务提议而被识别。根据一个实施例，业务机会可以根据客户分组识别(该客户分组可以在处理当前呼叫之前被重新评估，如上文所讨论的)而被识别。

根据一个实施例，业务机会的目的或目标是最大化业务结果和/或客户满意度。期望的业务结果可以随组织和/或时期而变化。例如，组织可以具有对于特定的NPS(净推荐值)、销售、征税和/或利润的全局目标。随后可以为不同的产品线、业务单元和/或类似项目设置更多的特定目标。例如，基于销售的业务目标可以具有与汇率、税收和销售相关的目标，而基于服务的机会可以具有与客户成就、NPS和/或类似项相关的目标。

根据一个实施例，在识别BO之后(因为BO对最大化业务结果和/或客户满意度的潜能，认为识别BO对呼叫中心来说是重要的)，路由逻辑尝试找到用于处理BO的两个部分(交互原因和识别的业务机会)的最佳匹配代理。根据一个实施例，分配逻辑(例如，路由策略/逻辑)搜索具有为BO识别的技能组(例如，资格、认证，等等)的代理。如果找不到这种代理，那么根据一个实施例，例如通过选择第二最佳BO(例如，具有相同的呼叫原因，但依据业务结果第二最佳)为给定客户调整BO。由于第二BO对于最大化业务结果和/或客户满意度的潜能较小，因此第二BO可以被认为对呼叫中心的重要性相对于第一BO较低。随后，重复该过程直到根据(可能是调整后的)BO找到合适的代理处理交互为止。

根据一个实施例，即使识别出处理BO的合适代理，特定代理对于该特定BO的成功可能性的评估可能是低的，或者比关于第二最佳BO的成功可能性更低。在这种情况中，可以选择第二最佳BO进行处理而非第一最佳BO。

当该过程完成时，因此更新客户配置文件以反映实际使用的BO。在下一个交互机会(即，该客户下一次与呼叫中心交互)，可以进行新的尝试以寻址顶级BO。

在代表性的实施方式中，并且给定交互信道、客户配置文件以及一组提议，响应于检测到与客户的待处理交互为该客户识别一组业务目标。在代理选择过程期间，路由逻辑尝试寻找用于既能处理交互的主要原因也能处理识别的业务机会的最佳匹配代理，并且根据一个实施例从第一(例如，最佳或者最高排名的)业务目标开始。如果没有代理可被用于处理交互原因和当前识别的业务目标，则使用下一个最佳BO等，直到根据该(可能调整后的)BO找到合适的代理处理该交互。

根据一个特定的实施方式，为每一对ithBO(I＝1…N)和可用代理(k＝1…M)分配排名R_ik。排名可以与例如业务结果(例如，利润)相关，该业务结果可以通过特定技能的代理从与特定BO的交互获得。例如，计划产生$100利润的BO可以比计划产生$80利润的另一个BO的排名更高。根据一个实施例，除了业务结果之外，在为BO/代理对分配排名中还考虑通过特定代理达到该业务结果的成功可能性。成功可能性可以根据例如代理关于BO的历史性能进行确定。根据一个实施例，该排名可以根据概率理论领域中通常理解的期望值的计算进行计算。在一个实施例中，期望值被用作排名。

根据一个实施例，期望值可以是特定代理的全部可能的业务结果的加权平均值。在一个实例中，期望值E(X)可以用以下方法计算并使用。在成功的情况中，每一个BO都具有值S。S也可以取决于给定的客户和其它因素。在一些实例中，还可以引入损失值L。在多数情况中，L为0，但也可以是正数(如果尝试本身是有积极效果的)或者负数(如果失败的尝试对于与客户的未来业务有消极的影响)。

根据代理在给定情况中将BO“销售”给给定客户的能力，每一个X＝BO/代理组合具有成功可能性P。然后：

E(X)＝P*S+(1-P)*L

根据一个实施例，为全部可能的BO/代理组合计算期望值E(X)，选择一个最高值。

根据一个实施例，全部可能的排名和/或期望值可以例如根据最近的呼叫历史预先定义或者在运行期间估计。对于等候被路由到代理的每个交互，获取一组业务目标和可用代理。随后根据排名的最大值选择最佳交互-代理匹配。

(选择的代理与调整后的BO之间)产生的交互接着被假定潜在地最大化业务结果同时避免客户不满。

短语“业务目标”并不旨在限于任何特定的结果实现。

本方法的概括是估算通过特定代理为当前客户实现给定业务目标的可能性，如果该可能性低于可配置的阀值，则该过程推进至尝试满足下一个最佳业务目标。

如果所有期望的结果都低于阀值，则随后可以评估一个或多个可能的后续策略。这些包括、但不限于选择最接近阀值的业务目标、给该业务目标赋予一个或多个权重并随后作出选择、在根据业务目标不做进一步调整的情况下根据交互的初始原因路由，等等。这些各种情况全部在所述的方案之内。

图8A-8B为根据本发明一个实施例的自适应业务目标路由过程的流程图。该过程可以根据存储在内存中的指令通过处理机实现。例如，该过程可以通过运行在路由服务器20中的软件模块实现。然而，本领域技术人员应当理解，该过程也可以通过硬件、固件(例如，通过ASIC)或者软件、固件和/或硬件的任意组合来执行。此外，该过程的步骤的顺序不是固定的，而是如本领域技术人员所理解的可以改变为任意期望的顺序。

过程开始，并且在步骤700中，处理器检测与客户的待处理交互(例如，独立的交互或者与事件相关联的任务)，并且如上文所述识别或检索业务目标数据，该数据包括例如交互的显明的或隐含的原因以及关于客户的第一被识别的业务机会。

在步骤702中，处理器开始代理选择过程。就此而言，处理器可以与统计服务器22交互，以用于识别具有与识别的业务目标相当的技能的代理的可用性。还可以识别被识别的代理中的每一个的技能级别。

在步骤704中，处理器确定是否已经找到适于处理所识别的业务目标中的每一个的代理。这种适合可以不仅仅基于代理的可用性，还可以基于被识别为具有合适技能的代理的技能级别相对于被认为适于处理特定业务目标的技能级别如何。如果代理的技能级别高于为业务目标识别的阀值级别，则该代理可以被认为正好适于该业务目标。

在步骤706中，匹配代理中的一个或多个被分配到业务目标。

然而，如果步骤704中的测试结果是否定的(没有用于处理当前业务目标的匹配代理可以被定位)，则该程序继续到步骤708以识别下一个业务目标。下一个业务目标可以识别关于该客户的第二业务机会。

一旦识别一组业务目标和匹配的一个或多个代理，则该过程根据关于图8B所示的分配的BO-代理对排名继续选择BO-代理对。就此而言，在步骤800中，处理器选择第一BO-代理对，并且在步骤802中，分配排名(所述排名可以正好是期望值)给该对。根据一个实施例，该排名可以是根据业务结果的识别和特定代理在实现该业务结果中的成功可能性。根据一个实施例，计算业务结果的期望值并将该期望值用于分配排名。

根据一个实例，第一BO可以具有$100的期望业务结果，而第二BO可以具有$80的期望业务结果。然而，根据处理第一BO的过去表现(对于第一BO的成功率为40％)，可以识别出被识别为适于处理第一BO的第一代理。根据第二代理在处理第二BO中的表现(对于第二代理的成功率为80％)，可以识别被识别为适于处理第二BO的第二代理。根据一个实施例，该过程将比分配给第一BO-代理对的排名高的排名分配给第二BO-代理对。就此而言，虽然依据业务结果第二BO并不是最好的，但该过程认为继续第二BO更有价值而非第一BO。

在步骤804中，作出是否存在更多的BO-代理对需要排名的决定。如果答案是否，则处理器评估分配的排名，并在步骤806中选择具有最高排名的BO-代理对。

在步骤808中，待处理交互被路由到选择的BO-代理对的代理。就此而言，呼叫路由服务器20可以发送指令到呼叫服务器18，从而识别交互被路由到的代理装置的地址。

在步骤810中，提示代理继续业务目标。例如，为交互推测的原因可以被显示在代理装置上，并且代理在看到这种原因时可以与客户一起处理该呼叫原因。处理器还可以与帮助引导代理呈现这种业务机会的脚本一起向客户显示提示，以呈现包括在BO中的业务机会。本领域技术人员应当理解的是，通过特定代理呈现的业务机会不一定是具有最高产出业务结果的一个。

根据一个实施例，业务目标可以与特定客户分组关联。就此而言，在选择合适的代理中确定要考虑哪些业务目标之前，可以先动态地将客户重新分配到特定的客户分组。

基于事件的路由

本发明的实施例涉及与单个交互路由(atomic interaction routing)相对的事件路由。在一个实施例中，基于事件的路由可以看作通过考虑该事件过去的步骤、下一个步骤以及预期的将来步骤而对整个事件的整体观察，并且基于该整体观察选择代理。就此而言，路由程序尝试选择熟悉该事件的之前环境、具有执行预期的后续处理步骤的技能和/或从事与给定客户之间的可能相关的其它交互的代理。据此，所选择的代理是被认为很好地适用于整个事件或者至少适合于与该事件相关联的特定子任务的代理。

根据一个实施例，客户分组还可以在处理特定事件的一个或多个步骤(任务)之前被主动调整。该机制可以与上文所述的为单个交互路由调整客户分组相似。

根据一个实施例，选择用于路由特定事件中的一个或多个步骤的代理可以是根据呼叫中心/企业的业务目标。根据一个实施例，如上文进一步的详细说明，选择具有使业务结果最大化并同时避免客户不满的最高可能性的代理。

图9为呼叫中心方案套件(例如，

)804的框图，该方案套件与CRM企业服务和市场应用程序(例如，

或者

)802结合。所识别的产品/系统是为说明的目的提供，并不用于限制性目的。因此，在一个可选实施例中，事件路由逻辑可以在CRM环境外实现，例如，在

编配和会话管理中实现。

这种集成允许企业利用两个重要功能的协同，也就是说，(通过CRM系统)对客户数据的管理以及(通过呼叫中心的)实时交互的管理。通过CRM和客户服务方案的无缝集成，企业可以向他们的客户提供访问选项的选择，例如电子邮件、传真、网页聊天、工作项以及传统语音。客户交互被实时处理，并且所述客户交互根据例如客户需求、历史、服务类别以及业务规则被自动地优先化、匹配并分配到最佳的可用资源。优选地，呼叫中心方案提供呼叫中心软件、预定义的路由策略和模板、装置和连续的支持。为此，平台优选地提供基于SIP的功能(以使代理能够被定位在任何需要的地方，从而从PBX约束释放呼叫中心)、基于业务的交互路由(以便优选地使用为客户的业务需求配置的路由模板使客户能够被连接到正确的代理)以及实时的和历史的报告(以实现客户服务的追踪)。

上述平台是可扩展的，以实现在这里称为“事件路由”的附加路由策略。该路由策略将在下文中使用示例实施方式进行说明。

优选地，该集成的系统(例如，但不限于，根据

桌面)使用单个代理界面用于CRM和客户交互管理。单个代理登录桌面使代理能够访问嵌入的电子邮件、聊天和Siebel桌面中的工作，不需要在应用程序之间进行切换。该方法提供了对入站呼叫处理的通过例如Sieble CRM界面的单点实时管理。为了便于本发明的技术，在一个实施例中，呼叫中心路由机制使用优选地连接到每个交互(语音、电子邮件、工作项，等等)的Siebel CRM数据客户(或“事件”)记录805，包括代理之间的转接、降低处理时间。其它CRM系统可以使用其它名称代替“事件”，并且该技术应当被视为应用于这种其它的基于CRM的环境，而不应当考虑采用的特定命名。优选地，CRM联络列表的重要且实时的更新推动基于呼叫中心的出站活动，从而增加交易机会并上传活动结果。集成的系统还为全部类型的内容(包括但不限于文件、传真、网页形式、图像，等等)的内容管理提供实时的智能路由以及实时工作流最优化(例如服务请求、客户订单/履行以及服务开通)。通过向客户中心代理提供客户数据的完整观察，能够实现更多的个性化交叉信道会话。该集成方法有利于优选地基于客户服务类别、需求、历史和配置文件对客户请求实时处理。该统一桌面方法也大大降低了操作成本并提高了客户响应度。

呼叫中心可以提供应用程序界面(API)或者SDK(软件开发包)，CRM提供商可以通过它们集成CRM系统。例如，呼叫中心可以提供客户交互管理(CIM)平台，该平台显示具有可启用服务的API的可升级的软件模板，该软件模板允许第三方集成CRM系统、服务和软件。应用程序通过抽象层或者通过网页服务或者通过低级(细粒度)接口通信。如上所述，以及在一个可选实施例中，CRM系统是呼叫中心本身的一部分。

在现有技术中，呼叫中心实现一个或多个类型的基于代理的路由，例如基于技能的最佳可用代理路由。根据这种路由策略，该现有技术被提高而考虑基于事件的信息。在“基于事件的”路由中，关于哪个代理应当接受特定交互以在呼叫中心环境中进行处理的决定至少部分地取决于例如(在CRM实施例中)与源于CRM的交互相关联的“事件记录”。因此，CRM系统或者服务器将(它的客户中的一个与系统之间的)客户支持交互模拟为“事件”。事件(或“任务”或“工作项”)具有相关联的事件记录，该事件记录具有识别该事件、它的类型、预期工作流(通过一组限定的或有序的步骤)到可能的方案、预期的时间设置、逐步升级路径以及类似信息的给定信息。根据发起事件的CRM系统，事件可以根据客户支持问题的性质与特定模板相关联。

在事件路由中，与事件关联的事件记录(或其中的信息)被用于确定应当识别呼叫中心的一组代理中的哪个代理承担该事件的附加工作/处理。将会看到，通常根据一个或多个因素选择最佳代理或目标代理，所述因素例如(由事件工作流限定的)该事件的处理过程中的特定的下一个交互或步骤的特性、给定事件的一个或多个预期的未来交互且该预期的未来交互应当优选地由相同代理处理、该事件的一个或多个先前执行的交互的出现(包括是否存在任何这种交互已经被重新开始、该事件的剩下的完成时间以及类似情况)。优选地，当时间路由策略实现时，整个事件记录(或者它的一些重要部分)被考虑以确定一组代理中的哪个代理应当被识别为与事件相关联的入站呼叫的目标。

在事件路由中，代替将个体交互(例如，语音呼叫、聊天、电子邮件，等等)路由到合适技能的最佳可用代理，一旦交互关联到特定事件，则该交互的路由被一个或多个基于事件的参数影响。另外，优选地，“路由的”就是事件本身(与与其关联的交互截然不同)。作为一个简单的实例情况，假设因为事件的属性使得需要与客户进行一些类型的未来交互，其中该未来交互在未来特定情况下和/或在事件空闲时间超时(或者一些其它触发原因)时被触发。采用基于事件的路由，一旦该触发原因出现，“事件”被路由到具有正确的技能并且可用的适合的代理(或者被路由到他或她的队列)，该代理随后(例如，通过电话、文本、电子邮件、聊天或者类似方式)与客户进行必须的通信。对于事件路由，当基于事件的触发原因出现时，事件被主动推送到代理以便处理，这降低了代理(由于该代理可能期望首先处理的一些其它交互，尽管当然可能存在一些情况，在其中一些其它分配的交互比所述事件具有更高的优先权)忽略该交互的可能性。对于事件路由，优选地，事件按照它们提交的顺序(或者相反，根据事件触发原因，或根据它们的优先级)被推送到代理(或者他们的队列)并被路由到具有适当技能的代理以处理该类型的事件。优选地，因为基于事件的路由涉及基于事件的参数，因此当代理/用户接收到事件时，(没有必须首先处理的更高优先级的交互)他或她通常处理该事件来代替选择处理一些其它交互。因此，在基于事件的路由中，优选地，事件被提供到代理(通过推送以被立即处理，或者另外通过推送到代理的工作框以被立即拉取)，以通过该代理处理。无论是推送还是拉取，事件路由中使用的上述模型都确保与CRM关联的工作流被严格地执行，并且确保目标代理主动地工作以解决该事件(或者将该事件移到可以处理的另一个代理或多个代理)。

代理通过事件路由可以彼此通信和另外交互，并且优选地，多个代理中的每一个都可以同时查看事件。如果代理决定他或她将转发事件到一些其它代理或实体(假设接收代理可以被显示为是适合的)，则优选地，接收代理/实体具有接收或拒绝事件的选择权，并且优选地，事件可以被升高优先级，从而可以被优先处理。如果事件被更新，优选地，则更新被推送到处理第一交互或仍在处理该事件的代理。

事件路由技术还可以在使用预约方法的分配逻辑环境下实施，其中逻辑根据优先级为一些代理在多个请求间执行仲裁，其中优先级进而可以基于交互年龄、到期时间以及类似项。

根据本发明，假设存在用于在CRM系统与呼叫中心服务器之间传送信息的机制(例如，API、网页服务器、一些其它的请求-应答协议或者类似机制)，其中所述呼叫中心服务器负责呼叫中心代理选择。当终端用户/客户打开任务时，在CRM系统中以常规方式打开事件。事件具有与关联的事件标识符(事件ID)，并且所述事件与数据记录关联，所述数据记录在本文中有时称为事件记录。如上所述，通常事件记录是与CRM系统关联的构成，并且识别事件、事件的类型、(通过一组限定的或有序的步骤)到潜在解决方案的预期的工作流、预期的时间设置、逐步升级路径以及类似项。如果事件正在从更早的交互中被重新打开，则事件记录可以包括该事件的呼叫历史。更具体地，事件记录是与CRM关联的面向对象的数据库系统中的对象(或者事件对象)。呼叫中心通常包括用于外部事件管理的呼叫中心服务器API，以链接到呼叫中心环境中的(当前的和历史的)交互。

优选地，呼叫中心报表系统或子系统报告事件如何被处理。报表可以包括、但不限于多少事件已经被处理、结束、解决、正在等候信息以及类似项以及在每个状态下多少个特定代理工作。与传统的代理交互报告相比，事件路由还可以提供更细的报告。因此，例如，当事件被推送到代理并且该代理接收事件，则代理处理该事件的时间可以被监控和报告。一旦代理返回该事件(例如，通过结束或解决它、通过搜索更多信息，等等)，系统标记发生的时间，并且接着可以向该代理推送新的事件。通过监控处理时间，并且假定具有固定处理步骤的确定性事件，呼叫中心管理获得特定代理处理事件需要多长时间的视图并且，如果可以的话，可以开始训练和其它矫正动作以处理缺陷。报告还可以指示哪些代理在处理最难的事件、哪些代理在处理很多事件以及这些事件的属性，等等。报告还可以指示代理什么时候针对该事件咨询另一个代理；如果很多代理都咨询特定代理，这可以指示被咨询的代理关于事件类型具有最相关的知识和/或其它代理需要适当的训练。当事件在代理之间转发时，这些转发也被报告，再次指示对附加代理训练的需要的可能性。优选地，逐步升级也被报告，从而帮助管理人员知道需要什么时候改变其它过程(根据这些逐步升级的属性和范围)。

优选地，接收事件的代理(为新事件的“所有者”)可以访问与事件ID相关联的事件历史。优选地，仅报告正在处理该事件(即，活动窗口打开并关注该窗口)的代理关于该事件的时间。这允许第一代理在某个时间段内处理该事件，并且当该事件被转发到第二代理时不会失去对该处理的信用。仅当第二代理正在处理该事件时(即，活动窗口打开，等等)，报告他或她的时间。优选地，CRM记录还反映处理该事件的每个代理或用户的相同活动。

优选地，事件路由不影响或改变事件历史。因此，不考虑最后处理事件的代理的身份，所有处理该事件的代理优选地接收他们的工作的信用。(例如，通过监控代理桌面上打开并关注的活动窗口)确定全部时间都被精确地记录，呼叫中心和/或CRM提供花费在每个事件上的时间的综合报告、处理该事件的代理/用户的身份以及识别的任意问题(动态、反常现象，等等)。

上述方式的事件路由和相关联的报告可以显示关于代理的有价值的信息以及他或她的感知值是否有实际数据的支持。如上所述，在事件路由中，代理根据事件特有的参数接收待处理的事件(并且因此他们必然不能挑拣和选择他们的交互)，事件路由数据提供代理活动的更加细致和精确的观察。因此，代理可以具有非常高的数量的转发和咨询或者低的结束率，等等，并且这些数据(即使与另外呈现给高度有效的代理的事件相关联)可以指示该代理实际有问题或者可能没有按照他或她的(实际的或感知的)潜力工作。该信息还可以表明需要对事件路由逻辑进行调整。相反地，事件路由和相关联的报告还可以显示先前仅被认为一般的代理(例如，具有低数量的结束的交互)现在处于很多事件(如果不是最难的事件)的转接和咨询的接收端。代理已经结束了其他代理已经拒绝从工作队列中拉取的难处理交互；但是，现在事件根据基于事件的参数被推送，其他代理向他的工作人员学习，使得他们可以处理他们通常会回避的事件。

当然，这里仅是典型的实例，但是它们示出了事件路由可以如何提供关于代理工作习惯的非常有用的信息，否则，当交互被路由到上述模型中的代理时并不能获得所述代理工作习惯。优选地，代理监控和事件报告统计以自动的方式生成；这些记录可以通过自动系统被再次解析，以生成通过代理的事件处理能力来识别(例如，排名)代理的输出报告。

更具体地，事件路由通过由熟悉事件先前情况的代理或者具有执行预期的后续处理步骤的能力的代理或者加入到与给定客户的潜在相关的其它交互中的代理或者类似代理来处理该交互的方式而优于单个交互路由。

尽管没有关于什么时候可以实施事件路由的限制，但是典型的是所述事件路由可以更多地用作后台功能，而单个交互更常通过呼叫中心处理。如果呼叫中心运行效率较低，那么可能希望使用事件路由来帮助呼叫中心处理任意的积压工作或者以其它方式降低延迟。

根据实施事件路由的一个实例，保险公司的工作人员可以打开CRM系统802中的事件记录。事件记录可以例如用于处理涉及客户的交通事故的保险索赔。根据一个实施例，事件记录识别处理保险索赔要执行的预期步骤的工作流。例如，该步骤可以包括获取事故的细节、确定责任方、授权客户将车辆带到车身修理厂、安排理赔人去车身修理厂检验车辆、从理赔人获得报告、授权车身修理厂维修车辆以及向车身修理厂支付费用。工作流的特定步骤完成时，可以在事件记录中追踪关于处理特定步骤的工作人员的信息、处理特定步骤的日期和时间以及类似信息。

根据一个实施例，工作流的多个步骤可以由企业的一个或多个工作人员/代理处理。就此而言，在需要代理处理的工作流特定步骤处生成自发任务，并且将该任务路由到被确定具有用于处理该交互的技能组的代理。根据一个实施例，没有寻找具有用于处理工作流中最接近的下一个步骤的技能组的代理，而是对工作流中的一个或多个未来步骤(紧接在最接近的下一个步骤之后)进行分析，用于确定处理一个或多个未来步骤中的每一个的技能组，同时做出关于紧接着的下一步的决定。处理器可以配置有逻辑以确定是否存在具有处理所识别的步骤中多于一个步骤的技能的单个代理。再次，同时为全部识别的步骤做出决定。这样，可以在处理事件的代理方面保持连续性。因此，例如，如果具有技能A的代理1可用于处理步骤1，但是具有技能A和B的代理2可用于处理步骤1和2，那么相对于代理1来说可以选择代理2。当然，代理很可能在不同的时间点及时处理该两个步骤。另外，代理可以最初仅接收到处理工作流中紧接着的下一个步骤的任务，并且可能知道或者不知道他已经被指定为处理后续步骤。然而在一些实施例中，代理知道后续步骤的分配。后续步骤的任务可以与紧接着的下一个步骤的任务的生成同时生成，或者稍后生成。生成的任务可以被同时路由到代理，或者在不同的时间路由。如果后续步骤的任务被稍后路由，则处理器检测到已经选择了代理，并且因此在不调用例如逻辑的情况下路由该后续任务，其中所述逻辑用于做出用于识别处理该后续任务的最佳代理的技能确定。

在传统交互/任务路由中，根据以下因素限定最佳目标(代理)：

o可用性、占用率，等等

o客户分组

o优先级

o处理给定媒体类型的交互所需的技能

o代理的能力

o客户交互历史(例如，最后的代理路由)

o附加标准，例如向上/交叉行销机会以及相应的代理技能

根据本发明的实施例，当为路由事件记录选择最佳匹配代理时，可能需要考虑完整的事件记录：

o事件处理中作为下一个“步骤”的特定的单个交互

o给定事件的预期的未来交互(基于事件分类/类别)，其中该未来交互应当优选地由相同代理处理

o给定事件中已经执行的、可能必须被重新打开的交互，

o整个事件的剩余完成时间

o考虑上述所有因素后选择路由目标

如果识别到多个代理同样适合于处理多个即将来到的工作流步骤，则可以根据例如所识别的代理的技能级别得到最终选择的代理。具有更高技能级别的代理可以优选地取代具有较低技能级别的代理。

根据一个实施例，如上所述，代替将自发任务路由到选择的代理，路由相关的事件记录以用于给出当前步骤所属的工作流中的代理环境以及用于理解该事件周围的历史。根据一个实施例，可以通过识别被路由到代理的任务中的事件ID来启动事件的路由。事件ID随后可以用于从CRM系统中检索事件数据。

根据一个实施例，交互或任务到代理的路由可以根据为事件设置的参数和/或围绕工作流的一个或多个步骤的参数被自动地触发。例如，可以根据日期/时间设置自动地触发任务。还可以根据工作流的两个或更多个步骤之间经过的时间或者因为最后一个工作流步骤的完成触发任务。就此而言，处理器监测触发事件并，响应于检测到这种触发事件的出现，自动生成并发送与该触发事件关联的任务。

组合的路由策略

如上所述，根据本发明的一个方面，上述的路由策略中的一个或优选的多个同时地和/或顺序地实施。图10示出多个情况。

路由策略可以根据每个交互或者多个交互来实施。

作为示例场景(a)，初始执行动态客户分组900，随后是自适应业务目标路由策略902。

另一个示例场景(b)以自适应业务目标路由902一起开始，随后是事件路由904。

作为第二示例场景(c)，初始执行动态客户分组900，随后是事件路由904。

另一个示例场景(d)涉及同时和/或顺序实施的动态客户分组900、自适应业务目标路由902以及事件路由904。

上面显示的顺序或排序(策略900，然后策略902，接着策略904)并不旨在限制。可以根据使用事件实施任意的顺序或排序。如图所示，这里的一个或多个路由策略被设计成扩大代理分配机制中实施的其它路由策略。

客户可以使用基于网页的配置工具或者其它接口机制，以使用上文的方案(单独使用或者与例如那些基于可用性、占用率、静态客户分组(静态)、优先级、处理给定媒体类型的交互所需的技能、代理能力、客户交互历史(例如，最后一个代理路由)以及其它标准(例如，向上或交叉销售机会、代理技能以及类似项)的现有代理分配机制结合使用)来规定或者以其它方式配置客户路由策略。

虽然上面的说明中提出了通过某实施例执行的特定操作顺序，但是应当理解的是该顺序是示例性的，可选的实施例可以以不同的顺序、组合某些操作、重叠某些操作或者类似形式来执行该操作。给定实施例的说明中的引用显示所述的实施例可以包括特定的特征、结构或属性，但不是每一个实施例可以不必都包括上述特征、结构或属性。

尽管在方法或过程中说明了所公开的主题，但是本主题还涉及用于执行本文中的操作的设备。该设备可以根据所需的目的进行特别的构造，或者它可以包括通过存储的计算机程序存储选择性地激活或重新配置的通用计算实体。该计算机程序可以存储在计算机可读存储介质中，例如，但不限于，包括光盘的任意类型的光盘、CD-ROM和磁光盘、闪存、只读存储器(ROM)、随机存取存储器(RAM)、磁卡或光卡或者用于存储电子指令的任意类型的永久性介质。

尽管分别说明了系统的给定组件，本领域普通技术人员应当理解的是，其中的一些功能可以在给定指令、程序序列、代码部分以及类似项中组合或共享。

如本文所用，代理可以例如通过专用于该目的的代理分配机制被显示分配，或者例如通过IVR被隐式分配。

在前述附图中的多个服务器、控制器、交换机、网关、引擎和/或模块(统称为服务器)中的每一个都可以是运行在一个或多个计算装置1500中的一个或多个处理器上(例如，图11A、图11B)、执行计算机程序指令并与其它系统部件交互以执行本文所述的各种功能的进程或者线程。计算机程序指令存储在内存中，所述内存可以使用标准内存装置(例如，随机存取存储器(RAM))在计算装置中实现。计算机程序指令还可以存储在其它非临时性计算机可读介质中，例如CD-ROM、闪存驱动器或者类似介质。另外，本领域技术人员应当理解，计算装置可以通过固件(例如，应用程序专用集成电路)、硬件或者软件、固件和硬件的组合实现。本领域技术人员还应当理解在不背离本发明的示例性实施例的保护范围的情况下，各种计算装置的功能可以组合或集成到单个计算装置中，或者特定计算装置的功能可以通过一个或多个其它计算装置而被分散。服务器可以是软件模块，所述软件模块也可以简单地称为模块。呼叫中心中的一组模块可以包括服务器以及其它模块。

多个服务器可以在站内计算装置上位于与呼叫中心的代理相同的物理位置处，或者可以位于站外(或在云中)的在地理上不同的位置，例如远程数据中心，并通过网络(例如，互联网)连接到呼叫中心。另外，一些服务器可以位于呼叫中心处的站内计算装置中，同时其它服务器可以位于站外计算装置中，或者提供冗余功能的服务器既可以通过站内计算装置提供又可以通过站外计算装置提供以提供更大的容错能力。在本发明的一些实施例中，由位于站外的计算装置上的服务器提供的功能可以通过虚拟专用网(VPN)访问并提供，就好像这些服务器是站内的，或者这些功能可以使用软件即服务(SaaS)提供，以通过互联网使用各种协议提供功能，例如通过交换使用在可扩展标记语言(XML)或JavaScript对象符号(JSON)中编码的数据。

图11A和图11B显示本发明的示例性实施例中可以使用的计算装置1500的框图。每个计算装置1500都包括中央处理单元1521和主内存单元1522。如图11A所示，计算装置1500还可以包括存储装置1528、可移除介质接口1516、网络接口1518、输入/输出(I/O)控制器1523、一个或多个显示装置1530c、键盘1530a和指向装置1530b，例如鼠标。存储装置1528可以包括但不限于用于操作系统和软件的存储器。如图11B所示，每个计算装置1500还可以包括附加的可选元件，例如内存端口1503、桥接器1570、一个或多个附加的输入/输出装置1530d,1530e和与中央处理单元1521通信的缓冲内存1540。输入/输出装置1530a、1530b、1530d和1530e在这里可以使用附图标记1530统称。

中央处理单元1521为响应和处理从主内存单元1522获取的指令的任意的逻辑电路。它可以例如在集成电路中实现、以微处理器、微控制器或者图形处理单元(GPU)的形式实现或者在现场可编程门阵列(FPGA)或者应用程序专用集成电路(ASIC)中实现。主内存单元1522可以是能够存储数据并允许中央处理单元1521直接访问任何存储位置的一个或多个内存芯片。如图11A所示，中央处理单元1521通过系统总线1550与主内存1522通信。如图11B所示，中央处理单元1521还可以通过内存端口1503与主内存1522直接通信。

图11B示出中央处理单元1521通过次级总线(有时称为后端总线)与缓冲内存1540直接通信的一个实施例。在其它实施例中，中央处理单元1521使用系统总线1550与缓冲内存1540通信。缓冲内存1540与主内存1522相比通常具有更快的响应时间。如图11A中所示，中央处理单元1521通过本地系统总线1550与多种I/O装置1530通信。多种总线可以用作本地系统总线1550，包括视频电子标准协会(VESA)本地总线(VLB)、工业标准架构(ISA)总线、扩展工业标准架构(EISA)总线、微信道架构(MCA)总线、外设部件互连(PCI)总线、PCI扩展(PCI-X)总线、PIC-Express总线或者网络用户总线。对于I/O装置为显示装置1530c的实施例，中央处理单元1521可以通过高级图形端口(AGP)与显示装置1530c通信。图11B示出计算机1500的一个实施例，其中中央处理单元1521与I/O装置1530e直接通信。图11B还示出本地总线和直接通信相混合的一个实施例：中央处理单元1521使用本地系统总线1550与I/O装置1530d通信，同时还与I/O装置1530e直接通信。

多种I/O装置1530可以存在于计算装置1500中。输入装置包括一个或多个键盘1530a、鼠标、触控板、跟踪球、麦克风和绘图板。输出装置包括视频显示装置1530c、扬声器和打印机。如图11A所示，I/O控制器1523可以控制I/O装置。I/O控制器可以控制一个或多个I/O装置，例如键盘1530a和指向装置1530b，例如鼠标或光学笔。

再次参照图11A，计算装置1500可以支持一个或多个可移除介质接口1516，例如软盘驱动器、CD-ROM驱动器、DVD-ROM驱动器、各种形式的磁带驱动器、USB端口、安全数字或COMPACT FLASH^TM内存卡端口或者适于从只读介质读取数据或者从读写介质读取或写入数据的其它任何装置。I/O装置1530可以是系统总线1550和可移除介质接口1516之间的桥接器。

例如，可移除介质接口1516可以用于安装软件和程序。计算装置1500可以还包括用于存储操作系统和其它相关软件并用于存储应用软件程序的存储装置1528，例如一个或多个硬盘驱动器或者硬盘驱动器阵列。可选地，可移除介质接口1516还可以用作存储装置。例如，操作系统和软件可以由可启动介质(例如，可启动CD)运行。

在一些实施例中，计算装置1500可以包括或者连接到多个显示装置1530c，该多个显示装置中的每一个可以是相同或者不同类型和/或形式。因此，I/O装置1530和/或I/O控制器1523中的任何一个可以包括任意类型和/或形式的合适的硬件、软件或硬件和软件的组合，以通过计算装置1500支持、启动或提供到多个显示装置1530c的连接或者使用多个显示装置1530c。例如，计算装置1500可以包括任何类型和/或形式的视频适配器、视频卡、驱动器和/或库，以接合、通信、连接或以其它方式使用显示装置1530c。在一个实施例中，视频适配器可以包括多个连接器以连接到多个显示装置1530c。在其它实施例中，计算装置1500可以包括多个视频适配器，其中每个视频适配器被连接到显示装置1530c中的一个或多个。在一些实施例中，计算装置1500的操作系统的任何部分都可以配置为使用多个显示装置1530c。在其它实施例中，显示装置1530c中的一个或多个可以由一个或多个其它计算装置提供，并且通过网络被连接到例如计算装置1500。这些实施例可以包括被设计并构造为使用另一个计算装置的显示装置作为用于计算装置1500的第二显示装置1530c的任意类型的软件。本领域技术人员应当认识并理解到计算装置1500可以被配置为具有多个显示装置1530c的多种方法和实施例。

图11A和图11B中所示出的这种计算装置1500可以在操作系统的控制下操作，该操作系统控制任务的调度并访问系统资源。计算装置1500可以运行任何操作系统、任何嵌入式操作系统、任何实时操作系统、任何开源操作系统、任何专有操作系统、用于移动计算装置的任何操作系统或者能够在计算装置上运行并执行在此所述的操作的任何其它操作系统。

计算装置1500可以是任何工作站、台式计算机、膝上型计算机或笔记本电脑、服务器机器、手持式计算机、移动电话或者其它便携式电信装置、媒体播放装置、游戏系统、移动计算装置或者能够通信并具有足够的处理器能力和内存能力以执行在此所述操作的任何其它类型和/或形式的计算装置、电信装置或媒体装置。在一些实施例中，计算装置1500可以具有不同的处理器、操作系统和与所述装置相兼容的输入装置。

在其它实施例中，计算装置1500为移动装置，例如支持Java的蜂窝电话或个人数字助理(PDA)、智能电话、数字音频播放器或者便携式媒体播放器。在一些实施例中，计算装置1500包括诸如与数字音频播放器或便携式媒体播放器组合的移动电话的装置的组合。

如图11C所示，中央处理单元1521可以包括多个处理器P1、P2、P3和P4，并且可以提供指令的同时执行或者多于一个数据片上的一个指令的同时执行的功能。在一些实施例中，计算装置1500可以包括具有一个或多个核的并行处理器。在这些实施例中的一个中，计算装置1500为具有多个处理器和/或多个处理器核的共享内存并行装置，并且作为单个全局地址空间访问全部可用内存。在这些实施例中的另一个中，计算装置1500为具有每一个仅访问本地内存的多个处理器的分布式内存并行装置。在这些实施例中的又一个中，计算装置1500具有一些共享的内存和一些可以仅由特定处理器或处理器子集访问的内存。在这些实施例中的又一个中，中央处理单元1521包括将两个或更多个独立处理器组合到单一封装体中，例如单个集成电路(IC)中的多核微处理器。在一个示例性实施例中，如图11D中所示，计算装置1500包括至少一个中央处理单元1521和至少一个图形处理单元1521’。

在一些实施例中，中央处理单元1521提供单个指令、多数据(SIMD)功能，例如在多个数据片上同时执行单个指令。在其它实施例中，中央处理单元1521中的多个处理器可以提供用于在多个数据片(MIMD)上同时执行多个指令的功能。在其它实施例中，中央处理单元1521可以在单个装置中使用SIMD和MIMD核的任意组合。

计算装置可以是通过网络连接的多个机器中的一个，或者可以包括如此连接的多个机器。图11E示出示例性网络环境。该网络环境包括通过一个或多个网络1504与一个或多个远程机器1506a、1506b和1506c(也统称为(多个)服务器机器1506或者(多个)远程机器1506)通信的一个或多个本地机器1502a、1502b(也统称为(多个)本地机器1502、(多个)客户端1502、(多个)客户端节点1502、(多个)客户端机器1502、(多个)客户端计算机1502、(多个)客户端装置1502、(多个)端点1502或者(多个)端点节点1502)。在一些实施例中，本地机器1502具有用作寻求访问由服务器机器提供的资源的客户端节点和作为向其它客户端1502a和1502b提供对托管的资源的访问的服务器机器的能力。虽然图11E中仅示出两个客户端1502和三个服务器机器1506，但是通常每一个可以是任意数量。网络1504可以是本地局域网(LAN)(例如，诸如公司内联网的专用网络)、城域网(MAN)或者广域网(WAN)(例如，互联网或者其它公共网络)或者上述网络的组合。

计算装置1500可以包括网络接口1518，以通过包括但不限于标准电话线、局域网(LAN)或者广域网(WAN)链接、宽带连接、无线连接或者上述任一个或所有连接的组合的多种连接连接到网络1504。连接可以使用多种通信协议建立。在一个实施例中，计算装置1500通过任意类型和/或形式的网关或隧道协议(例如，安全套字层(SSL)或者传输层安全(TLS))与其它计算装置1500通信。网络接口1518可以包括适于将计算装置1500连接到能够通信并执行本文所述的操作的任意类型的网络的内置网络适配器，例如网络接口卡。I/O装置1530可以是系统总线1550和外部通信总线之间的桥接器。

根据一个实施例，图11E中的网络完井可以是虚拟网络环境，其中网络的各种部件是虚拟化的。例如，多种机器1502可以是实现为运行在物理机器上的基于软件的计算机的虚拟机。虚拟机可以共享相同的操作系统。在其他示例中，不同的操作系统可以运行在每个虚拟机器示例上。根据一个实施例，实现“管理程序”类型的虚拟机，其中多个虚拟机运行在相同的主机物理机器上，每个虚拟机表现为似乎有其专用的机盒。当然，虚拟机还可以运行在不同的主机物理机器上。

还能想到其它类型的虚拟化，举例来说，例如网络(例如，通过软件定义网络(SDN))。还可以通过例如网络功能虚拟化(NFV)虚拟功能，例如会话边界控制器的功能和其它类型的功能。

申请人意在通过权利要求覆盖本发明的全部所述应用以及在不背离本发明的精神和范围的情况下对本发明为公开的目的而选择的上述实施例所做的改变和修改。向用户呈现的模板细节的特定方式也可以不同。因此，本发明呈现的实施例从各个方面应当理解为说明性的而非限制性的，本发明的范围将由权利要求和它们的同等项，而非前面的说明。

Claims (14)

1.一种用于增强呼叫中心中的指令处理的方法，所述方法包括以下步骤：

通过连接到电信网络的路由器接收与客户相关联的交互；

通过连接到所述路由器的处理器检测所述路由器处待处理的所述交互；

响应于检测到所述待处理交互，通过所述处理器检索所述客户所属于的第一客户分组的识别，其中所述第一客户分组与所述呼叫中心的第一目标相关联；

通过所述处理器根据静态因素或动态因素中的至少一个来重新评估所述客户的客户分组信息，其中所述静态因素包括客户配置文件中的变化、所述呼叫中心施行的标准中的变化和通过社交媒体对所述客户的影响中的至少一个，并且其中所述动态因素包括对所述客户的先验处理；

通过所述处理器根据所述重新评估识别第二客户分组，其中所述第二客户分组与不同于所述第一目标的所述呼叫中心的第二目标相关联；

通过所述处理器将所述客户重新关联到所述第二客户分组；和

通过所述处理器根据所述第二目标而非所述第一目标来处理所述待处理交互，其中在处理所述第二目标中，所述呼叫中心的装置被配置为通过所述电信网络加入与所述客户的装置的通信中。

2.根据权利要求1所述的方法，其中，所述第二客户分组与包括产品或者服务的交叉行销机会或者向上行销机会的业务机会相关联，其中响应于将所述客户重新关联到所述第二客户分组，所述交叉行销机会或者所述向上行销机会被呈现给所述客户。

3.根据权利要求1-2中的一项所述的方法，其中，所述呼叫中心的所述装置为所述呼叫中心的代理能够访问的装置或者自动响应装置。

4.根据权利要求2所述的方法，其中，与所述第二客户分组相关联的所述业务机会包括不包括在所述第一目标中的业务机会。

5.一种用于增强呼叫中心中的交互处理的系统，所述系统包括：

路由器，所述路由器连接到电信网络，其中所述路由器被配置为用于接收与客户关联的交互；

处理器，所述处理器连接到所述路由器；和

内存，其中所述内存存储指令，当所述处理器执行所述指令时使所述处理器：

检测在所述路由器处待处理的所述待处理交互；

响应于检测到所述待处理交互，检索所述客户所属于的第一客户分组的识别，其中所述第一客户分组与所述呼叫中心的第一目标相关联；

根据静态因素或动态因素中的至少一个来重新评估所述客户的客户分组信息，其中所述静态因素包括客户配置文件中的变化、所述呼叫中心施行的标准中的变化和通过社交媒体对所述客户的影响中的至少一个，并且其中所述动态因素包括对所述客户的先验处理；

根据所述重新评估识别第二客户分组，其中所述第二客户分组与不同于所述第一目标的所述呼叫中心的第二目标相关联；

将所述客户重新关联到所述第二客户分组；和

根据所述第二目标而非所述第一目标来处理所述待处理交互，其中在处理所述第二目标中，所述呼叫中心的装置被配置为通过所述电信网络加入与所述客户的装置的通信中。

6.根据权利要求5所述的系统，其中，所述第二客户分组与产品或服务的交叉行销机会或者向上行销机会相关联。

7.根据权利要求5-6中的一项所述的系统，其中，所述待处理交互的预期的结果与所述第二客户分组的标准组相匹配，或者所述预期的结果与所述第二目标相关，其中所述第二目标包括不包括在所述第一目标中的业务机会。

8.根据权利要求5-6中的一项所述的系统，其中，所述待处理交互用于实现与事件相关联的工作流的步骤，其中为处理所述待处理交互选择的代理是具有处理所述工作流的下一个步骤的技能的代理。

9.根据权利要求5-6中的一项所述的系统，其中，所述第二客户分组还与第三目标相关联，其中所述第二目标被识别为比所述第三目标对所述呼叫中心更重要，并且其中所述指令还使所述处理器：

识别用于处理所述第二目标的第一代理，并且确定所述第一代理在实现所述第二目标中的成功可能性；

识别用于处理所述第三目标的第二代理，并且确定所述第二代理在实现所述第三目标中的成功可能性，其中通过所述第二代理实现所述第三目标中的成功可能性高于通过所述第一代理实现所述第二目标中的成功可能性；

发送指令，以将所述待处理指令路由到所述第二代理；和

提示所述第二代理继续处理所述第二目标。

10.一种用于路由与事件相关联的一个或多个任务的系统，所述系统包括：

处理器；

内存，其中所述内存存储有指令，当通过所述处理器执行所述指令时使所述处理器：

打开客户数据库中的事件，其中所述事件与具有预期为所述事件执行的步骤的工作流相关联；

识别所述工作流的第一步骤和第二步骤；

同时执行所述第一步骤和所述第二步骤的分析，以确定用于处理所述第一步骤和所述第二步骤中的每一个的代理的技能；

根据所述分析识别具有用于处理所述第一步骤和所述第二步骤的技能的代理；

生成用于处理所述工作流中的至少所述第一步骤的第一任务；

发送指令，以将所述第一任务路由到所述识别的代理；

生成用于处理所述工作流的所述第二步骤的第二任务；和

发送指令，以将所述第二任务路由到所述识别的代理。

11.根据权利要求10所述的系统，其中，所述事件是包括出现在所述事件中的交互的历史的记录，其中所述事件与事件ID关联，并且用于路由所述任务的所述交互包括所述事件ID。

12.根据权利要求10-11中的一项所述的系统，其中，所述指令还使所述处理器：

监测触发事件，其中所述任务的所述生成步骤是根据检测所述触发事件的出现，其中所述触发事件是两个工作流步骤之间经过的设定时间段，或者所述触发事件是预设的日期。

13.根据权利要求10-11中的一项所述的系统，其中所述指令还使所述处理器：

检索与所述事件关联的客户所属于的第一客户分组的识别，其中所述第一客户分组与呼叫中心的第一目标相关联；

根据静态因素或动态因素中的至少一个来重新评估所述客户的客户分组信息，其中所述静态因素包括客户配置文件中的变化、所述呼叫中心施行的标准中的变化和通过社交媒体对所述客户的影响中的至少一个，并且其中所述动态因素包括对所述客户的先验处理；

根据所述重新评估的结果识别第二客户分组，其中所述第二客户分组与不同于所述第一目标的所述呼叫中心的第二目标相关联；

将所述客户重新关联到所述第二客户分组，其中所述第二客户分组与不同于所述第一目标的所述呼叫中心的第二目标相关联；和

根据所述第二目标而非所述第一目标来处理所述任务。

14.根据权利要求10-11中的一项所述的系统，其中，所述指令还使所述处理器：

识别呼叫中心的第一目标和第二目标，其中所述第一目标被识别为比所述第二目标对所述呼叫中心更重要；

确定第一代理具有用于实现所述第一目标的技能；

确定所述第一代理实现所述第一目标的成功可能性；

识别用于处理所述第二目标的第二代理，其中所述第二代理也具有用于处理所述第一步骤和所述第二步骤的技能；

确定所述第二代理实现所述第二目标的成功可能性，其中通过所述第二代理实现所述第二目标的成功可能性高于通过所述第一代理实现所述第一目标的成功可能性；

发送指令，以将所述任务路由到所述第二代理；和

提示所述第二代理继续处理所述第二目标。

Images