{"id":3270,"date":"2014-06-16T12:15:28","date_gmt":"2014-06-16T11:15:28","guid":{"rendered":"http:\/\/t-machine.org\/?p=3270"},"modified":"2014-06-16T12:15:28","modified_gmt":"2014-06-16T11:15:28","slug":"your-pricing-models-dictate-your-business-success","status":"publish","type":"post","link":"http:\/\/new.t-machine.org\/index.php\/2014\/06\/16\/your-pricing-models-dictate-your-business-success\/","title":{"rendered":"Your Pricing Models dictate your business success"},"content":{"rendered":"

Many businesses underestimate the power of a clever Pricing Model. I’m selling a new product at the moment (we’re helping schools teach children to program<\/a>), so pricing models occupy a lot of my head right now.<\/p>\n

Startups are so unsure of what model to use that they often say “anything, so long as we get sales”. They usually focus on simplicity (with a “new” product, a complex pricing model can tip people over the edge and make them “give up” on buying).<\/p>\n

Which is fine, but a cunning pricing model can work wonders.
\n<\/p>\n

Example: server hosting<\/h3>\n

Today I got an annual renewal notice for our server-hosting. Changing your “hosting provider” is technically simple but – in practice – a huge pain in the ass. We’ve used the same provider for 7 years, and in theory it’s unlikely we’d ever change.<\/p>\n

\n$1,000 \/ year for dedicated server
\n * 7 years = $7,000 to date
\n * 10 more years? = $10,000 to come\n<\/p><\/blockquote>\n

Nice business if you can get it, right?<\/p>\n

This is from a dedicated-server company. Bear in mind that, by comparison, Amazon EC2\/S3\/etc is some of the most expensive hosting available<\/em>. Think how much Jeff Bezos is raking in…<\/p>\n

Service<\/h3>\n

With hosting, you rent a physical server. An actual chunk of metal. They can’t upgrade that thing (generally speaking: they bought the best thing they could, in the smallest package – the “costs” of hosting come largely from the physical space to store it).<\/p>\n

In theory, I’m still using the same server I had 7 years ago. In reality, I negotiated an upgrade a few years back – they were able to put some more RAM in the case (but I suspect it’s maxed-out now).<\/p>\n

Pricing<\/h3>\n

The renewal offers<\/p>\n

\nPay the same this year as you did last year
\nReceive the same this year as you did last year\n<\/p><\/blockquote>\n

But if you go on their website as a new customer today – with no special offers! – you get:<\/p>\n

\nPay 1% more than I’m paying already
\nReceive 300% more performance\n<\/p><\/blockquote>\n

I can, of course, buy a “new” server and stop paying for the old. Transferring the data from one to the next is a standard procedure. But … transferring to a new server with this<\/em> provider is no less effort than transferring to one with a new<\/em> provider.<\/p>\n

Net effect of pricing model<\/h4>\n

Every time they come to collect their annual, guaranteed, easy cash from me, they scream “SWITCH TO OUR COMPETITORS, WHO’LL GIVE YOU A MUCH BETTER SERVICE THAN IF YOU PAY US TODAY”<\/p>\n

Their pricing model is actively driving away customers. And not just any customers: the best customers, the one’s who’ve been paying longest, who are cheapest – and hence: most profitable.<\/p>\n

Fixing this pricing model<\/h3>\n

Ideas?<\/p>\n

Let’s start with a recap of the constraints (we can’t change these; these are fundamental to the business. Pricing cannot change reality ;))<\/p>\n

    \n
  1. Any direct increase in value (a new\/better server) will cost the customer time\/effort (they have to migrate their code\/data), and push them to stop paying\n
  2. Any direct increase in value reduces the company’s assets (the old server has zero re-sale value, and no-one would pay for it these days. While this customer pays, it has value. When they stop, it becomes landfill)\n
  3. For a single customer, the longer they remain “loyal”, the worse this problem gets\n<\/ol>\n

    I see an obvious way out of this:<\/p>\n

    \nFor ongoing customers, reduce the renewal price periodically\n<\/p><\/blockquote>\n

    Key notes:<\/p>\n

      \n
    1. Price reduction doesn’t need to be annual. After 1 year, a server that was “a good price” is merely “a weak price”, not a “bad price”.\n
    2. Switching to a new provider costs the customer. So the value of switching is:\n
        \n
      • VALUE = (CURENT_POWER – COMPETITOR_POWER) + ($CURRENT_PRICE – $COMPETITOR_PRICE) – SWITCHING_COST\n<\/ul>\n
      • Each year, if switching provider gives an increase in POWER and decrease in COST that – in total – are less than the increase in PRICE … you don’t need to lower the price yet.\n
      • As soon as a customer switches away, they lose the benefits forever. Switching back to you resets their “discount counter” to 0 years. Free lock-in!\n<\/ol>\n

        Conclusion<\/h3>\n

        I’d love to try this change out. I’ve emailed my hosting provider (they’re decent guys, I’d like to help them) with this suggestion. It needs testing, but … I’m confident this would increase their profitability.<\/p>\n

        And how much effort did it take? Did we have to write code, buy assets, license software?<\/p>\n

        Nope – inventing pricing models is something you can do entirely in your head. The reward per cost is enormous.<\/p>\n

        Changing an existing pricing model isn’t free: usually you need to update your advertising and sales materials. However, in this case, it would be “very nearly free”, since we’re not changing the public-facing prices. We’re only changing the prices that are emailed \/ invoiced to existing customers – that means changing some numbers in an Accounting package. Very simple.<\/p>\n

        Pricing Models. What’s yours? Is it working for you – or against you?<\/p>\n","protected":false},"excerpt":{"rendered":"

        Many businesses underestimate the power of a clever Pricing Model. I’m selling a new product at the moment (we’re helping schools teach children to program), so pricing models occupy a lot of my head right now. Startups are so unsure of what model to use that they often say “anything, so long as we get […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[50,58,46],"tags":[],"_links":{"self":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/3270"}],"collection":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/comments?post=3270"}],"version-history":[{"count":1,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/3270\/revisions"}],"predecessor-version":[{"id":3271,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/3270\/revisions\/3271"}],"wp:attachment":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/media?parent=3270"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/categories?post=3270"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/tags?post=3270"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}