SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Does SaaS Limit Over-Customization?

Posted by Bob Warfield on October 23, 2007

One of the things I like about the Unreasonable Men blog is their propensity to throw the oddest ingredients into a stew just to see how it tastes.  Nothing unreasonable about that at all: it’s how we learn new and interesting things.

The stew this time is all about customization, or rather “over” customization.  Unreasonable sees clamoring about the difficulties of customization for SaaS.  This gets the juices flowing, and pretty soon we’re wondering whether:

If you took you’re on-prem code vanilla, wouldn’t that attack one of the core value propositions of SaaS – speed to market and easy upgrades? I could finance all the bits and give you a monthly rental. I’m being provocative but am genuinely interested in the answer… please if you’re a lurker give me you’re comments.

Fascinating question!

I’ll throw a log on the fire:  Robert Youngjohns, my recent ex-boss, commented that while he was the VP of Worldwide Sales at Sun, they were having a terrible time getting Siebel installed on-premises, and all because of customization.  Eventually they finished.  Some time later there was a discussion with Siebel about Salesforce being a lot easier, and Siebel responded, “If you’d just installed our software out of the box we would have been easier too!”  That’s exactly Unreasonable’s point.

Perhaps SaaS has accidentally stumbled onto the benefits of just saying “no”.  I’ll go a step further.  SaaS provides a politically safer outside-the-organization reason to say “no” to unnecessary customization.  But, in the spirit of the request for lurkers to come out and comment, let me offer some counterpoints, because some business processes have to be customized

Let me give a prime example from my last gig:  sales compensation.  Everyone does sales compensation a little bit differently.  Why?  There are lots of reasons.  Sometimes an industry has created a different model.  Insurance sales people are paid radically differently than car sales people.  If one company tries to change that, they will lose their salespeople.  Worse, in most insurance, the sales people don’t work for the insurance company.  They work for independent bureaus.  The sales comp becomes a means of attracting new brokers to sell your product.  As such, the offering must be fluid.

I’m sure others can give other examples.

You may have also heard my diatribe that IT must continually introduce change if it is to add value.  I put it a little more eloquently by saying that the IT productivity curve must continuously be replenished.  A failure to allow for customization dooms the particular software package and its customers to the commoditization of that module and its business process.  This is Ben Kepes fear when he talks about “a slippery slope to mass-homogenization where there really is nothing different between one enterprise and another.” 

There are some modules where commoditization and homogenization makes sense.  I’ve heard a number of Sales VP’s opine that Salesforce with minimal or no customization is fine because the business process it deals with doesn’t benefit much when you customize it.  In the worst case they view it as a system of record for the opinions of salespeople on what might happen.  But there are other business processes where customization matters. 

There is also simple customization that can be done fast and isn’t really so much about business benefit as identity.  I want to  put my logo on the screens.  I want to use my terminology as the way I think about my business.  I want to add a few new fields to various objects so I can track more information.  I need to be able to do ad hoc reporting on the data.  Every SaaS app should accomodate this kind of basic metadata functionality.

SaaS vendors need to understand whether their domain requires real customization or not.  If it does, they’re going to have to find a way to deliver that customization at a price and implementation time frame that makes sense relative to the rest of the SaaS model.  This means building more technology, at least until a platform comes along that addresses customization.  If the domain doesn’t require the customization, let’s try to get by without.  Help your customers control themselves.

2 Responses to “Does SaaS Limit Over-Customization?”

  1. […] on Microsoft&#8… on Microsoft’s Expensive Ri…allenjs on Microsoft’s Expensive Ri…Does SaaS Limit Over… on The IT Productivity Curve Must…Cliff on How the Internet and […]

  2. ilyabm said

    What if an ISV has a customer base to migrate to SaaS model? Telling customers that their solutions will be broken because some of the customizations don’t work anymore is hardly an option. More on that at

    Ilya Baimetov

%d bloggers like this: