用于解决服务请求的方法和系统与流程

本发明涉及用于接收和解决服务请求的方法和系统。本发明特别适用于诸如信息技术软件和硬件支持之类的行业，特别是在诸如服务技术人员之类的服务资源的部署和对服务技术人员的服务请求的分配中。本发明还可以适用于其他行业，例如，在会计、法律或其中消费者请求服务并且要求解决这些请求的任何其他服务行业中。

背景技术：

诸如信息技术服务行业之类的服务行业具有致力于响应于来自消费者的服务请求而提供技术支持的员工和/或承包商。一旦诸如信息技术服务组织之类的组织接收到与事件相关联的服务请求(例如，用户无法发送和/或接收电子邮件)，就会产生待处理任务(或“支持票据”，如信息技术服务行业中已知的)，该待处理任务保持未完成，直到事件得到解决，通常通过技术支持人员的到场和动作来解决。

典型地通过生成可供技术支持人员(例如，服务技术人员或与能够提供技术支持的组织相关联的任何员工/个人)使用的未完成或“开放”支持票据的列表来管理消费者向服务行业组织提交的服务请求。典型地，还记录与特定服务请求相关联的事件描述，并且使其可供技术支持人员使用，该技术支持人员能够查看与开放支持票据的列表中的任何支持票据相关联的描述，并且选择要在其上开始工作的支持票据。

传入服务请求典型地由与服务提供方相关联的运营商手动管理，该服务提供方在接收到服务请求时生成支持票据，并且将解决服务请求的任务指派给可用于处理该请求的服务技术人员。然后将服务请求添加到已经分配给该特定服务技术人员的开放支持票据的列表中，并且该服务请求保持待处理，直到被服务技术人员选择。虽然当存在相对少量的传入服务请求时，对服务请求的手动管理和分配仍然是可管理且可行的，但是在存在大量同时传入服务请求的情况下，该过程进行管理变得越来越困难且不可行。

另外，作为管理服务请求的当前过程的一部分，典型地不会对服务技术人员的技能、经验、资格或可用性给予准确的考虑，这经常可能导致与由于支持票据已经被指派给的支持人员缺乏必要属性而仍未得以解决的一个或多个支持票据相关联的事件。类似地，与简单任务相关的支持票据经常被指派给具有高每小时费率的高技能服务技术人员，这不仅导致客户不必要的支出，而且还浪费了宝贵的服务资源的技能和时间。

允许技术支持人员查看开放支持票据的完整列表以及相应事件的任何相关联的描述的当前方法高效地意味着服务技术人员能够基于服务技术人员的偏好从可用的开放支持票据的列表中“挑出并选择”任何开放支持票据。在这方面，具有解决起来困难或耗时的相关联的事件的支持票据往往保持未被服务技术人员选择，因此在开放支持票据的列表内保持未完成并且滞留。从消费者的角度来看，这是有问题的，因为已经提交了难以解决的事件的细节的客户有时被要求等待几天(甚至几周)以使特定服务请求受到关注并且使事件得以解决。从服务组织的角度来看，这也是有问题的，因为缺乏服务效率往往会导致客户不满意并且导致对组织声誉的潜在损害，从而导致客户参与度降低并且最终导致收入损失。

在其中支持票据要求具有特定技能、资格和/或经验的技术人员的关注以便高效地完成任务并解决事件的情形中，技术支持人员基于偏好来“挑出并选择”支持票据的能力也是有问题的。在这种情况下，如果技术人员选择要求超出该特定服务技术人员的技能集合或被要求的可用性的属性的支持票据，则该事件可能保持未解决，将花费比否则将要求的时间更长的时间来完成，将重新出现或将要求具有必要技能、经验和资格的替代技术人员的关注。应当认识到，这些结果中的每一个都是耗时的，因此从提交服务请求的客户的角度来看是令人沮丧和不期望的。从服务组织的角度来看，这些结果也是不期望的，因为它们实质上阻碍了服务的高效提供。

服务技术人员最初解决客户服务请求的当前安排经常导致询问客户不相关的问题。从客户的角度来看，现有系统的该特定方面是令人沮丧且不期望的，并且可能导致服务组织的顾客流失，或者至少与高效递送的服务递送相比提供低效、耗时且成本更高的服务递送。

与初始服务技术人员接收来自客户的联系并询问与客户无关的问题相关联的问题越来越多地导致客户变得沮丧并寻求他们要求的服务的替代供应商。呼叫中心位于境外或远离客户位置尤其是这样的情况，但无论如何，在接收到初始呼叫的服务技术人员不知道客户的已安装清单的情况下，他们通常会询问与客户无关的问题。初始服务技术人员通常是相对低技能的操作员，他们针对客户请求创建开放票据，之后将开放票据传递给具有适当技能的技术人员以解决客户的请求。

诊断和管理服务请求的当前方法通常要求服务技术人员使用存储器、在线论坛或手册来排解问题。存储器的使用要求每个技术人员依赖于在一段时间内获得的其自己的知识、技能和经验，因此要求服务技术人员准确地保留和重新收集信息。此外，在线论坛经常是不准确或过时的，并且手册也经常是过时或不可用的。因此，在尝试解决客户的服务请求时使用存储器、在线论坛和/或手册导致不一致的服务质量，其中不同的技术人员经常使用不同的解决步骤来处理相同的任务。

与诊断和管理服务请求的当前系统和方法相关联的另一个问题是服务请求的结果中的不一致。例如，同一服务请求可能由一个特定的服务技术人员解决，但是当被指引到另一个服务技术人员时保持未解决。

与用于管理服务请求的当前系统相关联的另外的问题包括服务技术人员有时无法及时响应服务请求，并且还无法根据在服务提供方与客户之间的客户服务协议中建立的紧急程度对任务划分优先级。

因此，需要在服务行业内接收和高效地调解服务请求的系统和方法。本发明的系统和方法寻求解决上面提到的与调解服务请求的当前系统和方法相关联的问题中的至少一些和/或提供替代方案。应当认识到，虽然参考信息技术行业描述了本发明，但是本发明的系统和方法可以适用于提供一个或多个服务的任何行业。

技术实现要素：

诊断和初始尝试解决服务请求

在一个方面，本发明提供了一种用于解决来自客户的请求的服务请求解决系统，该系统包括：计划维护组件，其包括用于维护计划的一个或多个处理器，计划包括详述多个客户的清单的清单数据结构；专家指导维护组件，其包括请求解决数据结构，该请求解决数据结构包括用于关于在清单数据结构中详述的清单的项目来解决请求的可能动作；以及专家指导系统，其包括可操作以用于动态地激活和/或停用请求解决数据结构的组件的一个或多个处理器，组件的激活或停用根据特定客户的计划来实现。

请求解决数据结构优选地根据主题专家的集体知识和用于解决客户请求的任何过程偏好和/或要求来定义响应于任何服务请求的可能动作。如果与修理设备相比更换设备的成本不那么昂贵，则“过程偏好”可以包括更换设备而不是尝试修理设备的动作。“要求”可以包括根据法规要求而要求执行的动作，例如，需要更换任何磨损或损坏的布线。

将认识到，由于专家指导系统可操作以用于根据特定客户的计划动态地激活或停用请求解决数据结构的组件，因此能够关于客户使用的所有清单项目来更新/修改(如要求的)请求解决数据结构，但是请求解决数据结构在特定客户要求时通过激活和/或停用组件来专门定制和/或配置。

例如，根据本发明的实施例，如果客户具有使用windows10操作系统进行操作的多台计算机，则在与客户的位置相关联的计划内维护的清单数据结构将详述使用windows10操作系统的所有计算机。在客户更新其it系统并引入一台或多台使用macos进行操作的计算机的情况下，将与客户的位置相关联的计划更新为使得在清单数据结构中详述该附加清单。一旦使用macos(表示附加清单)的计算机包含于在客户的计划中维护的清单数据结构内，则专家指导系统将激活请求解决数据结构的涉及macos的组件，使得用于关于运行macos的计算机来解决请求的动作呈现给接收请求并与客户进行初始对话的初始服务技术人员。

在实施例中，在请求解决数据结构内定义的每个动作被指派熟练度。指派的熟练度是个人(例如，服务技术人员)必须具有以便处理动作的最低熟练度。

动作在本发明的上下文内可以是涉及服务请求的问题，或者可以是作为解决过程的一部分而要求执行的任务。

将认识到，请求解决数据结构可以随时间扩展为包括与先前未预料到的事件相关联的动作，或者可以扩展为覆盖附加清单，例如，由软件开发者发布的新操作系统或在市场上可用的新设备。

鉴于随时间扩展请求解决数据结构的能力，本发明的系统和方法能够被迅速地配置为适应新的由客户安装的清单的项目。组件的动态激活和/或停用减少了否则将向客户询问的无关问题的数量，并且还适应新的客户清单的项目，这导致更高效且成本高效的解决过程，从而有助于服务提供方满足他们与客户的服务级别协议(sla)。

在实施例中，一个或多个计划可以与位置级别、子位置级别处的客户相关联，或者可替代地，可以与客户设备或系统级别相关联。在替代实施例中，计划可以与最高级别处的客户相关联并且包含所有位置、子位置和设备。

计划可以特定于客户或位置，或者可以适用于多个不同的客户或位置。

计划在本发明的上下文内可以定义组织内的高级别的清单，例如，在组织内的所有计算机上实现的计算机操作系统。例如，组织内的所有计算机都运行microsoftwindows2008操作系统。

可替代地，计划可以定义较低级别的清单，包括组织内特定位置处的个体设备，并且可以包括设备的细节以及操作该设备的基本要求。例如，组织内的所有计算机都连接到epsonworkforcewf-3640打印机，这些打印机要求电源、纸张和墨盒(全部详述规格和/或部件号)来进行操作。还可以包括定期维护要求的细节。

术语“清单”在本发明的上下文内包括设备和/或系统(以及这些设备和/或系统的任何相关联的操作要求)、客户(或客户的组)、人员或有某种关联的人员的群体。清单还包括位置、子位置甚至虚拟位置，例如，组织内的科室或部门。

例如，医疗机构(医院)可以具有各种科室或部门，例如，心内科、儿科等部门，这使得专家指导系统根据一个或多个计划来激活和/或停用请求解决数据系统的组件。

术语“清单”在本发明的上下文内还可以指无形清单，并且包括由个人、人员的群体或公司提供和/或供应的服务。例如，对于会计师事务所，公司的无形清单可以包括公司供应的一项或多项服务，例如，完成年度个人纳税申报。

因此，术语“清单”关于计划有效地包括与特定客户相关的内容，以便使专家指导系统激活和/或停用请求解决数据结构的组件。

例如，清单可以包括但不限于操作系统(软件)、硬件、公用设施(电力、燃气、水)、文具、销售点(pos)机器、照明、警报器、烹饪装置、冰箱、加热/冷却系统。

在实施例中，该系统还包括客户服务要求维护组件，其中维护服务要求数据结构，该服务要求数据结构定义关于每个客户的一个或多个服务要求。

“客户服务要求”可以包括由客户指定所有服务请求要在指定的时段内并且在预定义的预算内完成。

在实施例中，向请求解决数据结构内的每个动作指派优先级。

在实施例中，优先级被指派给与多个客户中的每个客户相关联的位置或子位置。在实施例中，优先级可以与请求的源相关联，例如，在特定客户位置或子位置处提交请求的个人。可替代地，可以通过在特定位置或子位置处进行系统监视来自动生成请求。在实施例中，指派的优先级将受制于客户与服务提供方之间存在的任何服务级别协议的条款。

“位置”在本发明的上下文内可以是诸如站点、场所、人员或人员的群体之类的物理位置，或者可以是诸如站点或场所内的房间(例如，办公室或会议室)之类的子位置。可替代地，“位置”可以是位于位置或子位置内的设备(例如，个人计算机)，并且可以包括元素的层次结构。

在实施例中，该系统包括针对由服务职员生成的每个服务票据计算总优先级的一个或多个处理器，该服务职员接收来自客户的服务请求。在实施例中，总优先级是基于向每个动作、请求的源或位置指派的优先级中的一个或多个的。

将认识到，将计划与包括用于解决请求的可能动作的请求解决数据结构结合使用，使得能够将与作为服务请求的主体的设备特别相关的动作提供给服务资源(例如，服务职员)，这避免在第一实例中需要具有技能的资源来处理服务请求。这使得服务提供方能够更高效地分配资源，并且还避免由于分配具有高每小时收费费率的高技能资源来创建与否则可以由较低技能和较低每小时收费费率的资源解决的服务请求相关的服务票据，而对客户过度收费。

在实施例中，系统包括清单映射工具，使得客户的清单能够在清单数据结构内被识别和维护。

将认识到，从一开始就识别客户的清单的能力结合根据客户计划激活或停用请求解决数据结构的组件的能力，消除或至少大大减少了使客户在服务请求解决过程期间遇到无关的问题和任务。

例如，如果组织中的所有计算机使用windowsos进行操作，则与客户相关联的计划将其反映为清单数据结构的一部分，使得请求解决数据结构的与解决macos事件相关联的任何组件将被停用。因此，专家指导系统不会提示处理初始服务请求并且创建服务票据的初始服务技术人员向与解决与运行macos的计算机相关的事件相关联的客户呈现任何询问。

将认识到，通过将计划与请求解决数据结构和专家指导系统结合使用，将大大减少否则在典型的解决过程中将向服务技术人员呈现的可能问题/解决路径的列表，从而避免或至少减少在尝试解决服务票据时的不相关询问和动作。

在实施例中，例如，在客户购买一个或多个新设备的情况下，能够将清单数据结构更新为包括附加清单。可替代地，例如，在客户从其场所中移除一个或多个设备的情况下，清单数据结构能够被更新为删除现有清单。

在另一方面，本发明提供了一种解决来自客户的服务请求的计算机实现的方法，该方法包括：在计划维护系统组件中维护一个或多个计划，该一个或多个计划包括详述多个客户的清单的清单数据结构；在专家指导维护组件中维护请求解决数据结构，该请求解决数据结构包括用于关于在清单数据结构中详述的清单的项目来解决请求的可能动作；以及通过使用专家指导系统来激活和/或停用请求解决数据结构的组件，其中，组件的激活或停用是根据特定客户的计划来实现的。

在另一方面，本发明提供了一种由服务职员解决来自客户的服务请求的计算机实现的方法，该方法包括：服务职员访问用于解决来自客户的请求的服务请求解决系统，该系统包括：计划维护组件，其包括用于维护计划的一个或多个处理器，计划包括详述多个客户的清单的清单数据结构；专家指导维护组件，其包括请求解决数据结构，该请求解决数据结构包括用于关于在清单数据结构中详述的清单的项目来解决请求的可能动作；以及专家指导系统，其包括可操作以用于激活或停用请求解决数据结构的组件的一个或多个处理器，组件的激活或停用根据特定客户的计划来实现，服务职员如专家指导系统指导地完成一系列动作，其中，服务请求被解决，或者在服务职员无法解决服务请求的情况下，与服务请求相关联的服务票据被分配给服务资源。

将认识到，在实施例中，“服务职员”可以是初始服务技术人员，其接收关于事件的客户通信并发起服务请求和/或生成服务票据。因此，“服务职员”在本发明的上下文内是与服务提供方相关联的能够接受客户查询并发起服务请求的任何个人。与服务资源相比，服务职员典型地具有较低的技能，因此与服务资源相比将具有较低的熟练度。由于服务职员的技能和熟练度较低，服务职员典型地不会根据每小时收费费率为他们的时间收费。可替代地，如果服务职员具有每小时收费费率，则其与服务资源的每小时收费费率相比典型地会更低。

在实施例中，客户可以通过电话呼叫、电子邮件或通过使用与本发明的系统相关联的应用界面来报告与服务请求相关联的事件。可替代地，可以连续地或定期地监视组织的一个或多个清单项目，并且例如服务票据形式的服务请求可以在检测到诸如故障或维护要求之类的事件时由系统自动发起。

在另一方面，本发明提供了一种存储一个或多个指令的计算机可读介质，该一个或多个指令当由与专家指导系统相关联的一个或多个处理器执行时，使得一个或多个处理器进行以下操作：激活或停用请求解决数据结构的组件，其中，组件的激活或停用是根据客户计划来实现的，客户计划包括详述多个客户的清单的清单数据结构，其中，客户计划在计划维护系统组件中被维护，并且其中，请求解决数据结构在专家指导维护组件中被维护，并且包括用于关于在清单数据结构中详述的清单的项目来解决请求的可能动作。

在实施例中，该系统还包括跟踪系统，其包括可操作以用于维护服务历史数据结构中的服务历史的一个或多个处理器。

由于根据本发明的一个实施例的系统能够维护初始解决过程的历史，因此在无法解决服务请求并且将与服务请求相关联的服务票据分配给服务资源的情况下，服务资源能够查询在服务历史数据结构内捕获的服务历史，从而消除资源重复在初始解决过程期间已经处理的任何动作。

将与服务请求相关联的服务票据分配给服务资源

在实施例中，该系统还包括资源信息维护组件，其包括用于维护资源数据结构的一个或多个处理器，该资源数据结构包括可用于关于清单的项目来解决请求的多个资源。

在实施例中，包括一个或多个处理器的专家指导系统可操作以用于根据与每个资源相关联的一个或多个最低标准来动态地激活或停用资源数据结构内的多个资源中的一个或多个资源。

在实施例中，一个或多个最低标准包括资源的技能、熟练度、合规性、经验以及可用性中的任何一个或多个。

术语“合规性”在本发明的上下文内包括但不限于由资源获得的学术、技术或监管资格中的任何一个或多个。

在实施例中，该系统还包括确定与服务请求相关联的服务票据要被分配至的资源的一个或多个处理器，其中，分配是基于与以下各项中的任何一项或多项结合的服务请求的：请求解决数据结构，其中，一个或多个组件根据客户计划被激活和/或停用；资源数据结构，其中，一个或多个资源根据与每个资源相关联的一个或多个最低标准被激活和/或停用；客户请求的计算出的总优先级；以及在服务要求数据结构内维护的涉及与服务请求相关联的客户的一个或多个服务要求。

在实施例中，资源在没有关于服务请求的细节的任何知识的情况下被分配服务票据。因此，资源在分配时将仅看到与服务票据相关联的最少细节，其中这样的最少细节可以包括生成待处理请求的时间和关于服务请求的来源的细节(即，提交服务请求的(多个)人员或公司的细节)，或者在系统自动接收并记录事件的情况下(在没有人员通过电话或在线提交的服务请求的情况下)，源详述接收到并自动记录的服务票据。在该实施例中，仅在服务资源接受服务票据时，向服务资源提供与服务相关联的所有细节(除了已经提供的最少细节之外)。

将认识到，在该实施例中，一旦服务资源接受服务票据，一旦与先前票据相关联的服务请求已经被解决和/或服务票据已经被标记为“已完成”，则系统仅允许服务资源接受下一个待处理服务票据。因此，从服务资源中保留与服务票据相关联的细节中的至少一些细节有助于避免服务资源基于偏好而拒绝与服务请求相关联的服务票据的情形。

在另一方面，本发明提供了一种使得能够由资源解决来自客户的服务请求的计算机实现的方法，该方法包括：资源访问用于解决来自客户的请求的服务请求解决系统，该系统包括：计划维护组件，其包括用于维护计划的一个或多个处理器，计划包括详述多个客户的清单的清单数据结构；专家指导维护组件，其包括请求解决数据结构，该请求解决数据结构包括用于关于在清单数据结构中详述的清单的项目来解决请求的可能动作；以及专家指导系统，其包括可操作以用于激活和/或停用请求解决数据结构的组件的一个或多个处理器，组件的激活和/或停用根据客户计划来实现，资源指示其准备好访问与服务请求相关联的服务票据；资源被分配下一个服务票据，其中，分配是基于以下各项中的任何两项或更多项的组合的：与客户相关联的计划，服务请求的计算出的总优先级，与资源相关联的最低标准，以及与客户相关联的一个或多个服务要求。

在实施例中，服务要求包括但不限于：商定的且可接受的服务时段，服务请求要在该商定的且可接受的服务时段内被解决；用于解决事件的预算/成本；能够处理该请求的服务资源的规范(例如，仅具有特定资格和经验评级的服务资源可以处理与特定客户相关的服务请求)；以及商定的时间，在该商定的时间内服务请求可以受到关注。

在实施例中，资源的一个或多个最低标准包括资源的技能、熟练度、合规性、经验以及可用性中的任何一个或多个。

术语“事件”在本发明的上下文内包含要求提供服务或某种动作的任何故障或问题，并且本质上典型地是但不一定是技术性的。事件的示例是人员的计算机无法发送和/或接收电子邮件。在另一示例中，事件可以是将职工成员添加到公司系统数据库的请求。事件可能包括咖啡馆业务断供咖啡豆或客户要求园丁倾向于修剪其草坪。因此，将认识到，术语“事件”在本发明的上下文内具有广泛的含义。

可能在信息技术领域内出现的可能事件的示例包括但不限于意外的系统关闭，计算机未启动，无法打印文档，无法连接到互联网，无法发送/接收电子邮件，数据丢失，无法打印，以及通过一种或多种病毒或对系统的未经授权的访问破坏系统安全性。将认识到，这些是本发明的方法和系统包含的事件的示例，而并不旨在提供详尽的列表。

还将认识到，本发明的系统和方法还包括管理与可能在其他服务行业中出现的事件相关联的服务请求。这些服务行业可以包括但不限于提供各种器具的维修的服务行业，包括电视和其他形式的家庭娱乐设备、电器(包括咖啡机、洗衣机、洗碗机、冰箱)、供暖和空调服务以及园艺服务。再次强调，将认识到，这些仅仅是本发明的方法和系统可以在其中使用的各种服务行业的示例，而不旨在提供详尽的列表。

在本发明的上下文中，术语“服务提供方”包括提供服务的任何个人、组或组织。将认识到，服务可以是任何类型的服务，并且在一个实施例中，服务包括但不限于与信息技术行业相关的服务。其他服务提供方可以包括但不限于会计师和会计师事务所、律师事务所、教育机构和/或教育者，或者运输、健康和酒店行业内的服务提供方。

将认识到，服务资源包括能够提供技术或其他方面的支持以便解决事件的一个或多个人员。在实施例中，服务资源包括一个或多个服务技术人员。在其他实施例中，服务资源可以是会计、医疗保健提供方、教育者或园丁。因此，术语“服务资源”在本发明的上下文内具有广泛的含义。

每个服务资源将与一个或多个标准相关联，使得特定服务请求能够被分配或者可用于满足一个或多个最低标准的特定服务资源。这样的最低标准可以包括但不限于服务资源的收费费率，服务资源的经验、技能和/或评级，服务资源的资格以及服务资源的可用性。

在实施例中，本发明的方法还包括对响应于服务请求由服务职员或服务资源执行的服务的记录进行监视和/或维护的步骤。因此，服务提供方可以监视和记录服务职员或资源完成任务所花费的时间，并且将监视的内容用于质量保证目的以及服务职员和资源的培训。

将认识到，客户在本发明的上下文内可以包括任何数量的人员，包括但不限于单个人员、两个或更多个人员的群体、诸如医院或教育机构之类的机构或者公司。

在实施例中，在客户是单个人员的情况下，客户可以例如在线或通过电话提交与一个或多个事件相关的请求。这种事件可能出现在例如个人计算机上。

在实施例中，在客户是公司的情况下，客户可以具有位于单个位置或者可替代地位于技术维护和支持由服务提供方根据服务级别协议负责的一系列位置的多台计算机。在该实施例中，服务提供方可以同时提交多个服务请求，并且使多个待处理服务请求等待由服务提供方服务。

将认识到，在实施例中，无论客户是单个人员、两个或更多个人员的群体、教育机构还是公司，可以根据在客户与服务提供方之间商定的服务级别来管理向客户提供的任何技术支持。在实施例中，通过服务级别协议来管理服务级别，服务级别协议的条款在与本发明的系统相关联的服务要求数据结构内维护。

本发明的实施例还允许服务提供方监视服务请求的进度，并且监视和评估服务职员或资源响应于服务请求而提供的服务的质量。

本发明的系统可以以单个应用或者可替代地分布式应用的形式来执行计算机指令代码。在实施例中，该系统在安全的第三方云提供方平台上可公开访问地操作。然而，在其他实施例中，系统可以是在具有受限的用户访问的私有云或组织特定的数据中心上操作的私有应用。

在实施例中，本公开的系统可以由公司购买、许可或以其他方式获得以供内部使用。因此，公司可以使用该系统在内部管理服务请求，而无需涉及公司外部的服务提供方或请求公司外部的服务提供方的服务。

系统界面可以是在多个设备上操作的任何常规界面，这些设备包括但不限于个人计算机、笔记本电脑、移动(智能)电话、ipad或平板电脑以及允许管理员或用户进行交互并且使用本发明的系统的设备。系统界面还可以通过要求用户输入例如访问系统的唯一用户名和密码来允许对用户的凭证进行认证。系统可以另外或可替代地采用使用随机生成的pin验证的方法。

附图说明

现在将参考(多张)附图更详细地描述本发明的(多个)实施例，其中：

图1a和图1b是根据本发明的实施例的系统和方法的概述的图解表示。

图2是根据本发明的实施例的服务职员在处理客户服务请求时所采取的步骤的图解表示。

图3是根据本发明的实施例的“位置”在本发明的上下文内的定义以及清单的项目如何可以与客户位置相关联并存储在系统应用内的图解表示。

图4是示出根据任何实施例的在本发明的系统内维护的位置(设备)和计划如何被链接并且交互以便生成涉及客户提交的服务请求的所要求的动作的列表的图解表示。

图5是根据本发明的实施例的系统界面的图示，其中示出了报告事件的个人(客户)的细节。

图6涉及根据本发明的实施例的授权矩阵。

图7涉及根据本发明的实施例的事务矩阵。

图8是根据本发明的实施例的计划的示例。

图9是根据本发明的实施例的另一计划的示例。

图10示出了根据本发明的实施例的请求解决数据结构的一部分，其示出了特定动作(问题)。

图11是根据本发明的实施例的系统界面的图示，其示出了与图10的动态专家指导系统中的特定动作相关的信息。

图12是根据本发明的实施例的系统界面的图示，其提供与特定服务资源相关的信息。

图13是系统界面的图示，其提供与在图12中所示的界面中详述的服务资源的合规性相关的信息。

图14是系统界面的图示，其详述了各种动作的列表及其指派的熟练度级别，指派的熟练度级别表示服务资源必须具有以便处理动作的所要求的最低熟练度级别。

图15是系统界面的图示，其详述了在图12中所示的界面中详述的服务资源的各种熟练度。

图16是根据本发明的实施例的新(待处理)服务票据的示例。

图17是根据本发明的实施例的已解决服务票据的示例。

具体实施方式

为方便起见，将关于特定实施例描述本发明，然而，本领域技术人员将认识到，本发明不限于该特定实施例。

图1a和图1b提供了根据本发明的实施例的系统的概述，特别地示出了服务器(100)，其中应用(102)包括关于位置模块(105)中的所有客户位置和设备的信息，包括位于客户场所内的诸如房间和办公室之类的子位置以及位于其中的任何设备。因此，术语“位置”在本发明的上下文内将被广义地解释为包括客户的物理位置或地址，或位于客户场所内的房间，或位于客户场所内的特定房间内的设备。

应用(102)还包括计划维护组件(110)，其包括一个或多个处理器，用于维护包括清单数据结构的计划，该清单数据结构详述客户的组织内的清单(例如，所有设备和系统以及操作这些设备和系统的任何要求)。应用(102)还包括请求解决数据结构(115)，其包括多个组件，其中每个组件详述涉及特定设备的一组动作。根据本发明的实施例，动作是作为任何解决过程的一部分要由例如服务职员回答的问题。可替代地，根据本发明的任何实施例，动作可以是作为任何解决过程的一部分服务职员要执行的任务。

应用(102)还存储和维护由例如服务职员生成的所有服务票据(120)，这些服务票据在一个或多个队列(125)中维护。应用(102)还包括位于分配模块(130)中的一个或多个处理器，其确定任何服务票据传送到特定资源(例如，服务技术人员)的定时，其中传送根据各种因素(如将在下面进一步讨论的)。应用(102)还包括资源信息维护组件(135)，其中维护与由服务提供方采用的(或以其他方式与服务提供方相关联的)每个服务技术人员相关联的信息，包括但不限于技能、处理各种定义的任务的熟练度、资格、位置、可用性以及与每个资源相关联的任何其他相关细节(例如，资源是否可以对客户场所进行现场访问，或者他们是否只能远程工作)。

图1a、图1b和图2还详述了根据本发明的实施例的服务职员(162)为了解决客户(140)请求的服务请求而采取的步骤。在客户(140)关于事件(例如，设备(155)故障或错误)提交服务请求时，服务职员(162)在其系统应用界面(165)上接收服务请求的细节，并且在步骤(170)中生成票据(130)。将认识到，存在客户可用于提交服务请求的各种选项(例如，通过与本发明的系统相关联的在线应用界面，通过电话或通过电子邮件)，并且在该实施例中，客户(140)通过在其计算机上访问的系统界面(150)提交请求。

服务票据(130)包括关于服务请求的细节，包括请求的源(即，提交请求的个人及其位置(即，他们的物理地址)，与错误或故障相关联的设备和该设备的位置，以及作为解决过程的一部分呈现给服务职员的多个问题(动作)。服务票据(130)还包括服务票据的状态，即，票据是“待处理”，“已分配和排队以供传送”、“已解决”还是“已传送”给服务技术人员。

参考图1b，存在服务票据(130)在解决过程期间可能遵循的两条可能的路径。第一条路径在图1b中指示为路径a，其中服务票据(130)最终由服务职员(162)在没有更高熟练度和技能的服务资源的任何协助或审查的情况下解决。第二条路径在图1b中指示为路径b(以及相关联的路径b1、b2和b3)，其中在服务职员(162)在初始诊断和解决过程期间无法解决服务请求的情况下，服务票据(130)被传送到服务资源(180)。

为了进行初始诊断并尝试解决由客户(140)关于设备(155)提交的服务请求，服务职员(162)由出现在界面(165)上的一系列动作提示，并且回答各种问题和/或执行具体针对性的且与设备(155)相关的任务。将认识到，关于客户(140)提交的服务请求提供给服务职员(162)的该一系列动作将是位于请求解决数据结构(115)中并且在解决数据结构(115)中维护的所有可能动作的子集，并且将特别地涉及设备(155)。在一个实施例中，这通过使用与设备(155)相关联的一个或多个计划来实现，该计划使得与系统应用相关联并且包括一个或多个处理器的专家指导系统(未示出)激活请求解决数据结构(115)内的与设备(155)特别相关的组件。与设备(155)相关联的一个或多个计划还将使得专家指导系统将请求解决数据结构(115)的与设备(155)不相关的任何组件停用。

将认识到，虽然在该实施例中，一个或多个计划与设备(155)相关联，但是本发明的系统和方法还设想将一个或多个计划与组织的子位置(例如，组织内的房间和办公室)链接(或以其他方式相关联)，或者甚至与组织本身链接或以其他方式与组织本身进行关联。

在初始诊断和解决过程期间服务职员(162)无法解决服务票据(130)的情况下，则服务票据(130)遵循图1b中指示为路径b的路径(以及相关联的路径b1、b2和b3)。特别地，路径b示出了服务票据(130)自动升级并分配到特定队列(在该实例中是队列a、b或c中的一个)，其中每个队列与满足最低标准的一个或多个资源相关联。例如，如果动作被指派的最低熟练度为10中的6(例如)，则将服务票据分配给这样的队列，从该队列只能发生向具有6或更高熟练度的一个或多个资源进行传送。

服务票据(130)向特定队列的自动分配取决于在位于服务器(100)内的系统应用(102)中输入、存储、更新和维护的多个因素。这些因素包括但不限于特定动作的指派的熟练度(即，指派给特定问题或任务的最低熟练度，其定义了处理该动作的服务资源的最低熟练度级别)，资源的最低标准(包括但不限于资源的技能、经验、熟练度和合规性)，票据的指派的优先级，服务技术人员的可用性，以及提交服务请求的客户与服务提供方之间的任何服务级别协议的条款。

图1a、图1b和图2还示出了监视设备(190)，其由与服务提供方相关联的服务递送管理器(195)使用，以确保服务票据不会被错过或者在超过任何指派的优先级或客户的服务级别要求的一段时间内保持任何队列。服务递送管理器(195)还可以使用监视设备(190)来查看与任何服务票据相关联的历史和进度。

在将服务票据(130)分配给队列b之后，服务技术人员(180)通过诸如笔记本电脑、计算机、智能电话、平板电脑等之类的电子通信设备(未示出)访问系统应用(102)，并通过选择电子选项指示他们已准备好接收并接受队列中的下一个服务票据。

在实施例中，在对关于客户(140)提交的服务请求的细节没有任何了解的情况下，服务技术人员(180)被分配并接收服务票据(130)。因此，服务技术人员(180)在分配时仅看到与服务票据(130)相关联的最少细节，其中这样的最少细节可以包括生成待处理请求的时间和关于服务请求的来源的细节(即，客户(140)的细节)。一旦技术人员(180)接受服务票据(130)，将向服务技术人员(180)显示所有相关细节，包括服务职员(162)在初始诊断和解决过程期间采取的步骤的服务历史。

一旦服务技术人员(180)接受服务票据(130)并获得对服务票据(130)的访问权，服务技术人员(180)能够查看票据的细节，关于服务职员(162)尝试初始解决服务票据时采取的步骤和动作的服务历史，以及与解决票据相关联的任何要求。在这方面，由于根据实施例的本发明的系统被配置为使得能够在系统服务器内记录和维护初始解决过程的完整历史，因此服务资源(例如，技术人员)能够查询在系统应用(未示出)的服务历史数据结构内捕获的服务历史，从而避免或至少降低服务资源采取已经在初始解决过程期间由服务职员处理的任何动作的可能性。除了帮助服务提供方满足服务提供方与客户之间存在的任何服务级别协议的条款之外，这还具有减少解决服务票据的时间的相关联的益处。

一旦服务技术人员(180)接受服务票据(130)，一旦与服务票据(130)相关联的服务请求已经被解决和/或服务票据已经标记为“已完成”，系统仅允许服务技术人员(180)接受下一个待处理的服务票据。因此，从服务资源(130)中保留与服务票据相关联的细节中的至少一些细节，从而避免其中服务资源基于偏好拒绝与服务请求相关联的服务票据的情况。

在服务技术人员(180)能够解决与服务票据(130)相关联的服务请求的情况下，服务票据(130)被标记为“已完成”并且关闭。然而，在服务技术人员(180)无法解决与服务票据(130)相关联的事件的情况下，要求服务技术人员(180)提供与服务票据(130)相关联的服务请求不能解决的原因，并且作为与服务票据(130)相关联的解决过程的服务历史的一部分记录该原因。特别地，要求服务技术人员(180)记录为了解决票据(130)而采取的任何步骤的细节，并且还指示妨碍技术人员解决票据的能力的任何因素。这些因素可能包括例如无法访问客户站点的特定部分以便解决票据，或者可替代地无法获得修复与设备(155)相关联的错误或故障所要求的任何部分。在这些情形中，票据将遵循路径b2返回到队列b并等待服务技术人员(180)在以后的日期的进一步动作或与最初接受服务票据(130)的服务技术人员(180)相比具有更高技能和/或熟练度的另一服务技术人员的进一步动作。

图3是根据本发明的系统和方法的实施例的如何可以识别组织(客户)的不同部分和任何相关联的清单项目并且将其存储在系统应用(102)的位置模块(105)内的图解表示。特别地，图3详述了典型的组织结构，其在该实施例中以分层次序示出，包括作为整体的组织在顶层的位置，随后是组织的子位置a、b和c，其表示组织的位于不同地点(例如，不同城市)的办公室。图3还详述了位于位置b的各种设备a、b、c和d，分别包括笔记本电脑(325)、计算机(330)、打印机(335)和销售点(pos)机器(340)。因此，组织(300)，子位置a、b、c和d以及设备a、b、c和c在本发明的上下文内都表示“位置”，一个或多个计划可以应用于、链接到“位置”或以其他方式与“位置”相关联。

图4中更清楚地示出了计划与位置之间的关联，其中设备b(计算机(330))与存储在位于服务器(100)中的系统应用(102)内的计划维护组件(102)中的两个计划(a和b)(335)相关联。与设备b(计算机(330))相关联的计划a和b使得专家指导系统激活和/或停用请求解决数据结构(115)的组件，以便生成与设备b(计算机(330))相关的一组动作(问题和/或任务)。因此，请求解决数据结构(115)内不涉及设备b的任何动作都不会出现在由服务职员(162)生成的服务票据(130)中。将认识到，将一个或多个计划应用于位置(无论该位置是指组织位置、子位置还是组织内的特定设备或系统)不仅消除了在初始诊断和/或解决过程期间向服务职员显示的任何不必要的动作(从而避免向客户询问与其提交的服务请求无关的任何问题)，而且减少了与解决过程相关联的时间和成本的量。

将认识到，参考图1至图4描述的实施例涉及提交请求的客户，然而，将认识到，在其他实施例中，可以由能够通过例如电话、电子邮件或其他手段接受来自客户的服务请求的、服务提供方(例如，信息技术公司)的员工提交请求。因此，用户在本发明的上下文内可以是报告事件的人，或者可以是尝试解决事件的人。在一些实施例中，报告事件的用户也是尝试解决事件的用户。

虽然在图1至图4中没有设想替代实施例，但是系统可以通过对客户场所内的一个或多个设备进行连续或定期监视/监督来自动发起服务请求。因此，当本发明的监视/监督系统识别和/或记录设备的故障时，系统将自动记录服务请求和/或生成服务票据。

为了提交服务请求并生成服务票据(130)，用户(在这种情况下是客户(140)(其可以是个人或公司))使用诸如智能电话、平板电脑、计算机或笔记本电脑之类的电子通信设备进入系统，并且通过使用如图5所示的示例的界面输入用户名和密码来访问与本发明的系统相关联的基于web的应用。可替代地，客户(140)可以简单地通过电话呼叫或电子邮件记录服务请求。如从图5中可以看出的，除了客户(140)的用户名和密码之外，用户的名字、姓氏(姓)、固定电话号码、移动电话号码、电子邮件地址、用户在公司内的角色和职位(在客户(140)是公司的代表的情况下)也被输入并记录在系统数据库中。如果需要，根据实施例的系统还允许针对客户(140)的名称输入附加注释，例如，客户(140)关于任何服务请求能够进行授权的支出的量。在用户是初次用户的情况下，存储所有用户信息并将其保存到系统中，以便如果同一用户将来访问系统，系统将识别出该用户并且他们的细节将被自动调用。

一旦客户(140)已经提交了服务请求，则提示服务职员(162)从被指定为与位于客户(140)的公司内的特定设备相关联的计划的一部分的可用事件/问题列表中选择特定事件(有时可能以问题的形式提出)。一旦已经提交了服务请求，则系统检查客户(140)是否被授权关于特定事件提交服务请求，如果是，则进行对服务请求的诊断和初始解决。

在客户(140)没有足够的权限来提交服务请求的情况下，系统确定是否能够识别具有足够权限来批准该请求的另一个人，如果否，则分配该服务请求进行人工处理。此时，可以与公司的相关人员(例如，总经理)讨论服务请求，以便推进服务请求。

另外，特定用户是否被授权提交请求典型地取决于与解决特定事件相关联的预期的服务时间或预算考虑因素。例如，如果服务请求与要求大量时间和/或支出来解决的事件相关联，并且预期的时间和/或支出高于提交请求的用户被授权的限制，则系统将检查以找到公司内具有足够权限来批准服务请求的下一人。

图6的授权矩阵中示出了系统如何跟踪人员被授权的限制的示例，该授权矩阵识别特定公司内的四个职位(默认，sdm(服务递送经理)，md(总经理)和om(运营经理))。在图6所示的示例中，可以看出公司内的所有职位都具有在数小时后提交非现场服务请求和现场服务请求的权限，然而md是唯一具有批准资本支出(capex)的权限的个人，并且还具有批准要求长达20小时的服务时间和总额高达999999美元的票据的服务请求的权限。sdm和om都具有批准总额高达100000美元的票据的权限，并且处于默认职位的所有员工都具有请求300美元的总票据支出的权限。

在识别出具有足够权限来批准该请求的个人并且该个人不批准该请求的情况下，可以更新系统以使其将服务请求标记为“已取消”。可替代地，在服务请求由具有足够权限来批准请求的个人批准的情况下，然后系统检查服务请求是否能够在各种要求内完成，包括在存在于客户与提供技术支持的服务提供方之间的服务级别协议(sla)的上下文内商定的任何要求。将认识到，该步骤涉及系统检查各种要求，包括但不一定限于：

·优先级/操作小时数——即，事件是否可以在一天中的特定时间得到调解？

·预算——即，事件是否可以在批准的机构内解决？

·熟练度/合规性——即，服务资源是否具有充分/已批准的熟练度和/或资格来解决问题？

·政策——即，是否适用阻止服务资源解决事件的任何政策，例如，奖励、法规或工会政策？

为了检查是否能够在所有设定的要求内解决服务请求，系统检查与向服务职员提出以尝试解决与服务请求相关的事件的每一个预定义问题相关联的各种元素。在这方面，与由系统检查的特定预定义问题(事件)相关联的各种预定义信息可以包括但不限于：

·用于完成任务以便解决与事件相关联的(多个)问题的设定和/或要求的时间；

·用户完成任务以便解决与事件相关的(多个)问题所要求的最低熟练度和资格(合规性)；

·(多个)问题是否可以在非现场采取动作/完成，或是否要求现场访问；

·指派的与事件相关的(多个)问题的子优先级。

为了检查特定服务请求是否可以在指定或商定的预算内完成，根据实施例的本发明的系统采用“事务矩阵”。图7提供了根据本发明的实施例的事务矩阵的示例，其列出了在特定计划内对于各种任务/服务请求收费的费率，并且还在与系统相关联的会计平台内将总账(gl)代码指派给特定事务。

如从图7中可以看出的，除了与事务类型(即，事务是现场还是非现场的)相关联的不同计费费率之外，还指定了计划类型(“pro”)。图7中示出的事务矩阵中还指定了每种事务类型的适用计费参数：

·时间段(即，费率按每分钟、每5分钟、每小时等收费)

·最短收费时段(即60分钟或其中的一部分)

·是否适用任何免费时间(即，前10分钟)

在服务请求能够在与客户与服务提供方之间的现有服务级别协议相关联的所有设定要求内完成，并且初始服务资源(例如，呼叫中心内的服务职员)对于处理请求(或与请求相关联的特定动作)具有必要熟练度的情况下，系统生成要求服务职员回答/完成的一个或多个动作。一旦服务职员响应提出的动作，则系统检查是否能够由于响应先前的动作而解决与服务请求相关联的事件。在事件得以解决的情况下，系统将更新，使得将服务请求标记为“已解决”。然而，在事件仍未解决的情况下，系统检查以了解是否存在尝试解决事件时可以提出的任何进一步的动作。

在存在进一步的动作的情况下，则系统生成要由服务职员回答/完成的进一步动作，然后系统在每个动作的生成之间重复所有要求的检查，以确保下一个动作满足所有要求，包括该动作是否仍然落在服务职员的熟练度范围内，以及动作的完成是否落在提交请求的个人的权限范围内。

在实施例中，并且作为票据生成过程的一部分，系统还基于指派的联系人(提交请求的人)的子优先级、与服务请求相关联的要求的操作以及事件位置的组合来确定要指派给服务票据的总优先级。在无法在初始诊断/解决过程内在与服务票据的总优先级相关联的预定义时间段内解决服务票据的情况下，服务票据排队以供分配给满足一个或多个最低标准的一个或多个服务资源，最低标准选自但不限于：

·可用性——即，在所要求的和/或预定义的时间段内可用于处理服务票据的服务资源；

·熟练度——即，基于技能和经验，服务资源是否具有所要求的最低熟练度评级；

·合规性——即，基于培训和资格，服务资源是否具有所要求的最低合规性；

·预算——即，服务资源是否具有适当的收费费率，使得服务请求能够在任何商定或设定的预算内得以解决。

如先前描述的，计划在本发明的上下文内可以非常具体地定义为适用于特定设备，或者可以更广泛地定义和应用于例如特定组织或与组织相关联的一个或多个位置。例如，根据本发明的实施例的计划可以具体地定义为适用于运行apple操作系统(例如，macos8)的特定设备，或者可以可替代地，更广泛地定义为适用于客户和所有其特许经营商或子公司。在实施例中，可以定制计划以适应特定公司的要求。因此，计划可以针对特定设备，并且特定客户计划可以包括针对与特定客户的清单匹配的各种设备的多个计划。虽然计划通常不是特定于公司(或客户)的，但是计划可以特定于公司(或客户)，并且在实施例中，计划被设计和调整，使得它们可以在尽可能多的位置(即，相对于客户或设备)使用。

图8提供了计划的示例，其包括仅与执行windows2012r2操作系统的设备相关的特定问题。因此，如果公司的一个或多个设备安装和配置了windows2012r2，则公司可以选择将图8中所示的计划作为其服务级别协议的一部分，使得在用户登录系统时向用户呈现与执行windows2012r2软件的设备相关的各种动作(问题和任务)，其示例在图8的计划中示出。

图9提供了详述计划(“pro”)的界面的另一示例，该计划适应适用于其上安装和配置各种操作系统的多个设备的更广泛的动作。在图9所示的计划中，除了关于公司可能要求支持的各种事件提供的动作之外，该计划还指定(如图9中所示界面的最顶层单元格所示)每月第1天向公司收取45美元的月度支持维护费。

将认识到，图8和图9中呈现的计划仅是公司(客户)可能作为公司与服务提供方之间的任何服务级别协议的一部分已经定义的可能计划的示例。还将认识到，在实施例中，公司可以具有一个或多个定义的计划以满足其技术支持要求。在这方面，公司可能具有与位于公司内的任何设备相关联的个人计划，或者可能具有与公司内的所有设备相关联的单个计划。

在实施例中，每个计划与设备列表相关联，请求解决数据结构内的所有可能动作的子集关于该设备列表而应用。在实施例中，每个计划还具有相关联的信息，该信息有助于定义如何调解服务请求以及如何解决事件。与任何附加信息组合的设备列表定义为了通过处理多个动作来解决事件要求多少时间和支出。

例如，并且参考图10，提供了根据本发明的实施例的请求解决数据结构的子集的图解表示，其示出了逻辑上从与特定设备相关的初始事件(“用户无法登录到计算机”)流出的一系列预定义的动作(问题和/或任务)。

参考图11，其关注图10所示的请求解决数据结构的子集的第二个问题(“显示器是否显示“按下control-alt-del”)，显然这个特定问题具有多个相关联的元素：代码(q_000000970)，解决问题所要求的活动类型(“非现场”)，用户(服务职员)处理动作所要求的最低熟练度(“2”，其中“0”是最低熟练度，而“6”是最高熟练度，服务技术人员回答问题所要求的最低合规性(“[商业设备授予]1级技术人员”)，回答问题所要求的时间(“5秒”)，与问题相关联的指派的子优先级(“50”，其中优先级“0”是最低优先级，而“100”是最高优先级)，以及在问题的回答为真的情况下的下一个问题(“按下ctrl-alt-del——登录屏幕是否显示？”)，以及在问题的回答为假的情况下的下一个问题(“键盘上是否亮灯？”)。

从图10和图11中显而易见的是，根据实施例的本发明的系统基于提供响应于针对事件的初始服务请求而提出的有助于实现事件的解决的一系列动作。为了精简、关注或以其他方式指引系统在任何给定时间可能向用户(例如，服务职员)提供的动作的数量和类型，系统采用详述与客户相关联的清单的项目的一个或多个计划，从而生成涉及客户提交的服务请求的动作。

因此，通过使用针对特定客户和/或一个或多个设备(即，客户的清单的项目)的一个或多个计划，实现涉及特定事件的有限数量的动作是可能的。在识别出先前未考虑和定义的事件/问题或动作的情况下，可以在系统内输入并存储新的事件/问题或动作，使得新的事件/问题或动作可用于协助解决未来的事件。因此，本发明的系统能够基于在先事件和先前经验随时间发展和演变。

在服务职员无法在初始诊断/解决过程期间解决与服务票据相关联的服务请求的情况下，将服务票据分配给队列，之后传送到具有处理服务票据必需的熟练度、合规性和可用性的服务资源。图12提供了系统界面的示例，该系统界面允许在本发明的系统应用内输入并存储与服务提供方采用的(或以其他方式与服务提供方相关联的)每个服务资源相关的信息。如从图12中可以看出的，除了服务资源的联系方式(固定电话号码和移动电话号码以及电子邮件地址)之外，系统上还存储服务资源的名字/首字母(“p”)、姓氏(姓)(“smith”)、用户名和密码。还记录服务资源的职位(“服务技术人员”)和角色(“服务支持”)。图10还示出了选项卡“合规性”、“动作熟练度”和“熟练度矩阵”(参见图13、图14和图15)，其包括与服务资源的或者服务资源要求的评级、技能和资格相关的信息。

在这方面，图13详述了“合规性”选项卡，其示出具有商业设备授予并且是2级技术人员的特定服务资源，而图14详述了“动作熟练度”选项卡，其示出各种动作的指派的熟练度。将理解，指派的动作熟练度是服务资源处理该特定动作所要求的最低熟练度级别。图15示出了服务资源p.smith(参见图10)关于完成各种类别中的各种动作的熟练度。例如，p.smith对于处理“音频&视觉类别”中(以及图15所示的其他类别)与不同活动类型“第三方联络”、“劳动第三方av”、“劳动第三方cctv”等相关的动作具有熟练度级别“6”。

在实施例中，在服务资源不具有处理动作所要求的熟练度的情况下，将服务票据返回到队列并重新分配以传送到对于该特定动作具有所要求的最低熟练度的替代资源。

因此，本发明的系统能够关于每个服务资源询问位于系统内的存储的信息，并且自动将服务票据分配给队列以供满足各种最低标准的一个或多个服务资源访问。

如先前关于本发明的实施例讨论的，一旦创建服务票据，并且在服务票据要求分配并传送到满足在任何服务级别协议中或在任何相关政策(例如，联盟政策、法律/合规性政策等)内指定的各种最低标准的服务资源的情况下，系统向待处理任务分配总优先级(为“41,648”和“1”的优先级别之间的任一处，其中“41,648”是最高总优先级，而“1”是最低总优先级)，总优先级将部分地确定将待处理任务分配至的或待处理任务可用于的一个或多个服务资源。将认识到，针对服务票据确定的总优先级可以取决于公司(客户)与服务提供方之间的服务级别协议内的任何数量的要求。

在实施例中，“总”优先级取决于可以根据规则或指派建立的任何一个或多个子优先级的组合。例如，总优先级可以根据包括提交请求的个人、事件的性质和事件的位置的子优先级的组合来确定。根据实施例，总优先级取决于指派给联系人(即，提交请求的人员)的优先级级别(从0到100的任一处)，指派给特定问题(即，为了解决事件而提出的特定问题)的优先级以及指派给位置(即，事件的位置)的优先级。例如，服务级别协议可以指定向由公司总经理提交的所有请求指派优先级100，而向由公司任何其他员工提交的服务请求指派优先级50。因此，形成子优先级的每个联系人、问题和位置被指派0到100内的优先级，其可以用于确定待处理任务的总优先级。

在实施例中，可以根据以下关系式来确定待处理任务的总优先级：

当计算的总优先级≤125时，

total_priority＝contact_priority*location_priority*question_proirity*0.001*0.48

然而，当计算的总优先级>125时，则相反根据以下关系式来确定总优先级：

total_priority＝(contact_priority*location_priority*question_priority*0.001)^{(((((contact_priority*location_priority*question_proirity*0.001)-125)*0.0022857142857143)+1)*0.48*0.001))}

可替代地，在另一实施例中，待处理任务的总优先级可以由系统根据各种加权关系自动确定，这具体取决于是否根据联系人、问题或位置的重要性(即，指派的优先级)对优先级进行如下加权：

按联系人加权

如果contact_priority≤50：

total_priority＝(contact_priority*0.1)*(location_priority*0.1)*(question_priority*0.1)

如果contact_priority>50：

total_priority＝(((location_priority*0.1)*(question_priority*0.1))*(contact_priority*0.1)^{(((contact_priority*0.1)-5)*0.4)+1)*0.48}

按问题加权

如果question_priority≤50：

total_priority＝(contact_priority*0.1)*(location_priority*0.1)*(question_priority*0.1)

如果question_priority>50

total_priority＝(((location_priority*0.1)*(contact_priority*0.1))*(question_priority*0.1)^{((((question_priority*0.1)-5)*0.4)+1)*0.48}

按位置加权

如果location_priority≤50：

total_priority＝(contact_priority*0.1)*(location_priority*0.1)*(question_priority*0.1)

如果location_priority>50

total_priority＝(((question_priority*0.1)*(contact_priority*0.1))*(location_priority*0.1)^{((((location_priority*0.1)-5)*0.4)+1)*0.48}

一旦系统自动确定总优先级，则系统检查授权矩阵以及服务请求/待处理任务是否能够在客户与服务提供方之间存在的任何服务级别协议(sla)的要求内被调解。如果请求未恰当授权，或者无法满足sla要求，则分配服务票据进行人工处理。然而，如果服务票据被恰当授权，并且能够在任何sla的要求内被调解，则系统识别服务提供方的满足各种最低标准的任何服务资源。

如果不能识别满足所有最低标准的服务资源，则将服务票据搁置，直到适当的服务资源变得可用。如果识别出满足最低标准的一个或多个服务资源，则服务票据自动变得可用于满足所有最低标准的一个或多个服务资源。

在实施例中，系统被配置为使得满足所有最低标准的服务资源必须一定从已经可用于资源的服务票据的列表中选择下一个服务票据。将认识到，这将有助于避免或至少最小化服务资源“挑出并选择”服务票据，在本发明的上下文中，“挑出并选择”是服务资源选择与其他服务票据相比被认为易于解决或要求更少时间来解决的服务票据的趋势。将认识到，从效率和客户管理的角度来看，“挑出并选择”服务票据是不期望的，因为如果认为服务票据解决起来是困难和/或耗时的，则服务票据可能会滞留数天甚至有时数周或数月。为了进一步减少服务资源“挑出并选择”服务票据的趋势，在实施例中，系统被配置为使得最初仅向服务资源提供任何服务票据的最少细节，其中，服务票据的完整细节仅在服务资源选择并打开服务票据从而确认(多个)服务资源接受服务票据时提供。

一旦服务资源选择下一个服务票据并且系统生成动作(或多个动作)以供服务资源关注，则服务资源尝试解决服务请求，之后服务请求将被解决或不被解决。如果解决了服务请求，则更新服务票据，以便将服务票据和服务请求标记为“已关闭”。

图16提供了一旦由服务资源选择则向服务资源显示并且由服务资源查看的服务票据的示例。如从图16所示的服务票据界面可以看出的，在服务票据的右侧，提供了与服务请求相关的各种信息，包括客户名称，记录事件的人员的姓名，报告事件的人员的联系方式细节，服务票据的优先级，服务请求的源(即，在图16所示的实施例中，服务请求由“johnbrown”通过电话提交)，服务票据的截止日期和时间，事件的sla时间以及创建服务票据的服务资源的细节。图13还示出了服务请求的标题(“用户无法登录到windows”)，并且还示出了要求输入“是”或“否”响应的、服务资源要考虑的问题历史和下一个动作(问题)。

根据实施例，本发明的系统和方法还可以提供用于记录服务资源完成动作和/或服务票据所花费的时间的手段。在这方面，图17示出了关于事件“电子邮件卡在发件箱中”以及从初始服务请求跟随的逻辑动作(问题)的列表的已完成服务票据。如通过查看图17可以看出的，服务请求由bobwhite(客户(henryjones&associates)的员工)提交，并且服务票据由johnjones(服务提供方的服务技术人员)创建。图17的服务票据还示出了服务提供方期望服务资源完成每个问题的时间，并且还示出了服务资源johnjones处理每个动作的完成所花费的实际时间(“真实时间”)。因此，根据本发明的实施例的系统和方法还允许监视、跟踪和评估任何服务资源的表现以用于质量保证目的，或者用于服务资源的培训/改进目的。

将认识到，由于根据本发明的实施例的系统和方法在分配给服务资源之前高效地诊断事件，因此可能实现提高的效率和成功解决服务票据，因为避免向不满足最低资格、经验和熟练度的服务资源分配待处理任务。因此，这有助于服务提供方根据客户与服务提供方之间的服务级别协议的任何条款履行其与客户的合同义务。

本说明书中对任何现有技术的引用不是也不应被视为承认或以任何形式或建议现有技术构成公知常识的一部分。

贯穿本说明书和所附权利要求，除非上下文另有要求，否则词语“包括”以及诸如“包括了”和“包括有”之类的变体将被理解为表示包括所陈述的整体或步骤或者整体或步骤的组，但不排除任何其他整体或步骤或者整体或步骤的组。