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?
- A properly defined and manageable set of expectations
regarding IT support/service.
- Something to be printed up and put in a file folder
somewhere.
- A joke.
- 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.
The goal of an SLA is to set a manageable foundation of
appropriate expectations so that the relationship between
parties will be workable and sustainable.
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.”