What was the customer buying when the software stayed elsewhere?

In 2000, Salesforce launched a customer-management service with a deliberately provocative message about the end of software. The product was still software. The difference was how a business obtained and used it. Instead of treating the purchase as a major installation on its own systems, a customer could access the service through a browser and pay for a subscription. The early decision is worth examining because it changed the surrounding transaction, not just the functions available to a salesperson entering information about a prospect.

Salesforce's historical timeline describes its launch and a staged protest outside a Siebel conference. That marketing made the contrast visible, but the spectacle was not the operating model. Contemporary New York Times reporting in 2004, republished by the Taipei Times, described the company maintaining the application on its own computers while customers accessed it online. The distinction moved part of the implementation and maintenance burden from each customer to the provider. It did not make the customer's need for dependable access or useful information disappear.

The June 2004 registration statement claims faster deployment and lower initial commitments, without independently proving those advantages for every customer. It also describes direct sales and partners. Browser delivery had not eliminated organizational persuasion. A different delivery model could simplify one part of adoption while leaving another unchanged: people still needed a reason to buy the service and a workable way to introduce it to colleagues.

The filing records objections concerning existing investments, migration, and security. These concerns were not necessarily failures to understand innovation. They reflected responsibilities the buyer would retain. The analytical question is which risks had become smaller and which now required different assurances. A provider cannot infer that removing an installation also removes the customer's need to understand access, accountability, and control.

The stakeholders saw different parts of the proposition. A sales manager wanted useful information and adoption by the team. Individual users wanted a tool that did not obstruct their work. Information-technology staff needed a service that could coexist with other systems and meet organizational requirements. Finance had to assess an ongoing commitment rather than only an initial purchase. The supplier needed customers to keep finding value over time. The innovation therefore involved a redistribution of work and risk across a continuing relationship, not a simple deletion of cost.

The initial scope made the proposition testable in a recognizable business activity: managing customer relationships. It did not require replacing every enterprise application at once. Contemporary reporting and the registration statement show that the service had reached paying customers before the 2004 offering. That establishes adoption of the model, while leaving important questions open about differences among customer groups and individual implementations. Later success should not erase the uncertainty visible in the early filing. Security concerns, switching effort, and competing approaches were part of the decision environment at the time.

For a leader considering a new model today, the useful exercise is to separate the desired result from the conventional method of buying it. Could the customer obtain that result with a smaller initial commitment, less coordination, or a different allocation of responsibility? Then ask what new assurance the alternative requires. Salesforce's early offer was powerful because it challenged an accepted delivery arrangement. The corresponding discipline is to make the new dependencies explicit. A lower barrier to starting is valuable only if the provider can sustain the relationship that follows the first subscription.

For a discussion tailored to your team, explore a workshop with Julien.