Close this search box.

Using SLAs to Effectively Manage Vendor Performance


Eric Liebross

Senior Managing Director of Business Transformation, Auxis

Related Topics

According to Deloitte’s annual “Global Outsourcing and Insourcing Survey,” the biggest concern of companies considering outsourcing is their ability to effectively manage supplier performance.

The survey also highlighted the two biggest concerns of current customers of outsourcing services: reactive (vs. proactive) management and poor service quality. Interestingly, attrition and cost, two commonly cited concerns of companies considering outsourcing, were not as much of a focus of the current customer base. The data speaks to a lack of collaborative, partnering relationships between customers and service providers.

Service Level Agreements (or “SLAs”) are one way to help manage supplier performance, but as the industry has matured, the SLA has evolved from a quantitative measurement vehicle to one that also focuses on addressing and resolving issues rather than just penalizing for them.

The Deloitte survey reported that the preferred approach to resolving supplier performance issues is to “manage the relationship”—meaning  to work with the vendor to identify the root causes of issues, which may not be limited to the provider alone—as well as to provide more governance and training designed to improve performance.

In some cases, restructuring service levels or contract terms are methods employed to address and improve performance. In most cases, respondents of the Deloitte survey indicated that they would continue to outsource functions rather than bring them in-house, even if they were forced to terminate the existing supplier relationship.

Examining the SLA

I thought it would be helpful to examine the Service Level Agreement, the document that establishes the relationship between the service provider and its customers, and that defines what “supplier performance” really looks like. And, like in most things, “one size does not fit all.”
Let’s start by understanding the terminology used in the agreement:

“Service Definition” means documenting the details of the service being provided. This should be an itemized list (we often call it a “Service Catalog”) that documents the key activities and responsibilities within a function, and should define the operational “hand-offs,” the steps in a function where actions and control shift from one party to another. The Service Definition requires detailed analysis and documentation upfront, and should be reviewed, validated and agreed upon by both parties.

The “Quality of Service” is the agreed upon, minimally accepted, performance criteria. It can be quantitative, such as the number of transactions processed in a given time period (e.g., the number of invoices per month), or qualitative, such as transactional accuracy or timeliness—and often involves both elements.

Another key element of the SLA is the availability of the service, which highlights the time when services are to be provided, and the ability to adapt to service demand cycles (such as 24×7 coverage or peak volumes during seasons). Another metric utilized is availability/“uptime” of key systems.

Other key requirements of the SLA can include business continuity/disaster recovery strategies, compliance requirements (such as SOX controls or PCI), reporting and review processes and  timing, as well as issue escalation and review processes.

Providing Structure

The SLA provides a structure that defines the performance, timing and expected outcomes of the services that are being provided. As previously discussed, one of the expected outcomes is almost always going to be cost savings, but it should not be the only goal. Trying to work “on the cheap” often results in sub-par performance over time, and an effective SLA lays out a structure that supports both cost savings and performance effectiveness that is manageable for both the customer and the service provider. The old adage that “you get what you pay for” holds true here.

Regardless of the structure, there will be issues, you can count on that. The SLA should also provide a structure for dealing with them. A well written SLA also establishes a platform for cost and performance improvements over time. And, when issues do arise, the SLA provides the methodology to address them: the rules of engagement, and communication and escalation protocols.

So how should the SLA deal with performance issues? What works better, the carrot or the stick? The natural reaction of most customers is to have a penalty-based SLA, providing financial penalties for suppliers who fail to achieve performance objectives.

But what is the definition of a performance failure? To avoid such penalties, the service provider is going to try to set standards that are easy for it to meet. Is this approach in the best interest of the customer? And what is the true impact of a performance failure? It’s one thing to late-pay an invoice, and quite another to provide poor customer service that results in lost business.

A Collaborative Process

The industry has moved from punitive agreements to one that are “rehabilitative.” The process of identifying issues early, establishing their root causes and working to address them has become more of the norm. Working together to fix a problem, rather than blaming each other, has proven to be a much more effective process within the outsourcing model. Remember, not all problems are only the supplier’s doing. An effective SLA should establish a foundation of honesty and collaboration, not one of blame.

Written by

Senior Managing Director of Business Transformation, Auxis
Eric brings more than 30 years of experience and a proven track record of success helping CFOs modernize and achieve peak performance in their back office to become more scalable, innovative and strategic oriented. He joined Auxis in 2002 and serves as Senior Managing Director, overseeing all Finance Transformation, Process Automation and Business Process Outsourcing services at Auxis. His areas of expertise include financial operations performance, shared services strategy, organizational and operating model design, process automation (e.g. RPA), and systems integration.