Freemium WordPress Developers: Should You Provide Support for Your Free Plugin?

There’s no denying it: WordPress plugin support can be a real time suck. For particularly popular plugins with lots of users, support can stretch into hours-long sessions. With that in mind, can you really justify offering free support for a free plugin?

Let’s face it: if you could provide free support without fear of hours spent unpaid, you would. The trick is to make providing free support work for you and your plugin, at the same time as helping your plugin’s users.

That’s exactly what we’re going to cover in this post.

Even Young Plugins Need Support

It’s tempting to suggest that of all stages in a plugin’s public life, the part just after release is the point where it’s least likely to need support. Of course, with only a few users at the beginning, the support won’t take a lot of time to provide, but it might not seem worth establishing a precedent of free support for so few users.

But on the contrary, it’s the perfect time to take full advantage of offering support in such a way that it benefits you as well as keeping your first users loyal. Getting used to giving the most effective support – for both you and the user – at this point will enable you to cope when your plugin is more widely used.

Providing free support at this stage can be useful for myriad reasons. Firstly, in the early days, support requests are going to provide you with lots of feedback. People will soon let you know if they need something, and you’ll start to see patterns emerging in the support tickets for areas that need improvement.

Meanwhile, you’ll be establishing a dialogue with your users (and potential future clients) who might – and you can ask, subtly – be willing to give your plugin a good review on the Plugin Directory.

ratings-plugin-directory

Especially in the early days of your plugin, these reviews will be fantastically important to you. Building rapport and being seen as friendly will enhance the reputation of your plugin too!

You’ll discover how people use your plugin; often in ways that you wouldn’t have imagined. This can help you to brainstorm, prioritize and implement new and/or improved features.

Keep Supporting Mature Plugins

It’s not just in those halcyon days after your plugin first comes out that free support is advantageous for you as well as your users.

Once you’ve developed more advanced features (based on that initial feedback, no doubt!) it’s likely you’ll be running a “freemium” system, where basic functionality is free, but clients can buy licenses to extend the functionality. It’s important to keep your paying customers happy, as they’ll be paying you well for the time you dedicate to their support.

However, you should still keep a level of support available for free users: they may well be encouraged to pay for your services if they receive a great experience with your support.

Making Support Work for You and Your Plugin

As I’ve said, free support should be provided such that it benefits you, your plugin, and your users. Therefore, you should always bear in mind that time spent on support takes time out of development and other directly money-making activities. In business, the 80/20 rule is very important.

Many of your users will require basic support and their requests won’t take too much time. For the more time-consuming, serial requesters for support, you need to learn to manage your time. When you release paid-for features including additional support, it might be an idea to politely but firmly encourage these users to upgrade, lest they find you unable to process all their requests.

Meanwhile, many support requests might be feature requests or customization jobs. If a client wants you to make an extra feature for them, you’re justified in wanting to make money from that work. In fact, if you can make a customized feature and adapt it for release in the main product, you’ve saved yourself some time and been paid extra for it! Converting these support requests into payment opportunities will ensure that you recoup some of the hours you put into providing top-quality support free of charge.

A further point to consider when providing free support is what sort of return you’ll make on your efforts. Coding a whole set of new features for one user under the premise of “free support” will be a waste of your time and money (because time is money!). However, if you’re answering some questions on features for a client thinking of buying your premium version, you’ve created a situation where you have direct influence over a client’s purchasing decision. This is what availability through free support can do for you.

Finally, the different forms support can take are worth bearing in mind. For common questions, creating a public FAQ can be useful.

public-faq-ratings-widget

The public FAQ for Rating-Widget.

Email or live chat support is also worth differentiating between; you should use whichever system(s) enables you to manage your workflow most effectively.

Conclusion

As you can see, support makes free plugins better: users (or later on, clients), the plugin itself, and ultimately you and your bank balance can benefit from providing basic levels of support, maintaining contact and building rapport. You can make more money and develop more desirable features, creating premium versions of your product while using feedback to polish and refine it.

With any luck, you’ll be able to put these practical steps into place to improve the way your plugin works for you. Even if you have a long-standing plugin and haven’t provided support up until now, you should consider implementing free support to see if it can also benefit you. All that remains is to wish you the best of luck in building your plugin’s reputation and value for everyone involved!

If you have any tips or tricks on managing your plugins, support and workflow, feel free to contribute your insights in the comments!

2 comments

  1. I think you definitely need to offer some support of any plugin you release for free in the WordPress Plugin Directory – but you can and should limit the range of support offered.

    The first step to a successful freemium plugin is generally a widely successful free version. One of the things you almost certainly need to get to that point is to help any users who, for any reason (including their not reading the documentation etc.), have problems using your plugin. This is particulary important in the early days when the plugin is establishing its creditability and reputation amongst WordPress users.

    Unfortunately some novice WordPress users will post support requests heavily criticising your plugin when the problem is nothing to do with your plugin, but rather their lack of skill and experience with WordPress.

    A plugin author needs to answer any such posts in way that makes clear to others reading the post where the problem actually lies. It’s important to do this in a way that does not attack or criticise the user but nevertheless clearly and professionally refutes the users unjustified criticism.

    Also experienced WordPress users, when discovering your plugin, will often check to see if you have a high resolved rate in the plugin’s Support Forum. They will also often scan & read the forum to get a feel for both potential problems with the plugin and the level of support offered.

    But if part of your freemuim business model is to offer premium support to paying customers, you also need to spell out clearly what level of support you offer in the WordPress Support Forum.

    While deciding what level that should be is as important as deciding on the price for your premium offer, what’s much more important is being clear and upfront about that decision and sticking to it.

     
    1. Criticising your plugin when the problem is nothing to do with it, is a very common case. As you mentioned, even though it’s very tempting to criticize back – you must stay positive and professional.

       

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>