Service Level Agreements

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 customer’s expectations if we don’t have a firm understanding of what they are.

We also know that each organization, group and individual user has their own unique set of value drivers they we’ll use to evaluate the quality of service being provided to them.

It is the responsibility of the service provider to manage their customer’s 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.  Your customers probably won’t be aware of your current workload and resulting work request lead times until you tell them.

I am a firm believer that every IT unit should meet with their internal and/or external customer base that they support to establish a set of measurable Service Level Agreements.  You don’t have to be a third-party services provider to take advantage of the benefits that a well-defined set of SLAs provides.   I have created a standard SLA document for each company I have been involved with, whether I was an internal employee, consultant or third-party service provider.

Our SLA document at Remote DBA Experts is fairly simple.   It contains Service Categories and individual services.   The SLA entry is clear and concise.   Each entry contains a description of the service, when we will provide the service (upon request, ongoing, reoccurring frequency) and the amount of time the customer can expect the service activity to be completed by.

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 by, 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, 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 Remote DBA Experts, 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.  The remaining service groupings are fairly obvious.
  • Monitoring – Robust monitoring is a key benefit that we provide to our customers here at Remote DBA Experts.  Our SLAs state what we monitor, how often we monitor a particular resource or event, and how quickly we will respond (15 minutes in our case) if a threshold is exceeded or a monitored event occurs.
  • Problem Resolution Activities - One of our SLAs is “Provide expert diagnostic analysis for all database 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 within 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 has optimal performance.
  • Change Management – Our largest category contains all of the changes we can be asked to make to a customer’s database and/or schema.
  • 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 customer’s databases are available when they need them.
  • 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.  We don’t want our customers to enter a ticket to clone their 14 tier Oracle E-Business Environment by the next morning.  Since we service multiple customers here at Remote DBA Experts, 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, Fail Safe, O/S, Data Guard and vendor provided high availability installation services are contained in this category.
  • Customer Management – This category contains all of the activities that relate to informing the customer of our activities.  Entries include meeting frequency, monthly reports, time reports, Root Cause Corrective Action discussions when problems occur and how quickly we will respond to a customer request for additional information.   If it is a communication activity or mechanism with the customer – its in there.

Helpful 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 isn’t as technical as you are.
• 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 minimum 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 you must, ensure that the verbiage of the service level metric description clearly states that your organization will only be held responsible for those activities that they do control.  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 Remote DBA Experts, we review all of our SLAs on a regular basis.  We also perform in-depth analysis 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.   If we find that we are weak in some areas, we take steps to correct the deficiency and quickly move on.

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 customer’s expectations if they (and you) don’t have a firm understanding of what they are.

Thanks for Reading,

Chris Foot
Oracle Ace
Director Of Service Delivery