Your Multi-Seat Pricing Questions Answered

Why are you changing your pricing?

The way we charged for Miva Merchant prior to the release of Version 9 was to charge on average $500 per year for unlimited usage of the core product not counting hosting.

This model is the result of legacy business decisions made starting all the way back in 1997 and simply are no longer sustainable for the future of Miva.

We reconsidered how we charge for the product from the ground up, to ensure we could charge appropriately for the actual software and needed a model that accomplished three primary goals.

First it had to uncap our earning power for the core software product so that with more usage came more revenue.

Second it had to not price out the small mom and pop businesses using Miva Merchant for their online stores.

Finally the price had to scale appropriately with some correlation to usage and size of business.

We considered a number of other business models, including charging a percentage of sales, charging based on page-views or simply raising our price radically to something akin to Magento Enterprise (which is $18,000 a year without hosting included).

When we fully considered all of those pricing models against (what is arguably the Software-as-a-Service industry standard) to bill on a per simultaneous administration user model (a la, we decided that charging based on Administrative Interface usage was the best possible way to achieve all three of our goals.

Why aren’t you grandfathering in existing clients on your old pricing?

Miva’s focus (especially since 2007) has been almost exclusively on serving our existing client base versus focusing on sales and marketing to acquire new clients.

Ultimately because of how we’ve chosen to place our focus (on our existing clients), it’s not feasible to grandfather our existing clients into our old pricing model. At our current client retention rates, it would take 9 years for Miva to fully realize the results of our price change if we had grandfathered our current customers and that’s not tenable.

To add a little color and comparison on this topic, all companies have limited resources and you have to choose how to apply them across the various sections of your business.

Some of our major SaaS Ecommerce Competitors spend upwards of 50% of their spending on sales and marketing and it’s clear from using those products they’re not applying the same level of resources and commitment to their actual product.

We run Miva exactly the opposite of that model, our total spend on sales and marketing is roughly 5% of our total spending and instead we focus huge amounts of our internal resources and budget on improving the product for our existing customers and ensuring they never have to face the daunting proposition of being forced to re-platform because they succeeded in their online business.

This shows very clearly both in the exceptional success of the release of Version 9. We’ve been able to fundamentally rebuild the underlying platform, have a point and click install process that upgrades old stores and not have a single store have a catastrophic upgrade failure (in which a store upgraded and was unable to continue accepting orders). Not only is our catastrophic upgrade failure rate for Version 9 non-existent, but also the quantity and severity of the bugs discovered since the release of Version 9 was very low and we’ve already pushed out 2 small updates to fix those known issues.

Another way you can see the results of our existing client focus is a combination of our churn rate (the rate at which we lose clients from Miva) and the average amount of online sales done on the Miva platform per store.

To put some perspective on it, the industry average for ecommerce platforms like Miva is for clients to last for just over 2 years and they average store sells somewhere in the neighborhood of $20,000 a year in total online sales.

However Miva has an average customer lifespan of approaching 9 years and our average storeowner is doing more than $650,000 in annual online sales.

The striking success of Miva’s customer base compared to what we see as the average in the ecommerce industry is a direct result of the focus we place on keeping our platform secure, robust and stable for our existing client base as opposed to spending our primary resources on the sales and marketing front.

Why don’t you include 2 seats in the base price?

When we studied the usage of our product (we spent about 18 months looking at average usage of the admin before we finalized these changes), what we discovered was that 65% of our clients never used more than 1 simultaneous seat. In addition only approximately 25% ever used more than 2 simultaneous seats. Finally we knew that we restricted usage without purchasing more seats that people would alter their behavior to maximize the value they receive per seat (in other words our customers would change their behavior to the extent they can to mitigate the price increase).

So when we considered what we wanted to charge per extra seat per month, we either had to limit it to one so we could keep the price down to $50 per seat per month, or we’d have to charge something closer to $100 per seat per month for additional seats if we chose to include 2 seats in the base price and still achieve our pricing goals.

This didn’t really make a lot of sense to us, it was hard to see giving 2 seats away for a $40 per month base license fee and then jump it up to $100 per month for additional single seats beyond that.

Why didn’t you just raise everyone’s price a little bit across the board?

Our clients come in all sizes when it comes to online sales revenue.

Approximately 50% of our clients sell less than $250k annually online and of all our groups of clients, they’re the least likely to need to purchase an additional seat. Our goal was to keep this groups price as close to their current pricing as possible.

Our second tier of clients, which makes up roughly 30% of our client base do between $250k and $1 Million in annual online sales. On average we expect people in this cross section to buy 1 or 2 additional seats (and in many cases they may not need to purchase any extra seats depending on how they use Miva). For this group a price increase of $50 to $100 per month is quite appropriate and affordable.

Finally the top 20% of our client base does over $1 million in annual online sales and we expect them to need anywhere from 3 to 50 or more extra seats per month (generally varying on how large of a company they are on their side). While in some cases the price increase to this group is exceptionally high as a percentage, it’s still incredibly low in absolute dollars (for someone doing $50 million in revenue in a Miva store, a $2,500 per month license fee if they’re using 51 seats is very affordable and significantly less than they’d have to pay for any alternative platforms that could handle that level of volume).

In other words, we couldn’t have put through a “small” (say $10 or $20 per month price increase) across the board and solved the fundamental pricing problem we’re solving with this new model.

Why are you forcing me to pay for more and more new features I never asked for?

To put it simply, we’re not. If you choose to still use Miva as it primarily existed from 1997 – 2007 (as a catalog manager and checkout system), then you should rarely have a need for more than 1 simultaneous seat.

However if you choose to use the new features developed since 2007, everything from Order Management, Fulfillment Management, Reporting, CRM style features, Marketing/Merchandising features (and more) then (assuming this falls across multiple employees), you’ll end up paying for the use of these new feature sets.

It’s worth noting in almost all of the cases mentioned above, the ability to do these things natively within Miva often actually reduce dependencies and costs spent with other software.

It wasn’t long ago that to successfully run an ecommerce business you needed a shopping cart, order management software, shipping management software and reporting software, and at least a light CRM to do customer service. All of these things can now be done within only Miva without the additional cost of those other platforms.

Do I really have to pay for a seat for my Developer (or Module Developer) who needs access?

As of today, the answer is yes if that access has to be simultaneous, but we’re making some changes in the near term future (Q1 2015) that will change the way developers access Miva admins.

Once the new Certified Developer Program is rolled out, then the answer to this question depends on how often your developer needs to be in your backend and if they work on multiple Miva sites or not.

If your developer is essentially a full time (or near full time) employee or equivalent, then yes they’ll still need a seat, even with our new Certified Developer Program.

However for Miva developers who spend a small amount of time in a lot of different stores, we’ll be releasing this new Certified Developer Program that provides them a special license that doesn’t cause their user to be counted against the license seat counts.

However this special license will only be able to be used on any one store at any one time by any one browser to ensure it doesn’t become a tool to circumvent the new licensing model.

Do I have to pay for a seat for another product like Synchro or ShipWorks?

As of now, yes if you need those programs to operate simultaneously to someone being logged into the Miva admin. The fundamental reason this is true today is that Miva can’t easily tell the difference between a human being logged in and Synchro (or similar being logged in). So any program that mimics the process of logging in as a human will end up using a seat while it’s logged in.

We have added a mechanism in Version 9 that allows those programs to automatically log them out as soon as they’re done completing their actions. We’ve posted instructions for how to enable this auto-logout with Synchro and for other third party products you’ll need to contact them to see if they’ve made the adjustments necessary to support the auto-logout feature.

We are looking at the real world impact of this and considering adding the concept of an API user, however since most competing platforms charge a premium for plans that include API user access, we haven’t concluded if the current model (of API users taking up a seat) needs to be altered.

Why don’t you track actual minutes used per admin user and bill that way, this way if I have an employee who only logs in once in a while, I don’t have to buy them a whole seat?

Conceptually this is not an unreasonable request, but it’s overkill from an engineering standpoint and we don’t currently have enough data to price such a model appropriately to achieve our stated pricing goals.

If our pricing was on average many thousands of dollars per month, then we might consider the analysis and engineering overhead necessary to achieve such a discrete level of measurement, but at $600 per year, per seat, that low of a price point doesn’t justify that level of discrete control.

If you’d like to read a more free flowing stream of consciousness style history about Miva and our business model(s) please read this: Multi-Seat Pricing, Software-as-a-Service and the Decline of the “Hosting” Industry.