Charles is overweight, he’s a smoker, has poor eating habits and zero physical activity. His heart specialist (luckily he never had any serious issues) is one of the best in the world.
Kenny, on the other hand, is very careful about his diet, doesn’t smoke, exercises on regular basis and doesn’t have a heart specialist.
That’s all you know about them. Who do you think will have more health problems in the future? Who will live longer?
First step in making sure you don’t get poor customer support is making sure you won’t need support at all.
Conventional wisdom says you should check how well theme authors handle support requests before purchasing a theme. And that makes perfect sense. What makes even more sense is making sure you don’t need support.
Fanciest Author Box Case Study
About a month ago we added a new setting field to our Fanciest Author Box plugin. It simply allows users to change time of execution for function that adds author box to posts. I was against adding it for a long time, but majority of support requests we were getting had to do with that same issue.
Now that users can tweak the setting and make sure their theme doesn’t mess up and not display Fanciest Author Box (certain themes just love hijacking the_content filter) sometimes we go more than a week without a support request. Before the update, 3-4 users would have that same problem each week.
Huge change, one that allows us to focus on further improving Fanciest Author Box (more on that soon), instead of fixing that minor issue at users’ sites over and over again.
So, when making your decision, don’t go for fixable problems, go for no problems. Like Kenny, you’ll have less trouble.
Image credit: Fried Dough
These are all responsibilities of the theme author. For now I prefer to create a mailing list where only members are able to communicate with the author or even with the other members personally.
For free themes there’s always support on wordpress.org forum.
ah yes, support… the thing that takes 90% of all plugin development time (including coding it!)
even if your code is not broken but you still get support tickets about something, it’s a sure sign that you need to do something to prevent people from asking the same old questions…
well done for being proactive and fixing something that wasn’t broken :-)
Sometimes, there’s nothing that will prevent same old questions :)
Not even a FAQ page or readme file.