Does “Self Provisioning” Make Sense for Your SaaS Company?

Mar 31, 2010 by Sinclair Schuller

Yes! How’s that for a quick answer? In all seriousness, I believe this to be a “no brainer,” but I think the burden of proof is on me to describe why. I think it’s important to set context and work our way backwards to conclude that an axiomatic ‘yes’ answers the question “Does ‘Self Provisioning’ Make Sense for Your SaaS Company?” Where do we start: at the definition of service, an understanding of conceptual dynamics at play, and agreement on the effect of competitiveness on distribution, of course!

Service. Let’s assume that “service” can be broken down into three main processes: engagement, implementation and execution. Engagement is the act of committing to use a service (e.g., signing a home builder to build your next home or remodel your existing home), implementation is overhead required to initiate use of a service, and execution is the process whereby the service provider performs its intended “statement of work” to yield an expected, implicitly or explicitly agreed upon result. I’ll use these process labels in my little analysis of what I see in SaaS.

If we dig in more, when we think of “service” we usually think of scenarios where, for a fee, some external entity completes a task or series of tasks on our behalf and produces some intended result. Second, I would say that it is generally understood that the service provider and the customer have a fundamental point of “equilibrium” with respect to knowledge required to provide the service and the knowledge required to engage a service. Yes, the knowledge can be skewed in one direction or another (As a trivialized example, a customer who is a Hollywood Socialite simply stating “I want a nice house” vs. anyone else stating “I want a two-story colonial with a basement, geo-thermal heating/cooling, solar power, and manufactured with a steel frame” places a heftier knowledge burden on the contractor that will ultimately build the house, while also increasing the contractor’s probability of failure since no clear requirements were presented.)

Rarely do we think of scenarios that require significant amounts of effort on the customer’s part to kick-off the engagement. For example, which is more typical:

• Having a contractor come to your house to provide you a work estimate based on his/her measurements and discussions with local officials.

OR

• Having the contractor come to your house and tell you “Great, nice house. All I need next is for you to go off and take measurements of your house, identify any new structural components and provide measurements for those as well, take care of architectural drawings, and deal with the town all by yourself regarding requisite approvals, and then I’ll give you an estimate.”

Ok, I know, some contractors do that, but what was your first thought? That’s right: “I’m planning on hiring and paying you and you want me to do what?!?!” Same goes for almost any service. Furthermore, we don’t couple the act of engaging the contractor with implementation; that is, we don’t tie the decision to use a contractor with the act of going out with that contractor to a supply store to pick out construction materials like wood, nails, and insulation. In fact, if a contractor ever said “Well, while we’re working on a contract together, let’s go out and start selecting what we’re going to use” we’d run for the hills simply because of the sheer idiocy of the request on the contractor’s part.

We expect that the engagement phase will be as trivial as is common for that type of service; we understand what the service intends to do, we have either an implicit knowledge of what implementation entails or have explicitly extracted it from the service provider, and intend to commit to that service provider. For example, a contractor would be ecstatic if he/she could post an ad for a set of pricing tiers for kitchen remodeling based on kitchen size and style, provide evidence regarding quality of service and accept signed contracts from consumers who were looking for kitchen remodeling. Furthermore, if it was common knowledge that kitchen remodeling required that the customer gets involved to a certain level of depth (picking out appliances), no one would have issue with the implementation phase since it was expected and generally accepted as protocol.

Notice how I hedged with the wording “as is common.” Frequently, product and service providers feel that their customers are a completely naïve group that lack the necessary crystalline knowledge and fluid intelligence to comprehend what they offer. Usually what this means is that your product or service has not been distilled to the correct level and cannot be digested by prospective customers without your help.

I bump into lots of folks in my SaaS discussions and travels, and I frequently hear “well, we’re not really worrying about self provisioning at this point. Our offering is too complex anyway.” What seems to be the case in most of these situations is that the SaaS provider has not identified a clear separation between engagement and implementation. In most cases (there are a few exceptions) engagement is not a complex process, even if implementation is. Without a clear distinction however, the complexities of implementation bleed into engagement, giving the service provider a false signal. In the SaaS business, a customer engages with a service by discovering the service and committing to use it. One can commit to use the service (signing a contract, paying some money) without being able to necessarily use the full functional set of the service immediately (since they may need complex implementation). Provisioning is just a synonym for pursuing and following engagement through to the end. If you’ve clearly separated engagement from implementation in your application and workflows, I’d say there is little reason to not allow self-provisioning. With SaaSGrid, we built a system that could take any application and provide an out of the box “storefront” and self provisioning capability because of this belief. You want to leverage point in time emotions your prospects have. When a prospect browses your corporate site, and they think “Hey, I really think this is the right system for us,” to lose that positive momentum because you didn’t think about or build a self-provisioning system would be a terrible loss. Do you have a complex implementation that would require the customer to migrate data, go through specific tailoring and setup? Fine. Do it after they engaged and committed to your service.

Do you agree that nearly all SaaS offerings, if cleanly partitioned into engagement and provisioning pieces, should offer self-provisioning? Do you see significant advantages to not offering a self-provisioning model?

read more