What you can expect with support

27 Apr 2011 · by David DeSandro

Just yesterday, Mr. Angel Marino pinged me for some help via the Isotope GitHub issue tracker. Most support requests come to me via the email mechanism I put in place with the support license. I recommend that customers looking for support to use email over GitHub issues or Twitter for the sake of confidentiality.

In this case, I got the impression that Angel was comfortable with openness, so now I have a good example of a typical support request process.

Here's how it went down.

Most importantly, he provided a live URL for me to look at. This is required for debugging. With that I got to work, running through my support routine.

  • Basic diagnostics. Making sure there are no JS errors and that the Isotope script is properly linked.
  • I then save a copy of the page locally and start developing on it.
  • Diagnose the problem. Revise any custom scripts. Resolve the problem.
  • Revise the script for best practices.
  • I then FTP my local copy to a publicly-viewable URL, so the customer can at least witness that it works.
  • Follow up with a response, pointing to the revised script I wrote.

When it comes to how I approach support, I'm trying to be as fair as I can with my customers and with myself. I realize implementing Isotope isn't as easy as most plugins. Naturally, there are going to be issues ran into by users with all levels of expertise. If you're paying to use Isotope, there's some accountability on my part.

But that's not to say that I am going to bend over backwards to resolve every issue that comes my way. I haven't put any sort of service-levels or promises up-front for a reason. Personally debugging others' issues can be especially time consuming, even for simpler implementations. I've priced the licenses so that I am rewarded for the work I put into the plugins, but also low enough that potential customers don't feel ripped off if I can't resolve their issue.

Support is still the trickiest part of running this business. I want my plugins to be used and enjoyed in a variety of implementations. I want my customers to get the best support possible, which is why I put my own personal time on the line, rather than recommending Stack Overflow or tweeting for help. But this comes at the cost of time, which the most expensive commodity I have to offer.