In August 2016 I left my job to create Metorik, an analytics and email automation tool for eCommerce stores. Here I'll share Metorik's journey with you, providing an intimate look into what goes on at Metorik from start to who knows.
- Bryce (@bryceadams)
Nov 15th, 2017
Very quickly after Metorik went live, I had my first customer with more than one store sign up.
In their case, they had a few different brands, each with their own WooCommerce store, customers, orders, etc. So they added each store to Metorik, started their trial, and when the trial ended and they wanted to sign up, they had questions:
Do I need to subscribe each store separately?
If so, is there any discount?
And if so, what about in the future when I add more stores - should I contact you for another discount?
It was soon pretty obvious this was a problem that needed to be solved. I identified a few different customer groups the 'one subscription per store' structure hurt:
Customers with more than one brand and a store for each.
Customers with a seperate 'wholesale' sale store.
Agencies who wanted to sign up all their clients (and pay for them).
With each of these customers, I was able to chat with them, calculate their average monthly orders across all their stores, and offer them a discount.
But over time, I found that I needed to keep an eye on all these customers and make sure they were still getting the right discount and not over-paying or under-paying. Additionally, there were likely some new users who fit one of the customer groups above but never reached out and maybe didn't even subscribe to Metorik because they weren't sure what to do.
I acknowledged this problem around May/June this year, but only recently figured out and implemented a solution for it. That solution was developed in September and went live at the start of October. I blogged a bit about it here, but thought it may be interested to talk a little bit about the process here on the Behind the Scenes blog.
When I built Metorik, I had a concept of 'stores'. Each 'store' had its own:
Store connection + data
The store connection, its data, team members, and settings, didn't need to be shared across multiple 'stores'. But the billing - that's where my problem existed.
So I came up with the concept of 'companies'. The plan was to handle the billing on a company level, and leave everything else at the store level, with a company 'owning' all of the stores.
One of the harder parts about this was actually just deciding what to call 'companies'. I had a few different ideas: 'Teams', 'Agencies', 'Groups', but they all felt a bit ambiguous or misleading. I ended up going with companies since it seemed to be the least ambiguous.
While making this change, I had to make a few other additions to Metorik in order for it to work:
Allow multiple users to be an 'admin' of a store.
The ability to delete stores yourself.
The ability to transfer complete ownership of a company to another user.
Since this was such a big change, I had to communicate it to existing customers. At the same time, I didn't want to waste the time and attention of my customers if it wasn't relevant for them. So I put together a list of customers who had 2 or more stores and emailed them directly to let them know about the change. Behind the scenes, I switched over every store to a company, and then grouped stores into single companies for those with more than one.
Since the new system automatically gave users the cheapest price for all their stores, while my discounting system before was manual and not very accurate, I actually took a hit to my MRR. I'm not certain how much, but I'm guessing it was around $400/month. Long-term, I'm not too concerned as now:
It's cheaper for my customers.
It's easier for them to add more stores.
I'll make up the loss over time as they grow and move into higher billing levels based on their combined store order volume.
And most importantly, it should help my customers succeed with Metorik and run all of their stores (or their clients' stores) more efficiently and effectively. That's a win for me.