Last week – and this weekend – I’ve been reading the comments on Pippin Williamson’s posts about his company’s decision to adjust prices on Easy Digital Downloads (and for those who are curious, I applaud it).
That’s a conversation in and of itself, and there’s a long comment thread that I think is worth reading for anyone involved in WordPess product development, but I digress as that’s the point of this post.
Some readers have left comments throughout the comment feed discussing the notion of community-based support forums. The whole thread is worth a read but:
- EDD used to offer community-based support forums (in addition to their other support),
- I’ve built and worked on products that had community-based support forums
And, in retrospect, I absolutely do not think it’s a wise decision for a WordPress-based product shop to offer them. I have my reasons, I’ll elaborate, but I want to be clear that I’m constraining this strict to WordPress because it’s what I know.
I can’t speak for any other segments of our industry.
Community-Based Support Forums
Years ago, I worked with a great team, and we built a solid product, and I’m still proud of the work we did. During that time, one of the things that we initially offer were community-based support forums.
At first, it seemed to make sense: When we were not answering support tickets (which was something that was happening more often than not – just ask Chris or Michael), others were helping one another out in the forums.
It seems like a win-win, right? You have your customers helping other customers, and you have your team helping customers with larger problems.
In an ideal situation, this is how it may pan out. But the world is not an ideal situation and, thus, neither is the nature of community-based support forums.
So, naturally, this raises a question: What’s wrong with community-based support forums?
What Really Happens In The Forums
When you have people helping people try to solve a problem with a paid product that provides support, and the support is coming from someone other than the vendor, then you’re looking at people who:
- don’t know how the product was built,
- might be providing solutions from a place of less experience than you or you and your team of developers,
- may be provided simply wrong answers from lack of experience.
So look at it this way: You have a product that you or you and a team have built. It’s been tested, evaluated, tested, evaluated, deployed, and sales are rolling along.
Then someone encounters a problem or a bug. They’ve purchased support, so they submit a ticket which puts the in a queue of indeterminable length. They don’t hear back as fast as they like, so they ask someone in the forums. They get a response, they modify the core code, it works, so they are happy.
Then you or your team gets back to their original support question, and they’ve found a legitimate bug. That’s great because it allows you to increase the quality of your software.
But they’ve changed the core code so whatever solution you offer is likely to be met with “Thanks, but I’ve gotten it resolved.”
But it’s resolved all wrong.
And depending on the nature of what you’re selling, this could introduce security bugs or other problems of which you’re simply not aware until you can diagnose the problem.
Now, though, you have to ask the user what they did to fix their problem, audit that code, then you have audit your code.
Ultimately, what does this do?
- Users helping users can produce incorrect solutions,
- Users helping users can generate more or longer support requests than necessary,
- The business is potentially taxed with more work than necessary to fix a bug or add a feature.
- And more.
Now I’m not one to try to layout a problem and then not provide a solution; however, I can’t provide a solution for all businesses. Who can? I don’t know the model; I don’t know the mode of operation, I don’t know the structure, I don’t know a lot of things.
One Way To Address This
But what I do know is that community-based support forums can generate more problems than not even though it sounds like an advantage and a selling point from the outset.
Being on the other side of this can change that perspective, though.
So the way I’d approach this problem is like this:
- Support is done on a one-to-one basis. Customers submit their support tickets to the problem team through an application like HelpScout and then receive 1-on-1 support from the team.
- Respond Immediately (Sort of). Let the customer know that they’re ticket is in line to be addressed but there is a backlog, and you’re working to get to it ASAP.
- Triage & Prioritize. Sometimes, however, it’s necessary to triage tickets via importance. Don’t be afraid to do this depending on the nature of a ticket.
- Share The Problem. This is optional but if you’re not going to have community-based support forums, then offer to share fixes, updates, and so on through a blog.
Again, this is just how I’d address it based on my experience, but it’s not necessarily the way to do it.
If you’re opting not to use community-based support forums, though, this is a potential way to handle opting not to use one.
So Use Them or Not?
For those who might be entertaining the idea of it, I hope this post provides enough insights to give you pause about introducing them.
I’m not saying they are always a bad idea, but I’m saying that there are some serious considerations to make because you may ultimately be causing you and your team more support tickets than necessary.