Changes to Visser Labs Support

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:

  1. build a support wall to reduce the volume of new tickets
  2. 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. 🙂

2 thoughts on “Changes to Visser Labs Support

  1. New Trello boards are up (Support issues and Feature requests” as are new Zendesk triggers to try and auto-categorise incoming support issues from feature requests and pre-sales.

    I’m playing with Zendesk to Trello card integrations so Trello becomes my task list instead of taking the most recent support ticket and having to read and re-read ticket ticket notes (some ticket notes spanning multiple tickets). Getting there 😉

  2. I’m going ahead and splitting up the single “All Plugins” Trello board that I currently have into separate “Feature requests” and “Support issues”. From here I’ll connect new feature requests to a bbPress topic so public discussions can happen there.

    If required down the line I’ll add a private bbPress component by lock down access to specific bbPress topics so that I can request accept file attachments (e.g. Plugin files, import/export files), logins, etc. for detailed feature requests.

Leave a Comment

Before you comment - Do you have a support request? If so, this is not the right place to post it. Please submit support requests for Premium Plugins on the Support page and in the community Support Forums for free Plugins.

Your email address will not be published. Required fields are marked *