An introduction to the MOF Customer Service SMF
Our previous blog articles in this series explain the role of the Microsoft Operations Framework (MOF), service management functions (SMF’s) and introduce ITIL IQ® which is the first step in implementing MOF within your business. Before you use this SMF, you may want to read the following ITIL IQ® guidance to learn more about the MOF IT service lifecycle and the Operate Phase:
Blog Article 1: What’s your ITIL IQ®? Meet MOF
Blog Article 2: The MOF Plan Phase
Blog Article 7: The MOF Deliver Phase
Blog Article 13: The MOF Operate Phase
The MOF IT service lifecycle encompasses all the activities and processes involved in managing an IT service: its conception, development, operation, maintenance, and ultimately its retirement. MOF organises these activities and processes into Service Management Functions (SMFs), which are grouped together in phases that mirror the IT service lifecycle. Each SMF is anchored within a lifecycle phase and contains a unique set of goals and outcomes supporting the objectives of that phase. An IT service’s readiness to move from one phase to the next is confirmed by management reviews, which ensure that goals are being achieved in an appropriate fashion and that IT’s goals are aligned with the goals of the organisation. Each SMF is anchored within a lifecycle phase and contains a unique set of goals and outcomes supporting the objectives of that phase. The SMFs can be used as standalone sets of processes, but it is when SMFs are used together that they are most effective in ensuring service delivery at the desired quality and risk levels.
Position of the Customer Service SMF Within the MOF IT Service Lifecycle
The Customer Service SMF belongs to the Operate Phase of the MOF IT service lifecycle. The following figure shows the place of the Customer Service SMF within the Operate Phase, as well as the location of the Operate Phase within the IT service lifecycle.
Figure 1. Position of the Customer Service SMF within the IT service lifecycle
Why Use the Customer Service SMF?
This SMF should be useful to anyone who is involved in providing a positive experience for IT service users by meeting their IT needs and addressing complaints and issues that arise during the normal course of using an IT service. It addresses how to provide that experience by:
- Recording and determining the nature of a customer request.
- Resolving requests for information, for existing and new features, and for changes.
- Resolving incidents.
- Ensuring good customer service.
Customer Service Management Function Overview
Customer service is the entry point for users who need to engage IT with their questions and concerns. Although multiple roles and teams are required to interact with and support the Customer Service SMF, the majority of the processes and activities within it are performed by a functional team called the Service Desk. The Service Desk is a team and, just like any other team, it can be centralised, distributed, or virtual. The team operates as a functional unit that focuses on ensuring that customer service related activities are carried out with high quality. The following table lists a number of reasons that users might engage the Service Desk and equates them to the MOF terminology that is used in this guide.
Table 1. Reasons for Contacting the Service Desk and MOF Terminology
|Reason for Contacting Service Desk||MOF Term|
|To request information on using an existing service to which the user already subscribes||Information request|
|To subscribe to an existing service that is being offered||Service Fulfillment request|
|To request a new service or feature to meet a new need||New Service request|
|To report a partial loss, degradation, or total loss of a service or service feature||Incident Resolution request|
Customer Service SMF Role Types
The primary team accountability that applies to the Customer Service SMF is the Support Accountability. The role types within that accountability and their primary activities within this SMF are displayed in the following table.
Table 2. Support Accountability and Its Attendant Role Types
|Role Type||Responsibilities||Role in This SMF|
|Customer Service Representative||· Handles calls as the first contact with the user · Registers and categorises calls · Determines supportability and dispatches calls||· Interacts with customers, including recording, categorising, classifying, resolving, and closing customer requests|
|Incident Resolver||· Diagnoses, investigates, and resolves||· Resolves incident requests, including troubleshooting, escalating if necessary, and applying a fix or workaround|
|Incident Coordinator||· Is responsible for incident from beginning to end · Owns quality control||· Oversees all incident requests|
|Problem Analyst||· Investigates and diagnoses||· Investigates and resolves an underlying problem|
|Problem Manager||· Identifies problems from the incident list||· Determines whether an underlying problem exists|
|Customer Service Manager||· Is accountable for goals of Support Desk · Covers incidents and problems||· Oversees customer service|
Goals of Customer Service
The primary goal of customer service is to provide a positive experience for users by meeting their IT needs and addressing complaints and issues that arise during the normal course of using an IT service. The driving vision for the Service Desk is to translate the complexities of IT into a one stop shop for IT users. The process flow defined in the Customer Service SMF provides the Service Desk with the guidance it needs to achieve its vision in an efficient, cost effective way. The Service Desk can increase its efficiency and cost effectiveness by initiating and maintaining a self help portal. Through this portal, the Service Desk can supply frequently requested information, automate common requests such as password resets, and provide step by step instructions to resolve common incidents. Table 3 shows the desired outcomes of the Customer Service SMF goals and lists measures that you can use to gauge how successfully you have achieved these goals.
Table 3. Outcomes and Measures of the Customer Service SMF Goals
|Maintain business productivity||· Restore services or service features to a satisfactory operational state
· Provide guidance and ”how to” information
|Increase value added by IT||· Facilitate Service Fulfillment requests
· Improve user satisfaction
|Improve business functionality, competitiveness, and efficiency||· Assess requests for new services and features for potential fulfillment by existing services
· Filter out insufficient justification for new services and features
The following table contains definitions of key terms found in this guide.
Table 4. Key Terms
|Configuration management system||A set of tools used to manage IT service management data such as changes, releases, known errors, and incidents.|
|Customer Service Representative (CSR)||A front line contact person on the Service Desk team.|
|Forward Schedule of Change||A record of upcoming approved changes, which may help you understand the impact that already approved changes might have on any new proposed changes, and vice versa.|
|Incident||Failure of a service or component to provide a feature it was designed to deliver.|
|Incident Resolution request||An inquiry to resolve the failure of a service or feature.|
|Information request||An inquiry to gain additional information about an existing service. This does not include activating new features or providing new services.|
|New Service request||An inquiry to gain a new service or feature.|
|Service||A collection of features and functions that enable a business process.|
|Service Fulfillment request||An inquiry to gain access to additional features or services offered through the IT Service Catalogue.|
Customer Service Process Flow
The customer service process flow provides the overall structure for this SMF, providing a consistent set of processes to record and track user contact. When a user contacts the Service Desk, the Customer Service Representative (CSR):
- Records the user’s contact information and the details of the request.
- Classifies the user’s request.
- Resolves the user’s request.
- Confirms the resolution and closes the request.
- Ensures good service.
Figure 2 illustrates the process flow for customer service.
Figure 2. Customer Service process flow
Process 1: Record the User’s Request
When a user contacts the Service Desk, the first step that the CSR must take is to open a Help request, and then perform the following tasks:
- Record the user’s contact information.
- Record the details of the user’s situation.
Only when this information has been documented can the CSR move on to the next process, categorising the user’s request.
Process 1a: Record the User’s Contact Information
In this process, the CSR opens a Help request and records the user’s contact information or receives an automated Help request generated by an alert or a user-initiated self-service request.
Figure 3. Record the user’s contact information
Activities: Record the User’s Contact Information
What happens if users call the Service Desk with ”quick” questions and these calls are not logged and recorded? The result is hours of undocumented effort. The disparity between actual effort and documented effort can make it very difficult for the customer service team to justify staffing requests or to turn away new support requests. Over time, the gap can widen and the value of IT can come under fire. Keeping accurate records of user calls and the time spent by the Service Desk to support IT users can generate very meaningful and powerful data. The first step in keeping accurate records is to open a Help request for every user call and record the user’s contact information. Help requests can also be opened automatically by input generated from a system alert or from a user through a self-service portal, a link embedded in an application or Web site, or e-mail. Automated inputs are scripted to open Help requests and record data. Manual inputs include direct phone calls and instant messages. These create real-time connections between users and CSRs, as well as requiring CSRs to manually open Help requests to capture the contact. The following table lists the activities involved in recording the user’s contact information. These include:
- Opening a Help request and recording the user’s contact information.
- Receiving an automated Help request generated by a system alert.
- Receiving an automated Help request generated by a user-initiated request from a link in an application or a Web site, or from a self-help portal.
Table 5. Activities and Considerations for Recording the User’s Contact Information
|Open a Help request and record the user’s contact information||Key questions:
· Is the caller an internal employee, an outside user, a partner, or a service provider?
· What is the user’s contact information: call back number, e-mail address, physical address?
· Is the call regarding a new Help request?
· Does the caller have an existing Help request still open?
· Is the caller reporting an issue for another user?
· Information provided by the user
· HR database
· User contact list
· A Help request with a unique number provided to the user that records basic information about the request. This should include the time of the initial contact so that CSR time can be tracked
· Capture a call-back number and other user contact information immediately. In some scenarios, the user may have just endured a long time on hold to reach a CSR. If a phone error occurs and the user is disconnected, the CSR should call the user back instead of requiring the user to get back in the call queue.
· Keep call routing systems simple. After more than three layers of questions, user frustration will grow exponentially. The flow of the questions should be changed as infrequently as possible since users who call often will memorise the sequence. If a change is made in the sequence, an announcement should inform the user at the beginning of the call.
· Make good use of pre-recorded messages. For example, if IT knows that the network is down for an entire building, the Service Desk is not going to add value by starting a Help request for every person affected. Instead, a front-end message should be recorded and played to all Service Desk callers informing them of the scope of the incident, its current status, an estimate of the time it will take to fix it, and the time that the front-end message will be updated next.
· These concepts should extend to self-help portals as well. When there is a known service failure, it should be posted on the portal site. Use patterns and traffic statistics should be tracked for the portal to demonstrate its value.
|Receive a Help request automatically generated by an alert||Key questions:
· Is the information in the request complete and accurate?
· Does the request include user contact information?
· Can the recorded symptoms be correlated to other events to provide the CSR with suggested incident causes?
· Is there sufficient data to set an initial classification and priority?
· System alerts from Microsoft System Center Operations Manager (or other RMM platform)
· Basic contact information and a description of the incident
· The name of the service or feature affected by the incident
|Receive an automatically generated Help request resulting from a user-initiated self-service request||Key questions: · Is the information in the request complete and accurate? · Does the request include user contact information? · Can the recorded symptoms be correlated to other events to provide the CSR with suggested incident causes? · Is there sufficient data to set an initial classification and priority? Inputs: · E-mail templates from embedded support links · Templates from self-help portals Outputs: · Basic contact information for the user experiencing the incident and a description of the incident · The name of the service or feature affected by the incident Best practices: · Use templates with a limited number of free-form fields. This drives consistency in the data collected and simplifies the process, in turn improving the user experience. · Make it quick and easy for users to report non-critical incidents from within applications and Web pages by embedding links to automatically generate Help requests. This creates the opportunity to capture data about the system state during the incident and automatically populate it into the request. · When a request is generated from a self-help portal, the automation routine should capture a list of the knowledge base articles or FAQs that the user reviewed prior to opening the Help request. This can later be reviewed and used to improve the self-help content. · Where possible, a confirmation message should be sent to the user (for e-mail and portal-generated help requests) that notifies the user of CSR response time for incidents raised in this manner. The confirmation should also provide a unique incident record reference number. · Some of the best-designed self-help portals go unused as the result of poor awareness and education programs. Users must be informed of available self-help tools and be educated on when and how to use them effectively. Companies with advanced maturity in financial management sometimes offer a discount to business units with users who make effective use of self-help portals.|
Process 1b: Record Details of the User’s Request
The next process is to record the details of the user’s request.
Figure 4. Record details of the user’s request
Activities: Record Details of the User’s Requests
Once the CSR has collected the basic user contact information, the next process is to record some details of the user’s request. This information ensures that critical information is captured up front so that in the event that the user is disconnected from the CSR, he or she does not have to repeat the details. The following table lists the activities involved in recording the details of the user’s request. These include:
- Recording the details of the user’s request.
- Validating the data contained in an automated Help request.
Table 6. Activities and Considerations for Recording Details of a User’s Request
|Record details of the user’s request||Key questions: · What technology or service is the request concerning? · Has the user made this request before? · What can’t the user do or what does the user want to achieve? · What does the user consider to be a successful outcome of his or her request? · If the user is reporting a failure, what does the failure look like? · How should the service or feature be performing? · If the user is reporting an incident, what evidence exists to confirm the incident? · If the user is reporting an incident, what are the steps to recreate the incident? Inputs: · Information provided by the user · Review of previous user requests · The user’s description of what a failure looks like · The user’s understanding of how the service or feature should be performing · If the user is reporting an incident: · Evidence provided by the user to confirm the incident · The steps provided by the user to re-create the incident · Direct experience by re-creating the incident on another system or by witnessing the incident through a remote control tool · Event logs or monitoring tools Output: · Help request updated with the details of the user’s request, which should provide input for classifying, prioritising, and resolving the request Best practices: · Use a tracking tool that provides customisable templates and question trees to help the CSR record the details of the request consistently. However, do not restrict the CSR to the point that it affects the quality of information captured. · The tracking tool should use drop-down lists to drive this activity; avoid free-form fields. Each drop-down list should contain an “I don’t know” choice. It is more valuable to record the number of times a CSR cannot properly categorise a request than to force the CSR to guess and choose incorrectly. · CSRs should be accustomed to speaking in user terms. Complex or technology specific language should be avoided.|
|Validate the data included in an automated help request||Key question: · Is the information in the automated Help request accurate? Inputs: · User information records, if available, from contact lists, HR systems, or configuration management systems · If necessary, contact the user directly to verify information · Help requests created from system alerts should be validated by reviewing the alert data and checking logs from the originating system|
Process 2: Classify the User’s Request
After obtaining the user’s contact information and some details of the user’s request, the next process is for the CSR to determine what type of request the user needs assistance with by performing the following tasks:
- Categorise the user’s request. This helps the CSR determine which solution will best benefit the user.
- Determine if the request is supportable.
- Prioritise the request.
Process 2a: Categorise the User’s Request
The first process is to determine whether the user has:
- An Information request.
- A Service Fulfillment request.
- A New Service request.
- An Incident Resolution request.
The resolution of the request is different depending on the category into which it falls.
Figure 5. Categorise the users request
Activities: Categorise the User’s Request
Categorising the user’s request allows the CSR to identify the solution that will best benefit the user. The following table lists the activities involved in categorising the user’s request. These include determining:
- If this is an Information request.
- If this is a request for an existing service or feature.
- If this is a request for a new service or feature.
- If this request concerns a failure with an existing service or feature.
Some Service Desk tracking tools make it possible to establish a set of questions and to trigger a workflow based on the responses to those questions. The tool should use drop-down lists and avoid free-form fields, and each drop-down list should contain an “I don’t know” choice.
Table 7. Activities and Considerations for Categorising the User’s Request
|Determine if the request is an Information request||Key questions: · Is the user asking ”how to” questions? · Is the user already using an existing service but has concerns about not getting the desired results or wants to learn how to use a particular feature? Inputs: · Information provided by the user · IT Service Catalogue Outputs: · Determination that this is an information request (if not, continue to the next activity) · Updated Help request to reflect additional details about the request Best practices: · CSRs should have easy access to a Frequently Asked Questions (FAQ) document. This document should include frequently reoccurring information requests expressed in user-friendly terms. · Categorising requests by type (Information, Service, or Incident) and by area (Technology or Service) provides important metadata that can be used to identify trends and to locate possible requests for inclusion in the FAQ document.|
|Is this a request for an existing service or feature?||Key questions: · Does the user want to gain access to a service or feature that is already available in the IT Service Catalog? For more information on service catalogs, see the Business/IT Alignment SMF. · Does the user already use the service and want additional features? · Is this a service or feature that the user has used in the past? · Will the user have any additional service or system abilities after the request is fulfilled? Inputs: · Information provided by the user · IT Service Catalogue Outputs: · Determination that this is a Service Fulfillment request (if not, continue to the next activity) · Updated Help request to reflect additional details about the request Best practices: · First, try to determine if the request is for service fulfillment or incident resolution. Users often say such things as “I can’t access the monthly reports.” This kind of statement can lead the CSR to attempt incident resolution, such as determining if the report site is down, only to find out later that the user didn’t have access to the site. If, instead, the CSR had asked a few additional questions at the beginning of the call, he or she may quickly have determined that an account needed to be created for the user on the report site. · Ensure that the organisation understands the difference between a request for a new service (New Service request) and a request for an existing service (a Service Fulfillment request). A New Service request requires modifying a service or system into a configuration for which it was not originally designed, or involves creating a service that doesn’t already exist. A Service Fulfillment request involves enabling or extending an existing service or system in a manner for which it was designed, tested, and certified. · The best way to avoid confusion is to maintain a list of Service Fulfillment requests and a brief explanation of how to identify them.|
|Is this request for a new service or feature?||Key questions: · Is the user seeking functionality not provided by an existing service or feature? · What new service or feature is the user requesting? · What is the justification for the request? · When does the user want it completed? · Does this request fit the profile of a standard change? Inputs: · Information provided by user · IT Service Catalogue · Existing Requests for Change (RFCs). Output: · Determination that this is a New Service request (if not, continue to the next activity) Best practice: · There is a fine line between a request for an existing service or feature and a new service request. Requesting an existing service or feature requires enabling it to perform in a manner for which it was designed, tested, and deployed. For example, if a Web server was designed, tested, and deployed to host 500 Web sites, then activating sites 1 through 500 requires requests for an existing service or feature. A request to add a 501st site would be a New Service request, which would have to be reviewed for feasibility and impact. It might even result in an additional New Service request to add more hard disk space to accommodate the extra site. The dividing line isn’t just about capacity, though. If the Web server was built to host only static Web sites and a user submits a request to enable active server pages, this would also require a New Service request.|
|Is this request about a failure with an existing service or feature?||Key questions: · Did the user have access to the service and then lose it? · When was the last time the user successfully used this service or feature? · Are others in the user’s work function able to successfully use this service or feature? · Has anything changed since the user last used the service successfully? Has the user moved offices, changed roles, installed new software, or received a new computer? Inputs: · Information provided by user · IT Service Catalogue Outputs: · Determination that this is an Incident Resolution request · Updated Help request to reflect additional details about the request Best practice: · In some organisations, up to 80 percent of failures are attributable to changes in users’ environments. It is a good idea to check this possibility right away. It is also possible that an intentional change was made to remove a service or feature from the user’s computer. In this case, if the user requests that the service or feature be returned, approval from Change Control might be required, and this should be addressed through a Service Fulfillment request.|
Process 2b: Determine Supportability
Before you can move on to resolving the request, you must also perform the following processes:
- Determine the supportability of the request.
- Determine whether to override an unsupported request.
Figure 6. Determine supportability
Activities: Determine Supportability
The second process in categorising a request is to determine its supportability. Answering the fundamental question, “Do we support this?” is a common problem for support teams. The following table lists the activities involved in determining supportability. These include:
- Determining if this is a supported service.
- Determining whether to override an unsupported request if this is not a supported service.
Table 8. Activities and Considerations for Determining Supportability
|Is this a supported service?||Key question: · Is the requested service listed in the IT Service Catalogue? Inputs: · IT Service Catalogue · Help request · User comments Outputs: · SLAs applicable to the supported service · Target times for escalation and resolution Best practices: · Build an IT Service Catalogue that lists the supported services and provides a pointer to the SLAs that define the goals of the services. It may also be helpful to have the support of a configuration management system (CMS) in order to cross reference individual components to the services they provide. For more information on service catalogues, see the Business/IT Alignment SMF. · CSRs should have full access to the IT Service Catalogue and configuration management system (CMS). If possible, the ability to make services and components use SLAs should be built into the tracking tool.|
|Override the service’s unsupported status?||Key questions: · If the service is not supported in the IT Service Catalogue, who has the authority to approve IT resources to work on it? · What is the overall impact of working on this unsupported service? · Is this unsupported service in violation of an IT security policy and does it need to be shut down? · Is the override a temporary or long-term decision? · Who can authorise a shutdown or removal of an unsupported service? · Has authorisation been granted to override the unsupported status and support the service? Inputs: · Authorisation to override the unsupported status of the service · Target times for escalation and resolution Outputs: · Decision to override an unsupported service’s status or to decline support of the unsupported service · Help request flagged as unsupported service, but overridden · Metrics to track support time for unsupported services · Flags, such as RFCs, to capture undocumented services that should be supported Best practices: · Considerable time can be lost in researching unsupported services. Even if a business unit procures a service or system not provisioned by IT, users expect to receive the same level of support as for a supported service because they perceive that all services are owned by IT. CSRs need a consistent means to determine if the service is supported. · Unauthorised services or devices can have a negative effect on IT service. For example, a shop bought wireless router can allow insecure connections to the public network or can cause network failures. CSRs need a means to address these issues and a path to escalate them to the appropriate levels of management. · Review the data from this process to capture trends and to identify services that are missing from the IT Service Catalogue.|
Process 2c: Prioritise the Request
Once you know that a request is supportable, you need to prioritise its importance in order to make the best use of the Service Desk’s available resources.
Figure 7. Prioritise the request
Activities: Prioritise the Request
A key success factor in reducing the time required to resolve a request is the ability to match requests against known errors, workarounds, and knowledge base articles. This can only be effective if requests are consistently classified using predetermined metadata. The following table lists the activities involved in prioritising the request. These include:
- Determining the impact and urgency of the request.
- Prioritising the importance of the request.
Table 9. Activities and Considerations for Prioritising the Request
|Determine impact and urgency||Key questions: · What services are affected or potentially affected? · What is the likely impact? · Are any business critical services likely to be affected? Inputs: · Service map. For more information about service maps, see the Business/IT Alignment SMF. · Help request · User comments · Investigation into the request · Information from the IT Service Catalogue. For more information about service catalogs, see the Business/IT Alignment SMF. · The configuration management system (CMS). For more information about a CMS. Output: · Metadata added to the Help request to assist with locating resolution suggestions and priority selection|
|Prioritise the request||Key questions: · What is the criticality of the business process that is affected? · What SLAs are in place? · How many people are affected? · What groups are affected: back office support, external users, or upper management? Inputs: · IT Service Catalogue · SLAs · Availability plan Outputs: · Determination whether work on other requests should stop in order to address a new, higher priority request · Determination of how long the CSR should work on the request before escalating it to a higher tier of support · Determination whether a special communication should be sent to inform users or IT managers of this request. Should the IT Service Continuity plan be invoked? Best practices: · Instead of asking the user to prioritise his or her request, ask the user to address specific business impact questions. The user will be more likely to provide good data to help establish the priority. · When possible, priorities should be preset by service, feature set, and business area affected. This should be captured in the SLA. The classification selected for the service should also assist in the priority selection. It may be possible to build logic into the request tracking tool to set the priority automatically, based on the request classification.|
Process 3: Resolve the Request
The path to resolving a request is different depending on the category of the request. The categories are:
- Information request. This is usually a request for information about an existing feature or service.
- Service Fulfillment request. This is a request to gain access to a feature or service offered through the IT Service Catalogue.
- New Service request. This is a request to provide a new feature or service.
- Incident Resolution request. This is a request to resolve the failure of a service or component to provide a feature that it was designed to deliver.
After categorisation and prioritisation of the user’s request is completed, the CSR should be prepared to resolve the user’s request.
Process 3a: Resolve an Information Request
Resolving an information request involves using the knowledge base to find the information that the user needs.
Figure 8. Resolve an Information request
Activities: Resolve an Information Request
Searching for existing knowledge is an important part of fulfilling Information requests. The following table lists the activities involved in resolving an Information request. These include:
- Searching for and locating applicable knowledge base articles.
- Determining if the articles are user-ready and sending them to the user, if appropriate.
- Verifying the successful receipt of the articles and assisting the user with the application of the knowledge, if necessary.
- Updating the Help request with the knowledge base articles that were shared with the user.
Table 10. Activities and Considerations for Resolving an Information Request
|Search for and locate applicable knowledge base articles||Key questions: · What information is the user trying to obtain? · Is the user’s question on the FAQ list? · Is the question regarding something in the IT Service Catalogue? · What knowledge bases are available? · Is this request likely to have been made before? · Are there external vendor-supplied knowledge bases that could add value? Input: · Help request classification data Outputs: · Identification of the best-fit knowledge base article · If an applicable knowledge base article cannot be located, the CSR should provide the user with a best-effort attempt to answer his or her inquiry Best practices: · Create and maintain a single interface to search for knowledge base articles. The articles should be flagged with metadata to organise the search results by category (Information, Service Fulfillment, New Service, or Incident Resolution) and by area (Technology or Service). · Usage statistics should be recorded to track the usefulness of the articles. This helps identify articles to retire or enhance, or, in some cases, to publish directly to users through a self-help portal. · Each knowledge base article should contain a list of Help requests for which it was successfully used. This provides the CSR with a better way to assess the applicability of the article.|
|Determine if the articles are user-ready and send the appropriate articles to the user||Key questions: · Can this information be shared directly with the user? · Does the article contain detailed technical information that must be interpreted? · Is the user authorised to see all of the information contained in the article? Input: · Knowledge base article and CSR’s experience Output: · Decision on how to proceed to best assist the user Best practices: · Knowledge base articles should follow a standard template format. The template should ensure that confidential or restricted access articles are marked as such. · A review of the article should determine if it is appropriate to share the article directly with the user. · Sending documents and files directly to users should be avoided. Whenever possible, a link to a knowledge base article should be provided. This is important because the article might be updated or retired in the future. Users should not refer to outdated information stored locally on their systems.|
|Verify receipt of the links to the articles and assist the user with application of the knowledge, if necessary||Key questions: · Did the user receive the links to the articles? · Does the user need assistance with the application of the knowledge? Input: · A review of the article Output: · Determination of whether the user needs assistance in order to gain benefit from the article Best practices: · When possible, the CSR should send links to the appropriate knowledge base articles immediately and remain on the phone while the user attempts to access the links. This can save frustration and delays if the user cannot access the articles and then has to call back and wait on hold again. · It is beneficial to provide CSRs with access to the technology solutions that are in popular use throughout the organisation. This enables them to step through knowledge base articles locally and see the results, thus making it easier for them to explain the steps to the user. · Alternatively, CSRs should have remote access to users’ systems to help them demonstrate the knowledge in action.|
|Update the Help request with the knowledge base articles that were shared with the user||Key questions: · Which articles were shared with the user? · Was more than one article required to resolve the request? · Did using any of the articles cause problems for the user? · Did some of the articles seem to apply to the request, but actually not assist the user? Inputs: · Knowledge base articles · User feedback Outputs: · Metrics to detect the success rate of knowledge management and problem management articles · Triggers to capture inaccurate information that is delaying service resumption efforts Best practice: · Help requests and knowledge base articles should maintain a two-way association.|
Process 3b: Resolve a Request for an Existing Feature or Service
Resolving a request for an existing feature or service in the IT Service Catalogue involves identifying and initiating the correct service fulfillment procedure.
Figure 9. Request for an existing feature or service
Activities: Resolve a Request for an Existing Feature or Service
A Service Fulfillment request is focused on providing the user with services or features from the existing IT Service Catalogue. This can be as simple as granting access to existing sites or tools. Resolving a request for an existing feature or service is focused on providing guidance and “how to” information to users to help them extract the full value from the services and features they are already using. These sub-processes are both heavily dependent on knowledge management. If the CSR determines that the user has a Service Fulfillment request, this portion of the flow guides the CSR to locate the appropriate directions and satisfy the user’s needs. The following table lists the activities involved in resolving a request for an existing feature or service. These include:
- Searching for and locating the correct service fulfillment procedure.
- Initiating the fulfillment procedure.
Table 11. Activities and Considerations for Resolving a Request for an Existing Feature or Service
|Search for and locate service fulfillment procedure||Key question: · What is the correct service fulfillment procedure for this request? Input: · The Help request information required to locate the appropriate fulfillment procedure Outputs: · Identification of the correct service fulfillment procedure · If a procedure has not been documented, the request category should be converted to a New Service request. See “Resolve a Request for a New Feature or Service” in this guide for more information Best practices: · Create and maintain a single interface to search for procedural documentation. The documents should be flagged with metadata to organise the search results by category: Information, Service Fulfillment, New Service, or Incident Resolution. · Usage statistics should be recorded to track the usefulness of procedural documents. The statistics help identify documents to retire or to enhance and, in some cases, documents to be published directly to users through a self-help portal.|
|Initiate the fulfillment procedure||Key questions: · Can this procedure be executed at any time? · Are there any prerequisites? · Is there an authorisation required to proceed? Input: · Service fulfillment procedure Outputs: · Estimation of the time and effort required to complete the request · Start of the fulfillment procedure Best practice: · Every fulfillment procedure should follow a consistent template that ensures that information such as required authorisation, prerequisites, license requirements, and financial impacts are documented. Additionally, every procedure should have an expiration date to ensure that it is reviewed and updated regularly. The template should also list a primary and secondary owner to contact if difficulty is encountered when executing the procedure.|
Process 3c: Resolve a Request for a New Feature or Service
Resolving a request for a feature or service that is not included in the IT Service Catalogue involves:
- Filtering the new service request to determine whether it should be accepted or rejected.
- Deciding whether to handle the request as a standard change New Service request.
- Deciding whether to handle the request as a non-standard change New Service request.
Process 3c1: Filter the New Service Request
The first process in handling a request for a new service or feature is to filter it and decide whether to accept or reject the request.
Figure 10. Filter the New Service request
Activities: Filter the New Service Request
When a user requests a new feature or service that is not included in the IT Service Catalog, the request is documented and its appropriateness is determined. If it is determined to be inappropriate, it is rejected. For example, there may be a corporate policy stating that only field-based salespeople can be issued laptops. Therefore, a request to provision a laptop for a non-field–based salesperson should be rejected. However, the request should still be recorded for trending and analysis. The authorisation for the change must adhere to an organisation’s established Change Management process. The Service Desk should have a list of Change requests that are marked for automatic rejection.
Table 12. Activities and Considerations for Requesting a New Feature or Service
|Filter the New Service request and determine whether to reject it||Key questions: · Has Change Management placed a cease and desist on this type of New Service request? · Is this a duplicate request? Inputs: · Change Management processes · Existing requests for new services Output: · Decision to accept or reject the request Best practices: · Moving the filtering process for new requests to the Service Desk, instead of through the Change Manager, allows for more efficient use of resources. · Enabling the Service Desk to record New Service requests helps expand the span and reach of Change Management. Allowing the Service Desk to capture these requests can improve the performance of the change process by formalising it early on.|
Process 3c2: Handling a Standard Change New Service Request
The next process is to determine if this is a standard change New Service request and to implement the change if it is.
Figure 11. Handling a standard change New Service request
Activities: Handling a Standard Change New Service Request
A standard change New Service request is a change that has been executed before, is well documented, and has been proven to be consistently successful. In other words, it has been determined to be very low risk to the environment. Standard changes, even though low risk, can range from simple to moderately complex. The Service Desk can be authorised to implement those that are simple and do not require in-depth technology knowledge. This continues to drive efficiencies and reduce costs. The Service Desk should also have a different set of activities for handling non-standard changes or standard changes that they are not authorised to implement. This allows the Service Desk to maintain itself as a central point of contact for its users. See “Handling a Non-Standard Change New Service Request” in this guide to learn about these activities. The following table lists the activities involved in handling a standard change New Service request. These include:
- Determining if this is a request for a standard change.
- Determining if the Service Desk is authorised to implement the change.
- Reviewing the request and implementing it.
- Validating that the request completed successfully.
Table 13. Activities and Considerations for a Handling Standard Change New Service Request
|Is this request for a standard change?||Key question: · Is there a Standard Change template to fulfill this request? Inputs: · Change Management processes · Existing New Service requests Outputs: · Determination to fulfill the request as a standard change or to handle it as a non-standard change · Standard change document Best practices: · A change can only be declared a standard change if it has been implemented previously and is fully documented. After this has been completed, Change Control can be requested to review and approve the change as a standard change. · Documentation for all standard changes should be centrally located and secured with appropriate permissions. The Service Desk should be granted full access to all standard changes that they are authorised to implement. · Like any other important IT Operations document, standard change documents should be managed in line with knowledge management practices. This means that a CSR should be able to search for and locate appropriate standard changes based on input from the user. · Each standard change document should have two parts: a Standard Change template that will pre-populate fields within the Request for Change (RFC) record and the implementation instructions.|
|Is the Service Desk authorised to implement this request?||Key question: · Has the Service Desk been authorised to implement this specific standard change? Input: · Standard change document Output: · Determination to handle the request or to handle it as a non-standard change|
|Review the request and fulfill it||Key questions: · What are the details of this change? · Are there prerequisites? · Is the user authorised to receive the outcome of this change? · Can this change be implemented now, or should it be scheduled for later? · Can this change be implemented remotely, or will it require a physical presence? · What determines when the change is complete? · Are there any post-change activities required? Input: · Standard change document Output: · Determination of how and when to implement this change · Completed change Best practices: · All standard change documents should follow an identical format to make answering the above questions simpler and quicker. · Part of this activity should include setting the user’s expectations about the time required to complete the change.|
|Validate that the request completed successfully||Key questions: · Can the change be validated with a monitoring tool? · Can the user verify that the goal of the change has been achieved? · Did anything unexpected occur? · Was the standard change document completely accurate? · Was the change completed in the expected amount of time? Inputs: · User input · Standard change document · Change results Outputs: · Assurance that the change has delivered its intended value · Assurance that the Help request is accurate · Opportunities for improving the standard change document|
Process 3c3: Handling a Non-Standard Change New Service Request
Follow this process if the New Service request is for a non-standard change.
Figure 12. Handling a non-standard change New Service request
Activities: Handling a Non-Standard Change New Service Request
The Service Desk needs a set of activities to handle non-standard change New Service requests as well as any standard changes that they are not authorised to implement. Large and complex non-standard changes often start as projects and not as changes. These changes are handled through the Business Alignment function. To learn how this is accomplished, see the Business/IT Alignment SMF. The process of handling a non-standard change New Service request begins when the CSR creates a Request for Change (RFC). An RFC is a standard document in which all relevant information about the proposed change is recorded. Non-standard change New Service requests are then routed to a central processing queue where the Change Manager or a delegated reviewer will process the RFC following the change control process. The following table lists the activities involved in handling a non-standard change New Service request. These include:
- Completing the RFC record.
- Assigning the RFC to the appropriate team.
- Handing off to Change Control.
Table 14. Activities and Considerations for Handling Non-Standard Change New Service Requests
|Complete the RFC record||Key questions: · What exactly is the user requesting? · How does the user want it delivered? · Is this similar to an existing service? · Can the user provide any documentation or references? · How will the user use this change? Inputs: · User input · Previous RFCs Output: · RFC with as much meaningful information about the change as possible to enable Change Control to evaluate the merits of the request Best practice: · Some tracking tools allow the creation of change templates to help guide CSRs in gathering a consistent set of information based on the category of the change.|
|Assign the RFC to the appropriate team||Key questions: · Is this a standard change that needs higher authority to implement? · Is this a non-standard change that requires additional review? Inputs: · Previous RFCs · Updated RFC Outputs: · If the change cannot be implemented by the Service Desk, the RFC is routed to the correct team; If this is a standard change that requires additional authority to implement, the Service Desk can retain ownership of the RFC, open a work order, and then send it to the team authorised to complete the work. · If this is a non-standard change, the RFC is routed to a central processing queue where the Change Manager or a delegated reviewer will process it following the change control process. Best practice: · Some tracking tools allow the creation of change templates to help guide CSRs in gathering a consistent set of information based on the category of the change.|
Process 3d: Resolve an Incident Resolution Request
An incident is an event that results in a service or feature failing to fulfill a documented goal, which is established using the Service Level Management process and documented within a service level agreement (SLA). Without this SLA, users can declare almost anything an incident, thereby causing IT to research and respond to every complaint. For example, a user may contact the Service Desk and complain that a Web application is ”loading too slowly.” If the Web application has a defined goal to load within 10 seconds, the CSR can measure the user’s experience and accurately determine whether this is an incident. Incident resolution is a process that is specifically focused on rapidly restoring a service to a state from which it can fulfill its documented goals. The resolution can involve a single step or multiple steps, as the example in the following figure illustrates. The multiple-step approach addresses situations in which, for example, you might restart a database back-end server and assume that the service has been resumed. However, the client component could also require a restart, so the service is still down according to the user’s perception.
Figure 13. Example of incident resolution The process flow for incident resolution consists of the following processes:
- Troubleshooting the incident
- Escalating, if necessary
- Applying a fix or workaround
The following figure illustrates the incident resolution process flow.
Figure 14. Incident resolution flow
Process 3d1: Troubleshoot the Incident
The first process in incident resolution is to troubleshoot the incident.
Figure 15. Troubleshoot the incident
Activities: Troubleshoot the Incident
After a request has been determined to be an Incident Resolution request, you should first check the knowledge base and known error documentation to see if a solution for the problem has already been discovered. If you don’t find any information that helps, you can begin troubleshooting. You must find a balance between the amount of time you spend researching the problem and troubleshooting it. Over time, you can fine tune this process and provide feedback to the Operational Health MR to help automate the resolution of incidents. The incidents resolved in this process count toward a very important incident resolution metric: First Call Resolution. Efficiency gained in this area can improve user satisfaction, reduce the burden on technology resources, and drive down the cost of support. Note: It is important to note that the ”Call” in First Call Resolution can be any type of contact. The following table lists the activities involved in troubleshooting an incident. These include:
- Searching and locating applicable knowledge base articles or known error documentation.
- Beginning troubleshooting.
- Determining if the incident is a planned outage.
- If service is not resumed, reviewing the Help request history.
- Determining whether the classification and priority of the incident are correct.
- Determining if the incident has been resolved.
- If necessary, beginning Problem Management.
Table 15. Activities and Considerations for Troubleshooting the Incident
|Search for and locate applicable knowledge base articles or known error documentation||Key questions:
· What information is the user trying to obtain? · Is the user’s question on the FAQ list?
· Is the question regarding something in the IT Service Catalog?
· The Help request should provide the information required to locate applicable knowledge base articles
· Identification of the best-fit knowledge base article
· If an applicable knowledge base article cannot be located, the CSR should provide the user with a best-effort attempt to answer his or her inquiry
· Create and maintain a single interface to search for knowledge base articles. The articles should be flagged with metadata to organise the search results by incident type.
· Usage statistics should be recorded to track the usefulness of articles. This helps identify articles to retire or enhance or, in some cases, to publish directly to users through a self-help portal.
|Begin troubleshooting||Key questions:
· What needs to be fixed?
· Is this a new, unique incident that no applicable knowledge base articles or known errors can correct?
· Can a CSR effectively troubleshoot the incident?
· Will the fix require a change?
· Can the fix be executed now or should it be scheduled for later?
· Help request
· User comments
· Updated Help request with answers to the above questions
· The entire effort should focus on the resumption of the service or resolution of the incident. If moving a user’s network connection from port A to port B will get that user working again, even though port A is still broken, then this should be pursued.
· Troubleshooting should be a science and not an art. Small methodical steps should be taken, changing one variable at a time. Each step should be documented in the Help request along with its results.
· Although there are training opportunities and workshops on troubleshooting, sometimes the best education is peer-to-peer. Consider establishing an internal mentoring program to partner employees with advanced troubleshooting skills with newly hired CSRs.
|Is this a planned outage?||Key questions:
· Is the outage on the Forward Schedule of Change? This is a schedule that contains details of all the changes approved for implementation and their proposed implementation dates.
· Is this service outside of its standard operating hours?
· Is the user being migrated to a new service?
· Forward Schedule of Change
· Release plans
· Automated maintenance records
· Updated Help request
· If this is a planned outage, the Help request should be updated and closed with a reason code to note that it was a planned outage. This data can later be used to track the effectiveness of communications around changes and maintenance activities.
|Review the Help request history||Key questions:
· What are the details of the incident?
· What has been attempted already?
· Has the service been resumed?
· Is the information complete and correct?
· Help request
· Determination of what has already been attempted to resolve the incident
· The Help request should capture all of the details so that anyone encountering the request can gain a full understanding of the efforts previously taken. Help requests may move between several teams before being resolved. Word-of-mouth reassignment will lead to misinformation or lost facts, prolonging the troubleshooting efforts and often resulting in contacting the user to answer the same questions again.
|Are the classification and priority correct?||Key questions:
· Should this Help request be assigned to a different team?
· Did the Service Desk check the wrong categories in the knowledge base and known error records?
· Is the priority correct?
· Has the scope of the request been expanded?
· Help request
· Decision to continue working on the request or transfer it to another team for additional effort
· Properly updated Help request
· The insights used to correct the classification should be captured in the Help request—including how it was discovered to be the wrong classification and what information was used to classify it correctly.
· When possible, a phone call directly to the CSR who misclassified the Help request can help to ensure that the CSR knows that the request is being returned and that the CSR is prepared to accept it and resume working on it.
· The Service Desk needs to stay informed of any significant changes in the status of an incident. Changing the priority of a request can have a major impact on SLAs. Additionally, if the incident has moved up in priority, it could require special notification and communication procedures.
|Is the incident resolved?||Key questions:
· Has the service returned to its normal operating state?
· Can the user confirm that the service is working correctly?
· Are there additional steps required to resolve the incident?
· Were modifications made to the environment in order to resume the service that need to be backed out?
· If no further action is taken, will the service fail again soon?
· Were spare parts or standby systems used to resume service?
· Monitoring tools
· User comments
· Additional actions to resolve the incident
· RFCs to correct additional faults discovered during service resumption
· Use monitoring and diagnostic tools correctly. For example, confirming that a desktop is connected to the network after rebooting it does not ensure that it has restarted correctly and is ready for the user to log on to it. However, starting a remote session to see what is displayed on the user’s screen will tell a more accurate story.
· Once the user is able to resume his or her business function, attention should turn to any outstanding activities that need to be performed to completely correct the incident. In some events, it might be necessary to transfer the Help request to a separate group to address the outstanding activities.
· Know the difference between resolving an incident and creating a change. Placing a system back into an operating state is a resolution activity. Modifying the configuration, setup, design, or appearance of a system or service by placing it in a new state is a change.
|If the incident is still not resolved, try Problem Management||Key questions:
· Does solving this incident require more research and testing?
· Would solving this incident benefit from root cause analysis?
· Help request
· Problem Management process. This process is not a part of the Customer Service SMF, but is described in detail in the Problem Management SMF
· Additional actions to resolve the incident
· Problem Management is a separate process that involves documenting and filtering a problem, then systematically performing research, developing and testing hypotheses, performing root cause analysis, and determining if a fix or workaround has been discovered. It is a very important process that should be pursued if an incident resists normal troubleshooting efforts.
Process 3d2: Escalate the Request
If the service has not been restored or if the incident has not been resolved after troubleshooting, it is time to escalate the request.
Figure 16. Escalate the request
Activities: Escalate the Request
You should only escalate the request if you cannot resolve it within the SLA or if it requires specialised knowledge. Escalation brings new knowledge and new people into the resolution process. It is a best practice for each tier and focus area to have a dedicated Help request queue for storing and organising the requests currently assigned to their team. Although the CSRs from the Service Desk are accountable for overseeing the request throughout its lifecycle, they cannot stay fully engaged with every request. It is the responsibility of the team receiving the request to help ensure quality control. Screening reassigned requests is critical to validate that the information in the request is correct and that all required information has been gathered and recorded. Any time someone makes an adjustment to key elements of a request, such as priority or classification, the Service Desk should be notified. The Service Desk initially provides user information such as the priority of the incident and an estimated service resumption time. If these factors are modified, the CSRs need to realign user expectations.
Table 16. Activities and Considerations for Escalating the Request
|Escalate or transfer the Help request||Key questions: · Is additional technology expertise required to resume the service? (Escalate) · Is there a different technology focus required? (Transfer) Input: · Help request Output: · A determination of which additional areas to involve in resolution attempts Best practices: · Support organisations should classify team members by their depth of expertise. This is often referred to as tiered support. The higher the tier, the greater the specialisation or expertise and, often, the expense. Therefore, it is always desirable to resolve incidents at the lowest tier of support. · All requests and incidents addressed by CSRs should be counted toward the First Call Resolution metric. Efficient IT organisations are able to achieve 80 percent and higher first call resolution rates. · Within each tier, resources should be grouped by area of focus. The focus could be on a particular technology or a specific line of business. · The first tier, and broadest area of focus, is the Service Desk. The Service Desk should maintain a level of ownership for the Help request even if it is assigned to different areas and tiers. This provides continuity in communication between the user and the IT organisation. In addition to SLA monitoring, this also provides a layer of protection to keep things from ”slipping through the cracks.”|
Process 3d3: Apply a Fix or Workaround
Once a fix or workaround for the incident has been discovered, it should be applied immediately.
Figure 17. Apply fix or workaround
Activities: Apply Fix or Workaround
Applying a fix or workaround discovered during troubleshooting is an important process in resolving an incident. The following table lists the activities involved in applying a fix or workaround. These include:
- Applying the fix or workaround.
- Setting user expectations.
- Initiating the service fulfillment procedure.
Table 17. Activities and Considerations for Applying a Fix or Workaround
|Apply fix or workaround||Key questions: · Are there any prerequisites for the fix or workaround? · Will it take effect immediately? · Are there follow-up actions? Is a reboot needed? · Will the service resumption efforts be more disruptive than the current incident? · Does the CSR have the permissions required to apply the fix or workaround? Input: · Updated Help request Outputs: · Decision to attempt resumption, defer until later, or engage different resources to take action · Results of resumption efforts Best practice: · Keep focused on the service and the business impact of applying a fix or workaround. Although it is in IT’s interest to fix any malfunctioning system, sometimes the timing of a fix can have a major impact on the business. Rebooting a VOIP router for a sales office during peak call times in order to correct a complaint about calls echoing could result in dropping active calls and losing new users.|
|Set user expectations||Outputs: · User informed of the expected time required to complete the Help request · Request updated with an estimated time of completion Best practices: · If possible, the request should be completed immediately. This saves time that might be consumed with follow-up activities if the user has to be contacted later. · Ensure that there is a method to track incomplete Help requests and assign CSRs to follow up until they are completed.|
|Initiate the service fulfillment procedure||Key questions: · Can this procedure be executed at any time? · Are there any prerequisites? · Is there an authorisation required to proceed? Input: · Service fulfillment procedure Outputs: · Estimate of the time and effort required to complete the Help request · Begin the fulfillment procedure Best practice: · Fulfillment procedures should follow a consistent template that ensures that information such as required authorisation, prerequisites, license requirements, and financial impacts are documented.|
Process 4: Confirm Resolution and Close the Request
After the Help request has been fulfilled, you must confirm that the Help request has been resolved and then close the request in this process.
Figure 18. Close the request
Activities: Confirm Resolution and Close Request
The following table lists the activities involved in confirming resolution and closing the request. These include:
- Updating the Help request.
- Determining if the service has been resumed.
- Determining if the incident has been resolved.
- Verifying successful fulfillment.
- Closing the Help request.
Table 18. Activities and Considerations for Confirming the Resolution and Closing the Request
|Update the Help request with the knowledge base articles and known errors that were reviewed or applied||Key questions: · Which articles or known error records were applied? · Was more than one article or known error record required to resume the service? · Did any article or known error record used make the incident worse? · Did some articles seem to apply but have no effect? Inputs: · Help request · Knowledge base articles Output: · Triggers to capture inaccurate information that is delaying service resumption efforts Best practice: · Help requests should maintain a two-way association with knowledge base articles and known error records.|
|Has the service been resumed?||Key questions: · Has the service returned to its normal operating state? · Can the user confirm that the service is working correctly? Inputs: · Monitoring tools · User comments Outputs: · Additional actions to resume the service · Updated Help request|
|Has the incident been resolved?||Key questions: · Are there additional steps required to resolve the incident? · Were modifications made to the environment in order to resume the service that need to be backed out? · If no further action is taken, will the service fail again soon? · Were spare parts or standby systems used to resume service? Inputs: · Monitoring tools · User comments Outputs: · Additional actions to resolve the incident · RFCs to correct additional faults discovered during service resumption|
|Verify successful fulfillment||Key question: · Is the user receiving the intended benefit of the service requested? Input: · User feedback Output: · Updated Help request that indicates the outcome of the service fulfillment procedure Best practice: · When possible, a CSR should contact the user directly to verify that the request was completed correctly. Direct contact can be in the form of a phone call or a personalised e-mail. The key to success for e-mail communications is to ensure that the message includes the Help request’s unique reference number and that replies to the e-mail are routed to a live person for a timely response.|
|Close the Help request||Key questions: · Was the request fulfilled successfully? · Are there any post fulfillment requirements or actions? · Was the procedure easy to follow and accurate? · Could the procedure have been executed by the user? · Is there a way to improve the procedure? Output: · Key data points to generate improvements in the service fulfillment process and improvements to fulfillment procedures Best practices: · The Help request should have specific fields dedicated to capturing closure data. Each field should be tied to a specific outcome with well understood values. All such fields should be mandatory and driven by drop-down lists to ensure consistency in data for reporting and evaluation. · Over time, it may become necessary to add fields or new classifications. Providing regular training to new and existing staff is critical to disseminating this information and continuing to drive consistency in the execution of the process.|
Process 5: Ensure Good Service
The final process in customer service is ensuring that the Service Desk has provided good service to the user. This is done through Service Desk quality assurance and SLA monitoring and metrics.
Process 5a: Service Desk Quality Assurance
The first process involved in ensuring that good service has been provided is performing Service Desk quality assurance.
Figure 19. Service Desk quality assurance
Activities: Service Desk Quality Assurance
Service Desk quality assurance is an extremely important part of ensuring good service. Good customer feedback can help to justify continued Service Desk staffing and funding, as well as help with the continuous improvement of the customer service process. The following table lists the activities involved in Service Desk quality assurance. These include:
- Verifying the resolution of the Help request.
- Sending a user satisfaction survey.
Table 19. Activities and Considerations for Providing Service Desk Quality Assurance
|Verify the resolution of the Help request||Key question: · Has the user been contacted directly and did he or she confirm the resolution of the Help request? Input: · Help request Output: · Determination to close the Help request or to continue troubleshooting Best practice: · As part of the end-to-end ownership of a Help request throughout its lifecycle, the Service Desk is accountable for ensuring that the user is able to do his or her job. However, there is a fine line between providing customer service and annoying a user. If another group has provided clear evidence in the Help request that the user has confirmed resumption and resolution, then no additional follow up is required.|
|Send user satisfaction survey||Input: · User satisfaction survey Output: · Feedback and data for continuous improvement Best practice: · Keep the survey short and to the point. The survey should be tailored to the type of request and should generate metrics that link directly to key performance indicators. A 4-question survey that users answer 80 percent of the time is more useful than a 10-question survey that they answer only 25 percent of the time.|
Process 5b: SLA Monitoring and Metrics
In this process, you determine the status of the SLA and report any SLA breaches.
Figure 20. SLA monitoring and metrics
Activities: SLA Monitoring and Metrics
Although SLAs have traditionally focused on measuring technical services, it is important that support services also be measured and monitored. Help request volumes can be significant and IT operations managers cannot manually monitor queues and select incidents that need additional attention. SLA monitoring for Support Services takes over this task. The following table lists the activities involved in SLA monitoring and metrics. These include:
- Determining if the SLA is 80 percent expired.
- Alerting the Help request owner.
- Alerting management staff and the business.
Table 20. Activities and Considerations for SLA Monitoring and Metrics
|Is the SLA 80 percent expired?||Key questions: · How is the SLA time measured? · What is the target time? · What is the target action? · What is the appropriate SLA expiration threshold for initiating action to meet the SLA? · What SLA objective has been missed? · How is it measured? Input: · SLA Output: · Alert trigger Best practice: · There should be default measurements for each priority of Help requests. However, this should be overridden by documented targets within an SLA.|
|Alert the Help request owner||Key questions: · Who is currently working on this Help request? · Is the current owner of the request now available? · Should an alternate person be alerted? · Is there an on-call or duty manager? Inputs: · Help request tracking tool · Support schedule · Microsoft® Windows Live™ Communications Server (LCS) presence Output: · Alert trigger Best practice: · Alerts should be consistent and agreed upon. Where possible, visual cues should flag Help requests within the tracking tool. However, not all teams will visually monitor the tracking tool at all times. In these cases, alerts should be sent via e-mail or Short Messaging Service (SMS) devices.|
|Alert management staff and business||Key questions: · Who needs to know about this SLA breach? · How can the breach be explained in business impact terms? · What roadblocks exist to resuming service? Input: · SLA Output: · Informed and engaged management Best practice: · If an SLA is missed, IT management should not find out from a phone call from a displeased user. Likewise, users need to be informed that IT management is engaged and working toward an expedient resumption of service.|
The Customer Service SMF addresses how to provide a positive experience for IT service users by meeting their IT needs and addressing complaints and issues that arise during the normal course of using an IT service. It addresses how to provide that experience by:
- Recording and determining the nature of a customer request.
- Resolving requests for information, existing and new features, and changes.
- Resolving Incident requests.
- Ensuring good customer service.
How can I implement MOF?
Hopefully by now you’ll begin to understand the value that the Microsoft Operations Framework can bring to your business. The goals, outcomes and measures outlined above require many activities and considerations which form part of our day to day activities at First Solution. In fact, we’re experts in MOF and have even developed a unique ITIL IQ® process that benchmarks a business’s current state, identifies their desired state and provides an action plan (called a Service Delivery Plan) that helps organisations of all sizes achieve their desired business outcomes. Most importantly, our unique ITIL IQ® process begins with a Proactive Services Maturity Review (PSMR) which identifies a score (out of 100) that clearly communicates the current state of your businesses IT operational maturity. Armed with your ITIL IQ® score, a non-IT professional such as a finance or procurement professional can concisely present to the IT Executive Officer the businesses current state, desired state, and ITIL IQ® score with an action plan to improve the ITIL IQ® score and thereby ensure that IT’s goals are aligned with the goals of the business and that both are progressing together. Once the IT Executive Officer has bought into the MOF concept we can help to develop an IT service strategy, IT service map, IT service portfolio and Service level agreements.
How can I monitor and control better IT services?
Simply get in touch to arrange a free Proactive Services Maturity Review and one of our MOF experts will conduct an interview with the IT Manager or IT Executive Officer within your business and provide an ITIL IQ® score with which you can measure the performance of your IT function. Once you know your ITIL IQ® score we can provide a Service Delivery Plan to help you improve it each month and measure and report progress back to you during a Monthly Service Review. And there we have it, an ITIL based solution to simply identify and measure the performance of your IT function. So, are you ready to monitor and control better IT services?
The Microsoft Operations Framework 4.0 is provided with permission from Microsoft Corporation.