Software-as-a-Service-as-a-Service (SaaSaaS)

Most people are familiar with the concept of consuming various products as a service today. You pay a monthly fee for Netflix instead of purchasing movies. And you subscribe to Office365 instead of buying the latest software suite. It is no secret that a noticeable shift towards "as-a-Service" models happened in the last couple of years. However, there are more than a few challenges to master the transition from an existing business model into a service. Some of these challenges are directly rooted in internal processes. Other challenges might present themselves in the logistics of the overall value chain - going from producer to distributor, vendor and ultimately the customer. While it may sound ridiculous at first, what if the whole Software-as-a-Service (SaaS) model itself could be offered "as-a-Service"? While the acronym of Software-as-a-Service-as-a-Service (SaaSaaS) might be a mouthful, the notion of providing SaaS-as-a-Service is not too far-fetched if we start taking a closer look.

Products as Services appear to emerge as the most economical choice in the context of information technology and with good reason. This view does not come without a certain amount of hesitation. As human beings, we do follow the urge to "own" something and to have something tangible to hold in our hands.

While that position is relatable, it is not very economical in a world where the mean-time-between-changes are much faster since the advent of the information age. "Owning something" very quickly turns into replacing it with something newer, better, more efficient. While we may be very familiar with the concept of leasing a car, this trend becomes even more apparent in sectors with rapid technological evolutions, like mobile phones, software, or network infrastructure. How often do you upgrade your phone for a better model? Apple and Samsung would like to see you do it every 24 months or even faster. Do you feel that you got enough value out of the product during that time related to the fixed price paid? Instead, how about spending a monthly fee that amounts to the exact total cost, maybe a bit less even, and receive the latest model in exchange for your old phone during your subscription? What would such a model mean for the recycling of old devices and the development of newer features?

While scary at first, there are some tangible benefits to using products as a service.

Why, then, does not everyone immediately shift to an "as-a-Service" model in their business?

The answer to this question is a mélange of different considerations:

How your products are acquired:

• Can you scale inputs based on your customer demand, or do you have to act as a buffer to connect to an old distribution model?
• Are you financing products upfront for a fixed amount of time?
• What happens when something changes? How quickly can you adjust?

How you model your business:

• Do you sell your products as-is, or do you bundle/enrich them with other services?
• Is your calculation on a deal-by-deal base, or do you prefer recurring and predictable cash-flows?

What your customer wants:

• How far ahead do they plan their investments?
• What are the update cycles for the deployed technology?
• Do they prefer CAPEX or OPEX-oriented payment models?

Most or maybe even none of these points are entirely new, however, let me try to add another mindset to this discussion. My personal background has been less focused on business models and more on the production side of the aisle, leading me to a slightly different perspective on the impact of subscription services.

The most critical issue is that the update cadence and how development does not happen in a vacuum. In other words, the update cycle of a product also includes feedback into the production process itself.

Imagine that you create this new, fantastic piece of spreadsheet software called "OverRow" and sell it to customers. Let's ignore complications with licenses and right-to-use agreements and think about this in a simplified manner. You are selling OverRow, and whoever buys it can own it forever. Since you are a nice person, you include free updates to fix bugs and maybe offer some slight enhancements along the way.

Soon you will find out that either:

1. The market is saturated, and there are not enough people to buy your software to sustain your development efforts.
2. Some improvements require so many resources that they almost justify putting out a new product.

So, at what point do you stop developing OverRow version 1.x and shift to version 2.0 or even release an entirely new product called YonderColumn? You can also turn this around and ask: "What feature do I hold back for the next release that entices customers to buy it?"

Now imagine this in a SaaS model.

The steady income stream takes any timing consideration out of the equation and is, economically speaking, a better way to price the product (in this example, OverRow). Instead of being locked in for a fixed period, customers are now able to iteratively inform you about the value of your product in a much smaller timeframe. If subscription numbers decline, changes might be required to satisfy the demand again. Such an approach gives you better metrics in judging how well your product is performing. Typical key metrics still cover how much a customer is spending or not, but drastically reduce the size of the sampling window. A subscription model lets you observe customer choices more iteratively on a month-by-month basis as opposed to a fixed payment model where multiple years might pass until a contract runs out.

So far, I have only spoken of SaaS itself, but let's take the extra step discussing SaaS as a service, or as I previously called it, Software-as-a-Service-as-a-Service (SaaSaaS).

If you are an intermediary business partner with the desire to offer a service, ideally, you would want to have subscription-based services available on the input side. This immediately enables flexible, scalable business models without forcing the partner to shoulder the stocking and distribution burdens.

But this might still not be enough.

Especially when you consider smaller partners typically have difficulties starting out and could use some way to bootstrap the process. Partners will transform the existing way of doing business. Along the way, they must assess the entire value creation chain for their potential of fitting into a service structure through all areas of engagement. The competitive advantages of suppliers can be measured by how "service-able" their business operates. Partners must be flexible at every step, from buying input products or services over to creating their own added value composition up to the actual bundle offerings purchased by customers. In contrast, it is no longer as easy as just procuring products, adding a small margin, maybe even a bit of service engagement, and then saying “see you in 5 years”. The concept of services needs to permeate every step from start to finish. You don't want to end up being the video rental store that has to buy and hoard movies to offer their temporary use as a service. Services don’t just happen on the customer side.

To stay with the movie analogy, an intermediary partner would probably prefer to subscribe to a service like Netflix and sell them on a per-movie basis. Even better, an intermediary partner can offer a combined package that provides an enhanced experience in a theatre setting with popcorn and comfortable seating to stay with the “added value” experience.

Furthermore, new challenges and opportunities present themselves. In the old world, a customer might purchase your product and never interact with you again. Today, customer communication is an option to gain valuable insights, and possibly even a differentiating factor in retaining customer loyalty.

There are more mundane challenges as well. When offering both software and a hardware product together, questions arise about "who owns what." We are seeing demand for very flexible models where any of these scenarios may apply, sometimes as multiple options from the same partner:

1. The partner buys the hardware and software upfront and offers them together as a managed service to customers.
2. The partner buys the hardware and software upfront and offers them together as a subscription service to customers. However, the customer wants to manage the configuration themselves.
3. The customer buys the hardware upfront and subscribes to the partner for software access and network management.
4. The customer buys the hardware upfront and subscribes to the partner for software access, but the customer wants to manage the configuration themselves.
5. The partner subscribes to a pre-established service, billed for a specific timeframe dependent on the number of licenses the partner or the customer uses on their behalf.

These options are certainly not complete and should merely hint at the plethora of options that customers might prefer. None of which tackle the question of billing processes on either side of the equation. And just as critical are the operational concerns about security and data privacy. All these complexities show that rigid processes in acquisition and distribution can smother any transition to a SaaS model right from the get-go.

The future will most certainly show that we need a baseline foundation for any service-based offering to shift from perpetual licenses to subscriptions, flexible billing, and technical support to handle multiple clients within the same instance. It is unlikely, if not impossible, for partners to shoulder the burden of acting as a buffer between old and new business models.

Software-as-a-Service-as-a-Service (SaaSaaS) may sound like a mouthful, but identifying these points of friction for existing businesses to transform and offering solutions to them as a service, is most certainly an exciting challenge for any vendor that relies on partner channels to be successful. It is up to us to support and offer guidance on these opportunities. It is also in our best interest to establish standard practices that can be flexible and do not risk being hyper-customized.