Patent Publication Number: US-2009222295-A1

Title: Method for managing an information technology service account

Description:
TECHNICAL FIELD 
     The invention relates to business account management and information technology infrastructure management. 
     BACKGROUND 
     An organization&#39;s Information Technology (“IT”) infrastructure is important to the organization&#39;s success. Interruptions in business continuity can detrimentally affect an organization&#39;s revenue, inventory, customer relationships, productivity, and reputation. Organizations are often engaged by companies that develop or manage infrastructure software to help manage the availability, stability, and adaptability of the IT infrastructure. 
     An engaging company (referred to hereinafter as a vendor) may be tasked to reduce the impact of downtime, improve IT infrastructure operational efficiency, and/or enable new mission-critical capabilities. Commonly, an account manager representing the vendor develops a support strategy for the organization on an ad hoc basis. An engagement model applied by a vendor to some or all customers (i.e., one or more organizations engaging the vendor) can be desirable to provide more consistent and efficient performance across accounts managed by different account managers and across accounts spanning different industries. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1A  is a flowchart describing a reactive phase of an embodiment of a method of engaging a customer in accordance with the present invention. 
         FIG. 1B  is a flowchart describing assessment of customer needs. 
         FIG. 2  is a flowchart describing a proactive phase of the embodiment of a method of engaging a customer. 
         FIG. 3  is a flowchart describing a planning phase of the embodiment of a method of engaging a customer. 
         FIG. 4  is a flowchart describing a maintenance phase of the embodiment of a method of engaging a customer. 
     
    
    
     DETAILED DESCRIPTION OF THE DRAWINGS 
     Referring to  FIGS. 1A and 1B , a flowchart illustrates a first phase of an engagement model applying an embodiment of a method of managing an information technology (IT) service account in accordance with the present invention. The method begins when a customer is engaged by the vendor (step  2 ). The customer may have an IT infrastructure managed by the customer or managed by another vendor, or the customer and/or the customer&#39;s IT infrastructure may be nascent or restructuring. Once the customer is engaged the first phase (also referred to herein as the reactive phase) begins. The vendor starts by training the customer on support (step  4 ). For example, the customer may be instructed on problem escalation procedures and data entry procedures. The vendor is then tasked to assess customer needs (step  6 ). An initial step in assessing a customer&#39;s needs may include determining whether any open cases (also referred to herein as open tickets) exist (Step  8 ). An open case can be an unresolved, documented problem. An open case will commonly be cataloged and its status is monitored until the problem is resolved, at which time the open case can be closed. Open cases are logged by the customer in a case database by using either an automated system (e.g., a designated website established to collect case data, an automated telephone system) or a semi-automated system (e.g., a customer support-staffed telephone system). The vendor further assigns the open case to a technical resource for resolution (step  10 ). The technical resource may be a software engineer, a hardware engineer, or alternatively the technical resource may be some other resource, such as a trainer for familiarizing the customer&#39;s technical staff with the vendor&#39;s products. The technical resource assesses the failure and a source of the failure and enters the information in a database (Step  12 ). The vendor repeats the steps until all of the open cases are reviewed and data is entered. 
     If all open cases have been reviewed, the vendor retrieves any existing customer feedback data from a database (step  14 ). Customer feedback data may be captured in service scorecards, questionnaires, solicited or unsolicited comments, etc. In other embodiments, the customer feedback data can be collected prior to reviewing open cases, or contemporaneously with reviewing open cases. The failure assessment data accumulated during open case review (also referred to herein as case data) is likewise retrieved (Step  16 ). The customer feedback data and case data can be aggregated in a central database particular to the customer to enable identification of patterns in the customer&#39;s aggregate data (Step  18 ). The central database can be a networked database, such as a website. Identified patterns can indicate whether the account has stabilized (Step  20 ). For example, identified patterns can be correlated with a level of customer proficiency with the IT infrastructure and/or technical capability of the IT infrastructure to service the customer&#39;s needs. The vendor can identify whether a problem spot exists by reviewing the case data and the customer feedback data combined and analyzed using trend analysis techniques known in the art. A problem spot may be architectural or may be related to a level of skill and knowledge of the customer&#39;s technical staff. Architecture refers to the engagement model, including deliverables (e.g., as shown in  FIGS. 1A , and  2 - 4 ) and sub-deliverables (e.g., as shown in  FIG. 1B ). If the architecture is determined to be insufficient, for example based on the results of the problem reporting procedure, the architecture can be modified by adding to or deleting from one of the deliverables or sub-deliverables. 
     If a problem spot is identified (Step  22 ) the vendor can determine whether a technical resource is required (Step  24 ). If technical resources are required the vendor identifies a technical specialist best able to address a problem spot (Step  28 ). Resolution may require software and hardware adjustments if the problem spot is architectural, or may include recommendations for customer adjustments to the customer&#39;s technical staff to improve the customer&#39;s IT infrastructure. If a technical resource is not required for resolving a problem spot, the problem spot can be further monitored. If aggregate data review identifies patterns that indicate account instability, but does not identify architectural problem spots, the account can continue to be monitored for patterns. 
     Referring to  FIG. 2 , the proactive phase begins once the reactive phase is completed. Alternatively, the proactive phase can begin at some threshold level of achievement (for example in reducing identified patterns) during the reactive phase. The reactive phase may continue being implemented in such embodiments. The vendor begins the proactive phase by establishing a problem reporting procedure (step  32 ). The problem reporting procedures targets information that the vendor determines is most likely to resolve future open cases as well as identify potential problems that have not yet occurred. Standardizing the reporting procedure can allow for more complete and uniform data collection so that steps of the method of managing the information technology service account are more accurate and effective. The problem reporting procedure can be particularized for the industry and/or the customer. For example, a customer that is a network service provider may require a problem reporting procedure tailored to request additional details that would preferentially identify and highlight potential problems with service continuity (i.e., network uptime). 
     The problem reporting procedure is deployed (step  34 ) and data generated by the problem reporting procedure are collected in a database and subsequently accessed from the database (step  36 ). The data are optionally pooled with historical data, for example the case data and customer feedback data described above. The vendor accesses the problem reporting database and monitors the service account for impending failures based on the gathered data in the problem reporting database (step  38 ). If there are impending failures associated with known issues the vendor preemptively identifies a solution (step  42 ). When there are no impending failures and all potential problem areas have been identified and resolved the method moves to the planning phase. As above, in alternative embodiments, the planning phase can begin at some threshold level of achievement (e.g., known issues associated with impending failures are reduced by some criterion) during the proactive phase. Further, the proactive phase may continue being implemented in such embodiments. 
     Referring to  FIG. 3 , during the planning phase the vendor determines whether new tools offered by the vendor address existing needs of the customer (step  48 ). Existing and/or new tools can be hardware-based or software-based, and can comprise proprietary or off-the-shelf technology. For example, software-based tools can include Clarify® software from Clarify, Inc. which can be used in sales and service automation (e.g., for open case database tracking) and Excel® spreadsheet software from Microsoft, Corp. which can be applied to analyze aggregated data. New tools can address existing needs by improving existing performance of the IT infrastructure (e.g., where performance is marginal) or new tools can address architectural problem spots identified during the reactive phase. Alternatively, the vendor can determine based on problem reporting database information and information gathered in the reactive phase if new tools can prevent impending failures. If new tools exist the vendor then reviews the new tools with the customer (step  50 ). The vendor then queries the customer product release and technology roadmap (step  52 ). The vendor assesses how effectively the existing IT infrastructure can manage the product releases and new technology. The vendor determines whether existing tools or new tools offered by the vendor address the new product releases in the technology roadmap (step  54 ). If the new or existing tools address new product releases the vendor reviews the tools with the customer in view of the new product releases and the technology roadmap (step  56 ). 
     Referring to  FIG. 4 , the account then enters the maintenance phase. During the maintenance phase the vendor persistently collects customer feedback data (step  60 ). The vendor then reviews the customer feedback data (step  62 ) and determines whether to modify one of the architecture and the tools (step  64 ). If the vendor determines that modifications required the vendor identifies the architecture and/or the tools for improvement (step  66 ). the vendor then arranges to implement the improvement (step  68 ). If the vendor does not identify modifications to the architecture and/or the tools, the process of collecting customer feedback data and reviewing the customer feedback data until the account is no longer managed by the vendor (step  70 ). Application of the method ends when the vendor ceases to continue managing the account and the engagement ends (step  72 ). 
     Embodiments of methods of managing an IT service account in accordance with the present invention can reduce maintenance charges typically associated with IT administration. For example, a typical open ticket in the IT service industry can cost as much as $800 in fees to disposition. Engaging in steps as outlined in the method allows a service account manager (“SAM”), for example, to manage an account, directing and anticipating action taken on the account to reduce or eliminate unnecessary escalations. Such escalations can delay addressing problems and can reduce both the vendor and customer efficiency. Improving interaction between the customer and the vendor can improve the working relationship between the customer and the vendor, as well as reducing costs for both parties. 
     The present invention can be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. 
     In some embodiments, the present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes and/or steps of the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data. 
     The foregoing description of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to practitioners skilled in this art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.