The emergence of cloud computing and big data, fostered by improved computing and storage resources capacity, has helped to remove traditional constraints on scale and profitability. While these potential impacts are further enhanced, the growth of software companies’ use of AI in their offerings has a more equivocal impact on scale and profitability, that should not be overlooked. We explore below the potential obstacles that could arise and which should be addressed.
The focus of our article is on companies that are using AI (including machine learning – ML -; we refer to both when we speak of “AI”) as the dominant component of their offerings – albeit not at a too early development phase. Note that such companies often deploy their model in a sort of subscription-based SaaS framework. For more clarity, we propose a semantic distinction between AI-powered models – AIaaS – and more traditional standard SaaS models
I. A definition of profitability measurement in AIaas
Though EBITDA tends to be a widespread aggregate of profitability for most business models, in a SaaS context and for the purposes of our analysis, we will refer to gross Margin (GM), which is a more relevant indicator for assessing the issues related to scalability. GM can be defined as revenue minus COGS (“costs of goods sold”), namely direct variable (or semi-variable) costs.
In a “standard” SaaS model, COGS principally encompasses (i) cloud infrastructure costs, (ii) customer success and (iii) professional services, with GM typically standing around 70-80% of revenue (and even more).
For AIaaS, the main categories of COGS are basically the same, but beyond cloud computing costs, a company need to purchase specific data to feed its models. Also, customer success management (CSM) and professional services functions may be expanded, and more generally, part of the costs of R&D employees can be considered as direct personnel costs.
II. Cloud computing and data procurement
In the case of AIaaS, cloud computing operations tend to be more complex, with a higher volume of data, which is often less structured or unstructured, particularly heavy to store and/or more difficult to process. As a result, both storage and processing costs are typically higher.
Meanwhile, training data is not usually a one-time charge (in the latter cases, to be recorded as R&D charges), and retraining it can often be considered as an ongoing cost (to be included in GM) (the concept of “data drift” reflects this underlying tendency of many AI models, which require constant training over time or else their performance will be crippled). This is all the more conspicuous when a company’s core value added depends on its capacity to provide updated information to its clients. To illustrate, let’s take the example of a FinTech company that provides its clients (investors) comprehensive information regarding sentiments, emotions, and rumours surrounding a specific investment or targeted company. In such a case, clients require fresh news so they can act quickly and appropriately.
Following this logic, the purchase of specific data – through a data licence subscription to access specific databases, for instance – will be similarly addressed with a classification in COGS when such a purchase needs to be made on a recurring basis, and in R&D when it may only be made for a certain period of time within the AI-driven service lauch phase.
Still, to mitigate these effects on AIaaS profitability, it appears likely that storage and computation execution capabilities will improve over time, and the associated costs will decrease. However, whether the scale and rapidity of these effects will be sufficient to bring AIaaS profitability patterns close enough to the more “traditional” SaaS model remains to be seen.
III. AI and irreducible human intervention
Data set training for AI models is still far from being a fully automated process. Human intervention is often inevitable to manually clean and label data sets. Following on from the data drift phenomenon previously mentioned, dedicated employees are expected to remain continuously mobilised, even beyond the usual “maintenance” (bug fixing, etc.).
Beyond these structural requirements, some AI-based services may require humans to be mobilised in “real-time”. This is particularly the case for (i) social media moderation with human reviewers (some Facebook employees recently admitted – in Nov.21 – that it is inherently difficulty for their Group to cope with the issue of content moderation, despite having AI tools backed by an apparently insufficient human workforce) and (ii) autonomous vehicle systems with remote human monitoring.
Finally, if the models are too complex – not sufficiently narrowly defined -, “edge cases” may result in a multiplication of human interventions, particularly at each client onboarding, but also later on.
IV. Addressing the scaling and profitability of AI-based models
Providing a range of typical GM rates in AI-dominated SaaS models can prove to be a relatively inaccurate exercise. The contribution of AI to business models can vary dramatically, and many companies are still in their AI ramp-up phase. Sometimes ratios of 50-60% are highlighted, but we also observe companies with much lower ratios. Whatever the impact, whether positive, neutral or negative, these companies at times have no choice but to integrate AI technology, if only to survive.
In their excellent article “The new business of AI”, Martin Casado and Matt Bornstein (Partners at VC firm Andreesen Horowitz) point out that AI companies appear to combine characteristics of SaaS (say “pure” SaaS) and Services business models. Though apparently structurally less profitable than traditional SaaS models, they recommend adopting a strategy that combines the best of both models, specifically (i) eliminating model complexity by favoring single models over unique models per client, (ii) narrowing problem domains to minimise persistent edge cases, (iii) conservatively confronting the economic reality of higher variable costs than initially expected and (iv) planning for change in the tech stack as better tools emerge for automated model training and standardisation of developers’ workflows.