As we discussed in Part 1 of this blog series, many SaaS providers are seizing opportunities to expand their offerings and become a go-to marketplace or network, but their original contract terms and procedures often don’t fit their evolving business models.
As an initial step when updating its standard agreements, a SaaS provider could survey the contractual relationship landscape of its business.
Relationship Structure(s)
Is the provider’s service a marketplace where buyers and sellers engage in transactions under direct terms between them and the SaaS provider is merely facilitating those transactions? If so, are the third-party applications accessed and used on an ongoing basis via the service or does the buyer use them independently? Does the provider evaluate or endorse any of these third-party applications (e.g., a “certified” app)? As we mentioned in Part 1, if the third-party application is used in a highly regulated context (e.g., a digital health app used in patient care), the provider should consider how integration with, or sale, referral, or endorsement of, the application could expose the provider to additional risks and compliance obligations, such as adverse event reporting.
Does the provider’s service also, or instead, offer third-party functionality for a premium (a portion of which might be retained by the provider under a revenue sharing arrangement)? If so, is the provider fully responsible for the relationship and contract with the customer (and the associated support)? The third-party developer may want the SaaS provider to flow certain disclaimers and other terms down to the customer. But, if the service will involve many third-party applications, the developer protections in the provider’s standard terms might need to be handled in a more general way (that applies across, and satisfies, all developers), because it may be impractical to include developer-specific terms for every third-party application, especially if the developer’s own standard terms are inconsistent with the provider’s terms, either in substance or in tone, or if the provider negotiates custom terms with its customers.
Counterparties might not neatly fit into a specific category. A given company might be a customer of the service while at the same time selling or providing applications to other customers. There is a common tendency, especially when a provider’s standard terms change incrementally over time, to try to capture everything in one agreement and use language like “if applicable” when a provision only applies to certain participants or scenarios. But such comprehensive agreements can become convoluted, potentially leading to confusion, mistakes, or disputes. Alternatively, some providers have multiple agreements that are in many ways (e.g., miscellaneous terms) redundant.
Supplemental Terms
A streamlined approach to this complexity is to have base terms that apply to all users, plus additional terms that apply to developers and/or sellers.
However, the SaaS provider should consider whether the base terms (e.g., use rights and restrictions) apply equally to all participants and whether the main agreement needs, at least, some additional flexibility. For example, many SaaS agreements include blanket prohibitions, such as on copying or modifying the service (or any associated code or materials). If those restrictions are overly broad for developers or other participants in particular contexts, the agreement could include language that opens the door for tailored exceptions to the general rules (e.g., “Except as otherwise expressly authorized in this Agreement” or “Except as otherwise set forth in the Developer Terms”). The developer-specific terms could also move in the other direction, however, by including additional use restrictions. For example, if the provider is concerned about exposure to unwanted risks, certain high-risk (e.g., life support) use cases could be prohibited.
Another example is a SaaS provider’s broad rights to change or suspend the service, which is relatively common in SaaS agreements, especially if the service is not critical to the core business operations of the customer base or is relatively easily replaced. Although most customers might be willing to live with the risk of the service being changed or suspended, some developers might be highly dependent on their integration with the service and demand a stronger commitment from the provider.
Further, just as developers may request certain protections (e.g., flowing their terms through to end customers), the provider could try to protect its reputation and limit potential risks by requiring strong warranties from the developers, even if the provider is mostly just facilitating transactions between the developers and end customers.
Time to Reboot?
When new functionality (e.g., a marketplace) is added to a service, it’s natural for a SaaS provider to want a quick, simple update to its standard terms, but a refreshed business model may require a revamped contract.