We made a mistake.
When our free package put strain on our support and infrastructure. “Drop it!” seemed like the only solution.
A few months later, having been bitten in the a$$, I have to admit… we got it wrong.
The happy days
We initially chose a freemium model for SnapBill. As a bootstrapped startup, armed with our minimum viable product, we believed getting users on board would allow us to see how the product was used and guide development. Indeed it did 🙂 and they were happy days.
In the beginning we didn’t believe we had a product worth paying for (at least not for our smaller users.) After a while though, even with a whole host of paying clients, the free package began taking a toll on operations.
Rather than following the KISS (Keep It Simple) ideal, we decided to risk doing something Stupid and rather focus on flexibility. It was a calculated decision.
After speaking to a number of clients the general consensus was that most were frustrated with the limitations of their current billing system. Everyone has their own idea of exactly how a billing system should function and many were unhappy with the “Sorry, no.” they received when they requested changes. We strive to say “we’ll make a plan” more often, but it requires a very careful balance.
This focus on flexibility resulted in one obvious issue… a complicated system. Not offering support to free users simply wasn’t an option and the support load quickly became too much for us to deal with.
We weren’t ready, panicked and decided to scrap our beloved free package.
Causality
Dropping the free package resulted in a massive drop in new signups.
We had expected a drop in signups followed by growth at a new rate, but alas, it hit us worse than expected. New signups plummeted and continued on a downward trend…
As time went on we could clearly see that new registrations weren’t just a fraction of what they had been before, but word of mouth referrals had by then also slowed down significantly.
The negative effect had taken its toll and only by December did growth kick off again, albeit at a much slower rate.
Trial and error
As we dropped the free package we decided to implement a 14-day trial. This wasn’t as well thought out as it should have been.
As a recurring invoicing solution you only begin to see our value when invoices get sent out automatically. This usually happens a month after you first invoice, so at the fourteen day mark – we haven’t shown you any value.
Not only were our signups down, but our conversions took a knock too.
We subsequently said our goodbyes to the 14-day trial. Replacing it with the, new and “improved”, 60-day trial.
Headless chicken
At the time we truly believed it was a step in the right direction. In actual fact we were just running around like headless chickens trying anything in the hope that something would restore our mojo.
We kept monitoring intently, but with a 60-day trial it takes a lot longer to get any results. We were forced to endure two months of pondering before any useful data surfaced.
When the results started coming through, they weren’t pretty. Even with our conversion optimizations and startup guides (A-B testing showed they were helping)… we were still receiving significantly less signups and conversions than before we had dropped the free package.
The white light
We decided to take a step back and try see if there was anything else we were missing (spoiler alert – there was).
We initially billed our users based on a per-client model. This didn’t really fit in with their usage of our system and the value we brought to our users. This design clearly excluded users who had hundreds of clients of which only a few were actively being invoiced.
There were also a large number of free users getting significantly more value out of our system, but since they only had a small number of clients there was no requirement for them to ever upgrade. These also happened to be the users causing the most load on our support team.
After speaking to our clients, our decision to switch to a per-invoice billing model, had already made noticeable improvements in the short time the change has been live.
Conclusion
Be extremely careful when deciding to change something that works. Often it’s not possible to test the reaction to a change, but deciding beforehand which metrics to monitor can make all the difference. If changing something clearly made the situation worse, it is always possible to change your mind. Re-introducing freemium quickly restored our numbers, though probably at a lower point than if we had left it out the entire time.
We had a stark reminder of the “no free lunch” rule. We understood the toll a free user would take on our system load, but we severely underestimated the cost to support those users. We followed that up by underestimating the value of being in contact with potential clients brings. Having quality support from the founders, early on, helped us establish a good relationship with the community. This helped us understand exactly where there was room for our new product to fit in. It also got our clients excited about our business and a large proportion of our paying user base, today, has come from those referrals.
In the end we changed our mind, and here’s to hoping happier days lie ahead.