Tag Archives: Suppliers

The What, Why and How of SLAs, aka Service Level Agreements (part 2)

Posted on by
Reply

Every company uses technology vendors, such as Software-as-a-Service providers, to provide critical components of their business operations. One pervasive issue in technology vendor agreements is the vendor’s commitment to the levels of service the customer will receive.  A representation to use commercially reasonable efforts to correct product defects or nonconformity with product documentation may not be sufficient for a customer relying on a technology vendor’s service for a mission-critical portion of its business. In this situation, the vendor may offer (and/or a customer may require) a contractual commitment as to the vendor’s levels of service and performance, typically called a “Service Level Agreement” or “SLA.” Service Level Agreements (SLAs) ensure there is a meeting of the minds between a vendor and its customer on the minimum service levels to be provided by that vendor.

In Part 1 of this post, I walked through uptime and issue resolution SLAs.  In this second part, I cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Other Types of Commitments in SLAs

Other common types of SLAs in technology agreements include latency SLAs and customer service SLAs.

Latency SLAs. “Latency” is the time it takes for a server to receive a server request, process it, and send a response. For example, when you load a webpage, a server request is sent to a web server to deliver the webpage, the server processes the request, and sends a response with the code to render the page in the user’s web browser. Latency can be affected by a number of factors, including the geographic location of servers, network/Internet capacity, and server optimization. For companies using a vendor to provide services as part of its client-facing systems (e.g., an address verification service), minimizing latency to ensure a high level of performance is critical. A latency SLA is a commitment to a maximum roundtrip response time for a vendor server request. Latency SLAs typically exclude the time it takes to get from the customer’s server to the boundary of the vendor’s network, and vice versa (as this is outside of the vendor’s control).

Customer Service SLAs. In some vendor relationships, ensuring the prompt provision of customer support is a critical component of the relationship. For example, if a vendor is providing support to a customer’s clients or employees, or is providing level 2 escalation support, customer support SLA commitments may be important to the customer to ensure a high level of service.  Customer support commitments often include commitments on time to first response (the time from the submission of a request to the time an agent opens the support ticket to begin working on it); time to resolution (total time needed to resolve the issue); average speed to answer (the percent of calls answered within a maximum time, e.g., 85% of calls within 30 minutes, or percent of emails answered within a maximum time, e.g., 90% of emails within 4 business hours); and/or abandonment rate (the maximum number of calls being abandoned in queue before a support agent picks up the call).

SLA Remedies

In order to ensure the service level commitments made by a vendor have teeth, the SLA should have remedies available to the customer in the event of a failure to meet one or more SLA commitments. The remedies are often the most heavily negotiated section of the SLA. There are a variety of remedies that can be applied in the event of a SLA failure.

Service Credits. One of the more common forms of remedy is a service credit, often a percentage of fees paid by the customer for the period in which the SLA failure occurred.  For example, if a vendor fails to meet a 99.9% monthly SLA, a service credit equal to a percentage of the monthly fees paid by the customer would be applied to the next monthly invoice.  A credit is often provided on a tiered basis, up to 100% of the fees for the relevant period based on the size of the SLA miss. Vendors may want to include language ensuring that if multiple credits are available for the same reporting period (e.g., a credit for failure to meet the uptime SLA as well as the issue resolution SLA), only the greater credit will apply.  The credit is usually applied to the next invoice, or if there will be no additional invoice, paid directly to the customer.  For a service credit related to an uptime SLA commitment, instead of a percentage of fees some vendors will offer a credit equal to the fees earned by the vendor during the period of time during which the Service was unavailable during the previous measurement period (or an average of the amount during previous measurement periods), under the theory that the credit is an accurate reflection of the actual fees that would have been earned by the vendor had the service been available in compliance with the SLA.  Customers should carefully consider what fees are used to calculate the credit – customers will want this to be as inclusive as possible.

Termination. In the event of a SLA failure, another remedy commonly offered by vendors is a right to terminate. Vendors typically put restrictions around the exercise of this right, e.g., termination is the sole and exclusive remedy available; termination is limited to the service subject to the SLA failure, not the entire service agreement; it is offered on a “use it or lose it” right which can only be exercised for a period of time following the measurement period in which the SLA failure giving rise to the termination right arose; or the right to terminate is only triggered by multiple failures, such as failure to meet its SLA commitments in three (3) consecutive months or any two (2) out of three (3) consecutive calendar quarters. Customers should carefully consider whether the limits on these rights are appropriate (e.g., ensure that “sole and exclusive remedy” applies only to a SLA failure, and would not preclude the customer enforcing its rights and remedies for any other breaches of the vendor agreement; ensure a right to terminate extends to the entire service agreement if the affected service component is a significant portion of the value of the relationship to the customer; etc.)

Other creative remedies. Vendors and customers should consider whether other creative remedies for a breach of the SLA, such as waiver of fee minimums, waiver or imposition of other contractual obligations, or provision of additional services (e.g., a certain number of free hours of professional services), may be an appropriate remedy for the customer and an appropriate motivator for the vendor to meet its SLA commitments.

Closing Thoughts – Things to Watch For

  • Remember that most vendors are trying to provide as close to 100% uptime as possible, and the best possible service they can to their clients. A SLA is intended to be a floor on performance, not a ceiling.
  • Some vendors do not include a SLA in their standard service agreement, instead letting customers ask for one. In my experience, less customers will ask for a SLA than you’d think.  It’s always a good idea to ask a vendor to ensure they include their SLA with the service agreement at the outset of the contract negotiation process.
  • If the vendor will not agree to include a SLA, ask them why.
    • In some cases, vendors will not provide a SLA with credits to all but their largest clients, relying on the fact that as a multi-tenant platform all clients receive the benefit of the SLAs provided to their largest clients. In this event, customers should consider whether to fight for a direct SLA or rely on their commitments to larger clients (which commitments may change over time).
    • If you can’t get a SLA from a vendor, customers should consider whether to push for a termination for convenience right (and refund of prepaid but unaccrued fees) in the event they are dissatisfied with the service levels they are receiving from the vendor.
    • Customers should also ask whether the service is truly a mission-critical service. If not, it may be worth considering how hard to fight for the SLA, or if the customer can offer to concede the SLA to win on another open negotiation point of greater importance.
  • Customers should watch for language in the vendor agreement that gives the vendor the right to unilaterally change terms of the agreement, instead of having changes mutually agreed upon. This unilateral right is often broad enough to allow a vendor to change the terms of the SLA as well. If so, customers may seek to limit the scope to exclude the SLA, or ensure that the agreement includes a termination right as described above.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

The What, Why and How of SLAs, aka Service Level Agreements (part 1)

Posted on by
Reply

Every company uses technology vendors, such as Software-as-a-Service providers, to provide critical components of their business operations. One pervasive issue in technology vendor agreements is the vendor’s commitment to the levels of service the customer will receive.  A representation to use commercially reasonable efforts to correct product defects or nonconformity with product documentation may not be sufficient for a customer relying on a technology vendor’s service for a mission-critical portion of its business. In this situation, the vendor may offer (and/or a customer may require) a contractual commitment as to the vendor’s levels of service and performance, typically called a “Service Level Agreement” or “SLA.” Service Level Agreements (SLAs) ensure there is a meeting of the minds between a vendor and its customer on the minimum service levels to be provided by that vendor.

At a high level, a SLA does three things:

  1. Describes the types of minimum commitments the vendor will make with respect to levels of service provided by the vendor;
  2. Describes the metrics by which the service level commitments will be measured; and
  3. Describes the rights and remedies available to the customer if the vendor fails to meet their commitments.

In many cases, a SLA is presented as an exhibit or appendix to the vendor agreement (and not a separate agreement). In others, a SLA may be presented as a separate document available on a vendor’s website.  Think of the former as a customer-level SLA which is stated directly in (and quite often negotiated on a customer-by-customer basis as part of) the service agreement with that customer, and the latter as a service-level SLA which the vendor wants to apply equally to every user of its service.

In this two-part post, I’ll explain the contents of, reasons for, and important tips and tricks around technology SLAs.  Part 1 will cover uptime and issue resolution SLAs.  Part 2 will cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Common types of commitments in SLAs

The most common types of commitments found in technology SLAs are the uptime commitment and the issue resolution commitment.

Uptime SLA Commitment

An uptime commitment is generally provided in connection with online services, databases, and other systems or platforms (a “Service”). A technology vendor will commit to a minimum percentage of Service availability during specified measurement periods.  This percentage is typically made up of nines – e.g., 99% (“two nines”), 99.9% (“three nines”), 99.99% (“four nines”), 99.999% (“five nines”), etc.  Some SLAs will use “.5” instead of “.9”, for example, 99.5% or 99.95%”.   Uptime is typically calculated as follows:

(total minutes in the measurement period - minutes of Downtime in that period) / Total minutes in the measurement period

Definitions are key. The right definitions can make all the difference in the effectiveness of an uptime SLA commitment. Vendors may gravitate towards a narrower definition of “Downtime” (also called “Unavailability” in some SLAs) to ensure they are able to meet their uptime commitment, e.g., by excluding a slowdown that makes the Service hard (but not impossible) to use. Customers should look carefully at this definition to ensure it covers any situation in which they cannot receive substantially all of the value of the Service. For example, consider the difference between Unavailability/Downtime as a period of time during which the Service fails to respond or resolve, versus a period of time during which a material (or non-material) function of the service is unavailable. The SLA should define when the period of Unavailability/Downtime starts and ends, e.g., starting when the vendor first learns of the issue, and ending when the Service is substantially restored or a workaround is in place; customers should look at this carefully to ensure it can be objectively measured.

Mind the measurement period. Some vendors prefer a longer (e.g., quarterly) measurement period, as a longer measurement period reduces the chance a downtime event will cause a vendor to miss its uptime commitment. Customers generally want the period to be shorter, e.g., monthly.

Consider whether the uptime percentage makes sense in real numbers. Take the time to actually calculate how much downtime is allowed under the SLA – you may be surprised. For a month with 30 days:

  • 99% uptime = 432 minutes (7 hours, 12 minutes) of downtime that month
  • 99.5% uptime = 216 minutes (3 hours, 36 minutes) of downtime that month
  • 99.9% uptime = 43.2 minutes of downtime that month
  • 99.99% uptime = 4.32 minutes of downtime that month

One critical question customers should ask is whether a Service is mission-critical to its business.  If it’s not, a lower minimum uptime percentage may be acceptable for that service.

Some vendors may offer a lower uptime commitment outside of business hours, e.g., 99.9% from 6am to 10pm weekdays, and 99% all other times. Again, as long as this works for a customer’s business (e.g., the customer is not as concerned with downtime off-hours), this may be fine, but it can make it harder to calculate.

Ensure the Unavailability/Downtime exclusions are appropriate. Uptime SLAs generally exclude certain events from downtime even though the Service may not be available as a result of those events. These typically include unavailability due to a force majeure event or an event beyond the vendor’s reasonable control; unavailability due to the equipment, software, network or infrastructure of the customer or their end users; and scheduled maintenance.  Vendors will often seek to exclude a de minimis period of Unavailability/Downtime (e.g., less than 5/10/15 minutes), which is often tied to the internal monitoring tool used by the vendor to watch for Service unavailability/downtime. If a vendor wouldn’t know if a 4-minute outage between service pings even occurred, it would argue that the outage should not count towards the uptime commitment.

Customers should make sure there are appropriate limits to these exclusions (e.g., force majeure events are excluded provided the vendor has taken commercially reasonable steps to mitigate the effects of such events consistent with industry best practices; scheduled maintenance is excluded provided a reasonable amount of advance written notice is provided.  Customers should watch out for overbroad SLAs that try to exclude maintenance generally (including emergency maintenance).  Customers may also want to ensure uptime SLAs include a commitment to take reasonable industry-standard precautions to minimize the risk of downtime (e.g., use of no less than industry standard anti-virus and anti-malware software, firewalls, and backup power generation facilities; use of redundant infrastructure providers; etc.)

Don’t overlook SLA achievement reporting. One important thing customers should look for in a SLA is how the vendor reports on SLA achievement metrics, which can be critical to know when a remedy for a SLA failure may be available. Vendors may place the burden on the customer to provide notice of a suspected uptime SLA failure within a specified amount of time following the end of the measurement period, in which case the vendor will review uptime for that period and verify whether the failure occurred. However, without proactive metrics reporting, a customer may only have a suspicion of a SLA failure, not actual facts. Customers using a mission-critical system may want to consider asking for proactive reporting of SLA achievement within a certain amount of time following each calendar month.

Issue Resolution SLA Commitment

Of equal importance to an uptime commitment is ensuring that a Service issue (downtime or otherwise) will be resolved as quickly as possible.  Many technology SLAs include a service level commitment for resolution of Service issues, including the levels/classifications of issues that may occur, a commitment on acknowledging the issue, and a commitment on resolving the issue.  The intent of both parties should be to agree on a commitment gives customers assurances that the vendor is exerting reasonable and appropriate efforts to resolve Service issues.

Severity Levels. Issue resolution SLAs typically include from 3-5 “severity levels” of issues.  Consider the following issues:

Impact Example Classification
Critical The Service is Unavailable
High An issue causing one or more critical functions to be Unavailable or disrupting the Service, or an issue which is materially impacting performance or availability
Medium An issue causing some impact to the Service, but not materially impacting performance or availability
Low An issue causing minimal impact to the Service
Enhancement The Service is not designed to perform a desired function

Issue resolution SLAs typically use some combination of these to group issues into “severity levels.”  Some group critical and high impact issues into Severity Level 1; some do not include a severity level for enhancements, instead allowing them to be covered by a separate change order procedure (including it in the SLA may be the vendor’s way of referencing a change order procedure for enhancements). Vendors may include language giving them the right to reclassify an issue into a lower severity level with less stringent timeframes. Customers should consider ensuring whether they should have the ability to object to (and block) a reclassification if they disagree that the issue should be reclassified.

Acknowledgment Commitment. Issue resolution SLAs typically include a commitment to acknowledge the issue. As with the uptime SLA, the definition of the acknowledgment timeframe is important (when it starts and when it ends). A vendor will typically define this as the period from the time it is first notified of or becomes aware of the issue to the time the initial communication acknowledging the issue is provided to the customer.  Customers should look at the method of communication (e.g., a post to the vendor’s support page, tweet through their support Twitter account, an email, a phone call from the customer’s account representative required, etc.) and determine if a mass communication method versus a personal communication method is important.

For critical and high impact issues, vendors (especially those operating multi-tenant environments) will often not offer a specific acknowledgment commitment, instead offering something like “as soon as possible depending on the circumstances.”  The argument for this is that for a critical or high impact issue, a vendor wants all available internal resources triaging and working the problem, not reaching out to customers to tell them there is a problem. In many cases, this may be sufficient for a customer provided there is some general acknowledgment provided to a support page, support Twitter account, etc. to alert customers that there is an issue. In others, a customer may want to push for their account representative, or a vendor representative not involved in triaging the problem such as an account executive, to acknowledge the issue within a fixed amount of time, putting the burden on the vendor to ensure it has appropriate internal communication processes in place.

Resolution Commitment. Issue resolution SLAs also typically include a time commitment to resolve the issue. One important thing to focus on here is what “resolve” means.  Vendors may define it as the implementation of a permanent fix or a workaround that temporarily resolves the problem pending the permanent fix; in some cases, vendors may also define it as the commencement of a project to implement a fix.  Customers should ensure that a vendor promptly implement a permanent fix if a workaround is put in place, and that failure to do so is a failure under the SLA. Many vendors are reluctant to provide a firm issue resolution timeframe, as the time required to resolve or implement a workaround is dependent on the issue itself, and are often unwilling to negotiate the resolution commitment or commit to a fixed timeframe for resolution.  Customers should ensure the resolution commitment is reasonable and that the vendor is doing everything it can to correct issues.  For example, for critical and high impact issues, consider an issue resolution commitment of “as soon as possible using continuous diligent efforts” – as long as the vendor is working diligently and continuously to fix the issue, they’re in compliance with the SLA. For lower impact issues, consider a commitment to implement a fix or workaround in the ordinary course of business.

In part 2, I’ll cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

Practical Tips for Managing Risks in Vendor, Supplier, and other Partner/Provider Relationships

Posted on by
Reply

The best place to stop a snowball from rolling the wrong way is the top of the hill.

When it comes to managing risk in business, there are two fundamental principles:

  1. You can’t disarm all of the land mines. A risk is like a land mine – it will detonate sooner or later once the right factors occur. Part of risk management is having enough information to know (or make an educated guess) at which risk “land mines” are more likely to go off than others, so you can stack rank and disarm the land mines in the right order. That way, hopefully you’ll disarm each one in time, and if one does goes off before you can disarm it it will cause minimal damage.
  2. You don’t have to stop every factor from occurring; you have to stop at least one factor from occurring. If a risk “land mine” detonates, a number of things all went wrong at the same time. Think of it as the lock on Pandora’s Box – for the lock to open (the land mine going off), the pins in the cylinder (the environmental factors) must align perfectly with the key (the catalyst). As long as one of the pins are misaligned, the lock won’t open. If you don’t have the resources or ability to ensure all pins are misaligned, try to ensure at least one pin is misaligned so the land mine can’t go off. (If more than one is misaligned, that’s even better.)

To manage a risk, a business must first mitigate and shift the risk to reduce the chance of the land mine detonating to the greatest extent possible, and then accept or rejectthe residual risk to the business. (For more on this, please see my earlier LinkedIn article on Revisiting Risk Management).

When it comes to your relationships with your key vendors, suppliers and other partners/providers, risk management principles should be applied to both existing partners/providers, prospective partners/providers, and “inherited” partners/providers (e.g., through acquisition). There are a number of ways to mitigate and shift risk in these relationships:

Mitigating the Risks

  • Do due diligence on your partners and providers. Perform research to see if the partner/provider has had security or privacy problems in the past. If they are public, look at the risk factors in their securities filings. Look at the partner/provider’s privacy policy to see if they make any claims they likely cannot live up to, or are overly broad in what they can do with your company’s data. Watch out for unrealistic marketing statements regarding privacy, security or their ability to perform the obligations you are contracting for. Use RFPs to gather information on prospective partners/providers up front (and keep it in case you need to refer to it later on if something they told in you in RFP proves not to be true).
  • Don’t automatically disqualify companies that have had past problems. If an RFP reveals that a partner/provider has had a past issue, focus on what steps they have taken to remediate the issue and protect against a recurrence. The result may be that they have a more robust security and risk management program than their peers.
  • Ask them what they do. Consider adding privacy and security questions to your RFP to gather information on current practices and past problems/remediation efforts (and to make them put it in writing). Watch out for answers that are too generic or just point you to their privacy policy.
  • Set online alerts, such as Google Alerts, to stay up-to-date on the news relating to your prospective or current partner/provider during the course of your negotiations and relationship, and escalate any alerts appropriately. If the partner/provider is public, set an alert for any spikes (up or down) in stock price.
  • Plan for the inevitable. Inevitably, your business relationship will end at some point. It could end when you’re ready for and expecting it, but you can’t count on that. If your partner/provider is mission-critical, develop an “expected” and “unexpected” transition plan and confirm that the partner/provider can locate and provide you the data you need to execute on that plan. For example, ensure you have all information and data you may need if the partner/provider ceases operations (for example, routinely download reports and data sets from their portal, or set up an automated feed). Alternatively, consider ways to ensure that if a partner/provider creates and stores mission-critical information (e.g., order or personal information, critical reports or data, etc.), it’s mirrored securely to a location in your control on a regular basis so that if there’s a problem, you have a secure and current data set to work from. This may be required or important under your company’s business continuity plan, and your contractual commitments to your clients.
  • Know your alternatives. Keep abreast of alternative partners/providers, do initial vetting from a security perspective, and maintain relationships with them. If a problem occurs, the company may have to switch partners/providers quickly. If you have taken the time to cultivate a “rainy day” relationship, that partner/provider may be happy to go out of their way to help you onboard quickly should a problem with your existing partner/provider occur (in the hopes that your company may reward their help with a long-term relationship).
  • Know what you have to do to avoid a problem. Once negotiated, contracts often go in the drawer, and the parties just “go about their business.” Make sure you know what your and your partner/provider’s contractual obligations are, and follow them. If they have “outs” under the contract, ensure you know what you need to do in order to ensure they cannot exercise them. If terms of use or an Acceptable Use Policy (AUP) or other partner/provider policies apply, make sure the right groups at your company are familiar with your obligations, and ensure they are being checked regularly in case they are updated or changed. If possible, minimize the number of “outs” during the negotiation. For existing or inherited partners/providers, consider preparing a list of the provisions you want to try to remove from their agreements so you can try to address them when the opportunity arises in the future (e.g., in connection with a renewal negotiation).
  • Put contractual provisions in place. Sales and Procurement should partner with IT and Legal to ensure that the right risk mitigation provisions are included in partner/provider agreements on an as-needed basis. Consider adding a standard privacy and security addendum to your agreements, whether on their paper or yours. Common provisions to consider include a security safeguards requirement; obligation to protect your network credentials in their possession; obligation to provide security awareness training (including anti-phishing) to their employees (consider asking for the right to test their employees with manufactured phishing emails, or getting an obligation that they will do so); requiring partners/providers to maintain industry standard certifications such as ISO 27001 certification, PCI certification, SOC 2 Type 2 obligations, etc.; obligation to encrypt sensitive personal information in their possession; obligations to carry insurance covering certain types of risks (ensure your company is named as an additional insured, and try to obtain a waiver of the right of subrogation); rights to perform penetration testing (or an obligation for them to do so); a obligation to comply with all applicable laws, rules and regulations); an obligation to complete an information security questionnaire and participate in an audit; language addressing what happens in the event of a security breach; and termination rights in the event the partner is not living up to their obligations. Not all of these provisions make sense for every partner/provider. Another approach to consider is to add appropriate provisions to a supplier/vendor code of conduct incorporated by reference into your partner/provider agreements (ensure conflicts are resolved in favor of the code of conduct).

Shifting the Risks

  • Use contractual indemnities. An indemnity is a contractual risk-shifting term through which one party agrees to bear the costs and expenses arising from, resulting from or related to certain claims or losses suffered by another party. Consider whether to include in your partner/provider agreement an indemnity obligation for breaches of representations/warranties/covenants, breach of material obligations, breach of confidentiality/security, etc. Consider whether to ask for a first party indemnity (essentially insurance, much harder to get) vs. a third party indemnity (insulation from third party lawsuits). Remember that an indemnity is only as good as the company standing behind it. Also, pay close attention to the limitation of liability and disclaimer of warranties/damages clauses in the agreement to ensure they are broad enough for your company.
  • Request a Parental Guaranty. If the contracting party isn’t fully capitalized, or is the subsidiary of a larger “deep pocketed” organization, consider requesting a performance and payment/indemnification guaranty to ensure you can pursue the parent if the subsidiary you are contracting with fails to comply with its contractual obligations.
  • Acquire insurance. Finally, consider whether your existing or other available insurance coverage would protect you against certain risks arising from your partner/provider relationships. Review the biggest risks faced by your company (including risks impacting your partner/provider agreements) on a regular basis to determine if changes to your insurance coverage profile are warranted; your coverage should evolve as your business evolves. Understand what exclusions apply to your insurance, and consider asking your broker walk you through your coverage on an annual basis.