Best Efforts, Commercially Reasonable Efforts, and Good Faith Efforts: How They Differ and How to Use Them Effectively

“Best efforts,” “commercially reasonable efforts,” and “good faith efforts” are three of the most common performance standards used in contracts. For example, Party A may agree to use best efforts to market Party B’s products; Party B may agree to use commercially reasonable efforts to complete a task; or both parties may agree to use good faith efforts to discuss additional business opportunities. Unlike objective performance measures, these three performance standards are highly subjective. What are “best” efforts? What is considered “commercially reasonable?” How do you define “good faith?” Many view these subjective performance standards to be three different levels of performance on a spectrum (good/better/best). However, this perception differs from the reality in the courts where definitions of these standards can differ significantly from jurisdiction to jurisdiction.

Parties find these subjective performance standards convenient where they can’t or do not want to be too specific or objective as to the level of performance required. Contract negotiations can get bogged down when one party insists on a subjective performance standard to which the other party is opposed. Where parties can’t fully agree, a slightly vague subjective standard can be used to “bridge the gap” and let the parties finalize contract terms. However, that’s just papering over a failure to achieve a true “meeting of the minds” on the terms of the agreement. A later disagreement in how to define and apply a subjective performance standard can lead to a foundering of the business relationship, a contract dispute, allegations of breach, and/or litigation or arbitration. Understanding the differences between these subjective performance standards, and knowing when and how to best use them, is therefore critical.

In this article I’ll talk through the commonly perceived differences between these three key subjective performance standards, and cover things to look out for when using these terms. I’ll also discuss why it is important to consider on a case-by-case basis whether including a specific definition for a subjective performance standard or using an objective performance measure may be a better approach.

Defining “best efforts,” “commercially reasonable efforts,” and “good faith efforts”

There is not a lot of case law, or consistency in case law, from which to draw definitions. In other words, there are no universally accepted definitions for these subjective performance standards. Here is how I differentiate them:

Things to consider and watch for when using these standards

Isn’t a “good faith efforts” standard already implied? US contract law has long provided that the performance of every contract is subject to an implied duty of good faith and fair dealing. Given this, every performance obligation in an agreement requires good faith efforts, unless a higher standard for a particular obligation is expressly stated in that agreement. Since good faith efforts is the default, is there any reason to expressly include good faith efforts in an agreement? Yes. A non-breaching party to a contract will want the ability to assert the strongest claims possible. Instead of having to rely on breach of an implied duty as the basis for a claim, a party may prefer to be able to claim a breach of the express terms of the contract as well. If “good faith efforts” are expressly stated, a party may have multiple causes of action in the event of a failure to meet those efforts. Also, as noted above, some courts have held that an express good faith efforts requirement should be interpreted as a higher performance standard.

Consider whether it makes sense to try to add boundaries to a “best efforts” obligation. If your company is on the performing side of a “best efforts” obligation that the other party will not agree to remove, one way to address the uncertainty and subjectiveness of the performance obligation is to “box it” with additional language that puts some boundaries around the obligation and defines which stones must be left unturned. For example, if XYZ asks for language stating “ABC will use best efforts to market XYZ’s product,” consider seeking a revision to “ABC will use best efforts to market XYZ’s product, provided such efforts will not require ABC to incur costs or expenses not expressly contemplated herein which in ABC’s reasonable judgment may negatively impact its business operations and operating results.” This revised language makes clear that in performing to the “best efforts” standard, ABC is not required to incur costs and expenses that could negatively impact it. ABC could also consider whether to add a lower standard to a “best efforts” clause, such as “reasonable best efforts” or “good faith best efforts,” which could lead to a court interpreting the language as a lower standard than best efforts and which ABC can argue more realistically characterizes the efforts to be expended in compliance with that performance obligation.

Avoid using qualifiers which can enhance, or muddy, a subjective performance standard. Consider avoiding adding qualifiers such as “all,” “every,” or “diligent” to a subjective standard e.g., “diligent good faith efforts,” “all commercially reasonable efforts,” or “commercially reasonable efforts to [do x] as soon as feasible.”  Qualifiers can add another layer of subjective complexity, and/or create a more onerous obligation than may have been intended. For example, if “commercially reasonable efforts” by definition does not require a party to leave no stone unturned and does not require continuous performance, requiring “all” or “diligent” commercially reasonable efforts may effectively convert it to a “best efforts” standard.

Subjective performance obligations may not play nicely with revenue recognition rules. Subjective performance standards like “best efforts,” “commercially reasonable efforts,” and “good faith efforts” may mean different minimum levels of effort to different parties. In order to evaluate performance under a contractual obligation, the parties must be able to (1) define the specific obligation to be performed, and (2) objectively measure whether that performance obligation has been satisfied. This is a core tenet of the new revenue recognition rules under ASC 606, which requires a contract to be broken into separate performance obligations so that revenue recognition occurs on a per-performance obligation basis when that performance obligation has been satisfied. Determining when a subjective performance obligation has been satisfied for ASC 606 purposes can be problematic as the parties may not agree when the obligation has been satisfied. It is advisable to try to use objective criteria, and not subjective performance standards, for performance obligations tied to revenue recognition.

Consider whether including a definition or an objective measure would work better

Parties should try to avoid ambiguity in contracts, and seek to use quantifiable and measurable obligations where possible. Using subjective performance standards such as “best efforts,” “commercially reasonable efforts,” and “good faith efforts” is often an easy way to agree on a performance obligation without being too specific on what level of effort is required to achieve it. There are times when using a minimum subjective standard instead of an objective one is a tactical approach in negotiation, such as where your company wants to be able to make an argument that its performance was sufficient without the need to demonstrate satisfaction of an objective measure.

> Consider using definitions. If you do use a subjective performance standard in an agreement, consider whether to include a definition of that standard in the agreement. By defining a standard such as “commercially reasonable efforts,” the parties are fencing in what is considered satisfactory performance of that standard, making it less subjective and easier to gauge performance if a dispute arises as to whether a party has satisfied the associated performance obligation.

> Consider whether an objective measure would work better. In a number of cases, an objective measure such as a maximum time period, a minimum required spend, a minimum number of generated leads or orders, or a minimum service level may make it easier for both parties to determine whether a party has minimally satisfied a performance obligation. Ask the other party what they would consider an acceptable result from the required efforts, and consider making that the contractual measure of minimum acceptable performance. For example, instead of saying that “ABC will use commercially reasonable efforts to generate sales leads during each term of the Agreement,” if the parties agree that 10 leads per year is the minimum acceptable performance, say “ABC will generate a minimum of ten (10) sales leads during each term of the Agreement.” If all ABC generates is 10 leads in a given year and the other party was hoping for more, the other party can choose to exercise its termination rights and find another partner.

Search your contracts and templates for subjective performance standards, and see if any can be replaced with objective measures – it could mean the difference in measuring satisfaction of performance obligations and avoiding costly contract disputes over subjective performance terms.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He is a corporate generalist who 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.

Aggregate Data Clauses – Accept or Push Back?

Before reflexively rejecting a vendor/provider’s aggregate data clause, determine whether pushing back is really necessary.

More than ever before, data is the driver of business. Companies are inundated with new data on a daily basis, which creates a number of business challenges. One of the more prominent challenges of late has been how best to protect data within a company’s infrastructure from inadvertent and improper access and disclosure. Another important challenge is how best to “mine” data sets through data analytics, the quantitative and qualitative techniques businesses use to analyze data in order to develop business insights, conclusions, strategies, and market trend data in order to provide guidance on operational and strategic business decisions. “Aggregate data” is key to data analytics; companies take existing data, anonymize it by removing any personal or other information that can be used to identify the source of the data, and aggregate it with other anonymized data to create a new set of data on which data analytics can be performed.

The strength of the conclusions and insights learned through data analytics is directly proportional to the amount of source data used. Aggregate data comes from two primary sources: (1) internal data sets within the company’s possession or control, such as transactional data, customer data, server data, etc.; and (2) external data sets such as free online databases of government data (e.g., US Census data) and data available from data brokers who have compiled aggregate data sets for purchase and use by businesses.

To ensure businesses have the right to use customer data in their possession for data analytics purposes, SaaS, cloud, software, and other technology agreements often contain an aggregate data clause. This clause gives a vendor/provider the right to compile, collect, and use aggregate data from customer information for the vendor/provider’s own business purposes. Many vendors/providers work hard to craft an aggregate data clause that fairly and adequately protects their data sources. Before reflexively rejecting a vendor/provider’s aggregate data clause, consider the analysis and questions in this article to determine whether pushing back is really necessary to protect your company’s interests.

The vendor/provider’s perspective

Customers often push back on aggregate data clauses for a variety of reasons, such as “it’s our policy not to give this right,” “why should you benefit from our data?” and “how can you guarantee someone won’t be able to figure out it’s us?” On the other side, a vendor or provider may argue that the aggregate data clause is a “table stakes” provision in their agreement. Under this argument, analytical data is used to generate macro-level insights which benefit both the vendor/provider and its customers, and as long as it is used in a way that does not identify a specific customer or client there is no potential harm to the customer in allowing its use for data analytics. Additionally, many vendors argue that the systems used to anonymize and aggregate data do not allow for exceptions on a per-customer basis. Additionally, vendors/providers often share insights and other conclusions drawn from data analytics with their customers and clients, e.g., through client alerts, newsletters, conferences, etc., and therefore clients benefit from allowing their data to be used in the vendor/provider’s data analytics efforts. Data analytics are often a critical part of a vendor/provider’s business plans and operations, and access to client data for analytics purposes is baked into the cost of using the service.

Is the aggregate data clause well-drafted and balanced?

Many vendors/providers take the time to craft an aggregate data clause that is fair and does not overreach. As long as the vendor/provider has protected the customer’s rights and interests in the underlying customer data, the use of a customer’s data for analytics purposes may be perfectly acceptable as a part of the overall contractual bargain between the parties. A well-drafted clause usually contains the following core provisions:

  • Grant of rights – A right for the vendor/provider to compile, collect, copy, modify, publish and use anonymous and aggregate data generated from or based on customer’s data and/or customer’s use of its services, for analytical and other business purposes. This is the heart of the clause. This clause gives the vendor/provider the right to combine aggregate data from multiple internal and external data sources (other customers, public data, etc.).
  • Protection of source data – A commitment that the customer will not be identified as the source of the aggregate data. While this is really restating that the data will be “anonymous,” some customers may want a more express commitment that the aggregate data can’t be traced back to them. I’ll talk more about this later in this article.
  • Scope of usage right – Language making clear either that the vendor/provider will own the aggregate data it generates (giving it the right to use it beyond the end of the customer agreement), or that its aggregate data rights take precedence over obligations with respect to the return or destruction of customer data. The common vendor/provider reason for this is that aggregate data, which cannot be used to identify the customer, is separate and distinct from customer data which remains the property (and usually the Confidential Information) of the customer under the customer agreement. Additionally, the vendor/provider often has no way to later identify and remove the aggregate data given that it has been anonymized.

Things to watch for

When reviewing an aggregate data clause, keep the following in mind:

Protection of the company’s identity. While language ensuring that a customer is not identified as the source of aggregate data works for many customers, it may not be sufficient for all. Saying a customer is not identified as the source of aggregate data (i.e., the vendor/provider will not disclose its data sources) is not the same as saying that the customer is not identifiable as the source. Consider a customer with significant market share in a given industry, or which is one of the largest customers of a vendor/provider. While the vendor/provider may not disclose its data sources (so the customer is not identified), third parties may still be able to deduce the source of the data if one company’s data forms the majority of the data set. Customers that are significant market players, or which are/may be one of a vendor’s larger clients, may want to ensure the aggregate data clause ensures the customer is not identified or identifiable as the source of the data, which puts the onus on the vendor/provider to ensure the customer’s identity is neither disclosed nor able to be deduced.

Ownership of aggregate data vs. underlying data. As long as the customer is comfortable that aggregate data generated from customer data or system usage cannot be used to identify or re-identify the customer, a customer may not have an issue with a vendor/provider treating aggregate data as separate and distinct from the customer’s data. Vendors/providers view their aggregate data set as their proprietary information and key to their data analytics efforts. However, a well-drafted aggregate data clause should not give the vendor/provider any rights to the underlying data other than to use it to generate aggregate data and data analytics.

Scope of aggregate data usage rights. There are two ways customer data can be used for analytics purposes – (1) to generate anonymized, aggregate data which is then used for data analytics purposes; or (2) to run data analytics on customer data, aggregate the results with analytics on other customer data, and ensure the resulting insights and conclusions are anonymized. Customers may be more comfortable with (1) than (2), but as long as the vendor/provider is complying with its confidentiality and security obligations under the vendor/provider agreement both data analytics approaches may be acceptable. With respect to (2), customers may want to ask whether the vendor/provider uses a third party for data analytics purposes, and if so determine whether they want to ensure the third-party provider is contractually obligated to maintain the confidentiality and security of customer data and if the vendor/provider will accept responsibility for any failure by the third party to maintain such confidentiality and security.

Use of Aggregate Data. Some customers may be uncomfortable with the idea that their data may be used indirectly through data analytics to provide a benefit to their competitors. It’s important to remember that data analytics is at a base level a community-based approach – if the whole community (e.g., all customers) allows its data be used for analytics, the insights and conclusions drawn will benefit the entire community. If this is a concern, talk to your vendor/provider about it to see how they plan to use information learned through analytics on aggregate data.

Duration of aggregate data clause usage rights. Almost every vendor/provider agreement requires that the rights to use and process customer data ends when the agreement terminates or expires. However, vendors/providers want their rights to use aggregate data to survive the termination or expiration of the agreement. A customer’s instinct may be to push back on the duration of aggregate data usage rights, arguing that the right to use aggregate data generated from the customer data should be coterminous with the customer agreement. However, if the data has truly been anonymized and aggregated, there is likely no way for a vendor/provider to reverse engineer which aggregate data came from which customer’s data. This is why many vendors/providers cannot agree to language requiring them to cease using aggregate data generated from a customer’s source data at the end of the customer relationship. One approach customers can consider is to ask vendors/providers when they consider aggregate data to be “stale” and at what point they cease using aged aggregate data, and whether they can agree to state that contractually.

Positioning an objection to the aggregate data clause. As noted earlier, the right to use data for analytics purposes is considered to be a cost of using a vendor/provider’s software or service and a “table stakes” provision for the vendor/provider, and the ability to use data for analytics purposes is already baked into the cost of the software or service. Some customers may feel this is not sufficient consideration for the right to use their data for analytics purposes. If that is the case, customers may want to consider whether to leverage an objection to the aggregate data clause as a “red herring” to obtain other concessions in the agreement (e.g., a price discount, a “give” on another contract term, or an additional service or add-on provided at no additional charge).

The GDPR view on use of aggregate data

The European Union’s new General Data Protection Regulation (GDPR), which becomes effective on May 25, 2018, makes a significant change to the ability to use personal data of EU data subjects for analytics purposes. Under the GDPR, a blanket consent for data processing purposes is no longer permitted – consent to use data must be specific and unambiguous. Unfortunately, this directly conflicts with data analytics, as the ways a data set will be analyzed may not be fully known at the time consent is obtained, and there is no right to “grandfather in” existing aggregate data sets. Simply saying the data will be used for analytics purposes is not specific enough.

Fortunately, the GDPR provides a mechanism for the continued use of aggregate data for analytics purposes without the need to obtain prior data subject consent – Pseudonymization and Data Protection by Default. Pseudonymization and data protection principles should be applied at the earliest possible point following acquisition of the data, and vendors/providers must affirmatively take data protection steps to make use of personal data

  • Pseudonymization – Pseudonymization is a method to separate data from the ability to link that data to an individual. This is a step beyond standard tokenization using static, or persistent, identifiers which can be used to re-link the data with the data source.
  • Data Protection by Default – This is a very stringent implementation of the “privacy by design” concept. Data protection should be enabled by default (e.g., an option in an app to share data with a third party should default to off).


Data analytics is an important part of every company’s “big data” strategy.  Well-crafted aggregate data clauses give vendors and providers the ability to leverage as much data as possible for analytics purposes while protecting their customers.  While there are reasons to push back on aggregate data clauses, they should not result in a negotiation impasse. Work with your vendors and providers to come up with language that works for both parties.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He is a corporate generalist who 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.

Use the Right Intellectual Property Contract Terms To Protect Against IP Risk

In most technology and service agreements, one or both parties use or license the other party’s intellectual property (IP), or one party uses or licenses its own intellectual property for the other party’s benefit. However, using or benefiting from another party’s IP carries certain risks, including the risk of an infringement claim, ownership or licensing disputes, open source software, and risks arising from a bankruptcy of the IP owner/licensor.  Where managing the risks from that IP usage is important, having the right contract clauses in place to shift and mitigate this risk can be critical.

There are a number of contract clauses that can be employed to manage and shift IP risk. Two contract clauses in particular – the IP representation/warranty and the IP indemnity – may seem complimentary but can expose a party to unintended liability if used together.

IP Representation/Warranty and IP Indemnity

There are two clauses which can shift the risk of intellectual property infringement – an express representation/warranty of non-infringement and an indemnity against non-infringement. (I will not cover implied warranties of non-infringement under the Uniform Commercial Code, which are very frequently disclaimed in technology and service agreements.)

A representation/warranty of non-infringement is a statement of fact (rep) or statement or promise of condition (warranty) that intellectual property licensed and/or used does not infringe the intellectual property or other proprietary rights of third parties. An IP rep/warranty may be knowledge-qualified, i.e., “to the best of [owner/licensor’s] knowledge.” An IP rep/warranty allows the IP owner/licensor to stand behind its intellectual property, and allows the IP user/licensee to assert an “innocent infringer” defense to certain IP claims. However, like other reps and warranties, there are potentially meaningful consequences if they are breached. Like other breaches of representations, a breach could give rise to a right to void the contract and rescission damages.  Like other warranties, a breach can give rise to contract remedies, a right to withhold or cease performance under the agreement, and/or a right to terminate the agreement for cause.  The user/licensee is required to prove damages resulting from a breach of an IP representation or warranty.

An intellectual property indemnification is an obligation to defend, indemnify, and hold harmless the other party from and against losses, damages, and expenses arising or resulting from a third-party IP infringement claim. (Most service providers avoid first-party IP indemnity clauses, as they are effectively an insurance clause.)  This can be a standalone IP indemnity clause, or an indemnification obligation for breaches of reps/warranties where the agreement contains an IP rep/warranty. As it’s very difficult for an IP user/licensee to determine or mitigate the risk of infringement itself, the IP indemnity allocates this risk to the owner/licensor (subject to the limitation of liability) without the need for the user/licensee to prove damages or other losses. Watch the geographic scope of the indemnity to ensure it matches where the IP will be used – if it’s limited to US patents/trademarks, for example, a user/licensee would not be protected from a claim that their use violates an EU patent. IP indemnification clauses usually include procedures for tendering a claim for defense and language governing who controls the defense, assistance provided by the indemnified party, and settlement of an indemnified claim. A major benefit of an IP indemnity is that the indemnified party does not have to incur or prove damages resulting from an IP infringement claim first; as long as an indemnified claim is brought against the indemnified party, the indemnification obligations apply. As long as the indemnifying party complies with its defense and indemnification obligations, the indemnified party does not have a right to terminate the agreement.

Service providers will often put contours around the scope of the intellectual property indemnity by including limitations to the obligation to indemnify based on certain acts or omissions of the indemnified party. These include where the user/licensee uses IP outside the scope of the license or terms; where the user/licensee modifies the IP other than as authorized by the IP owner/licensor; where the infringement claim results from the combination of the IP with other products or technology not provided by the IP owner/licensor; and where the user/licensee fails to accept or use an updated version of a product or service provided by the IP owner/licensor which has been modified to be non-infringing. Some parties also exclude IP protection where the claim results from open-source software used in their products or systems. One thing to watch for is whether the exclusions are comparative (claims are excluded “to the extent” that an exception applies) or absolute (if any of the exceptions applies, indemnification is not provided).

Savvy service providers and IP licensors understand that including both of these clauses into an agreement can have unintended consequences, such as the potential for remedy “double-dipping.” If a contract contains both an IP indemnity and IP warranty protecting Party B, and a third-party IP claim is asserted against Party B, Party B may be able to both assert a breach of rep/warranty claim and seek damages for breach of the warranty or seek to terminate the agreement for cause, while also tendering the third party claim to Party A for defense and indemnification. Because of this, many licensors and vendors will offer an IP indemnity, but not an IP warranty. However, this eliminates the ability for the user/licensee to rely on the rep/warranty as an innocent infringer. If both the rep/warranty and indemnity are used, one approach to harmonizing them is to add language to the IP warranty stating that the sole and exclusive remedy for breach of the IP warranty is indemnification pursuant to the IP indemnity. This gives the user/licensee the “innocent infringer” benefits of the IP warranty protection as well as the IP indemnity protection, while ensuring that a breach of the IP warranty does not result in a claim outside of indemnification obligations.

Other Intellectual Property Risk Protections

In addition to IP reps/warranties and IP indemnities, there are other contractual protections which can be used to protect against IP risk.

Indemnification Remedy Clause

Where infringement occurs, the IP user/licensee often wants more than just to be protected — they want the right to keep using the IP for the duration of the agreement. In the event of actual infringement, neither an IP rep/warranty nor IP indemnity forces the IP owner/licensor to remedy the infringement. This is why many agreements include an additional IP infringement remedy clause which generally commits an IP owner/licensor facing a claim or judgment of IP infringement to obtain the right to continue to use the impacted IP, to modify the IP so that it is non-infringing, or to replace the impacted IP with a non-infringing alternative. In some cases, if none of the remedies are feasible, one or both parties may be given the right to terminate the agreement; where a termination right exists, users/licensees should consider whether to ask for a prorated refund of license/usage fees for the remaining terminated period of the agreement. Watch for language on the timing of the remedy – in most cases, it’s when the indemnifying party is found to be infringing by a court of competent jurisdiction (and not when the claim is first asserted), which generally does not impact the user/licensee as the defense and indemnification obligations should apply prior to that point.

Allocation of risk (limitation of liability) Cause

While an IP indemnity and rep/warranty shifts risk to the IP owner/licensor, the amount of risk shifted is allocated between the parties through the limitation of liability clause. Is the indemnifying party willing to provide uncapped liability for its IP indemnification obligations? Some service providers have not priced unlimited liability into its fees, or is unwilling to provide uncapped liability as a policy or due to insurance limitations. The user/licensee usually wants to negotiate the broadest liability cap possible; one common compromise is to negotiate a “super-cap” for IP indemnification obligations above the base limitation on direct damages but short of uncapped.

It’s important to also look at the disclaimer of consequential damages. An indemnified claim can include consequential damages as part of the third-party claim (e.g., lost profits).  If the disclaimer of consequential damages does not specifically exclude indemnification obligations, any such damages claimed by a third party may not be indemnifiable which may not be what one or both parties want.  It’s important to note that there is a significant difference between third-party consequential damages awarded in connection with an indemnified claim, and first-party consequential damages related to an indemnified claim (e.g., the indemnifying party should not have to pay for a company’s lost profits due to an executive having to travel and participate in a deposition in connection with an indemnified claim). An exclusion to the disclaimer of consequential damages for third party damages awarded in connection with, or included in the settlement of, an indemnified claim may provide a finer point on the exclusion.

IP Ownership Clause

Another contract provision which can be leveraged to mitigate IP risk is the IP ownership clause, which addresses ownership of each party’s pre-existing IP as well as any new IP created in connection with the agreement. This clause is ideally located up front in a base agreement between the parties, but sometimes will be placed in a Statement of Work (“SOW”) or other ancillary document instead (order of precedence language in the base agreement can be critically important in that case). Ensure that each party retains ownership of its own IP (except to the extent ownership is transferred to the other party), and that each party is prohibited (to the extent permitted by law) from reverse engineering, disassembling, de-compiling, creating derivative works from, renting, selling, leasing, acting as a service bureau regarding, or otherwise attempting to learn the source code of the other party’s IP. If neither company will acquire ownership rights to the other’s IP (even IP created in connection with the agreement), make sure the ownership clause clearly covers this.  If one company will transfer ownership of developed IP (a “deliverable”) to the other, ensure the agreement clearly defines the deliverable and states that the deliverable is considered “works made for hire” as defined in the US Copyright Act, and consider adding language regarding transfer and assignment of the IP rights in and to the deliverables (which may be tied to payment for the deliverable). If a deliverable contains the developer’s pre-existing IP, consider asking for a perpetual, irrevocable, worldwide right and license to sue the pre-existing IP as part of the deliverable (this may cause the IP indemnity to survive in perpetuity).

IP Insurance Clause

Another way to mitigate and shift the risk arising from IP is through intellectual property insurance. IP insurance can be obtained through specialized policies such as a cyber liability policy and media liability policy. Coverage for IP infringement claims may not be available under comprehensive general liability (CGL) coverage – check your policy or walk through coverage with your insurance broker to ensure you understand what your IP insurance policies (or typical policies) cover and don’t cover. Users/licensees may want to ask the IP owner/licensor about IP insurance they carry, and request that the owner/licensor be obligated to maintain their insurance and protect the user/licensee under the policy, e.g., by tying the contractual limitation of liability to the policy coverage.

Open source software Clause

In many cases, companies use open source software (“OSS”) in their IP. There are a number of good reasons companies do this, including lower costs, better quality, and a large support community. As IP owners/licensors did not create the OSS they use, many will disclaim OSS from IP representations, warranties, and indemnities. However, there are risks to OSS usage. For example, under some OSS license types, software which uses OSS governed by one of those licenses becomes governed by that same license, which can include requirements to disclose the source code upon request or other limitations. Users/licensees may want to consider including an OSS representation/warranty that any IP or other deliverables provided to it will not contain open source software which has not been disclosed in the agreement or a SOW.

Rights in Bankruptcy (§ 365(n)) Clause

Licensees under software license agreements have a special tool for mitigating risk arising from a bankruptcy of the software licensor. When a company enters bankruptcy, the licensee (or debtor-in-possession) has certain rights to “affirm” or “reject” the debtor’s executory contracts, including some license agreements. 11 U.S.C § 365(n) gives licensees certain rights to continue to use licensed software in the event of the bankruptcy of the software licensor. To ensure these protections are available, consider including a clause in the agreement protecting the licensee’s rights under this section.

Software Escrow Clause

Finally, consider whether to include a contractual requirement for the owner/licensor to escrow licensed software.  For more on software escrow, please see my earlier post on software escrow.

An earlier version of this post first appeared as an article on my blog, Notes from the Trenches.

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, compliance and practical risk management, and is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice.

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

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)

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.