269 lines
16 KiB
Plaintext
269 lines
16 KiB
Plaintext
MARKETING AND SALES IDEAS
|
|
|
|
|
|
We will have two markets:
|
|
|
|
SAAS rental market
|
|
- User pays monthly fee to use RAVEN on our servers
|
|
- Pricing will be a factor of how many scheduleable users, accounting add-on and some kind of protection for us relating to bandwidth and number of simultaneous users
|
|
- Taking into account support and upkeep costs, hosting costs etc
|
|
- One flat price per month, as long as they keep paying they keep using and will get automatically updated and support included
|
|
- When they stop paying they can no longer use it but we won't delete the data immediately but give them time and warnings before we do
|
|
- User has the option to switch to a perpetual license by buying one in which case they can then run it self hosted or elsewhere
|
|
- This is important to marketing because it removes one of the negative preconceptions around risk using an online service (vendor bankruptcy kind of issues)
|
|
|
|
Perpetual market with maintenance subscriptions
|
|
- User buys a perpetual license for the software itself
|
|
- specifically this means they buy service tech licenses to add in single or groups with discount per group (to be determined based on what makes us the most money and target market)
|
|
- User pays for support and updates subscription either monthly, yearly or 3 yearly with increasing discounts for each
|
|
- User can update at any time while active
|
|
|
|
|
|
|
|
WHAT WE ARE SELLING
|
|
|
|
SAAS RENTAL
|
|
The ability to use the software for month to month priced by number of techs, accounting addon and whatever we deem to be the fair price to us for server hosting plus bandwidth overages
|
|
- ideally charge them for a 20 dollar server but use a 10 dollar server kind of thing
|
|
|
|
Perpetual:
|
|
AyaNova service technician licenses by count with sliding discount for volume purchases at time of purchase
|
|
Accounting add-on
|
|
Maintenance subscription for support and updates
|
|
- First purchase includes one year of support and udpates (or maybe a shorter time frame at a lower price? Have to research that to see what gets the most revenue)
|
|
- Subsequent years are at a rate based on whether they have the accounting add-on (one flat price) and so many dollars per service tech but sliding scale so costs less the more techs
|
|
|
|
PHRASING
|
|
Marketing will sell the licenses with the phrase "service technician" or whatever the most universal equivalent is with a blurb at the top
|
|
explaining that a "service Tech" just means anything you schedule so could be busses or etc, but then forever afterwards just say service tech as it's less confusing
|
|
|
|
|
|
|
|
|
|
|
|
WORKSHEET PLANNING STUFF FOLLOWS:
|
|
|
|
|
|
POTENTIAL NEW LICENSING SYSTEMS
|
|
|
|
What we need:
|
|
- Absolutely need recurring revenue, no two ways about that, it's our bread and butter
|
|
- Ease of administration and ease of billing procedures
|
|
- Automated system as much as possible for both us and the client
|
|
|
|
What our customers need
|
|
- Clear and easily explainable costs
|
|
- Ease of purchase and control over billing system
|
|
- Easy to upgrade or downgrade the level of licenses and options
|
|
- A reason to keep paying and not simply cancel a subscription when it suits them
|
|
|
|
|
|
|
|
SUBSCRIPTION / RENTAL / SAAS LICENSE
|
|
- Users pay a subscription fee to be able to use the software
|
|
- Includes support and updates as long as their subscription is active
|
|
- Software does not work without a subscription at all, they are renting the software
|
|
- Quote from a link below: Prices for annual subscriptions are generally some fraction of the perpetual license alternative.
|
|
Many companies aim for a crossover point of 4 to 5 years after which the costs for the annual license begin to exceed the perpetual license fee plus the annual support costs.
|
|
So, an annual license might be priced at 40% of a perpetual license.
|
|
- Not sure about that math
|
|
|
|
|
|
SAAS PRICING MODELS COMMONLY USED
|
|
|
|
FLAT RATE
|
|
- Same flat price for everything for everybody, i.e. 300 a month all in
|
|
- PROS: Easy to sell, market and explain
|
|
- CONS: rarely used less precedent, harder to extract value from different market segments, you get one basically, no flexibility for the customer
|
|
|
|
|
|
USAGE BASED
|
|
- Charged based on actual usage, some metric from the software, perhaps number of records or speed of access or space consumed or something
|
|
- Workorders per month or scheduled items per month would be a good metric for us
|
|
- Often used for scenarios where someone is hosting something and paying for the costs to host it, i.e. if we were hosting for people
|
|
- PROS: price scales with use, reduces barriers to use, scales for heavy users compensating for extra costs
|
|
- CONS: rarely used less precedent, harder to predict revenue, harder to predict costs for the end user,
|
|
|
|
CAPACITY / INFRASTRUCTURE *
|
|
- Based on something that represents the size of the company
|
|
- We sort of do this now with the price per scheduled user tiers
|
|
- Normally it's done with some kind of hardware or other consideration such as the size of the server in use based on the number of CPU cores on the machine
|
|
- Idea is it's cheap for a small company and more for a larger company
|
|
|
|
TIERED PRICING *
|
|
- Multiple packages at different price Points (MOSTLY THIS IS ABOUT VOLUME, NOT FEATURE DIFFERENCES SPECIFICALLY)
|
|
- Usually Small, medium and large (3.5 options is the average)
|
|
- Basic, Pro, Enterprise
|
|
- Targets a customer type for each tier trying to take into effect the needs at each tier with an appropriate level of service
|
|
|
|
- PROS:
|
|
- Commonly used pricing model so easier to market and for people to understand and compare due to familiarity
|
|
- appeals to multiple buyer personas better chance of a sale
|
|
- maximize revenue (offering a single $100 package will overcharge users with a $10 willingness to pay, and undercharge users willing to spend $200.)
|
|
- clear upselling route
|
|
- CONS:
|
|
- Potentially confusing (Do not have too many tiers, maybe 3 with an out for excessive costs to us like too much bandwidth or too many support requests)
|
|
- Appeals to too many people (don't try to have a tier for every segment)
|
|
- Heavy user risk (if top people exceed expected costs no room to move them up [This would be solved by having some kind of cap and overage charges I guess])
|
|
|
|
|
|
PER USER PRICING
|
|
- Exactly what it says, per POTENTIAL user of the software. 1 user one price, 2 users double the price 3 treble etc etc.
|
|
- Paid monthly or annually (discount of 12% for example)
|
|
- PROS: Simple, revenue scales with users, predictable revenue
|
|
- CONS: Hard to track, limits adoption as it can get expensive and so people might hold off too many users which increases churn due to less users tied to prodcut, rewards cheating, doesn't reflect real value; company doesn't see the difference from one user to 5 for them
|
|
|
|
|
|
PER ACTIVE USER PRICING
|
|
- Only charge per active user, don't pay for accounts that are unused
|
|
- Often targetted at Enterprise level customers
|
|
- Slack is a famous example
|
|
- PROS: Customers only pay for what they actually use so reduces their risk of widespread adoption as it won't cost any more if they end up not using it
|
|
- CONS: Not much value to a smaller business so extra incentive, not idea for us because it means we don't have defined recurring revenue just like the USAGE BASED model
|
|
|
|
|
|
PER FEATURE PRICING
|
|
- "Features" as value metric, not "users" (kind of a mix of what we do now)
|
|
- Tiers as in TIERED PRICING but by packages with sets of features more than by usage
|
|
- PROS: strong upgrade incentive, Compensate for delivery heavy (expensive to provide) features
|
|
- CONS: Difficult to get right (hard to determine which features go in which package could get ugly), Leaves a bad taste / easier to feel resentful for the customer as they know they could be getting more
|
|
|
|
|
|
FREEMIUM PRICING
|
|
- Tier but with a free level to hook people in.
|
|
- Pricing begins along a dimension of features, capacity or use case (you can use it to do this but not to do that; e.g. not free for commercial use)
|
|
- PROS: foot in the door, viral marketing potential for word of mouth
|
|
- CONS: Revenue killer; all revenue to support free needs to come from paid, increases churn, can devalue your core service
|
|
|
|
|
|
|
|
=-=-=-=-=-=-=-=-=-=-=-
|
|
|
|
OUR PRICING STRATEGY
|
|
- What is our pricing strategy?
|
|
- Example pricing strategies
|
|
- Penetration Pricing: "land and expand" initial unsustainably low pricing for short to medium time period to grab a market then upsell later once you have a big base
|
|
- Captive pricing: low intial price for "core" product but lot's of add-on's that are required to really use it and those generate the revenue (inkjet printers)
|
|
- Skimming pricing: start with an initial high price and slowly lower it over time (not sure this works in our market)
|
|
- Prestige pricing: maintain a high price to convey prestige or have a high prestige tier (with a rounded price $500 not $499.99)
|
|
- Free trial pricing: free month then charge to continue usage. Industry average is 50% adoption rate after free trial and 30 days is the average length
|
|
|
|
- I want it to be easy enough to sell that we never have to hard sell anyone on it or waste time convincing them, we don't want to have to do "sales" at all
|
|
- Penetration or low pricing will give us growth and our expenses are not high so the more recurring revenue from as many sources as possible the better.
|
|
- Rather see 500 low price customers than try to fight to keep 3 high price ones, far less risk
|
|
- Possibly this means that we would take an average less profit on each sale
|
|
- I'd like to see all options available for all users as much as possible. Maybe tiers based on scheduleable resources still? But that's hard to understand for users.
|
|
|
|
|
|
|
|
=-=-=-=-=-
|
|
PRICING PSYCHOLOGY
|
|
- Price Anchoring:
|
|
- set an anchor price by highlighting the most expensive package first on the marketing page so that people judge the other prices by comparison to it
|
|
- Maybe make the leftmost the most expensive or just otherwise highlight the most expensive so eyes are drawn to it first
|
|
- Always start with the most expensive price first when marketing or discussing with a customer
|
|
- Charm pricing
|
|
- People heavily judge the leftmost digit in the price subconsciously so don't sell for $400 sell for $399; people see the 3 and mentally get stuck on it
|
|
- Odd Even pricing
|
|
- People might be getting used to the .99 thing so don't end in .99, use .98 or .23 or whatever instead just keep the first digit low
|
|
- Product bundle pricing
|
|
- bundle shit together; causes people to think outcomes rather than about the individual prices
|
|
- Analysis paralysis
|
|
- Do not offer more too many options (research suggests 7 options plus or minus 2. So 5 or less is safest.)
|
|
- The biggest, most successful SaaS companies have an average of 3.5 packages available on their pricing pages.
|
|
- Center stage effect
|
|
- use the center column of multiple prices as the "most popular", or one we want to sell the most of; people will choose it more often by default all things being equal.
|
|
|
|
|
|
|
|
|
|
REQUIREMENTS
|
|
|
|
- JSON format
|
|
- secured with hash signature
|
|
- All licensed things are in a collection, not just the add-ons
|
|
- scheduledusers, accounting etc.
|
|
- Old versions should work with new licenses but not the reverse
|
|
- Has an ID and source values like current keys, ID may become much more important in future
|
|
- ALL TRIAL KEYS ARE REGISTERED TO SOMEONE NO SUCH THING AS TWO LICENSES IN CIRCULATION WITH THE SAME NAME (i.e. no more "Unregistered trial" meaning it's a trial, every user will have a specific name to test it out)
|
|
- Rockfish issues the trial key upon first request to empty db
|
|
- Need indicator that it's a trial key / evaluation key
|
|
|
|
- All licensed things should each have an expiry date possible to turn off that feature
|
|
- In the case of options they just stop working
|
|
- In the case of main user license everything stops working
|
|
- MUST be able to support monthly billing cycle (automatic license installation or approval so user doesn't have to install key every month)
|
|
- Rockfish should have a licensed yay or nay or new available route for RAVEN to check periodically and also users can trigger a force check
|
|
- RAVEN checks periodically for new license to fetch in line with billing cycle or expiry cycle.
|
|
- SAFE fallback if can't contact license server and allow a few misses before something kicks in, but not to allow people to use unlimited by blocking rockfish for example
|
|
- Support both perpetual license with rental maintenance subscription and rental license
|
|
- Need expiry date for maintenance so code can query if eligable for updates or support requests
|
|
- Need expiry date for entire license for rental and trial scenarios
|
|
- Support update restriction based on build date and license
|
|
|
|
- ?? what about the add-on's expiring at the same time as the sched users. currently the expiration dates differing is a hassle, should it be still supported??
|
|
- ?? what if we are not licensing by scheduled users anymore but by something else
|
|
- ?? need to analyze sales and determine the percentage of each level of license issued so I can group into tiers
|
|
- Current (5/29/2018) active subscription licenses:
|
|
- Single = 35
|
|
- Up to 5 = 18
|
|
- Up to 10 = 10
|
|
- Up to 15 = 1
|
|
- Up to 20 = 12
|
|
- up to 50 = 0
|
|
- Up to 999 = 0
|
|
- QBI
|
|
- QBOI
|
|
- PTI
|
|
- WBI
|
|
- RI
|
|
- MBI
|
|
- OLI
|
|
- OutLookScheduleExport
|
|
|
|
|
|
Maybe what is needed is:
|
|
- A single license expiry date no matter what is in the license
|
|
- A single support and updates date no matter what is in the license
|
|
- A single license "type" to support tiered pricing
|
|
- Tiers: 1 user, up to 10, up to 100, custom?
|
|
- Discussed with Joyce and she made a good case for one by one license sales as most customers are small and tiers may not help as they are in the 10 and under stage anyway
|
|
so maybe no tiers at all, just licenses for "service technicians" or some more generic term and make a not early that a "service technician" is any scheduleable resource
|
|
and then cotinue to use the term service technician afterwards because it's what the majority are scheduling and it is far easier to explain.
|
|
For the rental market though we will really need to take into account bandwidth so in future there may be more types of things to track.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PRODUCT LICENSE CHANGES FROM v7
|
|
|
|
|
|
Still optional and purchased separately as a single Accounting interface option:
|
|
QBOI, QBI, PTI
|
|
|
|
Possible idea: sold as "Accounting add on" and the user can use one of those of their choice and can switch which means 1 product instead of three which might make keys easier.
|
|
Possible downside is that we can't track who uses what or what we sell how much of so puts a kink in marketing or planning for deprecation or where to spend
|
|
effort, however there are other ways of addressing that.
|
|
|
|
|
|
//INCLUDED ADD-ON's
|
|
OLI - INCLUDED / TURNED INTO GENERIC FEATURE IMPORT / EXPORT CONTACTS and SCHEDULE TO ICAL
|
|
OutLookScheduleExport - INCLUDED / TURNED INTO GENERIC SCHED EXPORT ICAL FORMAT
|
|
Export to xls - Included with RAVEN
|
|
QuickNotification - Included with RAVEN
|
|
ImportExportDuplicate - Included with RAVEN
|
|
RI/WBI/MBI - UNNECESSARY with RAVEN
|
|
|
|
|
|
|
|
=====================================
|
|
|
|
RESEARCH SOURCES
|
|
- http://www.reprisesoftware.com/blog/2017/08/implement-a-recurring-revenue-license-model/
|
|
- https://www.linkedin.com/pulse/20140819084845-458042-the-change-from-perpetual-to-subscription-based-software-licensing
|
|
- http://software-monetization.tmcnet.com/articles/429528-long-but-rewarding-road-a-recurring-revenue-model.htm
|
|
- How to calculate pricing in a service business: https://www.patriotsoftware.com/accounting/training/blog/how-pricing-services-strategies-models-formula/
|
|
- SAAS pricing models: https://www.cobloom.com/blog/saas-pricing-models |