To Protect and Serve

• By Mikael Blaisdell
• 02/01/07

Careful consideration of service priorities is key to creating a sound service level agreement—and preserving the relationship between service provider and subscriber.

WHAT DO YOU GET when you draft a statement of service objectives, provider responsibilities, subscriber responsibilities, metrics for measuring priorities, response and resolution targets, terms and conditions, and fees/ consideration?

1. A properly defined and manageable set of expectations regarding IT support/service.
2. Something to be printed up and put in a file folder somewhere.
3. A joke.
4. The ability to check off another box on a “best practices in use by your department” survey.

All of the above are actual answers given by higher education IT professionals, and reflect a wide range of intentions regarding the drafting of such documents. One size definitely does not fit all; there is no single perfect service level agreement (SLA) for every department in every higher education institution. In fact, if an internet search is conducted using “‘service level agreement’ + university” as the search terms, the resulting list will offer more than 350,000 entries, including specific examples of service level agreements from universities and colleges of all sizes, all around the world. Want to know what the IT support group is promising to deliver to faculty and students at an institution similar to yours? The odds are very good that you’ll find a wealth of examples from which to copy, as you create your own SLA. With a few cut-and-paste operations to change the names, you’re set to go. But what will you have accomplished in the process? Will you have printed words on a piece of paper, or drafted the foundation for a working, sustainable relationship? Depending on who you ask, the answers to such questions vary, as does the definition of an SLA.

“Sure, we do SLAs for clients,” says John Webster, executive director of Cresh.net (www.cresh.net), an IT outsourcing and software hosting company delivering web access to enterprise system applications for the higher education market. “We have them in both directions: one with the application vendor, and another with the college or university that is using the application through us. The agreements have teeth, including percentage rebates for downtime and free service. But, in reality, an SLA is nothing more than a safety net. What’s important for us is the ongoing profitable relationship, and the SLA is a means to that end, rather than an end in itself.”

A college MIS director, who also must deal with campus “customers” on one side and providers on the other, comments, “We have defined a certain standard of service for our users, which is perhaps not quite the same thing as an SLA. It sets out our aspirations in terms of service provision, but we make no promises in case we can’t deliver! However, we do try to match the service provision to our known level of resources.” When the SLA is between an outside vendor and the school, however, the definition is not as loose. “There is a more formal process of procurement that the potential supplier must meet. If the supplier did not deliver, we would pull the plug on the contract,” the MIS director says. Why the difference between the service level target given to the users, and the actual agreement required of the providers? There are several elements to be considered that can vary considerably between different types of users and providers.

Weighing Service Priorities vs. Cost

The essential goal of an SLA is to set a manageable foundation of appropriate expectations so that the relationship between parties (whether between product/service provider and a school, or a school and its constituents) will be workable and sustainable. The vital elements of the agreement itself are: objectives, services to be provided, provider responsibilities, and subscriber responsibilities. Underlying each of those points are the resources that will be required to meet the promises. In essence, the questions you need to be asking are: “Why are we doing this?” “What are we offering/ buying?” “What are your responsibilities and duties?” and “What are my responsibilities and duties?” While “Do you/we have the ability to deliver?” may not be a stated part of this, there can be no true agreement without an affirmative answer.

Always, the most critical question in the process is, “What is most important to the client, and why?” For instance, Webster notes that many of Cresh.net’s university clients are 9 to 5, Monday through Friday operations. “Their real issue is not so much service level but payroll uptimes. They run payroll on Thursdays, and they have to make very sure that they are going to have access to the system. Their other work is not mission-critical to their organization.” Typically, such a client will not need, or be willing to pay for, a guarantee of 99.999 percent uptime 24 hours a day, 365 days a year. “We can give them the 99.999 percent guarantee if they decide they really need it,” says Webster, “but the incremental cost to us for getting to that last .999 percent would be high and we’d have to pass those costs on to them.”

For the manager of a campus help desk, using an Erlang calculator to predict the probable number of service requests from a user community—and the resources that will be required to meet them within a specified time frame—is not difficult if the necessary data is available. If you’re confident that you’ll probably get 100 calls between 9:30 and 10:00 in the morning, the calls will last around 5 minutes each, and you want to answer 95 percent of them within 60 seconds, then you’ll need to have about 23 agents ready in your center. (Several free Erlang calculators can be found on the web; for more information on such tools, click here.)

But are those calls truly important enough to cost-justify having 23 agents on staff at that time? While some of your students might think so, the university CFO probably will not be willing to increase your budget for that purpose without a compelling cost/benefit case.

Access channels, responsiveness, resolution levels, reporting…the list of SLA specifics may be as detailed or as general as required. “We set out the expectation for all events, connectivity, e-mail questions, phone inquiries, etc.,” says Webster. It’s also important to identify what is not to be provided. “Leave no stone unturned,” he warns. “Better to tell them that you will not provide a particular service than to let them make their own assumptions.” For example, when one of Cresh.net’s agreements did not specify that a particular reporting tool would be available, “the client assumed it was covered, and only discovered the omission some months into the agreement,” Webster recalls. “We ended up re-negotiating the contract, and we wound up paying for half of the cost increase out of our own pockets. We’ll make it up in the long run, but it would have been better if the problem had not come up in the first place.”

It’s the Relationship

“An SLA is only a conversation at the start of a contract,” says Webster. “What counts is the ongoing relationship.” Paul Moran, executive director of information and instructional technology services at King’s College (PA), agrees, and notes: “We’ve had a long-term relationship with our ISP and purchase a number of different services from them. It’s in everyone’s best interest to keep the quality high.”