I’m seeing this idea more — although it is often hidden due to perception that it is “pro serve” revenue (bad) vs “service as a service” revenue (not always bad).
The key with ServAAS is that the service must be productized. The words and definitions are wrapping around, almost touching each other now.
In a classic service context, “productized services” have edges. Think: Terminix vs Accenture. In order to make a ServAAS model work, it needs to be incredibly clear where the service stops. In other words, what will your people NOT do for a customer. It is soooooo easy to drift into extra work.
In many respect, obscuring people behind a wall of technology helps in this regard. Customers don’t necessarily know that it is HITL, nor should they. Customers that know will press and push for more. Companies that want to keep customers will provide. And then the virtuous cycle begins to erode.
Getting to this kind of model is a sea change for either services or software companies.
For services companies, adding boundary conditions is heretical from a customer satisfaction point of view — it means a lot of saying no! Typically services companies don’t have the structure to execute on this, and financially, don’t perceive the investment as valuable. For example, who defines the “product”? Who markets it? How do we charge? etc etc. Product companies have things like PRODUCT MANAGERS who do this stuff. Services companies don’t (usually). It is a tough investment because a product function is very fixed cost oriented. It can’t readily be variabilized into “projects” which are often the unit-of-measure for a services company.
Software companies have the opposite challenge. In addition to the cultural “eww” factor of adding service to their cost base, it also requires new structures. For example, how do you measure, manage, reward, etc. a cadre of people who take data from one system and put it into another? They aren’t “project people” (which, actually software companies can grok just fine… it’s pro-serve!) and they aren’t product people. They are somewhere in-between. They are providing a bounded service, but the mechanism is labor. Unlike other parts of a software company that do this (dev), it is inherently uncreative. It is mostly about moving from point A to point B as cheaply as possible… akin more to a call center support function than an inherent part of the revenue bearing “product.”
Perhaps a better name for this would be “solution-as-a-service” — maybe companies would be more comfortable with this. But, don’t get me started on the definition of a “solution.”