Sunday, January 25, 2015

Some Tech Support Gripes...

I normally don't talk about my job much here, other than the fact that they didn't handle the revelation that I was a Trans-woman very well.  That being said, I'm going to make an exception and do so here.  Without getting into too many details, I work remotely for a small software company.  It's a very small company and as such I do a little bit of a lot of different things.  Among them are second level support, documentation, some development, installation packaging, re-seller training, as well as managing things like our Exchange server and the like.  A great deal of that isn't really what I was hired for, but working at a small company you adapt and I do like my job and other than the issue above, I do like my boss.  We sell our software via re-sellers and not direct to end-users and as such our support is limited to those re-sellers and they are responsible for supporting their end-users direct.  As with anything some of those re-sellers have better people than others, so here are a few things that just drive me up a wall.

A couple of "disclaimers" first:

  1. Now keep in mind, that I was hired away from one of our re-sellers so I spent several years doing that job and must have done it well as not only were my own customers happy, the re-seller made a huge issue about me leaving, and my current company felt it was worth it to hire me away and deal with the aforementioned issue that it caused, so I've "walked the talk".
  2.  I'm a bit lazy tonight so anywhere you see C/E that means "call(ing)/email(ing)".
  3.  All of these things aside, I do honestly like my job, but every so often I have to let off a little steam. :)
 That all being said, here we go:

  • Is it really asking too much for those providing first level support to actually be able to convey the problem, including any error messages?  Nothing quite like getting a C/E and the person contacting us has no idea what the issue really is.
  • On that note, as first level support, how about actually at least making an effort to duplicate the problem and troubleshoot it before C/E us for support.  Maybe it's different elsewhere, but that is the expectation our company has and one that I always followed.
  • If you have to legitimately C/E for support, how about having somebody familiar with our product doing so?  Part of our re-seller agreements is that we are only supposed to take calls from people we have trained.  Now we're pretty flexible on that as for the most part a trained person can share enough knowledge with others to handle most support, but nothing like trying to help somebody who has C/E and they don't even know how to sign into the product and navigate their way around in it.
  • If you are going to C/E about an issue and you aren't on the current maintenance release - or even worse not on the current version - or worse than that, on a version that is several versions back - how about checking the Readme's to see if the issue is fixed first?
  • If you are doing to upload a database for us to troubleshoot/duplicate something, how about not using something standard like .ZIP or even .RAR to compress things with and not the "flavor of the day" file compression tool?
  • And how about providing login information with the database?  
  • I understand some people are more likely to be willing to be beta test sites than others, but as re-sellers, how about at least downloading the beta of a new version and spending at least a few minutes looking over it and the readme/documentation?  It's really frustrating to take C/E from re-sellers who don't do that and then come to me with end-users complaining about the way something does/doesn't work.  I've had the same one do it twice this week for two different sites.  They just upgraded them to a version that is 2+ years old and some things have changed.  Well, now that the version in question is 2+ years old, some things just aren't going to be changed since so many others are accustomed to them.  
  • If you open up a support call and a fix/workaround/patch is provided, how about letting us know when you put it in place and if it took care of the issue.
  • Speaking of the documentation from above, how about actually checking there every so often.  You might be surprised what you find and it might well save you a C/E and make you look a touch smarter with YOUR customer.
I could go on and on, but I think I've just about got most of this out of my system now.  As always thanks for reading. :)

- M

No comments:

Post a Comment