As more and more SaaS providers, in digital health, fintech, and other industries, look for ways to integrate with and offer third-party applications (in their quest for powerful network effects), they eventually reach a point where the reality contemplated by their original standard terms and the world (or metaverse) of their now-envisioned business model diverge.
In the early days of a SaaS provider, it might embark with one main service (or application), and its standard terms might take a simple, hardline approach that the provider is responsible for its own service and nothing else. For example, the provider’s terms might state that the provider has no responsibility whatsoever for any third-party services, applications, content, or other materials integrated with or available via its service. In fact, some providers use broad language to disclaim responsibility for third-party materials, even if those materials are a component or feature of the provider’s service.
To complicate matters further, such broad disclaimer language might be tucked away in various corners of the agreement. In addition to the main warranty disclaimer, the limitation of liability provision might specifically shield the provider from liability for third-party conduct or materials, and the force majeure provision might excuse the provider for any non-performance or delay resulting from third-party conduct or materials. Furthermore, going beyond merely limiting or disclaiming the provider’s own responsibility, the provider’s standard terms might impose indemnification or other obligations on the customer with respect to third-party materials, especially those that are chosen or authorized by the customer.
So what’s the issue?
What happens when third-party integrations become a significant, and attractive, feature of the service? What if a seamless integration is part of the value the service provides? What if the provider is pounding the pavement promoting the third-party application, as integrated with or available through the service? What if the provider receives payment, from the customer or the third-party developer, when the customer subscribes to or uses the third-party developer’s application? Who is responsible for maintenance and support of the third-party application, or its integration with the main service, and how is that maintenance and support coordinated with the customer?
How would the provider explain everything, both operationally and contractually, to an inquisitive or skeptical customer? Eventually, the provider’s desire for airtight, simple terms likely yields to the customer’s expectation that a valuable third-party application, or its interoperability with the service, is part and parcel.
So what’s the strategy?
When updating its standard agreement, the provider could distinguish between different types of third-party materials. For example, a core feature of the service that is white labeled by the SaaS provider but maintained by a third party is significantly different from a third-party-branded, off-the-shelf application that is sold by the third party to the customer (through or in connection with the service) pursuant to a direct contract between the third party and the customer.
The standard agreement could also be modified to clarify the provider’s responsibilities related to third-party applications. If, under the provider’s business model, it is responsible for accurate and continuous integrations for data harmonization across applications or for providing first-level customer support, then the agreement could clarify that no other provisions relating to third-party materials negate those responsibilities. However, the provider will want to carefully consider potential exposure to additional risks, such as regulatory regimes, associated with particular third-party technology, products, and services for which the provider would, in some respects, be responsible.
Ideally, the terms of the contract would align with reality, including the various parties’ relevant expectations, contributions, compensation, and control, along with the provider’s messaging about the service (including in relation to third-party applications).
In part 2 of this post, we will discuss the contracting process among the various parties and some other ways to morph a traditional SaaS agreement into a SaaS-enabled marketplace agreement.
[View source.]
