A service level agreement (SLA) is a highly effective tool for improving communication between service providers and customers. SLAs help provider and customer groups more effectively manage expectations, clarify responsibilities, and minimize conflict. Yet, despite the proven effectiveness of SLAs, not everyone believes in their value, insisting that if people trust each other, they should not need a formal agreement.
Working recently with an IT group whose members thought SLAs would help them better communicate the scope of their services, I was startled by the intensity with which one member of the department voiced his objections. The vehemence with which he protested suggested that he was reacting to something other than the current discussion. Perhaps he’d had a negative experience with SLAs that had left him skeptical about their merits. Or maybe he believed that trust made the world go around—or ought to, at least. Or perhaps he’d been a big-hearted kid who, for some reason, no one trusted, and he remained motivated ever after to demonstrate he was trustworthy.
In any case, he was mistaken in thinking that trust alone would suffice. Trust is crucial in any relationship, but it is fool-hardy to rely on trust alone in a complex service environment in which much is at stake. Even when people make service commitments with the intention of following through on them, they can easily forget the specifics they agreed to or discover that they have different interpretations of those commitments. In some situations, service commitments are broken when people change jobs and, in the absence of an agreement, their successors don’t know what commitments were made.
Service level agreements are valuable because people are—well, only human. SLAs don’t diminish trust; they strengthen it. Whether you’re the provider or the customer, SLAs can help you close existing communication gaps and prevent others from occurring. SLAs clarify the terms and conditions of service delivery and help keep service targets in clear view. They guide the process of monitoring and discussing service effectiveness. They provide a way to make service changes when such changes are warranted.
Although SLAs are especially valuable tools, not all SLAs are successful. Some fail to function as hoped. Others never get completed because insurmountable problems arise between the parties while their SLA is being drawn up. Whatever their value, the process of creating and managing SLAs is not without pitfalls. This chapter describes how to best handle this process so as to enhance communication and create winwin relationships between providers and customers.
An SLA stands the greatest chance of succeeding if the parties involved view it as all of the following:
• A mechanism for managing expectations. An SLA helps the provider and customer set, achieve, and maintain shared expectations about service delivery. An SLA undoubtedly would have helped Ken, the director in Chapter 2, get through to his customers about the products supported by his help desk.
• A conflict-reduction tool. The communication process involved in establishing an SLA helps the provider and customer minimize the frequency and intensity of conflicts and more readily and amicably resolve those that do occur.
• A living document. Once an SLA is in operation, the parties manage it by monitoring service delivery, holding periodic reviews, and negotiating changes as necessary. As the SLA is managed, so, too, is the relationship.
• An objective process for gauging service effectiveness. In creating an SLA, the provider and customer agree on what they’ll look at to gauge service adequacy. These indicators become the basis for open and cooperative discussions about service effectiveness.
While providing SLA training and consulting internationally, I became curious why so many SLA efforts fail. As I investigated the various situations, I discovered some common patterns. These patterns are identified below as the six key reasons for SLA failure, and are paired with six corresponding contributors to SLA success.
The most important benefit of an SLA is that it should help the provider and customer work together collaboratively, rather than clobber-atively!
It is clear that SLAs cannot succeed if the customer or provider enters into the process with punitive intent, yet examples of just such an approach are common. Consider these three examples:
• An information systems vice president felt that his clients complained too much. He directed his staff to create an SLA to stop the complaints. It didn’t occur to him that forcing his unhappy clients to honor a so-called agreement would simply give them one more thing to complain about.
• A chief information officer directed a technology team to produce an SLA “to make our clients more cooperative.” He believed that this would encourage clients to put more effort into working in cooperation with his organization.
• A business unit upset with snafu-ridden service delivery demanded that its provider organization enter into an SLA. This business unit’s management viewed an SLA as a club with which to bludgeon the provider whenever service slipped, as though each such blow would inspire improved service delivery.
For an SLA to succeed, both parties must view it not as a “gotcha!” but as a mechanism for building mutually beneficial relationships. An SLA that is used as a communication tool rather than a battering ram can contribute to improved service because all parties understand what to expect of each other.
So what are the options when a provider views its customers as ungracious grousers or when a customer sees its provider as Snafu Central? When either party is dissatisfied, it is best not to jump right into enacting an SLA. Try first to understand the other party’s perspective, take steps to address some immediate problems, and develop a plan to improve the relationship. The very process of attempting to understand these sources of dissatisfaction often reduces their intensity because—at last—someone is listening.
That was the experience in a company in which water-cooler gossip in both the provider and customer organizations centered on the latest misdeeds of the other. Creating an SLA was a transforming experience for both organizations. Through a process of dialogue and discussion, the SLA managers—the provider and customer representatives who headed the SLA effort—gained significant insight into each other’s challenges.
Tensions between the organizations diminished as the SLA managers learned about each other’s circumstances and used this knowledge to formulate recommendations regarding ways the two parties could work better together. As frequently happens in an SLA effort, this communication process helped to improve the relationship before the agreement was even implemented.
An SLA should be created to build a sound relationship, not to suppress evidence of dissatisfaction with the relationship. So if you’re considering establishing an SLA, think carefully: Are you doing so to whip people into line? If so, stop now before you invest heavily in implementing a solution that’s certain to backfire.
Creation and management of SLAs aren’t effortless tasks to be left until you’ve finished everything else on your to-do list. They are big jobs and need to be taken seriously. Yet one of the most common misconceptions among people who attend my SLA seminars is that creating an SLA is a process that can be hurried through. In fact, many seminar participants arrive under orders from management to complete one the following week (or the previous week, as one distressed participant bemoaned). By the end of the seminar, these people realize that creating a successful SLA will take longer, maybe a lot longer, than management expects. Creating an SLA is a project, not a tiny task.
Why is it such a big job? Because creating a successful agreement requires much more than simply plugging numbers into a template. The process of planning, establishing, and implementing an agreement can last for months and can involve numerous tasks, such as: assessing service history, creating service descriptions, defining service targets, gathering customer feedback, negotiating service standards, establishing tracking mechanisms, designing reports, documenting procedures, gaining approvals, educating pertinent parties, and training front-line staff.
Furthermore, departments that interact so as to support customers may discover that they can benefit from creating agreements among themselves before they enter into agreements with their customers. Sometimes called operational level agreements, these agreements are virtually identical to SLAs except that they are between groups within the provider organization rather than between the provider and customer. Creating these inter-department agreements can add weeks and even months to the length of time needed for the total effort.
The benefit of doing all this work is that creating a well-structured SLA vastly improves communication between providers and customers both during its creation and after its completion; invariably, the parties come to better understand each other’s needs, priorities, and concerns. The process of creating an SLA helps providers and customers build the foundation for a strong, successful, long-term relationship. To rush this process risks sabotaging the entire effort.
Because this communication process has such power to enhance mutual understanding, I prefer to see it take whatever time it legitimately needs. Sometimes, of course, the deadline for SLA completion is driven by external factors, such as the release date of a product, which may force the process to be rushed. However, the duration of the effort should not be determined by an arbitrary deadline.
Be forewarned: Completing the SLA is not the end of the job; in a sense, it’s just the beginning of a long-term commitment to communication. Once an SLA is in operation, managing it entails a number of ongoing tasks, such as tracking service delivery, holding service reviews, modifying the agreement, discussing problems related to the agreement, and maintaining contact with the other party. Managing the agreement, however, takes significantly less energy than the parties previously expended in resolving disputes, conflicts, and differences of opinion prior to completion of the SLA.
Given the scope of the effort, how long does it actually take to create an SLA? Well, it depends. Key contributors to the duration of the effort include the following:
1. The service environment: The more services covered by an SLA, and the more complex they are, the longer it takes to discuss, negotiate, and document the conditions of service delivery.
2. The proximity of the parties: Face-to-face negotiation is crucial in establishing an SLA, even if all other aspects of the SLA development work are done on-line or by phone. Travel time can add significantly to the length of the effort.
3. The span of impact of the SLA: Establishing an SLA between local groups generally takes less time than establishing an SLA that spans great distances. Global SLAs face complex issues due to differences in culture, time zones, pricing policies, legal and other regulations, and customer expectations.
4. The relationship between the parties: When the parties to an SLA trust and respect each other, the effort proceeds more expeditiously than when the relationship is adversarial and needs repair.
5. The contractual nature of the SLA: An SLA designed as part of a legal contract, and requiring the involvement of legal authorities, typically takes longer than a non-contractual SLA.
6. The availability of a model: The first SLA a group creates usually takes the longest. Once it is in operation, the document and the process can serve as a model for subsequent SLAs. If the first SLA is successful, later ones usually proceed much more rapidly.
7. Prior SLA experience: The most expeditious efforts are those led by SLA developers with prior successful SLA experience.
8. Availability of SLA development staff: Typically, personnel assigned SLA responsibilities have other concurrent duties. The extent of their availability to focus on SLA work affects the duration of the effort.
Given these factors, how long should it take to establish an SLA? I have found three-to-six months to be a good rule of thumb. When circumstances are optimal, three months may be a realistic estimate, or perhaps even less. However, if the situation is complex, even six months may not be enough time. Complex global SLAs sometimes take a year or more to reach completion.
One major reason why the process sometimes founders is that the people in charge of establishing the agreement are unfamiliar with how to go about it. I recall one manager who energetically predicted that she’d have an SLA in place in six months—but six months later, the effort had gone nowhere. She admitted that once they initiated the effort, no one was quite sure what to do first and what to do next.
A second major reason why the effort sometimes stalls is that one or both parties fail to bring a serious commitment to the effort. When management refuses to allocate staff to establish the SLA, or the effort is given a low priority, or one or both parties are unwilling to negotiate in good faith, progress becomes impossible. Although it may take longer than six months to create an agreement, if significant progress has not been made within that time, it’s best to stop the effort and examine why before either party invests more time and expense.
Imagine an IS organization developing a service level agreement to improve its partnership with its clients and not inviting a single client to participate in development of the SLA, or even to provide input. This unilateral approach happens more often than one would guess, and it is a surefire formula for failure.
Both provider and customer personnel must be involved in the formulation of an SLA. If one party attempts to control the process, members of the other party are likely to resist its terms even if they might otherwise have supported them. An SLA cannot be created unilaterally by one party in the hope that the other party will shape up, tone down, or go along. Yet many organizations believe this, seeming to think the meaning of “agreement” is “Let’s you and I agree to do things my way.”
For example, a vice president decided to use an SLA to improve his department’s relationship with customers who were dissatisfied with shoddy service. He had a team create a draft agreement and send it out to customers for feedback. Seeing the agreement as one more attempt by provider personnel to have their way, customers either trashed it, belittled it, or ignored it. The relationship between the two organizations remained strained for almost another full year until they undertook a genuinely collaborative SLA effort.
Although the SLA process must allow both parties to have some say, it may be neither feasible nor practical for providers and customers to collaborate on every aspect of the SLA effort. That’s why the one-sided approach—a unilateral agreement—is so prevalent in our everyday lives. Open your software package, for example, or click on the “accept” icon on-line, and you’ve agreed to the vendor’s terms. You’ve also agreed to terms unilaterally established by your bank or credit card company when you are an account holder—as I realized recently when my bank sent me a flyer that outlined its services and fees, stating, “We may change these fees and terms at any time, and if we do so, we will notify you in accordance with the terms of your Account Agreement.” Did I make an agreement? I suppose so. Clearly, I can agree to keep the account, or I can transfer it to another bank where I’ll be greeted with a similar “agreement.”
Read the fine print on the back of most tickets, whether to a sports event, a rock concert, or a ride at the amusement park, and you’ll discover that by using the ticket, you’ve agreed to specific terms—ones about which you’ve had no say. As an avid skier, I’ve read the list of hazards, dangers, and warnings printed on the lift ticket many times, but not thought much about it. However, I came to see the risk in a different light when I wrenched my knee skiing on steep terrain and two ski patrollers had to load me into a rescue toboggan. When they debated whether to take the long, slow, but safest trail down or the steep, icy, but quickest route, I was given no say in the matter. Of course, they selected the fast, icy route. I feared they’d lose control and catapult me on a solo journey down to sea level (Headline: “Skier Missing. Believed Drowned.”). I lived to tell the tale, but would have much preferred a collaborative decision.
Given the prevalence of one-sided “agreements,” perhaps it’s not surprising that many organizations begin their SLA effort with an “our way” mentality. But to talk about an SLA under such circumstances is a contradiction in terms. An SLA is, first and foremost, an agreement. Creating one entails discussion, collaboration, and compromise. A well-designed SLA enables the parties to amicably resolve their concerns about service delivery. Because they’ve agreed on how to handle disagreements, they will actually have fewer disagreements; those they do have can be resolved more rapidly and with less gnashing of teeth.
An SLA requires both service elements and management elements.1 The service elements clarify the services provided, the terms and conditions of service delivery, and the responsibilities of each party. The management elements focus on how the parties to the agreement will track, report, and review service effectiveness; how they’ll address SLA-related disagreements; and how they’ll negotiate adjustments to the agreement.
1 For detailed guidelines on establishing SLAs, contact me regarding my handbook, How to Establish Service Level Agreements. A detailed table of contents is on my Website (www.nkarten.com), along with a downloadable excerpt and several articles on establishing SLAs.
Both service and management elements are necessary if an SLA is to be effective, yet many SLAs I’ve evaluated for clients lack some or all of the management elements. In fact, omission of management elements, such as service reporting or periodic reviews, is a leading cause of SLA failure. These all-important service and management elements are described in the sections that follow.
The three main service elements are context-setting information, service description, and service standards. Each element is more fully discussed below.
Context-setting information introduces the agreement, setting out such information as the parties to the SLA, its purpose and scope, the set of services it addresses, important underlying assumptions, the service glossary, contact information, and perhaps an executive summary. This opening section sets the tone by communicating to readers that the SLA is a collaborative effort jointly undertaken by both parties.
The service description focuses on the services covered by the SLA. It also may include the services not covered if customers might reasonably assume the availability of such services. It can also include a description of the customer organization; the business needs to be addressed; and information such as the costs, pricing structure, and terms of payment. Some organizations prefer to place pricing information in an appendix to facilitate updating pricing changes. Of course, any information documented elsewhere that is easily accessible can be omitted from the SLA and referenced either in the context-setting section or in a section headed “Related Documents.”2
2 Thus far, very few organizations that have created SLAs with their internal customers have posted their SLAs on their internal Websites for viewing by both parties. Those that have done so have benefited from the ease of linking related documents and, as a result, have minimized the length of the core document.
Service standards ensure that both parties share a common understanding about the time frames, levels of responsiveness, and conditions under which the stated services will be provided. As a result of the common understanding, both parties know what they can reasonably expect. In an SLA, service standards typically focus on availability, up-time, responsiveness, throughput, timeliness, and quality. For example, a service standard might state
The Inquiry Database will have 99 percent availability between 7 A.M. and midnight Monday through Friday; 95 percent availability between midnight and 7 A.M.; and 92 percent availability at all other times, as measured over a calendar month, and excluding periods of scheduled downtime for maintenance. All stated times are Central Time.
Notice that this service standard describes
• availability levels for different time periods
• the time frame over which the availability is tracked
• service exclusions: conditions excluded from the calculation of availability, such as downtime for maintenance
A service standard might also describe different pricing for different levels of service, as well as service dependencies: other parties on whom the provider or customer is dependent in order to meet the terms of the agreement.
The four key management elements—service tracking, service reporting, periodic review, and change process—minimize conflict and strengthen relationships by ensuring that service delivery is tracked, reported, and regularly and objectively assessed. These elements interact to make the SLA a living document and are discussed more fully below.
Service tracking focuses on the gathering of service data as the basis for assessing service effectiveness. When data are collected and reviewed, problems can be identified and addressed before they escalate into crises. Ideally, service tracking incorporates both objective, quantitative measures and subjective, qualitative measures.
Objective, quantitative measures reflect what is—that is, actual service delivery—by capturing pertinent service data, such as problem resolution time for help-desk support, up-time for a network server, and transaction response time for a customer database. The provider and customer should track the minimum number of indicators that will enable them to assess service adequacy. Objective, quantitative measures help to quickly isolate unacceptable variations in service delivery by tracking their patterns; such measures also help answer questions such as the following:
• How has response time varied during the last six months?
• Is this month’s percentage of downtime consistent with past months’, or is it an aberration? If an aberration, what accounts for it?
• Does on-time delivery show seasonal variations?
• What kinds of problems have taken the greatest amount of time to resolve in the last three months?
• How do the number of call disconnects per hour vary over the course of the day?
Subjective, qualitative measures reflect what is perceived—that is, the customer’s experience in receiving the service—which may differ from what is, and is at least as important in generating customer satisfaction. In gathering subjective feedback, focus on the guidelines presented in Chapter 10. Try to use a combination of methods to gather feedback, such as the following:
• periodic customer surveys to gather data from a large number of customers
• service-specific assessment forms to have customers rate and comment on recent service experiences
• customer interviews for obtaining in-depth feedback
• evaluation of complaints for quickly identifying and resolving problems
Service reporting focuses on when and how service data will be reported and acted on. This public display of service information helps to highlight performance targets and actuals. Although service tracking and reporting are extremely important features of an SLA, don’t forget the power of the naked eye. Don’t wait for a monthly report to notice a troubling pattern that you’d easily see if only you had looked earlier.
It’s important to distribute service reports to both provider and customer personnel. Without an SLA, service information tends to be communicated to too few people. For example, one help-desk team prepared stunning charts summarizing monthly problem-solving patterns, but the team used the reports strictly for its own internal purposes. In reviewing the charts, I noticed the large percentage of time the help desk spent resolving printer problems. When I commented about this to a customer manager, she expressed surprise at this large percentage, and vowed to work with her employees so that they’d have fewer printer problems and could fix more of the problems themselves. In making this commitment, she took some ownership for the problem. Not all customers will take ownership as she did, but those who know about a problem are more likely to help prevent it than those who don’t.
Distributing service information—or at least providing access to it—also fulfills a valuable public relations function in reminding others of the services you deliver and your experience in delivering them.
Periodic reviews, led by the SLA managers of the two parties, ensure the regular and systematic review of service status by both customers and providers. The objectives of a periodic review are to
• review service delivery since the last review
• discuss major deviations from service standards
• resolve any conflicts or concerns about service delivery
• reevaluate services in light of current business needs and available resources
• discuss changes that are planned or in progress to improve service effectiveness
• negotiate changes to service levels, service tracking, or other relevant matters, and to modify the SLA accordingly
The importance of the review warrants face-to-face or at least voice-to-voice contact, so e-mail is not an acceptable channel for conducting periodic reviews. However, on-line access to service reports, such as by means of a corporate intranet, can facilitate discussions about service data during reviews by phone.
These reviews are critical to managing an SLA because they provide a formal, systematically scheduled way to assess service adequacy and to negotiate service changes. Regardless of what issues are on the agenda, other issues invariably arise that would normally not have received attention until much later, if at all. In the process, these meetings help strengthen relationships.
For example, the members of two divisions of an organization I once worked with were located in two distant cities and barely knew each other. Their distance from each other exacerbated the difficulties that plagued their relationship. After creating an SLA, they began holding monthly service reviews, alternating between the provider location and the customer location. Each SLA manager invited people from his own organization to come along when visiting the other’s site. Gradually, people from the two organizations met and became familiar with each other’s facilities and work environment. Over time, their pattern of blaming each other for problems was replaced with a pattern of cooperation in diagnosing problems and devising solutions.
A change process makes the SLA a living document by facilitating changes to the terms and conditions of service delivery. The change process enables the parties to make changes as circumstances warrant and when both parties are in agreement. This opportunity to make adjustments to the SLA often reassures those who fear being locked into service commitments that may subsequently prove unworkable.
Changes might be made for such things as adding new services or service standards, modifying service levels, setting new service targets, and adjusting the division of responsibilities. Of course, changes should not be made casually. Ideally, they should be confined to such matters as changing business or service needs, significant variations from agreed-upon service standards, or unanticipated events.
Typically, the primary work of creating an SLA rests with each organization’s SLA manager, the person designated to direct the SLA effort on behalf of his or her organization. Alternatively, some organizations invite a third party, often from a quality-assurance or quality-improvement group, to oversee the SLA effort or to help the parties establish the SLA.
In establishing an SLA, pay particular attention to the following steps, each of which entails communication that is often lacking in the absence of an SLA.
• Gather background information. Both the customer and the service provider need to gather internal information so that each has a solid basis from which to negotiate. Therefore, before eliciting commitments from their service provider, customers should carefully review and clarify their own service needs and priorities. And before making any commitments to customers, the service provider should examine its service history and determine the level of service it can realistically provide. This process of communicating with others in one’s own organization before communicating with those in the other organization is valuable in and of itself, aside from the SLA effort. Often, the information gathered highlights problem areas that need attention before the SLA effort can continue.
• Gather customer feedback. Before establishing an SLA, it’s valuable for providers to gather feedback from customers so that they have firsthand information about customer perceptions. Such feedback improves the provider’s understanding of customer concerns and creates a baseline against which to assess customer satisfaction after SLA implementation. As previously noted, customer feedback can be obtained in numerous ways, such as through surveys, focus groups, facilitated discussions, and interviews in person or by phone. The very act of meeting with customers and listening to them can help to improve communication before SLA negotiation even begins.
• Ensure agreement about the agreement. The two parties to an agreement sometimes have different ideas about the role of the SLA and what it will accomplish. For example, one party may view it as a quick fix, while the other may view it as a mechanism for building a long-term relationship. One party may want the SLA to reflect more stringent service levels than the other does, or expect it to deliver benefits that are outside its scope. Each party may expect the other to carry more of the work load in developing the agreement. Therefore, it’s advisable for the two parties to hold a discussion to ensure that they have a basic level of agreement about the agreement. Until they do, any further SLA effort may prove futile.
• Establish ground rules for the working relationship. In this step, the SLA managers focus not on the agreement, but on the process by which they will work together to create the agreement. Issues to be discussed include the division of responsibility for development tasks, scheduling issues and constraints, and potential impediments to the SLA’s creation. In addition, they may benefit from discussing their communication styles and preferences, as described in Chapter 6. By identifying similarities and differences at the onset, they will be in an excellent position to minimize conflict and to recognize and resolve any communication problems that arise.
• Create a service glossary. The service glossary enables the parties to work out differences in their interpretation of crucial service terminology. While creating such a glossary may not sound exhilarating, it generally leads to a wide-ranging discussion of how each party perceives service terms such as availability, up-time, problem resolution, and turnaround time. The result is a shared vocabulary that reduces the likelihood of future misunderstandings, making this one of the agreement’s most important features. I’ve even seen SLAs with a definition of “service level agreement” in their own glossary!
• Create a draft agreement. This is just one step in the process of establishing an SLA; it’s not the entire process. In this step, the parties create a structure for the SLA document and then research, discuss, debate, negotiate, and document the agreement until—over time—they reach accord about its contents. In doing so, they may each solicit assistance, input, or feedback from others in their own organization.
• Generate buy-in. Note that the result of the previous step is a draft agreement, not a completed agreement. Before implementing an SLA, all members of both parties who have a stake in, or are responsible for, the success of the agreement should have an opportunity to review the draft, raise concerns and questions, and offer suggestions. Using this feedback, the developers can conduct further negotiations, gain the necessary approvals, and finalize the document.
• Complete pre-implementation tasks. This step entails the identification and completion of such tasks as developing tracking mechanisms, establishing reporting processes, developing procedures for carrying out stated responsibilities, preparing pertinent documentation, communicating expectations to staff, and establishing and communicating an implementation date.
Then, and only then, are you ready to implement the agreement.
A common misconception is that once the SLA document is complete, the job is done. However, an SLA that is not managed dies upon implementation. Managing the SLA must be the responsibility of a designated individual or group within each party, whose role may include such duties as
• serving as a point of contact for problems related to the agreement
• maintaining ongoing contact with the other party’s SLA manager
• overseeing the tracking and reporting of key performance indicators
• planning and conducting service reviews
• coordinating and implementing modifications to the SLA and to service delivery
• conducting customer satisfaction surveys
• assessing and reporting on how the two parties can enhance their working relationship
• keeping management informed of any concerns regarding conformance to the provisions of the SLA
• planning classes designed to improve service attitude, foster awareness of the elements of high-quality customer service, and provide skills in service delivery
• overseeing ongoing relationship-building efforts designed to help the two parties work together in a supportive and cooperative manner
One of my most satisfying moments in providing SLA assistance occurred as two formerly adversarial groups neared the implementation date of an agreement with which both parties were pleased. During a private conversation, the customer’s SLA manager told me, “I believe we’ve reached a point in our relationship where we could switch places and come out with the exact same agreement.” Such a comment would have seemed inconceivable at the outset.
Both the SLA process and the resulting document are adaptable to numerous contexts and adjustable to the unique needs of all the parties. If you can’t get the approval or buy-in to create an SLA, then undertake as many of the individual activities as possible. This approach, which I call “How to succeed by not quite establishing an SLA,” can enable you, ultimately, to create an SLA.
For example, try the following as single activities:
• Assess your service effectiveness.
• Gather customer feedback regularly.
• Create and disseminate your service description.
• Create a service glossary.
• Formulate service standards.
• Track and report service delivery.
• Meet periodically to assess service adequacy.
• Make adjustments as appropriate.
Although service level agreements have been used primarily between technology groups and their customers, I regularly hear from and work with other groups interested in adapting SLAs for their own use. On numerous occasions, employees and managers from a company’s business divisions who attend my SLA seminars alongside members of their organization’s IT division have expressed interest in creating SLAs with other business units. The fact is, an SLA can be created to improve a relationship with whomever one interacts. A few people have even commented that they could use an SLA in their marriage or other personal relationships. However, couples-based SLA counseling won’t be making an appearance in my seminars listing any time soon!
3.137.170.241