Blog

The Art of Being a Successful Service Provider – Support Services SLAs

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:

Service Identification

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:

  • Customer Integration Activities – Our SLA contains a list of customer integration services that we will perform and their associated target dates. Not only do we offer customer integration service levels to our customers, we have also defined a set of service levels that we ask all new customers to adhere to during the integration process. Since we are a remote services provider, we need connectivity, accounts/passwords, environmental descriptions, etc.. Customers understand that we need this information before we can begin servicing their account. Our SLAs state what we need from the customer and when we need it by.
  • Monitoring – Robust monitoring is a key benefit that we provide to our customers here at RDX. Our SLAs state what we monitor, how often we monitor a particular resource or event and how quickly we will begin working in their systems if a threshold is exceeded or a monitored event occurs.
  • Problem Resolution Activities (event based)- One of our SLAs is “Provide expert diagnostic analysis for all operational problems that arise.” The frequency is “Upon Problem Identification” and the Service Level is “Troubleshooting begins within 15 minutes of problem identification and continues until problem resolution.” It tells our customers that when we identify a problem, we will be logged into their systems with 15 minutes and will work on it until it is fixed. Pretty clear.
  • Database Maintenance and Tuning – This category contains a listing of the various service activities we will perform daily, weekly and monthly to ensure each database is highly available and provides high performance.
  • Change Management – Our largest category contains all of the changes we can be asked to make to a customer’s server, database, schema, etc.. It is broken down into subcategories for clarification.
  • Backup/Recovery and Disaster Recovery – We feel that this set of services is so important to our service offering that we have a service grouping that contains all of the key activities related to making sure our customers’ databases are available when they need them. These activities include travelling to their DR location, the activities we will perform and how we will evaluate our success.
  • Installs/Upgrades/Clones – This category contains some of the most time consuming activities that we do for a customer. The completion times are clearly stated. Since we service multiple customers here at RDX, clearly stated notification and completion times for time-consuming projects are critical to our ability to service our entire customer base.
  • High Availability Configurations – RAC, Data Guard, SQL Server Clustering, Log Shipping, OS clustering and third-party, vendor-provided high availability installation services are contained in this category. If you name a high-availability configuration, we support it.
  • Strategic Analysis – Our goal at RDX is to not just be a service provider but also be thought of as a technology partner. We have dozens (and dozens) of experts on staff that we bring to bear on a regular basis to assist our customers on everything from third-party application reviews to new technology evaluations.
  • Customer Management – This category contains all of the activities that relate to informing the customer of our activities. Entries include meeting frequency, status reports, time reports, Root Cause Corrective Action discussions when problems occur and how quickly we will respond to a customer request for additional information on our services. If it is a communication activity or mechanism with the customer, it’s in there.
  • Helpul Hints for Service Level Agreements:

  • Make every effort to create a complete list of service activities. As stated previously, although every activity you identify may not be included in the Service Level Agreement, each one must be evaluated.
  • Categorize your list of services into groupings of similar service activities.
  • Don’t use high-tech verbiage to describe the service activity. Make the service description clear and concise. Remember that your audience may not be as technical as you are in the details of your service.
  • During contract negotiations with external customers or meetings with your internal customers, take the time to describe each service entry. Make sure your customers fully understand each line item. If your customers find a particular service entry to be confusing or unclear, modify the entry and keep modifying it until it is clear.
  • Routine reviews of your service entries and comparing them against changing customer needs are essential to ensure that your services and service levels continue to satisfy customer requirements.
  • Don’t create service level metrics for minimum thresholds (uptime and performance levels, for example) that are outside of your control. If you don’t completely control the environment, don’t guarantee a minimum threshold metric for it. If the service is dependent on other units, ensure that the verbiage of the service level metric description clearly states what you will require from your customer to guarantee the service level. For example, if you are a database unit, you don’t want to miss a minimum service level metric for application availability because of a network problem. Guarantee only what you can control.
  • 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.

    You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

    Comments are closed.