|
||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||
ABSTRACT
As a help desk becomes an integral player in a University's ability to expand technology to the community, its capability to keep up with the constantly changing and growing support needs becomes an increasingly difficult challenge. A help desk is often called to support systems and resources before the sponsoring group provides formal training to the users. Often a help desk receives calls about a new system before help desk consultants are introduced to the system or resource by the sponsoring group. Certainly, Service Level Agreements (SLAs) were designed to deal with this issue. But how can SLAs best assist a help desk in managing the never-ending need to provide cutting edge technical support.SLAs were designed to allow internal customers to state their service level needs. And, in turn, suppliers would be able to focus their resources into providing services at the required level. However, a help desk can be considered both a supplier and a customer. Therefore, the question becomes how can we design a SLA so it defines both the minimum requirements necessary before a help desk will support a service or resource as well as provides an agreed level of service to be delivered to the customer.This paper is designed to review SLAs and discuss questions including: What are the important elements to include in a SLA? What requirements are necessary for a system or resource to become eligible for support? What characteristics make up a production application? Should training, communication of outages, and 2nd tier support be included in a SLA? REFERENCES
Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.
INDEX TERMS
Primary Classification:
General Terms:
|
||||||||||||||||||||||||||||