Responding to Questions About SaaP – and Loving It


I love to receive comments and questions here at Spend Matters, and I was delighted recently to receive some excellent ones on my article “IQNavigator and iTeam Partnership Bringing Service-as-a-Product to a Business.” The article was about a specific case – and a general trend – of using a technology-based platform to organize digitally connected contingent labor to deliver standardized service outputs to clients, a phenomenon to which some are calling service-as-a-product (SaaP).

In this post, after reviewing  the SaaP concept briefly, I'll respond to the first of 3 questions I received (and respond to the other 2 in subsequent posts).

SaaP – What Does It Mean?

As I signaled in my original post, I’m not sure that SaaP will end up being the right way to describe what this thing is. But it is a real thing. Essentially, SaaP is a model in which a technology-based platform is used to organize digitally connected contingent labor to deliver standardized service outputs to clients. (The workers are only engaged across an online network, but they may perform the work and deliver the service output offline.)

Organizing labor to deliver service outputs is certainly nothing new – think of whatever falls into the category of indirect services spend, business process outsourcing or even a statement of work. These kinds of service models are not SaaP, because they are not supported by a unified technology platform designed to engage digitally connected contingent workers to produce specific services outputs. In addition, many of these models lean toward providing relatively customized services, on a case-by-case basis for different clients, whereas SaaP definitely leans toward providing relatively standardized, often unit-priced services to numerous clients across a given market segment.

Question 1: Where Will SaaP Go?

Will SaaP providers go directly to business buyers with category specific portals or will SaaP become offerings within vendor management systems?

To date, these services have been consumed by business users directly at the SaaP provider’s website. For example, this is the interface one would find at a SaaP called Scripted, which specializes in different writing outputs, such as the production of a short blog post:

A SaaP example from the website Scripted.

That said, there have been some exceptions where integrations have occurred with other enterprise systems, such as service management systems and content management systems, as well as VMS. Exceptions I have in mind are field service tech management systems like Field Nation, Onforce and Work Market, which have likely integrated with the VMS of some their customers, (though this has probably been for the purpose of establishing the VMS as a system of record, not to configure a real source-to-pay (S2P) process that extends to the direct buyer).

Still, IQN, as mentioned, may be starting to anticipate such a S2P use-case, and I suspect that other VMS providers may be as well. As SaaP platforms develop and, for many kind of things, make consuming a service output a faster, easier, better alternative to hiring specific workers, services procurement will take note, and handling SaaP will find its way into the product road maps of procurement technology providers. It may be some years off, but eventually this kind of services S2P with SaaP suppliers will be a reality.

Share on Procurious

Discuss this:

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.