Friday, November 2, 2012

The Cost of a Seat on Facebook

Just a quick thought to reflect on this morning. I was thinking about the nuances of customer portal pricing and page view limitations when I started thinking...

How much does a seat on Facebook cost?

There are a lot of aspects here -- server time, bandwidth, power, storage, engineering and development, marketing, etc.. You could break it down in a number of different ways, but here's how I was thinking about it.

First, there are the those front end development costs to build the system. In one respect, you might think of that as fixed. Sure, there is ongoing research and innovation and the expenses associated, but in some respects, once you've crafted the platform, it exists.

Then you have your operational costs: power, bandwidth, servers, storage, everything needed to run your network. Some of these costs may vary, depending upon the user, how active they are, how engaged they are with the platform, that sort of stuff. Still, if you think about the model for that, there are some basic cost predictions that you could develop.

All of that being said, think about how much it costs to add a user, essentially one more entry into a database table. Again, the simple cost of that line would be minimal. The only real substantive costs come through increase in resources required based on things like how active the user is, how much simultaneous activity that you need to support, etc.

This is what makes some of these customer portal pricing models that you see in the market seem so ridiculous. Many of the businesses selling cloud-based customer support portals want you to pay up front for something that most of us look at as simply adding lines in a database. It would be as if Salesforce.com wanted to bill you for each contact that you stored. In the modern world of the Internet, Facebook is happy to add users. Google is happy to give you Yet Another Email Address, and they don't mind if you use their platform for one more search. In a market where pricing like this exists, the prospect of pay-per-record (more or less) invariably seems mind-boggling.

A Salesforce Seat versus a Facebook Seat
This same issue really defines many of the current battles that I face related to Salesforce.com. Within most organizations, there is little resistance to paying for a tool that the business is using; however, the inevitable question is, "are we using it." If adoption is defined by a percentage of utilization, justifying the expense is more difficult when you have some users with very low utilization -- particularly when they 'cost' as much as someone who uses it a lot. You wind up with a conflict between the benefits of ubiquity versus the cost of paying for everyone to live on an all-you-can-eat platform. And if, in terms of code, a user isn't really any different than a contact, there's that inevitable question that eats away at the justification -- why does this cost so much?

When you contrast what Salesforce offers to the traditional pricing approach for enterprise software like Oracle, it's easy to see a benefit to the "that's not a module, it's included" approach. At that point, it's easy to find yourself in a position to use more that you might have envisioned in your initial look. This can also wind up with Salesforce eating larger portions of your software infrastructure.

All of that being said, the time when Salesforce.com seemed like an unbelievable value have passed. While I am often impressed with the utility, value isn't really a word that I would apply.

No comments: