Hi WooCommerce, Jigoshop, Exchange and WP e-Commerce users, I’m here in the middle of week 2 of this development workshop and doing my best to build new Plugin functionality as discussed earlier, unfortunately I’m realising I have over-committed to delivering feature requests and new enhancements which while they benefit some users do not benefit the greater community.
This failure to manage support tickets and feature requests is eating into my dedicated development time here at this development workshop and has been a major conflict in reliably allocating development resources since I started developing and then maintaining WordPress Plugins.
I need your help and advice on how to resolve this as there are many suggestions to managing Plugin support requests but no easy fixes.
I do not want to sacrifice my speed to market for delivering new functionality or personal connection I have with new as well as long-established tickets (I recently saw a first support ticket from a customer in 2014!). Hearing directly from Plugin users allows me to deliver Plugin updates that I would never have considered and that directly affect store owners operations.
Some strategies going forward could include:
- build a support wall to reduce the volume of new tickets
- stop directly committing to new feature requests
Suggestion #1: Build a support wall
This strategy is employed by many major Plugin providers, that means:
- adding level-based suppport staff (I’ve tried this)
- introducing support subscriptions that expire (I haven’t tried this and am reluctant to)
- validating support tickets against license purchases (I haven’t tried this and am reluctant to)
- simply hide from difficult tickets (I’ve tried this, never ends well)
The con’s of this strategy are:
- instead of taking 30 seconds to type a quick resolution (e.g. a PHP snippet) it could takes hours to days to filter through support levels (L2: Basic, L3: Moderate, L4: Advanced)
- it would require employing dedicated support staff for each support level
- support subscriptions are a annual cost which I can’t personally chew so can’t see why my customers would
- checking valid support subscriptions against new tickets may hold back a few tickets but won’t make a significant difference
Suggestion #2: Stop being a yes man
This strategy means I will stop committing to new feature requests directly via Support.
Instead new feature requests as they come into Support would be added to a dedicated Trello board or bbPress board where conversations could develop, a link to these resources would be provided to the support ticket author to monitor progress of that feature request.
The con’s of this strategy means that Plugin customers requiring rapid deliverables would need to wait in line as feature requests are processed else consider funding the project if development resources are available (this would depend on the volume of open support issues). Currently I encourage customers requesting new functionality to ping me once a fortnight so their ticket floats to the surface within Zendesk but this is not a sustainable model and is frustrating to both Plugin customers who are WooCommerce integrators as well as myself.
I need your help
What do you think I should do?
As a first step I’ve internally set up separate Views in Zendesk to separate support issues from feature requests and pre-sales but this is just a cosmetic change, new support tickets are still streaming in and I’m doing my best to develop new functionality for Plugins while supporting you, my Plugin customers. Thanks for your time. 🙂