Published: April 25, 2008 | Updated: October 10, 2008
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:
Categorize the user’s request. This helps the CSR determine which solution will best benefit the user.
Determine if the request is supportable.
Prioritize the request.
Process 2a: Categorize 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. Categorize the user’s request
Activities: Categorize the User’s Request
Categorizing 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 categorizing 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 Categorizing the User’s Request
Activities
Considerations
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 Catalog
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.
Categorizing 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 Catalog
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 organization 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 Catalog
Existing Requests for Change (RFCs). For more information about change control and RFCs, see the Change and Configuration SMF.
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 Catalog
Outputs:
Determination that this is an Incident Resolution request
Updated Help request to reflect additional details about the request
Best practice:
In some organizations, 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 categorizing 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
Activities
Considerations
Is this a supported service?
Key question:
Is the requested service listed in the IT Service Catalog?
Inputs:
IT Service Catalog
Help request
User comments
Outputs:
SLAs applicable to the supported service
Target times for escalation and resolution
Best practices:
Build an IT Service Catalog 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 catalogs, see the Business/IT Alignment SMF.
CSRs should have full access to the IT Service Catalog 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 Catalog, 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 authorize a shutdown or removal of an unsupported service?
Has authorization been granted to override the unsupported status and support the service?
Inputs:
Authorization 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 practice:
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.
Unauthorized services or devices can have a negative effect on IT service. For example, a store-bought wireless router can allow non-secure 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 Catalog.
Process 2c: Prioritize the Request
Once you know that a request is supportable, you need to prioritize its importance in order to make the best use of the Service Desk’s available resources.
Figure 7. Prioritize the request
Activities: Prioritize 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 prioritizing the request. These include:
Determining the impact and urgency of the request.
Prioritizing the importance of the request.
Table 9. Activities and Considerations for Prioritizing the Request
Activities
Considerations
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?
Information from the IT Service Catalog. For more information about service catalogs, see the Business/IT Alignment SMF.
The configuration management system (CMS). For more information about a CMS, see the Change and Configuration SMF.
Output:
Metadata added to the Help request to assist with locating resolution suggestions and priority selection
Prioritize 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 Catalog
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 prioritize 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.
.jpg "Cc543283.image5(en-us,TechNet.10).jpg")
.jpg "Cc543283.image6(en-us,TechNet.10).jpg")
.jpg "Cc543283.image7(en-us,TechNet.10).jpg")