"When you decide to call tech support?"
The optimal answer (IMO) is when you have a solid grasp of what's going on (and this could start a whole new topic on techs that don't understand fundamentals getting in over their head and expecting a tech support line to bail them out of what is really an install 101 issue).
So, call tech support when you are somewhere along the lines of having a problem that is reproducable, and where the "basics" have been covered (PC has been rebooted, failed software install was re-attempted at least once, wiring and connections were double checked, substitutions have been made where appropriate (eg: if the FIRST camera you are trying to bring up on a NEW LAN and a freshly installed PC is not working, try a 2nd camera before calling the first one "faulty" to see if the problem is happening across all cameras (so then, probably NOT an issue with any one specific camera), etc.).
Basically, everything is most efficient when the tech calls up support and you don't have to cover the basics or obvious stuff, and there is enough data to ensure that you are most likely troubleshooting the right components and not chasing a false issue).
I'm sure this will be a good discussion though.
It depends on whether I'm the one making the call, or taking it ;)
IPVMU Certified | 05/09/13 12:09pm
If the problem has no explanation I can find though I believe firmly it should work based on my knowledge and experiance, I'll give documentation a cursory look and then I'll call support. If it's something more out of my experiance or expertise, I feel obliged to more thoroughly check documentation first. But if the problem is a basic operation one and is a single sentance buried on page 97 of the manual and runs counter-intuitive to the way I, or 90% of the rest of the world would expect, then I don't feel bad about "bothering" support.
Perfect example, a single port ethernet extender we used for the first time last yeat that is PoE powered, and passes through the PoE power. We tried using it to make a switch hub-to-switch hub conneciton, but apparently it doesn't work unless there is an actual PoE load on the other end, like a PoE powered camera. Turns out they did have something in small print about it on the website, but it was small print (they've since made it bigger) and it runs totally counter to how I and many others I think would expect for it to work. So I did not feel bad about calling tech support on that one.
"having a problem that is reproducable" - The Holy Grail of Tech Support Requirements
As a long time support guy, nothing is more annoying/pointless than trying to solve a problem that is not reproducable on demand.
Luis, if any manufacturer has a component issue such as you described, it is in their own best interest to overtly provide the anomalous information... i.e. up-front message on the support wait line, 1st FAQ listed, etc. And most will, simply to avoid all the people like yourself who will invariably call when presented with a scenario that leads to erroneous conclusions based on prior experience/knowledge.
Define 'reproducable'. Does that mean I can make it reoccur on the same machine / setup more than once? Or does that mean I need to reproduce it on another machine (PC, camera, etc.)?
Btw, I second Brian K's point about doing the basics above (rebooting, checking connections, etc.).
Reproducable: You report that every time you 'X', then 'Y' happens.
Non-Reproducable (consistently): You report that 'sometimes' when you 'X', then 'Y' might happen..... or, sometimes X happens all by itself (but it's not doing it 'now')
The cause of reproducable actions can be determined by isolating devices 1 by 1 until you find the problem (starting with the most 'probable' first). With non-reproducable actions you are left to your 'best guess' based on past similar issues.
All good support people have a bit of 'detective' in the fabric of their nature...
Fortune tellers (guessers) generally do not make good support people... :)
But how many times do you expect me to reproduce it? Let's say a VMS fails to export a file. If I try it twice and it fails both times is that good enough? Do I need to try it from a different PC? Different cameras? Change the export length?
I think most of those choices are logical steps that all should be taken before you call support. But as a support person, I would not get annoyed if you hadn't tried all the logical troubleshooting steps.... that's what support people are for.
Every end user/integrator has their own strengths and weaknesses - just like all support people do. If the end user/integrator has not done all of the logical troubleshooting steps before they call, they are most likely going to have to do them anyway once they call support, so it's good practice to try these 'logical' steps before calling for support.
However, I think the demarcation line when determining whether or not to involve support is pretty clear:
If your question starts with "How do I..." then you should not be calling support. Anything else is fair game. :)
"If your question starts with "How do I..." then you should not be calling support."
I certainly agree if it's something simple, like "How do I add a camera?" or "Where do I change the frame rate?"
Often, there are issues like "I want to do X" where X is some form of advanced feature or atypical use case. Are you saying I am supposed to call an SE then? Or?
Yes. Or a manufacturers rep.
Support people (imo) fix stuff - or find the person who can fix the stuff, while owning the 'issue' until completion.
Advanced training, anomalous applications, etc should be the realm of SEs, presales, manufacturers reps, etc.
Are they always? Hell no... But if you have your support people performing these additional roles, if you get any volume at all, the level of your support will suffer. imo, this is unacceptable.
Also, I disagree about "How do I..." questions. I don't care how 'easy' the 'How do I' question is.... if it's in the manual, then don't call support (unless you have a unique situation).
IPVMU Certified | 05/12/13 06:32pm
A bit off topic, but I wonder how many manufacturers could reduce "stupid" questions with UI improvements. There are plenty of products who's manuals I have never read post-purchase. This goes double for relatively straight forward products like cameras: I should be able to just pick it up and get to work. As things get more complex (VMS or Access Control software), some reliance on the manual is tolerable, but even so, if you are still being overwhelmed with "How do I..." questions, I'd recommend re-evaluating your UI.
James: good call! Also, one of the downsides of the flood of cheap Chinese electronics, as good as the product may be, is the bad Engrish in the UI *and* manuals that makes it really difficult to find functions that should otherwise be obvious.
Chinese aren't the only ones guilty. I've seen European products where English was not the technical writers first language, and made the manual difficult to understand.
James = The Preacher
Me = The Choir
Unintuitive interfaces suck - and can crush your back-end in stupidity.
...and don't get me started on unintuitive/unhelpful error messages! :)
Good point, Undisclosed... although in most cases, it seems, the more Western manufacturers at least make an effort to translate things effectively. I'd swear most eastern Asian manufacturers (not to pick on JUST China) just run their manuals through Babelfish and straight to the printer.
Marty: I think most of those unhelpful error messages just come from Windows; that's beyond the equipment makers' control XD
Matt, disagree. A classic example is when a camera will not connect to a VMS. Most VMSes don't even try to offer any information. Was the IP address not reachable? Was it reachable but did the login fail? Did the login work but there was an issue connecting to the stream? etc.
When things go wrong, software should be as descriptive as possible to help guide the user to the most likely solution.
IPVMU Certified | 05/12/13 07:13pm
While I'd be the last one called a Windows fanboy, the OS has little to do with it. Indeed Windows offers a unified way to review logged error messages ("Event Viewer"), Linux programs scatter their log files everywhere. That point aside - I shouldn't need to find the log file except for extreme cases - the UI should tell me something went wrong and explain it (in red text somewhere - standardize everywhere possible).
John/James - talking about two different things here. Unhelpful error messages isn't the same thing as NO error messages. I'm talking about the sort of nebulous messages Windows produces like, "The system has recovered from an unknown error" and "The program is not responding and will close".
VMS and other software's complete LACK of error popups is a whole other level of frustration.