Unless you have been living under a rock or the ocean, we're witnessing one of the toughest economic periods in recent history. In the context of start-up fundraising, the great liquidity flow of the last 3 years has slowed down considerably; funds are renegotiating sky-high valuations, start-ups are conserving cash and limiting burn by restructuring operations and business models, and both start-ups and investors are moving towards greater unit-economic-based growth.
Against this backdrop, the importance of business models has taken centre stage. One model (more of a product or service delivery model) is the XaaS (anything as a service) model, which is primarily (defined rather simplistically for this post) characterised by remote access of tools/software/services through cloud services (as opposed to on-site deployment).
Some key (non-technical) attributes that help solidify the importance of XaaS entities, especially during slowdowns and recessions, are:
- Regular cash flow
- Ability to serve multiple users without significant incremental capital investment
- Scalability
- Possibility of remote work (to offset costs)
To avoid trapping myself in technical quicksand, I'll pivot to the purpose of this article.
What are some key attributes of a well-crafted XaaS agreement?
The trigger for this post was a general discussion with some very talented entrepreneurs who were struggling with identifying common traps in publicly available (read Google) drafts of XaaS documents, as the drafts were neither robust enough nor did they protect the XaaS provider ("Provider") from some common issues. I reviewed some of the available drafts and realised that some concerns could be addressed to better allocate the risks of product/service delivery. While commenting on each clause would turn this post into a tome, I decided to make this post concise and actionable.
I'll attempt to provide a list of key aspects that Providers may consider in their drafts. By no means are these terms comprehensive or exhaustive; they represent only some key (in my limited experience) elements of a strong XaaS agreement. As always, it is strongly recommended that you consider professional advice that identifies your specific business and legal requirements.
In most instances, the following terms cause the greatest misalignment:
- Terms of Use: The language that grants a right to the user to utilise the XaaS must be carefully drafted as a limited-purpose and-use licence instead of as a broad-purposed, unrestricted license. The difference in language between the two is not easily distinguishable but is vital to prevent misuse. A limited licence limits adverse claims from clients seeking to "game" the language. A limited usage right also limits a client’s control over any intellectual property associated with the service, regulates any follow-on use of the XaaS by third parties of the client, and clarifies the method by which any third-party use (if permitted) can be regulated.
- Operational efficiencies/Service Level: Providers would be wise to negotiate service levels that are realistically achievable. At times, most Providers suggest lofty (and at times, unrealistic) expectations to land the client. However, some fail to realise the ramifications of growth and neglect to account for it. Two ways of addressing this issue include a regular revision of the service levels (say on a yearly or half-yearly basis) or forecasting growth and accounting for it (and the consequent impact of achieving service levels) at the time of finalising the service level. In the same breath, Providers should focus on excluding force majeure events (acts that are so remote as to be excused from any breach of compliance) and regular downtime activities from service level breaches. While this may sound trivial and commonplace, you will be surprised by how many contracts include loophole-filled boilerplate clauses that act to the Provider’s detriment.
- Scope for customization and costs (whether fixed or otherwise): Large clients have been known to request Providers for tweaks and entity-level customisation. Capturing the extent and impact of such changes to the standard product is essential to avoid falling into the trap in which minor edits requested a few times by the client become a regular feature and add to the cost of operations without a consequent increase in revenue.
- Risk Mitigation (warranties, covenants, indemnities, guarantees): The sooner people realise the value of these clauses, the better businesses will be able to protect themselves and efficiently allocate and mitigate risks. No, these are not boilerplate terms, and Providers should be cautious while drafting and reviewing each of these terms. The consequences of non-compliance with obligations are severe for the client, and therefore, some clients negotiate aggressive indemnity provisions against the Providers. Providers should attempt to negotiate balanced and mutually applicable indemnity provisions, along with limits to the scope and extent of any indemnity (minimum thresholds, overall caps on liability, exclusion of liability clauses, etc.).
Business-specific alterations
A major issue with using templates is that one fails to consider industry or company-specific requirements. Ideally, Providers may consider altering certain operation-specific provisions to account for:
- Nature of business
- Transaction specifics (deal size, duration)
- Extent of utilisation of the Provider's cloud servers (for storage or processing purposes)
- Performance metric deviations or service levels that may arise as a result of the client's specific industry or nature of business
- Frequency of changes/updates to maintain or enhance the Provider's offering or to comply with regulatory guidelines.
- Use of third-party subcontractors to fulfil certain conditions of the agreement and necessary protections if subcontractors are proposed to be used.
Some XaaS agreements have peculiar requirements that must be incorporated specifically into the agreements. These include:
- Ownership of rights: At times, the Providers utilise existing third-party IP (licensed, of course) to create the XaaS product that is then licenced to the client. In such a scenario, Providers must disclose the right to utilise such IP and incorporate any licencing conditions (such as no reverse engineering or modification, etc.) in the XaaS agreement.
- Data Protection: If the transaction necessitates data sharing, Providers must be careful to consider the implications of jurisdiction-specific data protection laws, such as the EU GDPR, since these laws require obligations, compliance, and standard clauses for clients from such jurisdictions. These may also require that the Provider implement and adopt data security standards that comply with local data protection regulations. However, this clause should not be heavy-handed to restrict the Provider from utilising anonymized non-identifiable data for specific business use and improving performance. Such 'Permissible resultant data uses' are crucial for Providers to adapt and create more robust offerings. Thus, one needs to draft such clauses to balance legitimate regulatory requirements with commercial benefits for Providers.
- Non-solicitation: The clause that is often drafted but not often thought through in most commercial agreements plays an important role in XaaS agreements, especially for Providers. strong non-solicit clauses reduce the risks of the client poaching the Provider's employees.
Conclusion: It is understandable why start-ups avoid seeking expensive professional advice and assistance for their business early on; costs and cash-out go on non-revenue generating avenues, suggesting an inefficient use of scarce capital. However, this analysis is myopic as it fails to consider potential cost savings in the long run. Decide your course of action depending on your assessment of potential risks and the long-term impact of those risks on your business.
Disclaimer: Nothing in this post constitutes legal advice. All posts are my personal views. Please feel free to reach out to your attorney or legal advisor for specific issues.
