A couple of "disclaimers" first:
That all being said, here we go:
- 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".
- I'm a bit lazy tonight so anywhere you see C/E that means "call(ing)/email(ing)".
- All of these things aside, I do honestly like my job, but every so often I have to let off a little steam. :)
- 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