The Whys, Hows and How Nots of Buyer-Driven Service Level Redesign | Sherpas in Blue Shirts

Understanding the importance of effective service level agreements (SLAs) that are practical and create business value, most buyers design contract SLAs that are generally within provider’s control, are measurable, promote convergence of interests, and usually have a proper baseline. However, many buyers feel a need to reassess and redesign their service levels at some point during their contracts’ lifecycle.

Our interactions with a large and diverse group of buyers and service providers have shown that service level redesign is typically driven by one or more of four key reasons:

  1. Unmet or wrong SLAs: Service providers typically meet their contractual SLAs. When they don’t, it generally implies a flaw in the SLA design that needs to be addressed. For example, buyers may be capturing the wrong metrics. Or, they may have established the wrong targets for the right metrics.
  2. More business value: Buyers believe they are achieving insufficient value from their sourcing engagements, in terms of cost, flexibility, responsiveness, business alignment, etc. They may spend too many people and financial resources on defining service levels, yet fail to see material benefits from the service levels.
  3. Requirements change: Buyers’ business and IT requirements may have changed during the contract period – e.g., a newer baseline, regulations, evolving technologies, delivery models, provider capabilities, etc. – and these must be reflected in newer service levels. On the flip side, incumbent providers or competitors may be offering better engagement terms, payment options, or delivery models than when the contract was originally inked.
  4. Sourcing strategy change: Buyers that earlier outsourced to just one provider may be experimenting with multi-provider sourcing, and the different capabilities, services, and delivery models must be reflected in the SLAs when the services are split among providers.

The core of the SLA redesign process is to understand the mistakes made during contracting and execution. It also requires an effort in visualizing at least three to five years into the future understanding the IT environment that will be sufficient to cater to the business demand. Therefore, this also requires an understanding of evolving business needs.

The process itself consists of four steps, as outlined below:

SLA Redesign Process

This process is relatively easy for buyers that early on missed the basics of good SLA design such as practicality, manageability, collectability, measurability, etc. Understandably, it is harder for buyers that are satisfied with their provider’s performance but want to evolve the relationship to the next level to extract more business value.

Yet, whichever category they fall into, we have time and again seen buyers reducing the number of SLAs, believing it will lead to lesser complexity, simpler governance, and reduced cost. However, doing so may not solve the problem as they may end up removing even the “must have” SLAs.

Additionally, we frequently see buyers incorporating metrics that on the surface appear good but in reality cannot be concretely measured or clearly defined, such as innovation, collaboration, next generation delivery, etc.

SLA redesign is a challenging task that  must take into account not only cost and efficiency, but also the evolving competence of service providers, peer benchmarks, an understanding of the past, knowledge of business priorities, and, above all else, analysis of its necessity.

What have you experienced with SLA redesigns? What were your drivers, challenges, results, and outcomes? Do you have good, bad, or ugly to share with your peers?

Subscribe to our monthly newsletter to get the latest expert insights and research.

How can we engage?

Please let us know how we can help you on your journey.

Contact Us

"*" indicates required fields

Please review our Privacy Notice and check the box below to consent to the use of Personal Data that you provide.
This field is for validation purposes and should be left unchanged.