When asked if product support is done in-house by the company who built the product, the easy answer appears to be yes, doesn’t it? I mean, why would you have it any other way?
More specifically, why would you have someone who doesn’t work for your company handle support for something you (or you and your team) built?
Sure, there are loopholes – a phrase I use loosely in this post – for this like hiring someone to work for your company who can be a dedicated resource to handling support of the product when they aren’t as familiar with the product.
But when that happens, I think the lack of experience shows when you start to get into slightly more complicated issues.
Last week, I asked: “Should WordPress product support be in-house?” And the short version of the conclusion to which I came is simple: Yes. It should be.
But the problem is that when something goes wrong with your product, the general end user doesn’t know if it was your work, the theme, WordPress, or the environment on which all of the software is running.
And if your product is the last thing the user installed, then you’re likely going to be the first person contacted. So let’s say you are running a theme or plugin or WordPress product shop, and your customer has a problem, but it’s not related to the work that you’ve done.
In other words, though you do (and arguably should) offer in-house product support, the problem isn’t related to your product at all.
Recently, I’ve been talking quite a bit about profiting from open source software, strategies for supporting WordPress plugins, and debating just how much to support to offer. To say that I’ve been exploring business models and support offerings for my plugins would be a bit of an understatement. Clearly, this has been something that’s been …
Continue reading “Support Doesn’t Scale (or “Avoid Free WordPress Support”)”
One of the challenges of providing solutions built on top of WordPress is handling expectations of support and documentation. I’m not talking about running a support forum or writing elaborate API documentation. Instead, I’m talking about providing instructions for how users can manage their site, application, or plugin once you’ve completed work on the project. …
Continue reading “On Offering WordPress Support and Documentation”
I’ve written at length about the dilemma of supporting WordPress plugins and looking at various support systems both of which generated some good discussion on offering WordPress plugin support. Over the past few months, I’ve been mapping out exactly where I want to take the direction of the work that I do on plugins (as well …
Continue reading “A New Version of WordPress Plugin Support”