Cetrus Blog

Why CRM was the "Killer app" for SaaS

Posted by Erik Hoogerhuis on Jul 23, 2015 1:53:59 PM

Customer Relationship Management (CRM) solutions support perhaps the most demanding group within an enterprise – the sales team.  Until the arrival of Software as a Service (SaaS) solutions such as around 1999, on premise CRM came in essentially 4 “packages”: individual user, small workgroup (2-10 users), medium workgroups (10-100 users) and enterprise.   The jumps in application packaging correlated strongly to two variables – whether and what kind of underlying database was included, and the ability to provide multiple levels of reporting and add many additional data attributes for tracking.  Each jump up in packaging also included significant resource bumps to implement and customize the application. 

There are several competing interests around CRM in an enterprise:

  • Salespeople want to
    • Be able to track customer contacts and notes uniquely to each salesperson’s style
    • Input as little information into a system as possible
  • Sales management wants to
    • Analyze each salesperson’s pipeline to  understand opportunity status
    • Create reports to understand selling efficiency and for revenue forecasting
    • Ensure data on each prospect or customer exists to minimize relationship disruption if a salesperson leaves or a territory is reconfigured
  • Marketing wants to gather product use and marketing campaign success information
  • IT wants to minimize application change and support


When companies made the decision to implement an on premise CRM system, the standard approach was to gather input from each stakeholder group, identify the systems that would feed and receive information to/from the CRM, and prioritize what functionality would be initially delivered.  Consultants would then customize the application, build the integrations and prepare the customer for business process changes.  At one company I worked for that went through this process, we spent 3 months evaluating solutions, 2 months gathering requirements and then three months of implementation for the first rev to be delivered.  We thought this exhaustive process provided us enough knowledge of our processes and needs to answer the consultants’ questions appropriately. Only when we saw the first screens did we realize we’d made major mistakes in how to handle responsibility for account control.  It would take the consultants another 3 months to ship a “fixed” version, which still would not meet all the needs expressed 8 months ago.  Sales and marketing needs had changed significantly by then, meaning even if we’d had the solution implemented correctly, it wouldn’t have address our new and real needs. Our experience was not atypical.

Two big problems with on premise CRM were:

  • Speed of application upgrade/change could not meet the speed of change in sales organizations.  VP’s of Sales don’t have a year to plan for a new system, and can’t plan 3-6 months in advance for changes in sales tactics, compensation, territory structure or marketing campaigns.  They need to change incrementally every week and month with a few major changes being planned in advance. 
  • The expense of on premise software and the forced inclusion of all interested parties ensured that CRM systems became bloated with fields for all sorts of information that were desired by marketing.  All these fields ensured the application screens were bloated, reporting became complex, application response times became unacceptable and information became difficult to find or update.  Salespeople would use the applications because they had to.  What should have been a tool for competitive advantage became a hated, storage vault of incomplete data.

Enter, with a very simple value proposition, a CRM application which: 

  • Was as easy to use as a single-user application
  • Contained only the fields most needed by salespeople and managers

 Could be managed by an administrator in the sales organization

  • Could be changed at the whim of the VP Sales
  • Could be paid for out of an operating budget
  • Allowed the organization to add and pay for users as needed
  • Could be implemented without the participation or even knowledge of IT

Salespeople and management loved a solution designed not just to help them do their jobs, but which they actually liked.  In the first couple of years, Salesforce didn’t allow customization, only configuration, so a VP of Sales could have his/her administrators add or change fields, change names, etc. in a day and make them available for testing.  Changes could be rolled out simply and quickly.  Salesforce usage became a competitive advantage over other solutions.

Sales organizations drive revenue which is the lifeblood of organizations.  IT security, procurement, and legal all pushed back on acceptance of Salesforce. Salesforce was head and shoulders above on premise solutions in terms of cost, ease of use and acceptance.  When VP’s of Sales committed to higher revenue numbers, or pointed out competitors came out with more flexible pricing or packaging models faster because of Salesforce use, the organizational resistance to a new application model was broken.  Resistance to SaaS was less at smaller/mid-sized organizations than at larger ones, because the relative benefits of speed of change, lower cost of infrastructure, and concerns over data privacy were more compelling that at larger organizations.

SaaS for other applications didn’t have the same uptake as CRM, early on because while the infrastructure and IT savings might have been similar to Salesforce, the impact on revenue and need for constant and rapid change was not as strong.  As organizations experienced SaaS through Salesforce, the internal resistance lessened because the fears of data loss, application accessibility and uptime, security, etc. were proven false, whereas the benefits of the SaaS model were proven out.  It is a bit remarkable that SaaS has upended traditional application delivery in only 15 years, but it has.


Topics: Insider