Service Level Management is a formal way for setting customer expectations BEFORE the customer has the need to request service. It is a methodology for introducing and implementing reasonable expectations between you and the customers you support. These are most often contained in a document called a Service Level Agreement (SLA). The SLA establishes a two-way accountability for service, which is negotiated and mutually agreed upon. It is really a contract that documents operational and interpersonal relationships, establishes mutual expectations, and provides a standard to measure performance.
Without SLA management in place, you are effectively telling your customers that you will provide support to them, at any time, under any conditions, without any limitations to the systems and services they have. However, this is not the worst part. The worst part is that you cannot possibly ever meet your customers' service expectations because every customer will have a different expectation and that expectation will change every time they call.
Every day each one of us experiences the setting of expectations. The following are all examples of setting expectations: setting an appointment time, asking for a delivery time and asking for the wait time at a restaurant or car repair shop. Why should your IT support organization be any different?
The benefits of a SLA are many
- Improves customer service. You will find that cycle times (time to resolve cases) dramatically decrease.
- Facilitates communication. The IT service desk staff will be able to set customer expectations (i.e. your employees) in two ways. First, they can refer to the SLA document for definitions on how priorities are set and the maximum time the IT service desk has to resolve the case. Secondly, they can refer to periodic performance reports to inform customers how the support organization is actually performing. Average time to resolve is usually much less than the maximum time goal.
- Negotiated and mutually accepted. Since customers and the support center jointly created the SLA all customers will more easily accept the SLA.
- Documents agreements. With the SLA posted to your Intranet or in employee handouts, it becomes an "official" agreement.
- Defines procedures. Procedures should be defined and followed by both the IT service groups and employees (i.e. your customers)
- When there is a question or disagreement, the SLA can be used as a written reference.
- Sets standards for customer service. This is a powerful tool. It says "Mr./Ms. Customer, this is how I am going to provide support to you and this is what you must do in order to receive my support. I am ready to be measured on how I do and I will provide everyone with a report on my performance."
Getting Started: Establishing An SLA
- Understand the time commitment. Do not underestimate the time and commitment involved in this process. Your entire organization needs to be committed to implementing SLAs. Once you start this process, you are clearly defining your service commitment to your customers. The creation of an SLA is not just the function of the IT service desk because it is not just an agreement between the IT service desk and customers that call there for help. Ultimately, everyone in IT supports the customer through the IT service desk. The IT service desk will not only be setting customer expectations for cases it resolves, but also for those cases elevated to 2nd and 3rd level support groups. Everyone needs to be committed to the service goals of the SLA.
- Understand your customers' needs. Become familiar with your customer's daily operations, processes, and business initiatives. Take time to develop a list of all services and products that require SLAs.
- Identify participants. Identify all the stakeholders that should participate in the IT service management process. This includes your customers, as well as any other internal/external organizations that assist the IT service desk in providing support to your customers. Be sure to include the decision-makers. While this task may seem daunting, this process is an excellent tool for building cross-departmental teams.
- Know your current support metrics. One of the biggest objections of those that provide service is an unwillingness to commit to service goals that cannot be met. The biggest objection of those receiving service from you is that you take too long in delivering the service. Both of these objections are based on "gut feelings." If you have actual cycle times (time to resolve cases) by severity levels, then both of these objections go away. That is the power of real numbers. If you do not have a process in place for setting severity levels for cases, it is better to postpone the start of the project until you have done this. Set up your own guidelines within your IT service desk team and then religiously assign severity levels for every case. You do not even have to tell anyone outside of the IT service desk. You will be surprised by how much informal severity level setting is already taking place. This is also a good time for a customer satisfaction survey. It will provide a baseline for measuring improvements.
- Team meeting. Hold a project team meeting to explain the goal and determine tasks and timelines. It is in the team meetings that many of the fears come out. If a support group says that the IT service desk cannot be accurate in setting the priorities, then ask them the following. Ask them to create a document with the types of cases they normally receive, the type of questions and documentation they need in the case and what the priorities should be by case types. This will be used to instruct the IT service desk on setting priorities. When the IT service desk does not set priorities correctly, you will want a process for notifying and training the individual who handled the case.
Gotcha! Service level management: Why it fails1
1Original article by Char LaBounty of LaBounty & Associates, Inc.
- Too Complex. The most common pitfall is that the SLA documents are too complex. These documents should be short and very precise in defining the services you provide and the level of service you and your customers agree on. If they are longer than 3-5 pages, then you are doing it wrong.
- No measurements. If you do not have the technology and tool sets to track and report the timed-service events by responsiveness and resolution for the various severity level classifications, then SLAs will fail. Without continuous feedback on performance, the loop is incomplete and the SLAs become documents and nothing more.
- Unrealistic management expectations. Often management does not acknowledge the amount of time needed to implement service level management, and therefore they do not staff it adequately. This cannot be a part time job! It must be managed full time.
- Unrealistic objectives and goals. Frequently, IT management and customers set unrealistic objectives and goals. This usually happens because there were inadequate measurements done prior to implementing the SLA. It is critical to baseline the current service performance prior to beginning to negotiate the SLAs with customers.
- No alignment and buy in at all levels of management. It is important that all levels within the organization understand the value of implementing a service level management culture. Without this commitment throughout the organization, it will be difficult for the line staff to understand it, want to participate in it and for the Support Center staff to enforce it.
- No existing Operational Level Agreements (OLA) within IT. Some organizations believe they can implement customer SLAs without first having established their own internal IT support OLAs. OLAs are basically a service level agreement between each service group. The IT service desk should have an OLA between each service department it sends cases to.
- Underestimating the scope. An organization implementing service level management must understand that this is a company-wide initiative. It will have impacts on staffing, technology, and the company's culture. This is NOT a project assigned only to the IT service desk.
Creating a rough draft
There are several components to an SLA. It is important that the language is familiar to your environment. Use a straw man to introduce the concept to your organization. This will help the rest of the project team understand the complexity and importance. The following is an example of the categories that should be included in your SLA. However, remember that it must be clear, well written, and easy to read and not very long.
- Purpose of the SLA
- Mission of IT (This is not just between the IT service desk and customers)
- Customers covered under the SLA
- Owner of the SLA document and communications path
- Services covered. This is only a high level statement
- Service Goal
- Overall goal. Example: Resolve 100% of all severity level 1 and 2 cases in the timeframe specified. This is the first place that you are making a statement about what is important. You cannot be a success treating all cases equally. Level 1 and 2 are high severity level cases that directly impact the productivity of a number of customers/locations of the company. You must make sure these get done on time. Getting the others done on time is a bonus.
- Specific goals. List the severity levels and the time the case should be responded to and the time it should be resolved.
- Definition of terms. Do not assume that everyone will know what you are talking about. You need to define terms to the lowest common level. Be as specific as possible.
- Service delivery elements
- Service coverage times. State clearly what business hours are supported and what is supported after hours. Failure to do this will mean you can be called at any time of the night for the most minor of problems or requests. Be sure to consider the various time zones you cover. Keep consistent and list the time zone you are in (e.g., 7AM - 7PM EST).
- Environment(s) included. What do you cover? If you only support standard hardware and software, be sure to state it here.
- Environments excluded. If the IT service desk will take cases for non-standard hardware and will charge back costs to the customer, then list that here.
- Specific applications and network services coverage. List specific applications by name, the times they are supported and the times they are not supported. If there are maintenance windows for databases and servers when they will not be available, then make sure to list these windows.
- Methods for requesting service. For example, for all level 1 and 2 cases the request for service may be via the phone. For example, for level 3 and 4 cases the request for service shall only be via the Web.
- Customer responsibilities. Some examples are: How to submit a request, what standards are supported, and when customers should be available for the technician.
- Service tracking and reporting procedures. Some examples are: IT will log 100% of all requests, phone calls will be randomly recorded for quality and performance metrics will be posted on the web.
- Escalation procedures. State the escalation path and time for each severity level.
- Telephone, Web and Email response times. For example: Phone requests will be answered in less than 20 seconds, Web requests within 30 seconds and email within four hours.
- First contact resolution by the IT service desk. For example: The IT service desk will resolve at least 70% of all cases it receives.
- Reporting methods.
- Weekly management reports on the Web
- Monthly performance metrics on the Web
- Quarterly Customer Satisfaction Surveys results on the Web
- SLA contract period.
- When the current draft is effective
- When it will be reviewed
- How to request changes
- Examples of cases by severity level and case type.
- Sample of the customer satisfaction survey questions.
Obtaining IT support
If you have measured the actual case resolution times based on approximate severity levels and you have created a straw man SLA including this data, then you are ready to get the rest of IT involved.
- Meet with individual managers to explain how their department did on your test of priorities and response time.
- Explain how the SLA goals will impact how they are already doing.
- Use your existing allies within IT groups to prepare the way for acceptance.
Obtaining Customer support
At this stage you should have accurate performance metrics, IT support for the service levels and escalation procedures. Now you are ready to meet with customers to get their feedback. What customers should participate? As a suggestion, your most critical customers might be the best. They are great people to have in your customer task force because they really want to see IT meet their needs. They will not be afraid to give you their opinions. They will certainly question your current response time report. Their memories are long and they remember how hard it is to get the support they need to do their job. They will usually be fair. If you can get them to agree to the SLA, you can get anyone to agree. Also, it is better to get any arguments and concerns out of the way now before you go public with the SLA.
Marketing your SLA
No one likes to be surprised, including your customers. Once you have your project team working on the structure, wording and goals of the SLA, it is time to begin telling your customers about the project. You can do this while on the phone with them in the IT service desk. Another approach is to email periodic "Progress Updates" that explains the project, benefits and implementation plan. Sending these out every other week will get them prepared. They will be ready to support the SLA when it is approved.
Implementing your SLA
- Pre-SLA. Before you announce the SLA, practice as if you have an SLA. This includes the following: a. training the IT service desk, b. monitoring response time to ensure SLA compliance, c. resolving cases in accordance with the SLA, d. setting customer expectations, e. managing the work flow within the IT service desk and between the second level.
- Training the rest of IT.
- Weekly meetings. For the first month it is beneficial to meet regularly to find ways to improve communications and workflow, review Cycle Time Reports and exception reports.
- Service Group Feedback. Ask other service groups to review their cases for the proper Severity Levels. If they find discrepancies, ask them to provide a list of case types and the appropriate Severity Levels. This will be the basis for IT service desk training and documentation.
- Implementing within IT first.
- Apply appropriate Severity Levels.
- Escalate cases according to SLA rules.
- Report on performance.
- Send out the formal announcement to customers.
- Purpose of SLAs
- How Severity Levels are applied
- Responsibilities of support organization
- Responsibilities of customers
- Performance reporting
Success of service level management can only be measured by reporting on what percentages of cases by Severity Level were resolved within the goals of the SLA. The reason that you want to measure each Severity Level is that it is absolutely critical to resolve high severity level cases consistently within the SLA. However, sometimes lower severity level cases can fall outside the goals. In other words, we would like to say that we resolve 100% of all Severity Level 1 cases and 90% of Severity Level 4 cases within the times stated in the SLA. Customers will appreciate the process more when they know that if they are really in trouble, there will be resources there to help them.
Checks and Balances
There is a tendency when first starting service level management to focus in on the response performance. It is easy to make the numbers look good. All you have to do is close a case within the time specified without doing anything. While this makes the numbers look good, in the end you will have customers upset. Customers do not really care about the numbers. They only want their issues taken care of to their satisfaction.
Customer Satisfaction Surveys are one way to provide checks and balances to the empirical numbers of SLA compliance reports. Another way to make sure customers are taken care of is to have a policy for re-opening a case if the customer calls in to say they are dissatisfied. You should then have a report that shows re-opened cases. Management should use this for continued training.
Quarterly or annually a survey should be sent to all customers asking them their general opinions of the support they receive. You cannot ask for specific information when you do periodic surveys because customers only remember their last one or two incidents. Periodic surveys are not a good measurement of how your organization did for the year. Another limitation of periodic surveys is that survey responses will not be specific to each IT service desk group or person assigned the case. Customers do not really know, or care, what group handles their request. To customers they are just all part of the IT organization.
Incident surveys are surveys sent to the customer after each case is closed. The advantage to this is that you can capture perceptions immediately and you can link the feedback to both the service group and to the assignee. This is extremely valuable information because both rewards and training can be tailor-made based on the results. The disadvantage is that customers will get usually one survey a week and they might not respond with as great regularity. However, the advantages outweigh the disadvantages. Incident surveys are preferable to periodic surveys.
The effort to create a Service Management System is very significant. Organizations that have a system in place have higher customer and employee satisfaction ratings. After all, when every case is considered severity level one and every day is a fire drill, it is hard to enjoy your job for very long. That is why the turnover in support organizations where Service Management Systems are in place is lower than organizations where they are not. So, with higher customer and employee satisfaction, lower turnover, greater productivity and reduced cost, why would you not want to have a Service Management System guiding your organization?