15 Replies to “Community Platform Pricing for New Clients”

  1. There is always the inevitable – “what happens when I get to 100 million users?” – or similar question with any kind of variable pricing. And that variable pricing might hit further push back when there is some disconnect between the metrics used for success of the project, and the elements that lead to an incremental price increase. So there is always a measure of flexibility with each client – how they budget, how they measure success, how they have scoped to project within a broader strategy, but a successful client will always lead to more business, both within and outside the organization.

  2. I agree with Thad. We ( http://www.rSitez ) also have the same question, what happen when we have 100 million customers. It’s funny because this comment come from companies of all sizes.
    We have solved this issue with price ranges (plans) as Jeremiah’s suggest and we add a vble cost if they pass their particular plan. Once this occur, at any time, they can upgrade to the next level so the max vble cost is contained and known in advance. This approach seems to be working well for us. What has become more challenging is pricing special features requests. Funtional specs normally are vague, (ex. I want to include this functionality that I saw in this website and also add traffic and payment capabilities to it) and it’s difficult to put a price tag to all these things. We recommend before scope these requests to look their intended ROI. If it is just a cool thing to have that it will be use initially for a minimum part of your audience it’s always better to do it later when you really know what will work well for you. As you can imagine this recommendation not normally works and customers want a price even if you tell them the challenges of evaluating their requests.


    Luis Carbajo
    VP Business Development
    rSitez, Inc

  3. We’ve seen a slight maturation in pricing strategies at the vendors we evaluate for our clients. Most vendors we’ve worked with are fine with detailing the requirements and features for their offerings. Most cannot put a reasonable business case together though. But that’s changing as more vendors enter the B2B market where the requirement to provide TCO or ROI calculations in their proposals is an important selection criteria.

    Unfortunately it’s a bumpy path right now. We’ve been floored by several vendors who submitted million dollar proposals without a mention of helping the company get to a positive ROI. These vendors seem to price based on the relative strength of the client company rather than on a cost and profit method. Shooting for the moon early in pricing never works. Even if you get the contract, you’ll lose it when the client doesn’t reach break even or generate an expected ROI fast enough.

    Fixed price contracts with an escalation rider are always the best option for larger B2B contracts in our experience. The idea is that initially costs are fixed for the client. As traffic (and results like ROI or cost savings) grow, clients are generally willing to pay an increase to keep the results growing. It helps their organization, it helps their careers, etc. The key is to price the initial contract at a rate which makes the vendor money while staying within the client’s initial budget.

    By focusing on the results rather than the number of boxes to run the software or the number of interactions, vendors can move towards the sale a lot faster. As our industry continues to mature, this will become standard procedure in the sales cycle.

  4. Interesting thread here. We are always talking about pricing. After five years we have settled on one that seems to work well, in fact we worked with our customers to arrive at it. It is the tiered model that most closely aligns with our customers. Low entry level (works great for B2B clients that want to dip a toe in the water with a pilot), then the tiers map to wide bands that accomodate growth, but don’t stifle efforts to grow.

    We learned that when you price it based on a per user model, the client is not incentivised to grow the community, each person gets seen as cost. That is why we went with wide tiers that made that issue go away.

    We also do something that seems to work with growth, and that is to give them a call when they are within 10% of the next tier and have them decide if they want to cap signups, or let it ride – we then bill them the delta to move to the next tier. This was a client’s idea, and they all seem to love it.

    Mark Sylvester, CEO, introNetworks

  5. Our experience is similar to that described by Luis Carbajo and Mark Sylvester.

    In general, the number of users would generally be aligned with the value and hence ROI of an engaged user to the client. Our customers generally agree also.

    However, recently we have been challenged to come up with a lower cost model for registered but “inactive” user. Unfortunately, a mutually agreeable definition remains elusive. How long is a good period to declare a user as inactive? What do you do with their data. Any user’s data still costs something to manage and backup.

    We’re still modeling this so would love to hear some of your ideas on this. Maybe a few customers can propose something that is acceptable to them.

    Lastly, while all providers under the broad umbrella of social network vendors provide many similar basic tools, there are differences if not in terms of technology flexibility (Amount of customization, ability to change, etc) but also in terms of types and level service. All these affect our costs.

    And hence one size pricing does not fit everybody. Custom pricing for every client creates gigantic accounting and operational headache. Fortunately for customers, there are many choices and flavors out there. And there should be one that will fit the need for anyone seeking a solution for their particular case. We developed our pricing to be affordale to small-medium size use-cases – either small-medium businesses or small-medium community within an enterprise.

    My advice to clients is if pricing is the most important thing, I suggest make that the FRIST qualifying question to get to the short list quickly. There is some vendor out there that can meet your needs. And as Jeremiah sometimes may have said, get started! And I’ll add, don’t let price be the obstacle!

    C.H. Low
    CEO, Orbius

  6. I think there is always some flexibility for larger clients, the business case for each community can be very diverse. With that said, our pricing always follows a basic structure in line with Mike’s basic “Fixed price contracts with an escalation rider” – the variability comes in to how that escalation rider is structured – and we’ve settled on three different core scenarios that seem to cover 90% of our potential deals and that gives us the flexibility we need in a scalable way.

    And its been echoed here, we have that flexibility because the last, last thing we want to do – is throttle a clients growth – so those 3 scenarios are really built to make sure a client is completely comfortable growing their community.

  7. As a social community app vendor (Eve for Enterprise and LiveCloud) we always try to get as much information from the potential client up-front as possible. That helps us be much more flexible and nimble when it comes to pricing. When we know how many users/active participants there might be, we can factor that into equipment up-front costs and creative plans for covering the technology while allowing growth to happen unhindered. Advice to those shopping in this space—tell your vendors as much as you know, right away; they can then tailor a solution for you specifically. In this space, one size does not fit all.

Comments are closed.