Making Amends for Business Decisions

I wish I had all the correct answers all the time. I wish I had all the correct business acumen all the time. Nevertheless, I am a fallen man prone to error.

I have been selling Soliloquy for about 16 months now. During that time, I have gone through 4 different pricing/support/upgrade structures. With that in mind, I am incredibly grateful and humbled that my customers have yet to abandon me.

Although I would like to think otherwise in my prideful state, I confess that I am not a perfect businessman. I learn new things each and every day, but often those lessons are learned through very real and sometimes painful mistakes.

Now that I am on the other side of my decisions, I believe I have some insight into how each model I choose worked, the flaws inherent in them, and the reasoning behind the final decision to switch back to what I (almost) originally started with: yearly support and upgrade fees.

1. Automatic Yearly Support and Upgrade Fees

When I first began selling Soliloquy in April 2012, my business model was that of automatic yearly support and upgrade fees. When you purchased the plugin, it created a recurring billing cycle in PayPal that would automatically bill you when the time to renew came around.

This model is not bad – it is actually very good. However, I absolutely sucked at marketing. There is something to be said about good marketing, and at that time I thought way too much like a developer and not a marketer. It was no wonder I wasn’t making as much as I thought I should, especially when I learned what other competitors in the same field were making.

In my flawed view, I thought that the yearly fee model was killing sales. While that may have been true for some, I’d guess that wasn’t true for the 95% of other folks. I didn’t understand that I wasn’t marketing my product well, so I thought  yearly fees was the reason behind the lack of sales. Somewhere around December of 2012, I killed off the yearly automatic updates/support and gave everyone lifetime updates and support.

What an incredibly stupid and costly mistake. Assuming an attrition rate of 50% (which is probably modest), I’ve already lost tens of thousands of dollars from renewals. Ouch.

2. Lifetime Updates and Support

When I switched over to lifetime updates and support, I also had a major catastrophe with the ecommerce plugin I was using – Cart66. That coupled with a sub-par PHP setup caused my I/O to run out the roof and got my account suspended for 6 days. Those 6 days were tough, but with hindsight being 20/20, it was an absolute blessing in disguise.

I implemented the design and marketing plan currently on the site, and it didn’t take long at all for my sales to quadruple in just a few months. I didn’t change the product at all. I did change the marketing behind it to appeal to the audience that really wanted the plugin – users. And that made all the difference.

However, I began to feel the heavy burden and weight of the idea of “lifetime support and updates”. I may have as well been holding up the white flag of surrender. The more I thought about it, the more stressful the situation became.

I was literally operating a software Ponzi scheme.

In a Ponzi scheme (typically in financial markets), you are constantly at the mercy of gaining new customers in order to support original customers. As your customer base grows, so does your need for attracting new customers. Everything is fine an dandy as long as both are running in parallel, but that never happens. There will always be a tipping point where your sales begins to flatline or decline, and that’s when the Ponzi scheme begins to break down. At this point, the scheme costs more than you can bring in, and you begin to bleed out the lifeblood of your business.

As more original customers begin to request things be done for you, the burden becomes increasingly harder and harder to sustain until it all collapses.

When was the last time you remember anyone coming out good in a failed Ponzi scheme? *crickets*

It made me sick when I began to think about the business I was running as a type of Ponzi scheme. Nobody wins in that situation. Nobody. If for a second you think that you are getting a deal because someone offered you lifetime support and updates, run. Run as fast as you can, lest you get caught in the rubble of an inevitable infrastructure failure. You will be left with degenerate and crippling software that nobody can update or support.

I had to change models and change fast, so I decided to go with a support ticket model.

3. Support Ticket Model

This model, in theory, is a great business model. In theory.

The support ticket model is one where customers receive lifetime updates for the product but pay for each support request they make. This lifts the burden off folks who never ask for support to the folks that do ask for support. This also ensures that anytime you provide support, you have already been paid for it.

Sounds great, right?

It’s not a bad model. I tried it for about 4 months successfully with Zendesk. It did what I intended it to do – drastically reduced support. If you are looking to reduce support, this is the way to go. This is also the way to create pissed off customers who won’t recommend your product to anyone.

This was an unforeseen consequence of the ticketing model. For starters, people cherish their tokens. You would think that a completely computer-generated, zero face value support token was a family heirloom. I would have people beg me to replace their support token because they insisted that my plugin was the problem, not their horrendously coded theme from ThemeForest.

I got a ton of mean and nasty emails from customers saying how they felt isolated and stuck with the plugin because they couldn’t get any extra help without forking out $9 for a token, half the price of the plugin itself. I thought to myself, “$9 is a steal! I charge $250/hour to do consulting – they are getting an incredible deal!”.

Customers don’t see it that way. They see it as a complete rip-off. I was living in a dream world when I thought they would see things my way.

Finally, the biggest unforeseen consequence (and the most damaging) is the fact that people absolutely will not recommend your product to friends and colleagues when they know that you will be nickeled-and-dimed for support. In fact, it makes customers resent you and your product, no matter how good it is.

Beyond this, let’s look at the monetary aspect. How much money did I make from people purchasing extra support tokens? $75. That’s it. $75 in 4 months. Phew – talk about busting at the seams with revenues! It absolutely did not make me any money as I thought.

So while it did reduce support, the negative consequences drastically outweigh the extra time I would use to provide support to happy, potentially raving customers who would promote my product everywhere. In this light, I probably lost money from all the sales I missed from word of mouth referrals. And I am completely serious about that last statement.

So for anyone who is thinking about using a support ticket model, do yourself and your customers a favor and don’t do it. If you are thinking about it but have never used it before, learn from my mistake. Don’t go down that road unless you just like knowing that you’ve got a lot of pissed off customers on the other line. It sounds great in theory but is flawed in practice.

I talked with a lot of other business folks about this model, too – business folks outside of the software world. They all looked at me like I was a crazy man. I now see why.

4. Optional Yearly Updates and Support

And so now, as of August 3, 2013, I have come full circle (almost) in my pricing/support/updates structure. I have grandfathered in all of my previous customers into lifetime updates and support, and all new customers will fall under the new, sustainable business model.

This model functions just like Gravity Forms. Carl and his team get it right with this model, and it is what I recommend to any new business person that is launching a product in the WordPress market. 

In this model, customers pay yearly for support and updates. This ensures that the product stays in active development because business owners are bound to customers by current and future profits. I have a responsibility to continue to develop and support Soliloquy because I have customers counting on and willingly paying for it.

However, unlike the first model, the upgrade and support fees are not automatic. They are manually initiated by the customer if they decide that it is the right path for them. If the customer is fine with the product and doesn’t need any extra support, then they can continue doing what they are doing without any worry of paying any fees. Because they aren’t (and can’t) request support, it doesn’t cost me anything to have them make that decision. It’s neutral for both of us, and that is the absolute best business outcome when you have stagnant customers.

This model ensures that customers who desire support and updates will in turn pay for the support and updates. That payment for the support and updates allows my business to be sustainable and scale as needed.

Well what about normal computer software like Photoshop? They don’t require you to pay yearly fees.

They also don’t mind leaving you in the dust when their next version of the same software hits the market 8 months later. If you are happy with the version you’ve got, cool. You don’t have to pay anything else, but don’t expect support forever. They will phase out the life cycle of the product and force you to upgrade (ehhhemm, paying a fee) in order to continue to receive support.

On Making Amends

With all of the changes I have made in my business models, I’m finally settled on the last one. I’ve had the fortune (and misfortune) of living through all of them, and I’ve experienced the good and bad of each. No model is perfect because no person or business is perfect, but the last model gives the best of both worlds to both customers and businesses alike.

My only regret is that I had to go through this at the expense of my customers. I am incredibly grateful that they would stick with me while I was making changes. Some left, but the overwhelming majority stuck with me through it all. I am floored and humbled that they would do this as they had every right to setup their slider foundation elsewhere.

I still remember the day when I got my first customer. I don’t ever want to lose that feeling. I don’t want to forget where I came from. It is because of the loyal customers that I am here today selling Soliloquy, and the change in my business model reflects my passion for making sure that I continue to create and foster a culture of loyal, raving customers.

Everyone makes mistakes – we are human. It is how we respond to them that sets us apart.

Enjoy? See Inside my WordPress Toolbox

Over 20,000 people have purchased my WordPress products. Get absolutely FREE access to regular updates and my toolbox - a collection of WordPress-related products and resources that every WordPress professional should own.

  • James Laws

    Great stuff and valuable lessons. We’re discussing our own options over here:

    That being said we are looking into a pay-per-ticket model with a slightly different angle. I think every ticket should be able to be submitted without a fee. Many times it might be something where we either need to fix a bug or simply improve our documentation. When not the case the ticket could be escalated to a paid support request. Of course all of this has to be properly disclosed and detailed so there is no confusion.

    I wonder of this would at all mitigate the unhappy customers that you describe since everyone can make their issue known and easily be responded to at no cost to the customer and in most cases little cost to us. It’s more of a hybrid between open support and your token based system. Thoughts?

    • griffinjt

      That’s definitely a better option than what I had implemented, but an issue I foresee will be nitpicking between what is a “bug”, what “should be included in documentation”, and what is actually qualified as a “paid request”. Unless you’ve got hard lines drawn, subjectivity is always going to favor paid support on your end and free support on their end.

      I still think you are going to struggle with customers being upset that they have to “pay” for support. From what I have learned, folks have been conditioned to expect “free” support, even if that support is not actually free. Although people pay a monthly fee for hosting and support, they only see the fee as for hosting because it is marketed to them as hosting. They perceive the support as free, and while perception isn’t reality, what they perceive is the driving force of what they feel, which is why I believe they will be upset when they have to pay for a response that they believe should be free.

      This was the case for me, and while your system does sound better and more refined, you still face the problem of customers not being happy with your product based totally on support, even if they pay and you provide a satisfactory solution. Here’s the conversation they will have:

      Potential customer: “What do you think about this plugin? Is it good?”

      Customer who had to pay for a support response: “The plugin is great, but I had to pay for extra support to get something working.”

      What potential customer hears: “Yikes. I’ve never used this plugin before. What if I get stuck and need help? I don’t want to be paying all these extra support fees.”

      That is hypothetical, but stick yourself in that situation. If you’ve just been required to pay for a support response you thought should be free, you are going to fail to mention to the potential customer that anyone can submit a support request free of charge because you still have a bitter taste in your mouth about having to pay to get your particular issue resolved. The potential customer isn’t going to hear that your product is awesome. They are going to hear that you have to pay for support if you need it.

      My suggestion would be to market your product in such a way that the yearly fee comes as an afterthought because of the idea of getting a solution RIGHT NOW is better than paying a yearly fee. Then you can completely win them over with head over heals support. That creates fanatical customers who are going to recommend your product for everyone. The yearly fee will just be an afterthought.

      That’s how Chick-fil-A works. Their prices are higher than most fast food restaurants, but all you want to talk about is how awesome the food is and how spectacular their service feels. That’s the type of customer base you want to foster – raving customers that talk about your product, no matter what the cost or fees. I don’t think you are going to create that culture with a ticket system.

    • James Laws

      Those are all valid points. We technically have a ticket system in place (I’m not a fan of forums) that is supper successful when it comes to managing tickets. We have a support subscription model currently but not used often so I see the benefit of tying updates and support together for that reason.

      That being said the requests that we get that are not simply point people to existing docs, should have a doc, or a bug that needs to be fixed any way are a lot less common. The reason I like the free submission of tickets is that these things should be corrected anyway and customer are helping us by reporting them. The other (less common) stuff is where we need to control costs.

      With so much of this I think it’s always about managing expectations and being extremely good at telling your story so that when the few naysayers tell it differently, most won’t believe it.

      But your hypothetical (but most definitely true) customer conversation does make a great point that has to be considered. Truth is that even a support subscription is unsustainable. What I mean by that is some users will purchase a subscription for say even $99 for the year and based on your current development rates one hour of support still constitutes a loss. Imagine 10 hours in the year, or 20. Neither is an unexpected amount of support for some customers.

      I guess my point is, when dealing with support, unless you are willing to take a loss you are always going to disappoint or upset someone (which is also a loss as you point out). At least with a pay-per-ticket option you are deciding where you are willing to take that loss. In the end I don’t think that a truly sustainable support model currently exists. I wonder if it ever will.

      • griffinjt

        I think tying in updates and support is good, too. It makes your product cohesive.

        Your support tickets could be different from mine, but issue discovery a lot of the time accounted for as much or more time than the solution itself. That can be costly in and of itself, and allowing anyone and everyone to submit tickets increases that cost, even if you can utilize things like macros and canned responses. With anything there is an opportunity cost, and it boils down to whether you believe the opportunity cost you are forgoing is less valuable than the service you are providing at the time. Through my experience, I believe the support ticket model has a higher opportunity cost, but again, my model was not exactly like yours. :-)

        I think in some regards it could be unsustainable, but not in the light you present. That loss is assuming that you could unilaterally replace the time spent supporting customers with time spent consulting at the rate you charge, and for anyone that has been in the consulting industry (like you and I), we know that is never the case. In a perfect world, yes, the model is unsustainable, but the world isn’t perfect. 😀 I believe there will be some customers you lose money on, but the number of customers where you make money far outweighs the other. And once you grow too large to maintain yourself, you can hire support staff, which are paid less than your consulting rate, so your profits continue to increase as the support burden from you is lifted.

        I completely agree with your last point. You are going to take a loss somewhere – there’s no way around that. Someone is always going to feel like they have gotten the short end of the stick. :-)

  • Susan Nelson

    Thank you for this post, Thomas. I am in the process of trying to figure out the best way to offer support and I appreciate hearing about your experience. Since I sell WP themes that don’t require licensing to work, I’m not sure of what might be the best support model.

    I only have one theme available at the moment, but will have several more in the near future. Support isn’t too time consuming for me right now, but I expect that to change when I add more themes to my collection. Currently, I offer free and unlimited support via a forum on my site, but I can definitely see how that could get out of control with more requests coming in.

    Do you have any thoughts about this type of situation?

    • griffinjt

      I think the same principles from above apply to your situation as well. There will eventually be a tipping point where the amount of support you provide outweighs the money you bring in, and it will cost you money to support those life long customers, eventually causing you to abandon the business model for something else or abandon the work altogether.

      A yearly support and updates fee for your themes would be a good place to start, and continue to wow customers with support so that they don’t think about the upgrade fee. :-)

      • Gary Jones

        I think there’s a key difference here though – your plugin can be updated automatically, where as most themes can’t, which means the benefit from general theme updates is seen as far less beneficial by the user, since they’ll have to do all the changes manually, or upload and re-apply all of their customisations.

        • griffinjt

          Good point. The support argument still applies, though, because folks are going to want support to make said customizations to their theme.

          • Susan Nelson

            I agree with Gary and was thinking about that point myself.

            I’ve been doing some more thinking this morning and looking around at how others handle it and now I’m wondering what you think about something like this… Offer free, basic support via a forum (covers set up and bugs only) and offer paid/priority support via email (or something) for advanced/customization issues.

            I don’t know if a membership-type set up would work for someone like me who is also selling my themes in other marketplaces like Etsy, Creative Market, etc.

          • griffinjt

            I guess that’s the trouble of selling in other places where you don’t have control over the support outcomes. Great for short-term sales, but not for longevity. If that is the case, free basic support is your best scenario at it will minimize the support cost on your end. Priority email support can be a differentiating factor for your yearly support fee and something you could market very well (as well as something like guaranteed response times, etc.).

          • Susan Nelson

            Thanks for your input, Thomas. I appreciate it!

  • Rebecca Gill

    I view this as being similar to parenting. You do the best you can, and when you know more, you do better.

    WordPress is evolving and maturing. As this occurs, we developers have to evolve too. I think the vast majority of us are trying to do this while still keeping our customers as our priority.

    I have always felt very supported by you and I know my clients who have purchased licenses have as well. If anything I feel I underpaid for my license and I owe you more and not less.

    • griffinjt

      That’s a good reference point for this. I wouldn’t know about parenting since I am not a parent yet, but it sounds like a similar learning curve. :-)

      I appreciate your kind words, Rebecca! Glad to have you as a customer!

  • Pingback: Good Business Ethics - |

  • Pingback: How Not to Sell Genesis Themes()

  • Pingback: Best Responsive WordPress Slider — Introducing Soliloquy Version 2()

  • Pingback: supplemental resources()

  • Pingback: A Case for Charging for Addon/Plugin Updates - Patrick Pohler()