With WooCart we’re trying to significantly simplify the building and maintenance of WooCommerce stores. We’re managed hosting at the core but we do a lot more for WooCommerce users than any other host.
We had three goals with pricing: simple, fair and easy to understand.
We’ve gone through three versions of pricing in the last couple of months, trying to find the best one. In this blog post, I’ll cover our journey and why we’ve decided on Resource-Based Pricing in the end.
Launch: Visitor-Based Pricing
After doing initial research, we saw users and hosts are used to visitor-based plans and it looked like the best option by far. All of the leading WordPress managed hosts do it, and it’s easy for the user to understand. At least in theory.
So we launched with visitor-based pricing.
We quickly found that the theory differed from reality. It’s very hard to quickly explain to the user why the number of visits in the hosting dashboard will never look like the one in Google Analytics. There are a lot of reasons why this happens: from plugin auto-pings to brute-force attempts, scraping bots and many other things.
Whatever impacts the resources of your server needs to be counted, but GA just counts actual visitors to the site. The user would not be happy seeing 50,000 visits in the hosting dashboard while GA showed half or even less than that.
We had multiple emails from our users requesting a detailed explanation, and we saw people on Facebook confused by other host’s visits dashboard as well. All of this made us question the decision. We were still at the very beginning and we needed to get the fundamentals right.
After some discussions in the company and with people in the industry, we decided we should move to order-based pricing.
Iteration: Order-Based Pricing
We’re store-focused so why not make it order-based? It makes it simple for users to understand and it fits our goals. Larger stores pay more and get more resources which sounds completely reasonable. Again, at least in theory.
The problem became when we started to see the large differences in resource usage independent of the number of orders.
There were stores making 1000+ orders per month on what was our smallest plan, without any performance issues. The stores were running fast because they were simple. But then some users had stores with 70+ plugins, a complex theme, but no orders and they needed two plans larger resources.
We needed to add a disclaimer to the pricing page that if you have a very complex store, the smallest plan will not be enough, no matter the order number.
Which meant we had a Resource-Based Pricing if you went above the resources for your plan, but Order-Based Pricing if you went above the orders for your plan. That did not sit well with us. Our users would feel we’d penalize them for success while we’d still charge them for resources when they crossed them.
The last nail in the coffin of this pricing were two strong-worded comments on FB:
Ouch! Those are not the associations we want our potential users to have with our pricing. We needed to seriously rethink our pricing.
Final Version: Resource-Based Pricing
We tried to avoid it but we started considering Resource-Based Pricing again.
We revisited our research and found we have one major advantage over the competitors charging per visit – we do not run shared resources. That means we can provide pricing based on CPU and RAM usage, not just disk and bandwidth or some other nontransparent metric.
We also wanted to get the pulse on our existing users, and the WooCommerce FB community so we created a short survey.
The results showed the majority of people prefer resource-based pricing, a large part order-based, and only a small minority visit-based, which was surprising.
It sounded very promising for our new plan. We decided we’ll change the pricing to resource-based that same week.
We chose to add visits as a guideline to the pricing page. We hide the technical details of the plans in the pricing boxes, but show them under the FAQ. This way we don’t confuse beginner users, while still giving details to advanced users.
We also make usage very transparent: we show CPU, Memory, and Disk usage in the Server Metrics. We also show memory usage per plugin under Plugin Metrics so the users know exactly what the culprit is. This means they have the tools to understand what uses memory and can work to lower it if they choose to do so.
While Resource-Based Pricing is not as simple as visits pricing is in theory, in practice, it’s by far the fairest to the user, and very transparent.
Pricing is one of the hardest problems a SaaS company faces. If done wrong, it can prevent users from signing up and even trying the service (as seen from FB comments above). We think we’ve gotten as close as possible to ideal pricing for our use case.