8.7 Components of an SLA

---

The basic elements in an SLA comprise the contract that is established between the users and the support team. These basic elements of the agreement are as follows:

I. Parties to the Agreement

II. Term of the Agreement

III. Scope of the Agreement

IV. Limitations

V. Service Level Objectives

VI. Service Level Indicators

VII. Nonperformance

VIII. Optional Services

IX. Exclusions to the Agreement

X. Reporting Procedures

XI. Administration Process

XII. Reviews

XIII. Revisions

XIV. Approvals

The Parties to the Agreement section of the SLA should simply identify who is providing the support services and who is expecting to receive the support services. The length of time the agreement is in effect is referred to as the term. The term is generally for one or two years at a time and is often set up to be renewable. Because technology changes so rapidly, renewable term conditions in an SLA are not recommended. This allows both sides an opportunity to come back to the negotiating table and reassess the SLA based on new input data.

The Scope section defines the services that are to be provided in the agreement. This is the section where you specify exactly what is supported, by whom, and when the support is expected to be rendered. For each application or piece of hardware, have a separate paragraph. This helps when technology changes or makes something obsolete and you want the SLA to remain in effect. You simply amend the relevant paragraph found in the scope section of the SLA by striking it and adding a new paragraph for the new equipment or software.

The Limitations paragraph is meant to clarify or place caveats on the level of support that is to be rendered within the scope of the SLA. These conditions or caveats are designed to protect the support team from being subjected to coverage of an SLA for any and all conditions imaginable. For example, if software performance were being measured based on response time, a part of the Limitations section may confine the terms of the SLA to performance under normal load conditions of 500 concurrent users, with a maximum of 750 users. Beyond that level of 750 users, the software named specifically in the Scope section of the SLA cannot be guaranteed to be operational by the support group.

The Objectives section is the part of an SLA that most people refer to when talking about SLAs. This is where levels of service are identified and defined. This includes measures of accuracy, number of users (as cited earlier), availability, volume, speed, response time, performance, timing, and so on. This section is where criteria are benchmarked and determined to be the standard to which the support team must adhere to as part of the agreement. Often, it is recommended that two standards, expected and minimum, are defined for each criteria in the Objectives section. The next section, Indicators, is used to define how these Objectives are measured or recorded.

The Nonperformance section of the SLA is where the stipulations of what happens when the support group fails to meet the objectives of the SLA will be found. If performance of the support team is such that objectives of the SLA fail to be met, this section will define what remedy occurs, at what point, and by whom. The consequences of failure on the part of the support team are negotiated in advance in this section. Recourse for the group receiving support is spelled out here. Both sides must agree that such consequences are fair and reasonable, or this section is meaningless. The penalty for nonperformance should be measured in terms of equal effect to the impact such nonperformance had on the group expecting support. Do not allow one side or the other to be treated too lightly or too strongly in this section. Remember that meaningful contracts mean having a goal of fair-mindedness and equity achieved on both sides of the negotiating table.

The Optional Services section would be where definitions of activities performed outside the normal scope of operations are added. This may include activities performed only occasionally, such as year-end close of the company books, where system availability may be required over weekends, holidays, and so on. This section would allow such situations to be spelled out and prevent surprises. It is often hard to think of such issues when first negotiating an SLA, but when doing so, try to look at operational issues for an extended period and determine what activities may require entries in the Optional Services section.

Reporting, administration, reviews, revisions, and approvals are all part of an overall SLA life cycle process. These activities revolve around communicating performance or nonperformance issues regarding the SLA to the organization, administering the SLA when situations arise where expectations are not met or unreasonable demands for support are made, providing periodic review of the SLA to ensure it is suitable to the current business environment, and making revisions as necessary to bring the SLA current with changing conditions. Approvals are required to effect such revisions and ensure the SLA is fair to all parties involved.

Books have been devoted to the development and administration of SLAs. Software exists that is focused entirely on SLA maintenance and administration. Volumes of data could be written about the details of SLAs, but the most important thing to remember is that it must be negotiated, fair, measurable, and have some level of accountability for nonperformance. It must be subject to periodic review and must go through an approval process. Otherwise, it is not worth the paper it is written on. You should never accept an SLA as valid or binding if the items defined in it cannot be benchmarked against some standards and subsequently measured against that benchmark to evaluate your performance. If that is the situation you are facing, it is definitely time to sit down and revise that SLA to something more reasonable. SLAs are often written without the proper level of participation or negotiation from the support groups, and unreasonable expectations are set (unintentionally, in most cases). The support group may try to uphold such expectations in good faith, but they are doomed to failure because the expectations are set higher than are reasonable. The support team, working as hard as they possibly can, will bear the brunt of much criticism, and it will be unwarranted because expectations were not reasonable.

8.7.1 Help Desk Checklist

This checklist identifies the type of customer support that the Help Desk may need to provide. It is intended to assist in preparing the organizational support team for handling questions or problems regarding the use of the product or deliverable. The checklist should be broken down into functional categories and common questions that have been gleaned from training classes. Issues that have been identified during the testing process should be documented and made available to the support staff. These items will be supplanted with other knowledge obtained by the support staff as the calls are handled. It is also a good idea to consider using a Help Desk software package that can preload such scenarios to save time for the support agent. Software that can readily access support data by functional categorization is most useful and will save the organization money. An example of this would be as follows:

  OS - Linux | SFA Product - Acme | Contacts Screen |    Address Section | State Field | no selection |    1-patch 4.32 available   

The support software used by the support agent would display these as filtered selections. In this case, the operating system is Linux. While running the Sales Force Automation software (whatever your company bought), the Contacts entry screen Address field will not display the state the contact lives in. As the user reported the problem, the support agent was making selections from a menu-driven application that narrowed the problem down to what was stated above. Ideally, the support software would inform the agent that a patch is available to fix the problem, and the agent could relay that information to the user.

---