How to best provide support for the software you create is an interesting point of deliberation. I’ve gone through various stages and iterations, all different as circumstances have evolved, but all driven by the same question:

How can I create the best experience for the user in a way that is sustainable?

On a podcast a while back I said something to this effect:

Free support is only sustainable on either end of the spectrum. Either you have so many users that you’re able to well monetize them to the point that you have a dedicated support team tasked with making sure they are well cared for; or you have so few users that the drain on your time is negligible and can easily be handled along with other day-to-day tasks. The tricky stuff lies in the middle.

When I first started writing hacks for b2 and plugins and themes for WordPress, my life looked a lot different than it does now. I had a day job which paid all my bills, a wife that also worked long hours, and the work I did on my own site was what generated most of the code I released to the community.

The community was also much smaller and had a different profile back then. A handful of hackers that would use each other’s code, send each other suggestions, and generally collaborate as peers.

Nowdays the profile of the average WordPress user is far different. WordPress has become a tool for business users that do not need to have technical experience to make WordPress work for them. This is awesome, but it fundamentally changes the nature of the support requests I see.

My station in life has changed quite a bit too. I have a daughter, I run a great team of 15 people and I’m dealing with some medical issues. I don’t have the time that I used to, and what time I do have I’d rather spend building something than responding to emails.

How I¹ handle support today is to break it down into two types of support:

1. User Support
2. Product Support

With User Support, we provide one-on-one attention and do our best to solve whatever issues the user might be experiencing. This can even extend to troubleshooting plugin conflicts and server configuration issues. We reserve this level of support for our paid products (RAMP, Carrington Build, etc.).

For our free products, we provide Product Support. This means we listen and pay attention to bug reports and try to fix anything that appears to have a reproducible use case. However we do not provide one-on-one support for users and do not dive deeply into one-off reports of edge cases.

I feel that this is a reasonable compromise, and I believe that most of the users of my products agree. There will always be people who believe they can make unreasonable demands on your time, but luckily there’s a handy button on those emails (or even voicemails, yikes!) for resolving them with minimal effort.

---

A few years back I had the idea that the collective support burden on WordPress plugin developers had grown to the point that we should all outsource it to a 3rd party. To support this, I created WP HelpCenter and tried to partner with plugin and theme developers through a referral program.

This ended up being a flop, for a few reasons. The main on was users that actually needed support were typically unwilling to pay for it. From their perspective the plugin/theme wasn’t working and they were doing the developer a favor by reporting a bug. They certainly weren’t going to pay anything for it. What users are willing to pay for is customization, and that’s an entirely different beast.

I still think something like WP HelpCenter could work, but it would be a lot of work and would need real buy-in from all parts of the community.

This post is part of the following projects: Carrington Build, WP HelpCenter, RAMP. View the project timelines for more context on this post.