We have learned in previous blogs that identifying what our customers expect from us is an absolute requirement in meeting their needs. We probably won’t be meeting all of our customers’ expectations if we don’t have a firm understanding of what they are.
We also know that each IT organization, group, application team and individual user has their own unique set of value drivers they will use to evaluate the quality of service being provided to them.
It is the responsibility of the service provider to manage their customers’ expectations throughout the entire sales and service delivery life-cycle. Customers that have a firm understanding of the service offerings, emergency response times, work request lead times and completion times have a much greater chance at being a satisfied customer than those that don’t.
Let’s face it, being a technical service provider isn’t an easy job to begin with. Your customers will hold you to a higher standard than they do their own in-house personnel. And they should. Why complicate the customer management process by not providing your customers with a strong understanding of what they can expect from your organization?
Defining a set of clear, concise Service Level Agreements (SLAs) will help to solidify support requirements and dispel any incorrect assumptions a customer may have on the services your organization provides.
Please note that I have intentionally left out SLAs that are based on availability and performance thresholds. That is an entirely different discussion and outside the scope of this article. The focus of this article is on support services. In addition, our work request lead times for our services are not set in stone. Like all support personnel, we understand that administrative requests are often driven by fast-paced business needs. Our goal is to help our customers succeed in their respective competitive market arenas. They are suggested guidelines for the majority of requests that are submitted by our customers.
I am a firm believer that every IT unit should meet with their internal and/or external customers that they support to establish a set of measurable Service Level Agreements. You don’t have to be a third-party service provider to take advantage of the benefits that a well-defined set of SLAs provide. I have create a standard Support Activity SLA document for each company I have been involved with, whether I was an internal employee, consultant or third-party service provider. Just like RDX’s external customers, your internal customers probably won’t be aware of your work request lead and completion times until you tell them.
Our SLA document at RDX is fairly simple yet very detailed. It contains service categories and individual services for each product (Oracle, SQL Server, DB2, UNIX/Linux, EBS, etc.). The SLA entry is clear and concise. Each entry contains:
- A formal description of the service (activity performed)
- When we will provide the service (upon customer request, ongoing, reoccurring frequency, event based)
- Suggested lead time we require to perform the service (if it is a requested activity)
- Performance standards (criteria we use to determine if the activity is successful)
- The amount of time the customer can expect the service activity to be completed by
- What we will need from the customer to perform the activity (security, connectivity, actions required by their personnel…)
Service Level Agreement Development:
The first step is to create a list of services your organization provides to the internal and/or external customer base. The Information Technology Infrastructure Library, or ITIL as it is most commonly known, uses the term “Service Catalog” to describe the service listing. ITIL documentation states that IT organizations “must identify what internal and external customers expect” from the service organization before the Service Catalog can be created.
Identifying what your customers want is beyond the scope and intent of this article. Our focus is to ensure that your customers fully understand the level of service your organization will provide to them. It is important to list all of the services you offer. Your SLA document may not contain a minimum service level for all of them, but each one must be evaluated. You also need to identify if you are guaranteeing any minimum levels of availability and performance for products, applications and hardware components that your unit supports.
Identify key Service Groupings for the SLA Document
Categorize your list of services into groupings of similar service activities. At RDX, we have grouped our services into the following basic categories:
Helpul Hints for Service Level Agreements:
At RDX, we review all of our SLAs on a regular basis. We also perform in-depth analyses on how well we are accomplishing each of our service level activities defined in our SLA documents. We use these results to create an internal “report card” that we use to measure our success as a service provider.
There is a direct correlation between how clearly a customer understands your service level guarantees and a successful customer/service provider relationship. As I stated previously, you probably won’t be meeting all of your customers’ expectations if they (and you) don’t have a firm understanding of what they are.