If you build any kind of software that gets used by anyone but yourself, one of the first things you learn is that support usually eats way more time than actual work. It’s somewhat of a depressing discovery, and usually a lesson you learn a number of hard ways. All isn’t lost though, there’s a ton to glean from this realization, most of which results in much better output from you.
Most of the difficulty with software support begins with the original ticket itself. We’ve all been in the boat before, we don’t step back and look at our issue, instead submitting a ticket as though the developer was sitting next to us the whole time, recognizing all of the environmental variables in place.
“Feature X is broken, do you know how I can fix it?”
It didn’t take me long to start going above and beyond when submitting crash reports, support tickets, or discussing an issue with someone in person. The more useful information I’m able to provide the faster my issue gets solved, a byproduct of which is taking the least bit of time from the developer. Yes, if you’re paying for support the developer has offered their time to you, but there’s a fine line between being a customer and being a parasite.
I hardly ever use canned responses, but I keep a select few handy for software support. Take some extra time to make sure you’re including as much detail as you would need should you be receiving any support request you type out.