Comments on: Platform Edition Licensing http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/ Authored by Scott Hemmeter of Arrowpointe Corp, this blog is written from the perspective of a Salesforce.com solution provider and contains information on Arrowpointe's AppExchange products as well as tips, findings, sample code, functionality wishes, etc. Fri, 05 Dec 2008 01:57:17 +0000 http://wordpress.org/?v=2.6.2 By: lux http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-101 lux Fri, 07 Apr 2006 16:44:00 +0000 http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-101 I once worked for a company that tried a "blended" model of paying per seat and per query for a database-backed hosted service, and I'll agree that uncontrollable per-transaction costs is a sales issue. Companies balk when they face the possibility of excess charges that they can't control. I once worked for a company that tried a “blended” model of paying per seat and per query for a database-backed hosted service, and I’ll agree that uncontrollable per-transaction costs is a sales issue. Companies balk when they face the possibility of excess charges that they can’t control.

]]> By: David Claiborne http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-98 David Claiborne Thu, 06 Apr 2006 17:51:43 +0000 http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-98 One of the marketing points of the internet has always been "all your can drink" for a fixed price. When you start counting each transaction and assessing a cost, it gets very messy. Also companies get scared. I remember back in the days of time-share computing (way back), one of our terminals froze up on over a holiday weekend. We blew the annual time-share budget in 3 days just because the phone line did not hang up. It is like cell phones - it is cheaper to get a large number of included minutes than to have a smaller number and pay overages. Some companies are charging more for the API. Netsuite, the last time I checked, does have lots of limitations and extra costs associated with using the API. - Basic fee covers 100,000 “transactions” per year - Sliding fee when exceed, e.g. additional $1,500 for 100,001 to 250,000 transactions - Currently no allowances for differing user counts, so a 1,000-user company gets no extra "transactions" Of course, Salesforce.com charges for the api by limiting its access to Enterprise users only. One of the marketing points of the internet has always been “all your can drink” for a fixed price. When you start counting each transaction and assessing a cost, it gets very messy. Also companies get scared. I remember back in the days of time-share computing (way back), one of our terminals froze up on over a holiday weekend. We blew the annual time-share budget in 3 days just because the phone line did not hang up.

It is like cell phones - it is cheaper to get a large number of included minutes than to have a smaller number and pay overages.

Some companies are charging more for the API. Netsuite, the last time I checked, does have lots of limitations and extra costs associated with using the API.

- Basic fee covers 100,000 “transactions” per year
- Sliding fee when exceed, e.g. additional $1,500 for 100,001 to 250,000 transactions
- Currently no allowances for differing user counts, so a 1,000-user company gets no extra “transactions”

Of course, Salesforce.com charges for the api by limiting its access to Enterprise users only.

]]> By: Scott Hemmeter http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-97 Scott Hemmeter Thu, 06 Apr 2006 15:58:14 +0000 http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-97 It sounds like there might need to be 2 types of Platform licenses <ul> <li>A per user license for companies wanting to use the front-end also. For example, for an HR department that wants to use it for Employee Management and Recruiting. These apps will have high user counts and low/no API transactions.</li> <li>A volume based license for people that are looking to use it more as a back-end to their own application. These apps will have have low user counts and high API transactions.</li> </ul> It sounds like there might need to be 2 types of Platform licenses

  • A per user license for companies wanting to use the front-end also. For example, for an HR department that wants to use it for Employee Management and Recruiting. These apps will have high user counts and low/no API transactions.
  • A volume based license for people that are looking to use it more as a back-end to their own application. These apps will have have low user counts and high API transactions.
]]> By: Steve http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-96 Steve Thu, 06 Apr 2006 14:41:32 +0000 http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-96 We're running into all sorts of community or coalition-based CRM efforts that are hamstrung by the cost of having licenses for each user in the community. I'd love to have a platform model. I think it's a logical step for sf.com, but also for CRM, which has historically been a centralized, inside system. As we've seen with many apps lately, surprising value can come from opening the system to the outside world. Hopefully sf.com will lead CRM into that realm. We’re running into all sorts of community or coalition-based CRM efforts that are hamstrung by the cost of having licenses for each user in the community. I’d love to have a platform model. I think it’s a logical step for sf.com, but also for CRM, which has historically been a centralized, inside system. As we’ve seen with many apps lately, surprising value can come from opening the system to the outside world. Hopefully sf.com will lead CRM into that realm.

]]> By: Scott Hemmeter http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-95 Scott Hemmeter Thu, 06 Apr 2006 14:06:03 +0000 http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-95 I believe the pricing model should not be only per user. Take, for example, someone making a consumer facing application that is pumping lots and lots of API transactions and data through, but are doing it with 1 user account to login on the back-end. Then they have another one to manage the application internally. I think any pricing model will have to include volume in order to be fair to the various needs out there. I think the per user price should be cheaper (e.g. $10/month for each set of 5 users) that includes a a per month threshold for API calls (e.g. 5000) and, maybe, volume (x MB). If you go over your API quota, you get charged a nominal fee per 100 additional transactions. Something like that. Doing licensing based solely on user count does not totally fit the platform model, in my honest opinion. The platform exists and it mega-scalable. Bringing the price down will bring more people. It might be less revenue per customer, but there will be more customers. If Salesforce doesn't price it this way, someone will with another platform. Salesforce has an advantage of first and best to (in) market right now and it will be important to get it right. I believe the pricing model should not be only per user. Take, for example, someone making a consumer facing application that is pumping lots and lots of API transactions and data through, but are doing it with 1 user account to login on the back-end. Then they have another one to manage the application internally.

I think any pricing model will have to include volume in order to be fair to the various needs out there. I think the per user price should be cheaper (e.g. $10/month for each set of 5 users) that includes a a per month threshold for API calls (e.g. 5000) and, maybe, volume (x MB). If you go over your API quota, you get charged a nominal fee per 100 additional transactions. Something like that. Doing licensing based solely on user count does not totally fit the platform model, in my honest opinion.

The platform exists and it mega-scalable. Bringing the price down will bring more people. It might be less revenue per customer, but there will be more customers.

If Salesforce doesn’t price it this way, someone will with another platform. Salesforce has an advantage of first and best to (in) market right now and it will be important to get it right.

]]> By: David Claiborne http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-94 David Claiborne Thu, 06 Apr 2006 04:29:30 +0000 http://sfdc.arrowpointe.com/2006/04/05/platform-licenses/#comment-94 UBS covers salesforce.com fairly well. Heather Bellini is the analyst. This is from a report on the last quarter earnings report. <blockquote>In our opinion, the company’s long-term goal of becoming a platform provider for OnDemand applications is highly dependant on creating a significant eco-system around it and therefore AppExchange will be a critical proving ground. We do believe that over time, it would make sense for the company to migrate to a platform pricing model for this of say $10 or $20 per month per user, rather than requiring all users to also license actual seats of Salesforce.com when they might not need that functionality (in the case of human resource employees for example).</blockquote> Ms. Bellini has made this same comment in different ways many times over the past few months. Either she is very pre-cognizant or a good analyst. UBS covers salesforce.com fairly well. Heather Bellini is the analyst. This is from a report on the last quarter earnings report.

In our opinion, the company’s long-term goal of becoming a platform provider for OnDemand applications is highly dependant on creating a significant eco-system around it and therefore AppExchange will
be a critical proving ground. We do believe that over time, it would make sense for the company to migrate to a platform pricing model for this of say $10 or $20 per month per user, rather than requiring all users to also license actual seats of Salesforce.com when they might not need that functionality (in the case of human resource employees for example).

Ms. Bellini has made this same comment in different ways many times over the past few months. Either she is very pre-cognizant or a good analyst.

]]>