Pricing 101 - 13 Jan 2020

Pricing Basics

Reading up on pricing strategy.

3 Different strategies generally recognised: skimming (high price for high value product), neutral (same as competition), and penetration (discounted for high volume sales). There is a stated corrolation between your lifecycle and the appropriate pricing strategy: emerging = skimming (new customers should be willing to pay for the exclusive access to a new product), growth = penetration (customers buying a proven but novel product, goal is to maximise market capture), mature market = neutral (avoid penetration as that equals a price war which will destroy everyone's profit margin.)

(Source: here.)

Beyond that, there's an assumption that price is set with an understanding of the profit margin, which can be complicated, especially for startups and doubly so for hardware given changing components, uncertain volumes, etc.

We could say, for example, that we want to sell at a loss, as part of a penetration strategy, or at a high premium (luxury, cf Tesla) in order to finance other products or the ability to subsidise other customers... but all of that implies a deep understanding of COGS etc.

Moving more towards the realm of tactics we have anchoring (more expensive options next to desired sale), psychological tools ($99 etc).

Button Pricing Shift & Break-even Point Analysis

Thinking about how we price the buttons and how the pricing and relationship interrelate. I was exploring a price that went mostly contrary to the advice we received, and have been following, that we should try to get monthly subscription costs; and in doing so, end up with a model that is far more hands off. i.e. a model where we are largely handing over the system to people to run and implement and manage themselves.

The current pricing thinking is a price for installation, plus a monthly subscription fee that is determined by how many buttons you have. e.g. $15 per button per month.

With the shift I'm contemplating, the price would be an up-front fee per button/room (potentially plus a fee per enclosure, but ideally that would be included), plus an installation fee.

There would be an ongoing fee for system maintenance and support but we're talking about technological support similar to any other system you might have and I'm imagining a price point that is similar to ODetect: $100 per month or less.

e.g. if we charged:

• $50 per button,

• $200 per enclosure,

• $900 per building, and

• $999 per year for maintenance and support of the system (replacement buttons are extra, upgrades are included etc),

• Price would equal $3,450 initially, and then $999 per year thereafter plus replacement costs.

Break Even Point: 2,672 units or $374,043 per year

A recent Weekly Report Budget excel doc (still in draft for end of this week) has details in the Some Calculations tab... COGS are very high-level guesses, and BEP is based on that (so grains of salt). Revenue per button is also very high-level, but if we use above assumptions and think in terms of one year sales (vs using more complex concepts like LTV annualised or something...), we come to:

• $140 - sales value per button

• $67 - cost per button

• 2,672 units as a sales target to reach break even.

• which means $374,043 in sales.

• which probably equates to about 76 buildings per year (assuming average of 35 rooms).

If we consider the ongoing support and replacement etc as a SAAS revenue stream, then the economics there will be different and would support different cost centers (which would also likely reduce the fixed costs for the above calculations). Am hoping to get some more guidance on how to blend these with each other for a more robust model.