Published: April 25, 2008 | Updated: October 10, 2008
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 Catalog.
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 categorization and prioritization 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
Activities
Considerations
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 Catalog?
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 organize 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 authorized 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 organization. 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 Catalog 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 Catalog. 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
Activities
Considerations
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 organize 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 authorization 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 authorization, 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 Catalog 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 authorization for the change must adhere to an organization’s established Change Management process. For more information about Change Management, read the MOF Change and Configuration SMF. 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
Activities
Considerations
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 formalizing 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. For more information on standard changes, see the Change and Configuration Management SMF.
Standard changes, even though low risk, can range from simple to moderately complex. The Service Desk can be authorized 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 authorized 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 authorized 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
Activities
Considerations
Is this request for a standard change?
Key questions:
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 authorized to implement.
Like any other important IT Operations document, standard change documents should be managed in line with knowledge managementpractices. 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 authorized to implement this request?
Key question:
Has the Service Desk been authorized 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 authorized 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 authorized 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. For more information on RFCs and the Change Management process, see the Change and Configuration SMF.
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
Activities
Considerations
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 authorized 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
Activities
Considerations
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?
Input:
The Help request should provide the information required to locate applicable knowledge base articles
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 organize 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?
Inputs:
Help request
User comments
Output:
Updated Help request with answers to the above questions
Best practices:
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. For more information on troubleshooting, see the Problem Management SMF.
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?
Inputs:
Forward Schedule of Change
Release plans
Automated maintenance records
Output:
Updated Help request
Best practice:
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?
Input:
Help request
Output:
Determination of what has already been attempted to resolve the incident
Best practice:
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?
Input:
Help request
Outputs:
Decision to continue working on the request or transfer it to another team for additional effort
Properly updated Help request
Best practices:
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?
Inputs:
Monitoring tools
User comments
Outputs:
Additional actions to resolve the incident
RFCs to correct additional faults discovered during service resumption
Best practices:
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?
Inputs:
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
Output:
Additional actions to resolve the incident
Best practice:
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 specialized 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 organizing 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
Activities
Considerations
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 organizations should classify team members by their depth of expertise. This is often referred to as tiered support. The higher the tier, the greater the specialization 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 organizations 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 organization. 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
Activities
Considerations
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 expecttations
Output:
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 authorization 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 authorization, prerequisites, license requirements, and financial impacts are documented.
.jpg "Cc543284.image8(en-us,TechNet.10).jpg")
.jpg "Cc543284.image9(en-us,TechNet.10).jpg")
.jpg "Cc543284.image10(en-us,TechNet.10).jpg")
.jpg "Cc543284.image11(en-us,TechNet.10).jpg")
.jpg "Cc543284.image12(en-us,TechNet.10).jpg")
.jpg "Cc543284.image13(en-us,TechNet.10).jpg")
.jpg "Cc543284.image14(en-us,TechNet.10).jpg")
.jpg "Cc543284.image15(en-us,TechNet.10).jpg")
.gif "Cc543284.note(en-us,TechNet.10).gif")
** Note** It is important to note that the ”Call” in First Call Resolution can be any type of contact..jpg "Cc543284.image16(en-us,TechNet.10).jpg")
.jpg "Cc543284.image17(en-us,TechNet.10).jpg")