CN101552842A - 用于电信服务中心的呼叫中心应用数据和互操作架构 - Google Patents

Abstract

本发明涉及用于电信服务中心的呼叫中心应用数据和互操作架构。具体地，公开了一种呼叫中心应用数据和互操作架构，其提供用于对提供呼叫中心功能的应用进行管理的集中式设计。对于呼叫中心操作的所有方面的所有应用，该架构使用主数据存储库对信息流进行整合。该架构提供了贯穿完整雇佣生命周期(包括最初的聘请和终止)的所定义级别的员工信息。该架构通过将人力资源信息诸如员工出勤和休假管理、ID管理、交通运输管理、职责日志和调动管理与呼叫中心应用或者任何其他应用进行整合，以此来提供员工信息。

Description

用于电信服务中心的呼叫中心应用数据和互操作架构

相关申请交叉引用

本申请要求2008年1月9日提交的印度专利申请序号No.73/MUM/2008的优先权。

技术领域

本申请涉及数据处理系统，并且具体涉及呼叫中心系统架构。

背景技术

信息技术的快速增长已经带来了日益复杂和精细的产品和服务。在尝试为用户提供有意义的辅助中，各公司对于呼叫中心进行了可观的投资。呼叫中心的主要目标包括：与消费者一起工作来解决问题，回答问题，以及提供对产品和服务的持续支持。

即使不考虑现代呼叫中心的一般复杂程度，挑战仍然存在。具体地，很多领域仍然是易错的，并且受制于需要进行重复的人工劳动来执行任务。此外，呼叫中心数据经常是按照混乱的方式管理的，这导致了数据冗余和数据丢失。同时，数据操作是繁忙的，而即便是例行维护也需要高级技术。这些缺点限制了呼叫中心提供及时、准确和自动的报告的能力；保护数据安全的能力；以及提供实时数据跟踪的能力。

需要一种改进的呼叫中心应用架构。

发明内容

一种呼叫中心应用数据和互操作架构(“架构”)，提供用于对协同操作以提供呼叫中心功能的多个应用进行管理的集中式设计。该架构对通过主应用数据存储库的信息流进行协调，并且针对处理呼叫中心功能的所有方面的应用提供定制的支持。该架构为所有呼叫中心应用和使用该应用的员工(包括经理、主管和呼叫业务员)熟练地地处理信息流。

应用实现了适用于从聘用到终止的完整雇佣周期跨度的功能，并且还提供了其他支持功能。应用可以实现包括人力资源功能、员工出勤跟踪以及员工减员管理在内的功能。应用功能的其他示例包括员工休假管理、员工职责日志和标识管理。应用不限于语音特定的应用(例如，基于电话会议的问题解决)，而是还可以包括非语音过程(例如，基于电子邮件或者互联网的订单处理)。

可以在基于网络的工具中实现该架构，该工具针对上文描述的劳动密集的过程和数据完整性挑战提供了显著的改进。网络可以包括本地网和远程网或者网络的互连，网络可以是专用的和内部的，或者是可公共访问的。网络可以包括基于互联网的连接性，以用于对存储在主应用数据存储库中的应用和数据的本地或者远程访问。此外，该架构提供了可视性和跨越呼叫中心及其应用的协作二者。

呼叫中心的动态环境是指诸如员工或者呼叫中心设备的资源经常在过程之间调动。过程(process)可以是呼叫中心功能的任何实例，诸如：来自呼叫者的关于特定产品的现场(fielding)技术查询，激活产品或者服务，或者执行和确认针对产品或服务的订单。多种多样的过程以及过程间频繁的资源调动产生了按照系统化的方式对资源进行跟踪的需要。在这点上，该架构例如有利于跟踪呼叫业务员或者主管在与呼叫中心任期内针对其工作的过程。该架构还可以跟踪其他相关的详细信息，诸如呼叫业务员在每个过程中的持续时间、后来的主管以及表现数据和其他详细信息。

此外，该架构跟踪关于系统内每个员工的信息。该架构可以跟踪关于每个已定义层级的每个员工的信息。层级可以反应相对位置或者级别，诸如经理→主管→呼叫业务员，该架构维护层级中每个级别的每个员工的有关信息。在层级中的每个已定义级别，该架构还支持针对所有员工的特定的个体访问权。可以根据层级中的员工级别、员工所属的过程以及其他因素来设置访问权。

如上所述，该架构包括主应用数据存储库。在一个实现中，主应用数据存储库遵循主数据组织模式(schema)。主数据组织模式在多个呼叫中心应用数据集需求之间是统一的，因为主数据模式处理由呼叫中心应用生成的所有信息流。主数据组织模式按照模式细分(subdivision)进行划分，其中模式细分定义了特定于不同呼叫中心应用的个体应用数据集需求的多个个体应用数据模式。

通信接口从呼叫中心应用接收呼叫中心应用数据请求。处理器和支持软件(例如，数据库管理软件)处理呼叫中心应用数据请求。具体地，处理器响应于呼叫中心应用数据请求来执行数据操作，同时通过主应用数据存储库中的特定应用数据模式进行工作。数据操作可以包括以每个应用为基础来添加、删除或者改变数据字段，诸如以日为基础添加员工出勤记录、改变员工被指派到的过程或者在员工已经实现职责时从职责需求列表中删除已完成的职责。该架构由此将呼叫中心应用从本地数据库和处理开销中解脱出来。

在研究下文的附图和详细描述之后，其他系统、方法、特征和优点对于本领域技术人员而言将变得易见。意在将所有这样的附加系统、方法、特征和优点包括在本说明书之内、包括在本发明的范围内并且受到所附权利要求书的保护。

附图说明

参考下文的附图和描述可以更好地理解本发明。附图中的组件未必是按比例绘制的，而是将强调的重点放在示出本发明的原理上。而且，在附图中，相同的参考标号表示贯穿不同视图的相应部分。

图1示出了呼叫中心应用数据和互操作架构。

图2示出了包括模式细分的呼叫中心应用数据和互操作架构，其中该模式细分定义了用于特定应用的多个个体应用数据模式。

图3示出了公共应用数据模式的一部分，该公共应用数据模式实现了对多个呼叫中心应用公共的共享数据集需求。

图4示出了案例管理应用数据模式。

图5示出了案例管理应用数据模式。

图6示出了案例管理应用数据模式。

图7示出了案例管理应用数据模式。

图8示出了休假应用数据模式。

图9示出了休假应用数据模式。

图10示出了职责日志应用数据模式。

图11示出了出勤应用数据模式。

图12示出了调动应用数据模式。

图13示出了减员应用数据模式。

图14-图34示出了人力资源应用可以实现的图形用户界面(GUI)和报告的示例。

图35-图48示出了减员应用可以实现的GUI和报告的示例。

图49-图56示出了职责日志应用可以实现的GUI和报告的示例。

图57-图65示出了休假应用可以实现的GUI和报告的示例。

图66-图71示出了出勤应用可以实现的GUI和报告的示例。

图72-图87示出了My OneView应用可以实现的GUI和报告的示例。

图88-图95示出了交通运输应用可以实现的GUI和报告的示例。

图96-图109示出了案例管理应用可以实现的GUI和报告的示例。

图110-图112示出了ID管理应用可以实现的GUI和报告的示例。

图113-图117示出了调动应用可以实现的GUI和报告的示例。

图118示出了用于对呼叫中心架构中多个呼叫中心应用的操作进行协调的逻辑流的一个示例。

图119示出了用于对用户进行认证的逻辑流的一个示例。

图120示出了在用户进行呼叫时向用户显示清单的图形用户界面的一个示例。

具体实施方式

图1示出了呼叫中心应用和互操作架构100(“架构100”)。架构100提供对关键记录的一致和及时的阅览，并且通过赋予代理其自己的信息来改进个体性能。架构100还提供如下能力：从面板得到可分析的详细报告(历史的和实时的二者)，以用于根本原因分析。组织中所有事件的中央存储库提供了准确、及时和安全的数据存储。

具体地，中央存储库可以实现为主应用数据存储库102。在主应用数据存储库102中，按照主数据组织模式104来组织数据。主数据组织模式104将在下文详细描述。

架构100对多个呼叫中心应用的处理及其与主应用数据存储库102的交互进行协调。图1中所示的应用示例包括案例管理应用，其具有三个逻辑部分：账户完整性管理(“AIM”)应用106、在线订单处理(“KANA”)应用108以及销售订单录入(SOE)应用110。AIM应用106例如可以提供允许用户改正账户错误或者维护任何账户的完整性的GUI和处理逻辑。KANA应用108可以提供用于处理在线web订单的GUI和处理逻辑。SOE应用110可以提供用于处理电话订单的GUI和处理逻辑。由此，只要客户通过电话进行了订购，SOE团队便通过SOE应用110将订单载入系统。

其他应用示例包括：职责日志应用112、减员应用114、标识管理应用116、员工详细信息应用118和休假应用120。其他应用示例包括：出勤应用122、交通运输应用124、调动管理应用126以及人力资源(HRIS)应用128。

架构100实现中心辐射型设计。应用106-120通过主应用数据存储库102来交换数据，其中主应用数据存储库102减轻了每个个体应用的本地数据库开销和处理需求。架构100中可以运行附加的、不同的或者更少的应用。

图1还示出：架构100为管理团队130提供了管理性访问。管理团队130可以通过用户界面与架构100进行交互，通过该用户界面，授权用户可以对每周名册模块132所维护的个人数据进行更新，或者可以对主应用数据存储库102中存储的数据进行其他改变。此外，调度团队134可以向每周名册模块132提供输入。由此，每周名册应用132维护有员工及其在任何特定星期被指派给任何特定过程的调度的最新视图。此外，可以建立上传过程136，用以手动或者自动地将出勤数据上传至出勤应用122。

呼叫中心轮班工作，并且可以将任何员工安排到任何轮换中工作。调度包括员工的工作日和每周休息日(其休息时间)。调度团队134根据多个不同的参数来准备轮班员工的名册。架构100使得每周可以获得该名册(例如通过Excel(TM)表单形式)。管理团队130或者调度团队134每周通过上传过程136来将员工名册录入架构100(例如，录入到出勤模块中)。

可以在互联网信息Web服务器(IIS)上主控架构100中的处理。处理例如可以通过C#并使用ASP.NET来实现，其中数据存储在SQL2000数据库中。例如，可以通过Microsoft

SQL Server 2000、Microsoft SQL Server 7.0版或者其他数据库服务器技术来实现上述数据库和数据模式。关系数据库引擎可以将数据作为可扩展标记语言(XML)文档返回。此外，还可以使用XML来插入、更新和删除数据库中的值。

此外，该架构可以在相同或者不同的机器上运行关系数据库引擎的多个实例。每个实例可以具有其自己的系统和用户数据库的集合。应用可以连接到单个机器上的每个实例，其方式类似于其连接到运行在不同机器上的实例。

可以用来实现该架构的其他技术包括：用以创建交互式Web应用的异步JavaScript和XML(AJAX)，用于将HTML更严格、更简洁地呈现为XML的XHTML，用于编制和添加样式的层级式样式表单(CSS)，用于提供对文档的内容、结构和样式进行动态访问和更新的JavaScript文档对象模型(DOM)，以及与Web服务器异步交换数据并且降低了从服务器持续取回资源这一需要的XMLHttpRequest。

由于可以在无需用户重新加载整个网页的情况下发送和取回数据，因此可以根据需要以及在需要时传送少量数据。而且，可以在任何粒度级别动态地刷新页面元素，以对此进行反应。没有改变的信息无需在网络间发送。可以按照W3C的“文档对象模型(DOM)层3加载和保存规范”或者其他规范对实现进行标准化。

除上述应用之外，架构100可以提供其他功能。例如，架构100可以提供员工信息访问应用136(“My OneView”)。员工可以访问My OneView应用136来查看积存假期、日程、节日列表以及与员工相关联的其他雇佣方面。下文将更详细地描述其他示例。

图2示出了包括模式细分202的呼叫中心应用数据和互操作架构100的另一视图，其中模式细分202定义了针对特定应用的多个个体应用数据模式204-218。模式细分202可以从逻辑上或者物理上将数据库的表、字段和其他结构划分为特定于个体呼叫中心应用的表、字段和其他信息的集合。此外，主数据组织模式104定义了公共应用数据模式220。公共应用数据模式220可以包括这样的字段、表或者其他结构：多个应用使用该字段、表或者其他结构来共享数据或者具有对其的共同访问权，以支持其操作任务。

图2中个体应用数据模式的示例包括：案例管理AIM数据模式204、职责日志数据模式206、案例管理KANA数据模式208以及减员数据模式210。其他示例包括：休假数据模式212、调动数据模式214、案例管理SOE数据模式216、以及出勤数据模式218。数据模式204-218维护特定于具体应用的数据。更具体地，每个数据模式204-218支持特定的应用数据集需求。例如，减员数据模式210包括用于维护减员应用114在执行其减员管理、跟踪和报告任务中所操作、发送、接收、显示或者处理的任何数据的表和字段。细分202确保了用于每个呼叫中心应用的数据集需求之间的清晰隔离，而不是使跨过对于多个应用共同的表和字段集合的数据集需求含糊不清。

个体应用可以通过一个或多个本地网或者远程网或者这些网络的互连来与架构100的其他部分进行通信。在执行其处理时，个体应用可以提交数据请求，并且从架构100接收数据响应。为此，架构100实现了通信接口222并且包括处理器224，其中处理器224可以接收数据请求、处理数据请求并且将数据响应返回给个体应用。更具体地，存储器226可以存储数据请求处理逻辑228，诸如数据库管理应用。数据请求处理逻辑228接收数据请求(诸如出勤数据请求230和减员数据请求232)。作为响应，数据请求处理逻辑228响应于该数据请求来执行数据操作(例如，数据库查询，或者数据库读、写或更新)，以此来处理该数据请求。数据请求处理逻辑228遵循主应用数据存储库102中的应用数据模式，从而使特定的应用数据模式支持特定的呼叫中心应用。一个结果是：架构100减轻了呼叫中心应用106-128的本地数据库处理开销，并且提供了对跨过多个应用的呼叫中心数据的集中式存储和控制。

在下表中给出呼叫中心应用数据模式的特定示例。

下面的表1-表4示出了可以支持交通运输应用124的交通运输应用数据模式。

下文的表5-表11显示了可以支持职责日志应用112的职责日志数据模式206。图5提供了附加详细信息。可以将个人级别/机构级别定义为从A到H，其中A是最高级。例如，E级的人员可以是团队领导，F可以是领域专家，而G和H可以使具有类似工作性质和职责的团队成员/客户支持代表。

下面的表12示出了人力资源IS(HRIS)数据模式，其可以支持HRIS应用128名册功能。

下面的表13-表16示出了可以支持出勤应用122的出勤数据模式218。图11提供了附加详细信息。

下面的表17-表20示出了可以支持减员应用114的减员数据模式210。图13提供了附加详细信息。

下面的表21-表22示出了HRIS数据模式的附加表。

下面的表23-表26示出了用于支持调动应用126的调动数据模式214的表。图12提供了附加详细信息。

下面的表27-表33示出了支持HRIS应用128名册功能的HRIS数据模式的附加表。备选地，名册功能可以在分离的应用中实现，并且可以将名册表组织为支持名册数据集需求的分离的名册应用数据模式。

下面的表34-表37示出了HRIS数据模式的附加表。

下面的表38-表44示出了支持ID管理应用116的ID管理数据模式的表。

下面的表45-49示出了支持案例管理KANA应用108的案例管理KANA数据模式208的表。图6提供了附加详细信息。

下面的表50-58示出了支持休假应用120的休假数据模式212的表。图8和图9提供了附加详细信息。

下面的表59-表66示出了支持案例管理AIM应用106的案例管理数据模式AIM 204的表。图4和图5提供了附加的细节。

下面的表67-表69示出了支持案例管理SOE应用110的案例管理数据模式SOE 216的表。图7提供了附加详细信息。

下面的表70示出了员工数据模板。

下面的表71-表109示出了架构100的通用系统表。表71-表109可以在公共应用数据模式220中实现，作为一个示例，以提供员工的一般性信息，诸如名字、姓和电子邮件地址。图3提供了附加详细信息。

HRIS应用128有助于管理员对组织信息进行管理。HRIS应用128还管理各种过程、问题、用户详细信息、邮件详细信息，并且管理公告板。HRIS应用128还包括过程管理模块，其实现了过程的创建、激活和解激活。该模块还可以实现过程图表和过程团队管理，并且处理针对组织中的所有过程而编辑的信息。

过程管理模块可以管理过程图表，并且报告关于过程中各管理级别的信息。过程管理模块还可以管理过程团队，并且报告过程的各团队及其级别的信息。过程管理模块还可以编辑过程信息，以提供针对过程功能的编辑。图14-图20示出了HRIS应用129可以针对过程管理模块而实现的图形用户界面(GUI)屏幕、报告以及处理的示例。

具体地，图14示出了图形用户界面1402，其显示了显示部分1404以及用于控制图形用户界面1402的各种控件1408-1414。图形用户界面1402还可以包括显示标题1420，其显示与图形用户界面1402相关联的标题。

图形用户界面1402的控件1408-1414可以是多样的并且是多个。在一个实现中，图形用户界面1402的控件包括下拉菜单控件1406、复选框控件1408、可选显示项控件1410、按钮控件1412、打印控件1414以及导出控件1416和显示部分控件1418。

下拉菜单控件1406可操作以在下拉菜单1406激活时从下拉菜单显示下拉菜单项。

复选框控件1408可操作以选择与复选框控件1408相关联的显示项。图形用户界面1402可以包括多个复选框控件，并且任意复选框控件可以独立于其他复选框控件而被激活。

可选显示项控件1410可操作以将用户转换到与可选显示项控件1410的显示项相关联的其他图形用户界面。例如，可选显示项控件1410可以是超链接，当显示项控件1410被激活时，其向用户显示新的窗口。

按钮控件1412可操作以在激活时传送动作消息。例如，按钮控件1412可以传送与创建新过程或者解激活先前所选过程相关联的动作消息。按钮控件1412可以与复选框控件相关联。

打印控件1414可操作以传送打印所显示图形用户界面1402的指令。

导出控件1416可操作以将显示部分1404的所显示项导出到其他应用，诸如电子表格应用。

显示部分控件1418可操作以控制显示部分1404中显示项的显示。例如，激活显示部分控件1418可以传送如下指令：应当在显示部分1418中显示附加的显示项。图形用户界面1402可以将显示部分控件1418实现为超链接或者其他图形控件。

控件1406-1418以及显示部分1404仅仅是代表性的而非排他的。例如，图形用户界面1402可以实现更少或者附加的控件。其他类型的控件，诸如滚动条、输入域、单选按钮，也是可能的。

图15示出了图形用户界面1502的一个示例，其具有备选的设置：显示标题1420、显示部分1404以及图形用户界面控件1406、1408、1412和1414。图形用户界面1502还实现了附加的控件1504和1506。控件1504是文本域输入控件的示例。文本域输入控件1504可操作以从用户处接收形式为文字数字式字符的输入。控件1506是日历日期输入控件的示例。日历日期输入控件1506可操作以从用户接收对日历日期的选择。

图14和图15还示出了各种图形用户界面控件。图16-图117也示出了具有图形用户界面控件的图形用户界面。然而，图16-图117中所示的图形用户界面可以实现多于或者少于图14和图15中所示控件的控件。而且，图16-图117可以实现各种类型的图形用户界面控件。因此，图形用户界面的很多不同布置是可能的。

HRIS应用128还可以包括用户群组管理模块。用户群组管理模块可以管理用户群组，并且有助于指派、查看和管理用户访问权限。图21-图23示出了用户群组管理模块可以实现的GUI屏幕、报告和处理的示例。

HRIS应用128还可以包括节假日管理模块。节假日管理模块可以管理员工节假日，并且提供节假日列表编辑。节假日可以有多种类型，诸如固定的或者可选的。节假日可以在每个历年开始时进行更新，并且也可以根据位置而变化。图24示出了节假日管理模块可以实现的GUI屏幕、报告和处理的示例。在用于任何应用的任何GUI中，可以通过点击“电子表格(spreadsheet)”图标来导出数据。

HRIS应用128还可以包括组织信息管理模块，其有助于用户组织信息的录入和管理。可以保存多种类型的信息，包括诸如团队名称、HR代表姓名、生日、DOJ、级别和位置的员工详细信息。可以管理的其他信息包括标识符，诸如网络标识符、域标识符和企业标识符。图25示出了组织信息管理模块可以实现的GUI屏幕、报告和处理的示例。

HRIS应用128还可以包括公告板管理模块和问题管理模块。公告板管理模块提供用于上传在用户登录时显示在屏幕上的公告或者其他消息的界面。问题管理模块管理用户提出的问题。图26以及图27-图28分别示出了用于公告板管理和问题管理的GUI屏幕的示例。

HRIS应用128还可以包括名册管理模块。名册管理模块提供用于上传和管理名册的界面。图29和图30示出了用于名册管理的GUI屏幕的示例。注意，名册可以作为用于特定过程的电子表格文件而启动，该电子表格文件在选定的日期范围上传到系统中。

HRIS应用128还可以包括人数报告模块。人数报告模块提供用于报告人数以及所选过程和日期范围的调动详细信息的界面。人数报告模块可以提供调动类型筛选器。图31和图32示出了用于名册管理的GUI屏幕的示例。

HRIS应用128还可以包括任期概况报告模块。任期概况报告模块提供用于按照任期来报告员工数目的界面。任期概况报告模块还可以提供针对以下选项的筛选器：日期范围、过程名、位置、任期类型以及任期范围(按照天数)。任期报告模块可以提供针对所选任期范围的员工详细信息。可以通过以下筛选器来分离数据：日期范围、过程名、位置、位置类型、任期类型以及任期范围(天数)。图33和图34示出了用于任期概况和报告的GUI屏幕的示例。

该减员应用114跟踪在组织中发生的减员。人力资源人员使用该信息来查看特定过程中的减员。减员可能属于三种类型：受控、不受控和潜逃。减员可以有各种原因，诸如进修或者再教育、家庭问题、发展前景问题、对其他领域的兴趣、希望调出联系中心/BPO、面对管理问题、获得更好的前景、伪造证书、健康原因、潜逃、个人原因、死亡或者其他原因。图35-图38示出了用于减员跟踪和报告的GUI屏幕。减员应用模块114还可以提供减员批准和拒绝界面和功能，如图39和图40所示。

图41示出了减员应用114的数据流程图。基于员工代码(4102)，指派减员类型。直接主管提交报告(4104)，并且获得经理批准(4106)。如果经理没有批准，将减员记录发回系统中(4108)，否则将退出信息传送至组织的部门，员工状态变为非活跃，并且将该员工从员工层级中删除(4106)。主应用数据存储库102存储减员动作的结果。

减员应用114还可以包括减员报告模块，其提供可用来获取减员详细信息的界面。减员报告模块可以提供针对以下的筛选器：员工代码、日期范围、过程名、位置和团队名称。图42示出了用于减员报告模块的示例GUI。

减员应用114还可以包括减员概况模块。减员概况模块可以提供作为交互式报告的减员概况报告。通过点击图形化视图链接，可以查看从过程级别到代理级别的减员数目，并且可以获得减员数目和减员概况的图形表示。图43-图47提供了用于报告和处理减员概况数据的GUI屏幕的示例。图48提供了减员应用114可以生成的退出报告的示例。

职责日志应用112跟踪主管和经理在月初设定的职责，并且还跟踪相同职责的实现。职责日志应用112可以包括日志管理模块，其根据TL(团队领导)行为、DM(代理经理)行为、OM(执行经理)行为和其他行为的岗位来管理职责日志。可以在标准结合处(诸如岗位和级别)来设置职责。图49示出了用于日志管理模块的GUI屏幕的示例。

职责日志应用112可以包括职责目标管理模块，其有助于职责目标的报告和设定。图50示出了用于日志管理模块的GUI屏幕的示例。

职责日志应用112可以包括基于所添加的灵活性的层级的调度管理模块。图51和图52示出了用于调度管理模块的GUI屏幕的示例。通过点击“View My Commitment Target(查看我的职责目标)”链接，用户可以查看其个人的职责目标和已完成的目标，诸如图52中所示的报告屏幕。

职责日志应用112可以包括用于设定和管理职责目标的职责管理模块。图53和图54示出了用于职责管理模块的GUI屏幕的示例。

图55示出了职责日志应用112的数据流。在定义了针对业务的呼叫中心行为之后，正式地定义了过程方面的行为(5502)。继而，设定行为职责目标(5504)，诸如以月为基础。在员工履行职责时，更新职责目标信息(5506)。主管继而可以运行报告，以检查各个员工是否实现了职责目标(5508)。职责数据驱动记分卡报告或者其他类型的报告(5510)。可以将包括目标和完成在内的所有职责数据例如按照特定于职责日志应用112的数据模式保存在主数据库102中。

职责日志应用112可以包括职责概况模块，用于报告所实现和设定的职责。图56示出了职责概况模块的GUI屏幕的示例。

休假应用120包括实现申请、批准、转发和取消休假请求的逻辑和界面。休假应用120可以包括假期计划器模块、休假分配模块、批准休假模块、我的已申请休假模块以及休假概况模块。下面描述每个模块。

假期计划器

员工可以使用假期计划器、通过选择特定的日期范围来申请休假。图57示出了假期计划器GUI的示例。主管及高层还可以通过输入员工代码并点击图58中所示的“代表”按钮5802来代表其团队成员申请休假。在代表另一用户申请休假时，主管可以检查员工域5804中显示的用户名是否是申请休假人员的正确姓名。

一旦选择了日期范围，员工便点击“计划休假”按钮5702。假期计划器继而可以显示如图58中所示的包括日期列表的界面，并且检查该人员的积存假期以及该日可用的配额。员工还可以在所提供的域中设定休假的类型和原因。

休假分配

休假分配模块可以更新过程方面的人数以及针对特定日期范围的休假分配比例。图59中示出了示例GUI。通过点击查看分配链接5902，休假分配模块允许对针对特定过程和日期范围的级别方面的休假引用进行更新，如图60所示。

批准休假

批准休假模块实现如下界面，主管及高层可以通过该界面来批准各自团队成员的休假许可证，如图61所示。为了批准休假，管理员点击“Ticket Number(许可证号)”链接6102。可以通过诸如员工代码、过程名称和团队名称的搜索标准对数据进行筛选。通过点击“Action Selected Item(动作所选项)”按钮6104，将显示如图62所示的下一屏幕，即休假详细信息。主管可以从动作的下拉列表中选择任意选项，以取消休假、批准休假、将请求转发给其他人以用于动作或者其他选项。

我的已申请休假

员工可以使用“我的已申请休假”模块来检查其已经提交的休假许可证的状态。图63中示出了示例GUI。通过点击“Cancel Leave(取消休假)”链接6302，员工可以取消已申请的休假。

休假概况

从休假概况模块获得休假应用详细信息。该模块可以实现如图64所示的GUI，包括针对日期范围、过程名称、位置或者其他特性的筛选器。

图65示出了休假应用120的数据流程图。休假应用120可以确定当前的休假分配(6502)，并根据可用配额来确定是否批准休假。例如，如果某日的配额不可用(6504)并且经理没有剩余的特殊配额(6506)，则拒绝休假。否则(6506)，休假应用120可以确定任何人的积存假期是否可用(6508)。

如果休假可用，休假应用120可以批准休假(6512)；否则，员工可以选择在没有批准薪水的情况下尝试休假(6510)。员工可以根据期望取消休假(6514)。否则，可以批准休假(6516)。按照特定于休假应用120的数据模式来存储相关的休假数据。

出勤应用122实现管理出勤、验证出勤和报告出勤的逻辑和界面。为了管理出勤，图66中所示界面显示了针对所选过程和日期的已调度团队名称。主管可以通过在链接“标记出勤”6602上点击来标记出勤。通过点击图形化视图链接6604，用户可以得到针对所选日期和过程的出勤状态数据的图形化表示，例如，作为3D饼图6606。可以通过位置来筛选数据。

为了核实出勤，图67中所示的界面允许主管标记其各自团队成员的出勤。该界面还提供在主管/后备主管缺席的情况下由团队实时地标记出勤。此外，通过每日的出勤来调整用户的个人、补休和病假积存。

图68示出了出勤应用122的数据流。具体地，跟踪各类出勤状态，并将其按照特定于出勤应用122的数据模式进行存储。例如，如果员工上班(6802)，可以存储该状态。如果员工没有上班，则出勤应用122可以确定该员工是否具有已计划的休假。如果是，并且员工具有剩余的积存假期(6804)，则相应地减少已计划假期积存(6806)。如果员工是病假，则同样相应地减少病假积存。如果没有病假剩余(6808)，则出勤应用122可以扣除已计划假期(如果有任何可用的话)。如果员工缺勤，但是没有剩余积存假期，可以通知主管，或者可以逐层上报以进行查阅。另一方面，如果为员工安排了补假，但是员工在进行工作，则相应地增加积存假期(6810)。

出勤报告模块可以实现报告过程人数的界面，其具有诸如日期范围、过程名称、时区和位置的筛选器。图69示出了用于出勤报告的示例GUI。图70示出了过程概况GUI，图71示出了团队概况GUI。

My OneView

员工信息访问应用136(“My OneView”)是为组织的员工设计的。组织内的每个员工可以具有对该应用的访问权。在一个实现中，My OneView包括如下模块：My OneView问题、我的联系详细信息、我的积存假期、我的喜好链接、我的记录、我的出勤、改变密码、我的团队层级、搜索员工、我的日程、我的商业Id、查看历史列表、我的团队联系详细信息和管理团队联系。可以实现更多、更少或者不同的功能模块。

My OneView问题模块登记员工使用系统所遇到的问题。图72示出了该模块的GUI的示例。当员工自己提出问题时，则其证书显示在相应的文本框中。GUI提供位置的录入/选择、问题概述以及详细的问题描述。

该模块还有助于代表任何其他员工提出问题。当选中复选框7202(“on behalf of(代表)”)时，显示文本框。在文本框中，员工可以录入他所代表的提出该问题的员工的员工代码。在录入员工代码时，图72中所示的GUI更新为显示代表其提出问题的员工的证书，而不是登录该模块的员工的证书。

我的联系详细信息模块允许员工保持和更新联系详细信息。员工可以选择联系类型，例如通信地址或者原籍。员工可以将其相应的地址录入文本框，并选择城市、州、国家和地区。员工还可以录入邮政编码、固定电话号码、移动电话号码、传真号以及其是否需要接送(例如，去往或者来自工作场所)。在完成之后，联系详细信息发给主管批准，并且存储在数据库102中。交通运输应用124、HR部门或者其他区域可以处理该信息，以确定例如员工的公用车安排。图73示出了录入联系详细信息的GUI的示例。

我的积存假期模块显示GUI(例如，如图74所示)，其可以是只读的，并且描述员工的积存假期。该GUI可以显示假期类型(例如，补假、可选和固定)以及特定休假类型的积存假期。还显示针对其显示积存假期的详细员工信息(例如，姓名、过程名称、主管姓名、团队名称等)。

我喜好的链接模块跟踪员工的喜好链接。员工可以录入URL、标题以及对链接的评价。如图75所示，可以分别从Edit(编辑)和Delete(删除)链接来编辑或者删除上述域的内容。

我的记录模块跟踪用户的记录。员工可以书写记录的标题，并且录入详细的记录本身。GUI同样可以提供编辑记录。图76示出了示例GUI。

我的出勤模块接受员工输入，以标记他或她的出勤。详细的员工信息也同轮班细节一起显示。图77中示出了示例GUI。

改变密码模块有助于改变客户用户(诸如非员工或者合同工)的密码。图78中示出了示例GUI。

我的团队层级模块根据团队名称生成团队层级的视图。该模块还根据诸如位置、过程名称和团队名称的标准进行排序。其他排序标准包括公司任期(例如，以月为单位)以及按照升序和降序来布置记录。在找到团队成员详细信息时，模块接受团队成员姓名选择，继而检索团队成员层级和网络详细信息。图79示出了示例GUI。

搜索员工模块搜索组织内的员工。该模块可以根据其详细信息被搜索的员工的员工代码进行搜索。该模块继而呈现员工详细信息，诸如层级详细信息、网络详细信息和版本信息。该模块可以使用诸如图80所示的GUI。

我的日程模块根据名册来显示出勤、每周休息日和员工的其他日程信息的视图。该模块还将显示针对该日程的详细员工信息。图81示出了该模块的示例GUI。

我的商业ID模块显示员工的不同商业ID的视图。该模块根据过程名称以及商业ID来按照升序或者降序对ID进行排序。该模块还显示详细的员工信息，以及各商业ID的密码。图82示出了该模块的示例GUI。

查看节假日列表模块呈现节假日列表的视图。该模块根据节假日类型(可以使固定类型或者可选类型)进行排序。该模块还根据位置和历年来进行排序。该模块还显示节假日的详细信息，诸如日期、节假日名称和节假日类型。图83示出了该模块的示例GUI。

我的团队联系详细信息模块显示团队的联系详细信息。该模块可以根据过程名称和团队名称或者其他标准来进行排序。该模块还可以根据联系类型(可以使临时通信或者永久联系)来进行排序。该模块响应于在根据排序标准显示员工联系地址的弹出式窗口上点击员工姓名。图84示出了该模块的示例GUI。

管理团队联系模块有助于团队联系的管理。具体地，主管可以使用该模块来更新他或她的团队成员的联系信息。该模块可以接受对联系类型的选择，诸如通信地址或者原籍。主管继而可以在文本框中录入地址，并继而针对城市、州、国家和地区进行各种选择。主管还可以录入邮政编码、固定电话号码、移动电话号码、传真号以及员工是否需要接送。可以将完成的信息发送给主管以便批准，并且该信息可由交通运输应用或者其他应用用来确定公用车调度或者其他交通工具决策。图85示出了该模块的示例GUI。

该模块还允许代表任何其他团队成员来管理团队联系。当选中复选框(“代表”)时，该模块可以显示接受员工代码的文本框。作为响应，可以呈现图86中所示的GUI，其显示了员工的联系详细信息以用于编辑。

图87示出了My OneView的数据流程图。具体地，员工可以选择上面阐释的任何模块(8702)。数据通过架构100流回主数据库102。作为示例，当员工更新地址(8704)或者雇主更新地址(8706)时，可以批准该更新(8708)，并将其存储在主数据库102中。

交通运输应用124管理和报告与员工有关的交通运输(“adhoc”)。交通运输应用124可以批准或者拒绝adhoc请求，并且可以被划分为：由adhoc请求模块、批量adhoc请求模块以及批准/拒绝adhoc请求模块来处理的管理任务；以及由adhoc报告模块、接送名册模块和联系信息名册模块处理的报告任务。

Adhoc请求模块提交adhoc请求。员工可以为其自己提出adhoc请求，或者可以为其他员工提出请求。该模块填入创建adhoc请求的人员的员工详细信息。该模块可以接受诸如adhoc类型、接/送日期、adhoc原因以及注释的adhoc参数。该模块可以从数据库102中维护的名册填入轮班开始时间和轮班结束时间。图88示出了该模块GUI的示例。与上面描述的其他模块类似，该模块的GUI可以包括“代表”选择器，其允许个人为其他员工进行adhoc请求。

批量Adhoc请求模块提出批量adhoc请求。批量adhoc请求可以由多个员工进行请求而引起。为此，图89中所示的模块GUI可以接受以逗号隔开的员工代码列表，以及诸如过程名称、adhoc类型、原因、轮班开始时间和轮班结束时间的其他信息。

批准/拒绝adhoc模块有助于主管对团队成员生成的adhoc请求进行批准和拒绝。在主管批准请求之后，该模块可以显示询问是否向交通运输部门发出请求的弹出式窗口，以及显示adhoc详细信息并具有打印adhoc请求的选项的弹出式窗口。图90和图91示出了该模块GUI的示例。

关于报告，Adhoc报告模块跟踪所生成的adhoc请求。交通运输部门可以使用所跟踪的信息来获取adhoc请求的详细信息，诸如员工姓名、adhoc类型、日期、原因、时间以及批准人数据。图92中示出了adhoc报告GUI的示例，其允许通过员工代码、开始日期、截止日期、过程名称、位置、团队名称以及其他参数来进行搜索和报告。

接送名册模块显示针对请求交通的用户的、通过过程和位置排序的、特定日期范围的接送名册。交通部门可以使用交通名册模块来建立将要到来的一周的接送路线计划。图93示出了交通运输GUI的示例。

联系信息报告模块检索和显示请求接送的员工的详细联系信息。可以通过录入员工代码并选择“搜索”来生成该报告，并且可以基于过程和位置来排序该报告。该模块响应于点击包含用户详细地址的弹出式窗口上的员工姓名。图94示出了该模块GUI的示例。

图95示出了交通运输处理的流程图。交通运输应用124接受adhoc请求(9502)或者批量adhoc请求(9504)。批准或者拒绝该请求(9506)，将请求传送给交通运输部门(9508)，并将其存储在主数据库102中。

架构100包括案例管理应用，其可以具有三个逻辑部分：账户性管理(“AIM”)应用106、在线订单处理(“KANA”)应用108以及销售订单录入(SOE)应用110。作为概述，案例管理应用捕获任何非语音过程中的平均处理时间(AHT)。案例管理应用可以在逻辑上或者物理上划分为以下界面：我的案例、管理案例、案例批次、管理错误类型、管理特许权以及编辑账户信息。

“我的案例”界面支持以下任务：登记新案例、对已登记案例进行工作、基于所选日期查看案例、使用不同的筛选器搜索案例以及对案例执行以下动作：“是”、“否”、“搁置”和“提交”。图96示出了“我的案例”GUI 9602以及支持账户信息GUI界面9604的示例。用户可以通过点击“添加新案例”按钮来登记新案例。在选择批号和账户号之后，可以从主数据库102检索其他详细信息(诸如，行业、错误类型以及特许权)并将其填入该界面。

案例管理应用支持AHT/ACW/回转时间计算。为此，案例管理应用捕获以下多个时间戳：

开始时间：

当用户点击“添加新案例”时(通过图96中所示的界面9602的链接或者按钮)，应用捕获当前时间作为“开始时间”。

启动时间：

当用户点击账户信息GUI 9604上的“保存账户详细信息”选项时，应用捕获当前时间作为“启动时间”。

结束时间：

当用户点击案例动作界面(图97中示出了一个示例)上的“保存”选项时，应用捕获当前时间作为“结束时间”。换言之，当已经在案例中采取动作时，捕获结束时间。

案例管理应用确定如下测量：

AHT(平均处理时间)＝(开始时间-结束时间)；

ACW(呼叫工作以后，或者结尾时间)＝(启动时间-开始时间)。这是用来建立日志的时间。

TAT(回转时间)＝(结束时间-启动时间)。

“管理案例”界面为主管/经理显示已登记的案例以及由其各自的团队成员提交给他们继续工作的案例。图98示出了管理案例界面的示例。该界面可以是实时显示。该界面可以支持基于以下标准筛选的数据：员工、日期、账户号、团队名称、案例状态、审计案例或者其他标准。该界面可以显示案例信息，包括：案例号、批号、账户号、创建人姓名、清除和审计状态、回转时间、提交或者其他信息。该界面通过显示各个所选案例的账户信息来对嵌入在案例号中的链接进行响应。

“管理批次”界面例如可由主管或者经理用来添加和编辑批次详细信息，以及使批次详细信息活跃或者不活跃。每个批次可以映射到其特定的行业和错误类型。图99示出了管理批次界面的示例。该界面可以根据批次类型进行筛选，并且可以显示批次信息，诸如批号、批次类型、批次中的案例数目、接收日期、创建者姓名以及活跃/不活跃状态。

“管理错误类型”界面可以用来例如根据特定的行业来添加或者编辑错误类型，以及使得错误类型活跃/不活跃。图100示出了管理错误类型界面的示例。

“管理特许权”界面可以用来添加/编辑特许权详细信息，以及使特许权详细信息活跃或者不活跃。图101示出了管理特许权界面的示例。

“管理AIM注释”界面可以用来添加或者编辑AIM注释详细信息，以及使特定注释活跃或者不活跃。图102示出了管理AIM组件界面的示例。

“SOE呼叫类型跟踪器”界面跟踪由案例管理SOE代理接收到的呼叫的类型。销售类型也由该界面跟踪。图103示出了SOE呼叫类型跟踪器界面的示例。如图103所示，可以将多个类型指派给任何呼叫(例如，Service Check(服务检查)和Cancel Order(取消订单))。

“AIM案例报告”界面可以接受搜索参数，并显示匹配案例。该界面可以通过开始日期、截止日期、批号、案例状态、注释类型或者其他标准进行筛选。图104示出了AIM案例报告界面的示例。

在线订单处理应用108可以提供SOE呼叫类型详细信息GUI，诸如图105中所示。该界面可以根据日期范围、员工代码或者其他类型进行筛选。

图106示出了SOE呼叫类型报告GUI。SOE呼叫类型报告GUI可以显示销售订单条目信息，诸如员工代码、员工姓名、销售类型、系统类型、呼叫类型和创建日期。该GUI可以通过员工代码、日期范围或者其他标准进行筛选。

图107示出了用于跟踪案例处理的数据流程图。员工录入批号(10702)，案例管理应用检查该批次是否为活跃(10704)，并且在不活跃的情况下使该批次活跃(10706)。员工继而可以保存指派给该批次的案例的详细信息(10708)。可以在个体基础上执行关于案例的决策(10710)。如果案例是困难的并且被指派以搁置状态，可以将员工重新指派到另一案例(10712)。如果案例无法解决，可以为该案例指派“否”状态，并且可以关闭该案例(10714)。可以将引用案例转送给主管来处理(10716)。为已解决的案例指派“是”状态，并且将相关的案例数据存储在主数据库102中。

图108示出了与图107类似的数据流程图。然而，图108示出：案例管理应用可以结合上传到系统的案例批次进行工作(10802)。系统可以自动将案例分配给个人来解决，或者系统可以接受人工输入以将案例指示给特定员工(10804)。

图109示出了用于SOE呼叫跟踪的数据流程图。员工设定系统类型(10902)、销售类型(10904)、呼叫类型(10906)以及针对销售订单而捕获的任何其他数据。案例管理应用将数据保存在主数据库102中。

ID管理应用116创建、管理和报告员工标识号。图110示出了用于ID管理应用116的ID创建的示例GUI。该GUI可以捕获以下信息以用于创建标识号：姓名、描述、用于创建的回转时间(以小时为单位)、组织Id/客户指定ID、请求类型或者任何其他相关数据。

图111示出了用于管理员工商业ID的示例GUI。该GUI有助于创建和管理员工过程和商业相关的ID。该GUI按照员工代码、过程名称来筛选数据，以及按照商业ID和顺序或者其他标准来进行排序。

图112示出了用于ID管理的数据流程图。员工选择过程名称(11202)，并且可选地选择要上传的文件(11204)，该文件可以包含商业ID(11206)或者商业ID密码(11208)。架构100确定ID是否已经存在(11210)，并且覆盖已有的ID和密码(11214)，或者存储新的ID和密码(11212)。ID数据存储在主数据库102中。

调动管理应用126管理员工或者团队成员在雇佣或者过程之间的调动。员工或者团队成员调动可以包括员工或者团队成员的调入、调出以及过程内调动。调动管理应用126可以包括管理模块，其使用例如图113中所示的GUI来附近团队调动。可以通过点击“createnew movement(创建新调动)”按钮11302来安排新的调动。可以通过点击GUI中的数据域中嵌入的链接11304来查看已有的调动许可证。

图114中示出了调动创建界面的示例。调动创建界面包括用于“来自”或者“去往”的调动标准录入字段：不同的功能、过程和/团队，以及接受原因、安排日期以及请求审阅者的录入。可以提供其他调动选项。

在一个实施方式中，调动可以有三种类型：

调入(新员工调入生产)；

调出(员工调出目前的业务)；以及

过程内调动。

在点击“得到团队层级”11402时，界面检索层级/要选择的团队成员姓名的列表，如“团队成员姓名”下的界面中所示。在选择员工之后，用户可以选择“安排调动”按钮11404，以告知系统继续。ID管理应用126可以向员工、主管或者受调动影响的其他个人发送通知(例如，电子邮件消息)。

ID管理应用126中的“批准调动”模块提供了如下界面，相应的经理通过该界面来批准调动请求。图115中示出了示例GUI。该GUI可以在日期域中提供链接11502。该链接导致了图116中所示的批准GUI的显示。批准GUI接受对动作(例如，批准、取消或者转发给他人)的选择，并且允许主管保存部署。

图117示出了用于调动管理的数据库框图。调动可以发生在过程内(11702)、过程外(11704)或者进入过程(11706)。主管录入去往/来自信息、调动原因、所安排的调动日期以及任何其他参数(11708)。当主管选择团队层级时，调动管理应用126取回员工列表(11710)。主管从列表中选择一个或多个员工(11712)，安排调动(11714)，并且将调动请求提交给经理进行批准(11716)。如果调动获得批准，则调动过程完成，并且进行安排(11718)。在任何情况下，将已批准或者取消的调动数据存储在主数据库102中。

图118示出了用于对呼叫中心架构中的多个呼叫中心应用的操作进行协调的逻辑流11800。逻辑流11800最初包括按照在多个呼叫中心应用数据集需求之间统一的主数据组织模式来建立主应用数据存储库(11802)。逻辑流11800继而可以包括对主数据组织数据模式进行细分(11804)。在一个实现中，对主数据组织数据模式进行细分包括将主数据组织数据模式细分为：第一应用数据模式，其支持第一呼叫中心应用的第一应用数据集需求；以及第二应用数据模式，其支持第二呼叫中心应用的第二应用数据集需求。此外或者备选地，逻辑流11800可以包括按照主数据组织模式来建立公共应用数据模式，其实现对第一呼叫中心应用和第二呼叫中心应用共同的的共享数据集需求(11806)。

在对主数据组织数据模式进行细分(11804)和/或建立公共应用数据模式(11806)之后，逻辑流11800继而进行到建立呼叫中心应用通信接口(11808)。呼叫中心应用通信接口此后可以用于从呼叫中心应用接收数据请求。

逻辑流11800继而可以进行到启动多个呼叫中心应用的执行。例如，逻辑流11800可以进行到启动案例管理应用的执行(11810)，启动减员管理应用的执行(11812)，启动休假管理应用的执行(11814)，以及启动调动管理应用的执行(11816)。在备选实现中，逻辑流11800可以包括启动更少或者更多的呼叫中心应用的执行。此外，逻辑流11800可以包括启动其他呼叫中心应用的执行，诸如人力资源应用或者其他呼叫中心应用。

呼叫中心应用通信接口继而可以从呼叫中心应用接收呼叫中心数据请求(11818)。例如，呼叫中心应用通信接口可以从案例管理应用、减员管理应用、休假管理应用以及调动管理应用接收呼叫中心数据请求。然而，呼叫中心应用通信接口不能从任何呼叫中心应用接收呼叫中心数据请求，或者呼叫中心应用通信接口可以仅从一个呼叫中心应用接收呼叫中心数据请求。其他配置也是可能的。

逻辑流11800继而进行到处理接收到的呼叫中心应用数据请求(11820)。逻辑流11800可以包括多个不同类型的处理，包括：先进先出处理、先进后出处理、同时处理、循环处理或者任何其他类型的处理。通过呼叫中心应用通信接口从第一呼叫中心应用接收第一呼叫中心应用数据请求。

图119示出了用于认证用户的逻辑流11900的一个示例。最初，可以向用户呈现登录屏幕或者其他图形用户界面(11902)。登录屏幕或者其他图形用户界面可以配置用于从用户接收认证证书，诸如用户名和密码。然而，在一些实现中，认证证书可以仅是用户名或者仅是密码。

一般地，用户可以是任意类型的用户。在一个实现中，逻辑流11900识别两种类型的用户：固定工用户和合同工用户(也称为访客用户)。尽管逻辑流11900可以使用任何类型的认证机制，在一个实现中，逻辑流11900被配置用于使用三种类型的认证机制之一来认证用户(11904-11908)。认证机制(11904-11908)可以被配置用于根据用户类型来认证用户。

第一认证机制使用域服务器数据库11918来认证用户，其中用户提供认证证书集合，标识该用户是固定工用户(11904)。在一个实现中，第一认证机制除了接收用户提供的认证证书之外，还接收域名服务器的名称。第一认证机制可以使用域名服务器数据库11918和主应用数据存储库102来认证用户。

第二认证机制使用主应用数据存储库102来认证用户，其中用户提供一组认证证书集合，标识该用户是合同工或者访客用户(11906)。在第二认证机制中，逻辑流11900可以继续进行到主应用数据存储库102，以确定用户是否提供了合同工或者访客用户的、一组可接受的认证证书。

最后，第三认证机制使用本地当前账户(诸如域ID)来认证用户，而不使用密码来确认用户(11908)。第三认证机制还可以使用主应用数据存储库102来认证用户。

在接收到认证证书之后，逻辑流11900继而进行到认证用户(11910)。认证用户可以包括：逻辑流11900确定用户是否被认证(11912)。在认证机制标识用户是已认证用户的情况下，逻辑流11900将用户标识为授权用户(11916)。类似地，在认证机制标识用户是非认证用户时，逻辑流11900将用户标识为非授权用户(11914)。尽管逻辑流11900可以包括一个认证机制，逻辑流11900可以使用一个或多个认证机制来认证用户。其他认证机制也是可能的。

图120示出了在用户进行呼叫时向用户显示清单的图形用户界面12000的一个示例。在图形用户界面12000中显示的清单可以与过程相关联。该清单可以列出各种动作、项目或者与相关联过程有关的其他需求。例如，清单中的动作之一可以读取“Apologized andEmpathised(道歉和同情)”，其向用户指明用户应当在呼叫时或者在过程中道歉和同情。图形用户界面12000还可以显示诸如复选框、单选按钮或者其他控件的控件，用户可以激活这些控件来表明用户已经完成了清单中的项目、动作或者其他需求。

附图中所示的元素如上所述的互操作。不考虑所描述的具体实现，所有讨论本质上都是示例性的而非限制性的。例如，尽管将所选的方面、或者实现的组件描述为存储在存储器中，但是符合本发明的所有或者部分系统和方法可以存储在其他机器可读介质上、在其间分布或者从其读取，其中机器可读介质例如：次存储设备，诸如硬盘、软盘和CD-ROM；从网络接收到的信号；或者目前已知或者以后开发的其他形式的ROM或者RAM。

此外，尽管描述了本发明的特定组件，但是符合本发明的方法、系统和产品可以包括附加的或者不同的组件。例如，处理器可以实现为微处理器、微控制器、专用集成电路(ASIC)、离散逻辑或者其他类型的电路和逻辑的组合。类似地，存储器可以是DRAM、SRAM、闪存或者任何其他类型的存储器。标志、数据、数据库、表、实体和其他数据结构可以单独存储和管理，可以包含在单个存储器或者数据库中，可以是分布式的，或者可以在逻辑上和物理上按照多种不同方式来组织。程序可以是单个程序的部分、单独的程序或者可以跨过多个存储器和处理器分布。

尽管描述的本发明的各种实施方式，对本领域技术人员而言易见的是，在本发明的范围内可以有更多实施方式和实现。因此，本发明仅受所附权利要求书及其等价项的限制。

Claims (23)

1.一种呼叫中心应用数据和互操作架构，所述架构包括：

主应用数据存储库，包括在多个呼叫中心应用数据集需求之间统一的主数据组织模式，所述主数据组织模式包括模式细分，其定义：

所述主数据组织模式内的第一应用数据模式，其特定于针对第一呼叫中心应用的第一应用数据集需求；

所述主数据组织模式内的第二应用数据模式，其特定于针对第二呼叫中心应用的第二应用数据集需求；

呼叫中心应用通信接口，其可操作以：

从与所述呼叫中心应用通信接口通信的所述第一呼叫中心应用接收第一呼叫中心应用数据请求；

从与所述呼叫中心应用通信接口通信的所述第二呼叫中心应用接收第二呼叫中心应用数据请求；以及

处理器，其耦合至所述呼叫中心应用连接接口和所述主应用数据存储库，并且可操作以：

响应于所述第一呼叫中心应用数据请求，按照所述主应用数据存储库中的所述第一应用数据模式来执行第一数据操作，以此来处理所述第一呼叫中心应用数据请求，从而减轻所述第一呼叫中心应用的第一应用本地数据库开销；以及

响应于所述第二呼叫中心应用数据请求，按照所述主应用数据存储库中的所述第二应用数据模式来执行第二数据操作，以此来处理所述第二呼叫中心应用数据请求，从而减轻所述第二呼叫中心应用的第二应用本地数据库开销。

2.根据权利要求1所述的架构，其中所述模式细分进一步定义公共应用数据模式，所述公共应用数据模式实现对于所述第一呼叫中心应用和所述第二呼叫中心应用共同的共享数据集需求。

3.根据权利要求1所述的架构，其中所述共享数据集需求包括员工数据集需求，其包括彼此相关的多个数据集群组，所述群组包括：

团队细节数据集群组；

员工一般信息数据集群组；

员工地址信息数据集群组；

员工组织详细信息数据集群组；

用户登录证书详细信息数据集群组；

员工层级详细信息数据集群组；以及

用户群组权利详细信息数据集群组。

4.根据权利要求1所述的架构，其中所述第一呼叫中心应用数据请求包括监管管理案例数据请求组分。

5.根据权利要求1所述的架构，其中所述第一呼叫中心应用数据请求包括案例分配数据请求组分。

6.根据权利要求1所述的架构，其中所述第一呼叫中心应用数据请求包括SOE呼叫跟踪数据请求组分。

7.根据权利要求1所述的架构，其中：

所述第一应用数据模式将所述第一应用数据集需求划分为数据集子需求，所述数据集子需求包括：

第一数据集子需求，包括：

案例特许权数据集群组；

批次详细信息数据集群组；

案例错误数据集群组；

案例注释数据集群组；

案例动作数据集群组；

案例当前状态数据集群组；

案例信息数据集群组；以及

已登记案例动作数据集群组；

第二数据集子需求，包括：

kana案例动作历史数据集群组；

kana案例最终状态数据集群组；

kana已登记案例动作数据集群组；以及

kana案例信息数据集群组；以及

第三数据集子需求，包括：

已登记呼叫详细信息数据集群组；

呼叫类型详细信息数据集群组；以及

用户呼叫详细信息数据集群组。

8.根据权利要求1所述的架构，其中所述第一呼叫中心应用数据请求包括监管建立职责目标数据请求组分。

9.根据权利要求1所述的架构，其中所述第一呼叫中心应用数据请求包括监管管理职责安排数据请求组分。

10.根据权利要求1所述的架构，其中：

所述第一应用数据模式将所述第一应用数据集需求划分为彼此相关的多个数据集群组，所述彼此相关的多个数据集群组包括：

主管职责描述数据集群组；

主管目标描述数据集群组；

目标历史数据集群组；

主管职责日志活动目标数据集群组；

已完成职责数据集群组；

职责安排数据集群组；以及

目标描述数据集群组。

11.根据权利要求1所述的架构，其中：

所述第一应用数据模式将所述第一应用数据集需求划分为彼此相关的多个数据集群组，其中每个群组被指派以所述第一应用数据集需求的子集；以及

所述第二应用数据模式将所述第二应用数据集需求划分为彼此相关的多个数据集群组，其中每个群组被指派以所述第二应用数据集需求的子集。

12.一种用于对呼叫中心架构中的多个呼叫中心应用的操作进行协调的方法，所述方法包括：

按照在多个呼叫中心应用数据集需求之间统一的主数据组织模式来建立主应用数据存储库；

将所述主数据组织数据模式细分为：

第一应用数据模式，其支持针对第一呼叫中心应用的第一应用数据集需求；

第二应用数据模式，其支持针对第二呼叫中心应用的第二应用数据集需求；

建立呼叫中心应用通信接口；

通过所述呼叫中心应用通信接口从所述第一呼叫中心应用接收第一呼叫中心应用数据请求；

通过所述呼叫中心应用通信接口从所述第二呼叫中心应用接收第二呼叫中心应用数据请求；以及

按照所述主应用数据存储库中的所述第一应用数据模式来执行第一数据操作，以此来处理所述第一呼叫中心应用数据请求，从而减轻所述第一呼叫中心应用的第一应用本地数据库开销；以及

按照所述主应用数据存储库中的所述第二应用数据模式来执行第二数据操作，以此来处理所述第二呼叫中心应用数据请求，从而减轻所述第二呼叫中心应用的第二应用本地数据库开销。

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

按照主数据组织模式建立公共应用数据模式，所述公共应用数据模式实现对于所述第一呼叫中心应用和所述第二呼叫中心应用共同的共享数据集需求。

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

启动作为所述第一呼叫中心应用的案例管理应用的执行；并且其中：

所述第一应用数据模式包括案例管理应用数据模式，并且所述第一应用数据集需求包括针对所述案例管理应用的案例管理数据集需求。

15.根据权利要求12所述方法，进一步包括：

启动作为所述第一呼叫中心应用的减员管理应用的执行；并且其中：

所述第一应用数据模式包括减员应用数据模式，并且所述第一应用数据集需求包括针对所述减员应用的减员数据集需求。

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

启动作为所述第一呼叫中心应用的休假管理应用的执行；并且其中：

所述第一应用数据模式包括休假管理应用数据模式，并且所述第一应用数据集需求包括针对所述休假管理应用的休假管理数据集需求。

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

启动作为所述第一呼叫中心应用的调动管理应用的执行；并且其中：

所述第一应用数据模式包括调动管理应用数据模式，并且所述第一应用数据集需求包括针对所述调动管理应用的调动管理数据集需求。

18.一种设备，包括：

数据存储库建立装置，用于按照在多个呼叫中心应用数据集需求之间统一的主数据组织模式来建立主应用数据存储库；

细分装置，用于将所述主数据组织数据模式细分为：

第一应用数据模式，其支持针对第一呼叫中心应用的第一应用数据集需求；

第二应用数据模式，其支持针对第二呼叫中心应用的第二应用数据集需求；

应用通信接口建立装置，用于建立呼叫中心应用通信接口；

第一接收装置，用于通过所述呼叫中心应用通信接口从所述第一呼叫中心应用接收第一呼叫中心应用数据请求；

第二接收装置，用于通过所述呼叫中心应用通信接口从所述第二呼叫中心应用接收第二呼叫中心应用数据请求；

第一处理装置，用于按照所述主应用数据存储库中的所述第一应用数据模式来执行第一数据操作，以此来处理所述第一呼叫中心应用数据请求，从而减轻所述第一呼叫中心应用的第一应用本地数据库开销；以及

第二处理装置，用于按照所述主应用数据存储库中的所述第二应用数据模式来执行第二数据操作，以此来处理所述第二呼叫中心应用数据请求，从而减轻所述第二呼叫中心应用的第二应用本地数据库开销。

19.根据权利要求18所述的设备，进一步包括：公共应用数据模式建立装置，用于按照所述主数据组织模式建立公共应用数据模式，所述公共应用数据模式实现对于所述第一呼叫中心应用和所述第二呼叫中心应用共同的共享数据集需求。

20.根据权利要求18所述的设备，进一步包括：第一启动装置，用于启动作为所述第一呼叫中心应用的案例管理应用的执行；并且其中：

所述第一应用数据模式包括案例管理应用数据模式，并且所述第一应用数据集需求包括针对所述案例管理应用的案例管理数据集需求。

21.根据权利要求18所述的设备，进一步包括：第二启动装置，用于启动作为所述第一呼叫中心应用的减员管理应用的执行；并且其中：

所述第一应用数据模式包括减员应用数据模式，并且所述第一应用数据集需求包括针对所述减员应用的减员数据集需求。

22.根据权利要求18所述的设备，进一步包括：第三启动装置，用于启动作为所述第一呼叫中心应用的休假管理应用的执行；并且其中：

所述第一应用数据模式包括休假管理应用数据模式，并且所述第一应用数据集需求包括针对所述休假管理应用的休假管理数据集需求。

23.根据权利要求18所述的设备，进一步包括：第四启动装置，用于启动作为所述第一呼叫中心应用的调动管理应用的执行；并且其中：

所述第一应用数据模式包括调动管理应用数据模式，并且所述第一应用数据集需求包括针对所述调动管理应用的调动管理数据集需求。

Images