How Long Should You Wait Until Calling Manufacturer Tech Support?

Some integrator techs are relentless in making things work. It absolutely has upsides but sometimes it makes tasks take far longer than they need to be, if they had simply conferred, even briefly, with the manufacturer. For instance, there are often undocumented issues or undisclosed bugs that make the task at hand impossible or there is some obscure trick that the manufacturer knows from having dealt with this for another user across the globe, etc. that would immediately solve this.

What do you all think? Any relevant experiences or tips you have related to this?


Member consensus is that integrators should try to solve the problem first, spending up to an hour in troubleshooting / experimenting. After that time, calling support becomes increasingly valuable as the problem may have a tricky or undocumented solution that the manufacturer may know but may tech the integrator tech a lot of time to resolve independently.

Techs spending far too much time troubleshooting problems, while refusing to call technical support, is a common problem for IPVM integrator members and a costly one at that.

As someone who has gotten mad that tech support wasn't called sooner AND spent too much time stubbornly 'trying to figure it out on my own', I understand both sides here.

Especially among tech types, part of the fun is solving the problem. On the other hand, stepping back and recognizing time = money is not always easy for someone laser focused on solving a weird issue. Engineers and techs get that 'thousand yard stare' sometimes and it takes a manager snapping fingers to remind them it is costing money just fiddling around with things.

The quality of tech support available makes a huge difference in determining 'when to call'. If it was a problem on a new/ unfamiliar product, it is best to make the call ASAP. If it was a weird, low-level issue on a product we were well-versed and trained on, there was nearly a 0% chance the issue would be solved by Tier 1 support. I hated those calls where some operator reading a flipchart was stepping through a process I already tried, but they didn't understand what they were really recommending or why.

Anyone who's been around awhile has seen this phenomenon. Sometimes I have to do that with my own people. They'll tinker with something and pinpoint a certain problem area or quirk in a system, then just accept it at face value. I have to tell them to call the manufacturer's tech support and verify it's an actual limitation and not a fixable issue. Sometimes it seems they're afraid to call tech support. With this being a male dominated field, I guess it's related to the "man refusing to ask for directions" thing.

Everyone knows you call technical support as soon as the customer is "Ready to rip the system out"

The length of the fuse is so varied, too. Some just grit their teeth and would endure months of FUBAR if pressed, others explode and are ready to start over for anything that isn't fixed by a reboot!

The rule at my last job was you could choose to call immidiately or you could choose to tinker with the problem, but you must call tech support after an hour of working at the problem, or at least call the boss and ask if he or any other tech knew the answer. We did a lot of "system rehab" (ie take over a semifunctional, disfunctional, or nonfunctional alarm, camera system, telephone system, or whatever that a previous trunkslammer had thrown up their hands and given up on), which meant hours and hours of troubleshooting. In cases like this, where there is no tech support to call, we'd tinker for an hour and call or text the boss with a status report. The status report had to include actions taken ("I toned out a quarter, half, all the wires in wiring cabinet 1B"), tasks accomplished ("I identified, labeled, and verified the connections on 1, 5, 100 wires"), issues holding up work ("cannot identify wire 137, am unsure if the wire is broken or the jack is on another floor and they just ran it to this closet for some reason") and intentions ("will try tracing wire to see if I can find the break, or figure out if it's running in a different direction, or what", or "tried changing the baud rate on the PTZ, no result, verified connections as good, am calling Pelco now") At every break, and at the end of every day, we had to send an additional status report recording all that we'd done from the begining of the workday, and what our next step was going to be, after lunch or the next day.

It's a good system, I think. First, the boss knows what the tech is up to, what the tech already tried, and can either offer their own insight into the problem or at least have a good idea of how much longer troubleshooting is likely to be. Second, forcing the tech to stop, think about what they've tried so far, and think about what their next step should be often leads to insights that wouldn't be forthcoming if the tech gets to tunnel-visiony (a problem I find myself particularly prone to).

So. An hour of tinkering, not more, but more important than the time limit is to stop, gather your thoughts, think about what you've done so far and why, and what you think should be happening or what you want tech support to do for you ("tell me how to adjust this particular setting so that it doesn't interfere with that particular setting" is more useful than "get this razzle-frazzle thing working for me, you stupid jerk").

Ari, great feedback and recommendations.

I concur on both the one hour rule and having status reports. We recently provided some guidance to an end user with a system having significant problems for weeks on end. When we asked the integrator what specific steps / settings they had tried, they replied that they did not write it down / did not know. At that point, what can you do? You don't know if they missed something obvious, are making stuff up, etc. Frustrating...

The best thing I ever read on the subject of troubleshooting is a book called The Great Influenza by John M Barry (Amazon referal link).

In 1918, just as World War I was sputtering to a close, a flu pandemic struck the globe, killing millions of people- possibly as many as 100 million, although wartime censorship ensured that accurate numbers are difficult to come by, even today. The pandemic could have been even worse than it was, but medicine was at the time developing scientific methods of identifying and treating diseases. Aside from the fact that it's a terrific book, the description of the way scientists identified the virus and developed a treatment that worked (by taking careful note of what didn't work, which allowed them to figure out why it didn't work) neatly parallels the way we would troubleshoot a big, complicated, messy surveillance system- identify all the wires, test all connections, isolate problematic components, and decide whether to repair or replace. Although of course people usually don't die if you can't figure out why Camera B can't see the parking lot very well, of course.

Adopting the scientific method- working slowly and methodically, documenting your work every step of the way, thinking about what works and what doesn't in order to apply what you've learned to new situations- is the only way to troubleshoot, and this book is the best tutorial on the scientific method I've ever seen. It should be required reading for every technician.

Mr. Fancypants over here demands literacy from all his techs.

The best thing I ever read on the subject of troubleshooting is a book called The Great Influenza by John M Barry (Amazon referal link).

Damn, it must be good; they don't even have a single copy(!) left over at ADI... ;)

At least they did have "Confessions of a Trunk Slammer" by A. Erenthal, excerpted without permission:

...That's why I'm glad to have started out as a trunkslammer, and to have worked for so many trunkslammers throughout my career... Actually, the name Erenthal, from the low German, translates loosely to 'lid closer', yet it takes more than just a name to be a 'slammer, but I digress...

At least they did have "Confessions of a Trunk Slammer" by A. Erenthal, excerpted without permission:

That's the funniest thing I've read this week. Thanks!

I like the 1 hour rule. As the salesperson, I'm the one that gets the call from the customer when they get an enormous bill for the service call that a tech decided to "tinker" with for 8 hours and those are unpleasant calls. Worse, they typically end up in crediting the customer so the cost of all that "tinkering" comes out of the company pocket AND it leaves a bad impression with the customer so it might even end any future business with them. I don't think its so much a "man not asking for directions" problem because I've known women to do the same thing. I think its more the tech/engineering mentality that makes them determined to crack the nut - male or female. Managers need to recognize it as an admirable quality that needs to be controlled so making a policy of 1 hour or whatever length of time you want but insist on a hard stop to the tinkering, a call to factory tech support AND....let the salesperson know whats going on so we don't get blindsided by an angry customer call!

"Worse, they typically end up in crediting the customer so the cost of all that "tinkering" comes out of the company pocket AND it leaves a bad impression with the customer so it might even end any future business with them."

Good point. This is one of the things that I see lots of techs / engineers struggle with. Appreciating / caring for the business side of things. Compare an integrator tech who alone can solve something in 8 hours versus that same tech, talking with support, solving it in 1 or 2 hours. Clearly, the latter is better for business but many techs don't seem to recognize or prioritize that. In my experience, it's hard to teach / convey to many....

That's why I'm glad to have started out as a trunkslammer, and to have worked for so many trunkslammers throughout my career. A trunkslammer who doesn't prioritize efficiency will soon go out of business.

Of course, many trunkslammers take this philosophy way too far, which is part of the reason they have the reputation they do.

I don't know what I can add to the already spot-on 'what should be' analysis, so let me just quantify some of the variables that go into the semi-conscious 'what is' calculation. Terms:

SS = Minutes spent Successfully Solving last time you solved it without calling

US = Minutes spent Unsuccessfully Solving last time you gave up before calling

SC= Minutes spent Successfully Calling last time you were helped

UC= Minutes spent Unsuccessfully Calling last time you were not helped

which naturally arranged yields the self-optimizing and distinctly Bayesian: M = (SC - SS) - (US -UC)

One example: (50 SC - 20 SS) - (10 US - 10 UC) = 30 minutes

But then one bad experience with tech support, increasing UC would increase M:

(50 SC - 20 SS) - (10 US - 90 UC) = 110 minutes

Of course this calculation is still subject to many competing and significant biases, a few of the notable are:

Likelihood of Peer Ridicule - LPR, General Knuckle-headed Tendency - GKT, Let Me Try One More Thing fallacy - LMTOMT, Average distant stare length (in yards) - DSL, and then ultimately limited by minutes before help desk closes on east coast/china/mumbai - MBC...

I've lost many months of my working life to Let Me Try One More Thing...

I am programming these formulae into a scientific graphing calculator app on my phone as we speak.

Pretty sure any time spent actually trying to figure out the app while inserting variables on-site will exceed M by several orders of magnitude, but at least I'll look extra-high-tech doing it.

BTW, you left an imporant variable out of the SC/UC calculation: MOH (I'll let you figure out what that stands for... shouldn't be hard ;)

MOH is included in both SC and UC, but a better model would split call time into Hold time and Live time since Hold time should probably be way more negatively weighted than Live time. Also as the budding 'slammer's experience grows he develops one-off models by manufacturer, thereby increasing accuracy.

These mfr. specific models, and the inevitable resultant descrepancies between co-workers, often leads to the facetious wishing of fortune, e.g.

Newbie: "Hey Boss, I'm gonna give the guys at ChipChopper a call."

Ari: "Good Luck!"

Note that proper delivery is essential to effective ridicule: head should not pan more than 20 degrees before speaking, utterance should be delivered with an slight yet audible underlying guffaw, and after delivery the head should commence an understated shaking with eyes averted. Also note that although some would add the qualifier "with that", its effect is unclear, and remains mostly a regional preference.

Needs more expletives.

There definitely needs to be a way of better weighting the quality vs. quantity of the LT component, when it comes to SC. When I have to explain three times to the script-reading first-level tech, every troubleshooting step I've already taken and how it factors in the final diagnosis, that definitely vectors the quality downward.

On the other hand, when I've talked about six feet over the guy's head in the first two sentences and he simply bumps me straight to the engineers... that weights the LT significantly in their favor.

Ours is the one hour rule, and it is part of our written handbook. It is the "law". The handbook explains to everyone who reads it why in terms of dollars and cents, and that another customer is probably waiting on you while you "try one more thing". The mention of documentation is critical. Our policy is to document everything. Even the factory tech's name, etc. We were cleared in a law suit once because our documentation was so good. We did not even have to take the stand. The judge looked at our documentation and dismissed us from the suit. It did not hurt that the customer admitted, under oath, he had made adjustments.

Mark, Good feedback! Do you use any software or system to coordinate documentation?

We design our own forms to allow for documentation, and the techs are shown how to fill out the forms as part of training. If they consistently fail, we retrain or if need be, re-hire. We consider and emphasize documentation just as important as a technical fix. If you did not document that call correctly, you are not finished with that call yet and you get to finish it on your own time. It begins to cost the technician. From there, we have an in-house intranet where the info is stored for recall. We designed it ourselves as well. It looks a lot like facility software and is available on the web 24 x 7 to the entire staff, including the customer service. We then cover the major hickups in our staff training. And when I say staff, I mean the entire staff. Even our interns get trained on documentation. I have a rule here, and it is in the handbook as well. If you did not document the conversation it never happened. No exceptions. I don't want to hear any whining. I will not stick up for you. I won't support your arguement without it and I stick to that rule. They all learn very quickly.

Largely Jon, it is all about what management considers important, (top down thinking) and how much emphasis gets placed on it. Since that is money out of my pocket, there is considerable emphasis put on it.

The forms and website are all customized around Microsoft products. They work well if you know how to use them, everyone has them, and why spend any time re-inventing that particular wheel?

this is a bit off topic ... Mark Jones, I've always been told that, at least here in CA, you can't have an employee "finish it on their own time". If they're working for you (fixing a mistake or not) they must be on the clock and "punishment" comes in the form of write ups, no raises or termination. Are you aware of some labor laws I'm not?? Or is it just that I'm doing business in a business unfriendly state?? Alon

No you are essentially correct. It is not so much a State law as it is Federal. A 40 hour work week is a 40 hour work week everywhere. Anything beyond that is overtime. In our case, we have GPS on all of our vehicles. We know when the employee left for work and when they returned home - remote technicians. If they leave at 9am, and get home at 4pm, that is not a 40 hour work week. The 40 hour work week works both ways. I owe them for it, but they have to put in their 40 hours. The law does not say 40 consequtive hours, it just says 40. So if you have not finished your paperwork, all of it, and you put in 35 hours this week according to your GPS, guess what? You will finish it. You may say to me, well I am already home, on my own time, but my counter is this; you have only put in 35 hours. You owe me 5 more. He/she may be outstanding. Finished all their work, paperwork is correct and still only put in 35 hours. My next question is what about your qualifications? Are they all up to date? Has your vehicle been serviced? There are always things to do. That money is coming out of your pocket. Make it count.

I am already paying you for it. Now do it. If it becomes habitual, re-hire. I define habitual as three times. That is ample warning. It is a tougher stance, but they get the picture quickly or they are gone. If you allow sloppy work, then that is what you will get. Leadership and accountability starts at the top.

And yes, document, document document.

I'm confused. You pay them for 40 hours, but you allow them to go home when they're done with the job, even if they finish early? Meaning that there's a bit of slack time when they're home that they're supposed to use to do paperwork, vehicle maintenance, and other administrata? What if the work and the paperwork takes longer than 40 hours?

Sorry Ari, I did not notice your question. Most of your techs are remote. They work from home. Federal law is purposefully unclear about how to account for their time. Since we can't use a time clock, we depend on GPS records. To answer your question directly, if their responsibilities take them over 40 hours/week no matter what those responsibilities may be, they have to have PRIOR approval from an admin person, no matter where they are. On the worksite or at home. If it is at the worksite, the admin person has to have written authorization from the customer to bill the overtime. If at home, we just say no. Since installing the GPS devices, and I did not have them installed for that purpose, we have had no compliants about working too much or more than 40 hours. I now have proof positive. And I random audit the records myself every Friday. All of that, every bit of it is documented in our employee handbook. And yes, we have been audited by the IRS and Dep. Of Labor, our insurance companies and the US Government since we do work on Federal jobs. Not a peep.

Federal law is purposefully unclear about how to account for their time...

What is their 'purpose' for being 'unclear'?

I have done a lot of reading on this because of our remote technicians. They do not punch time clocks and there is no verifiable way of keeping track of their time(fair to them and fair to the company as well). Judges don't have a clear answer either => they don't know how to verify it either. If you have people who work remotely, the law and technology leaves you out in the cold somewhat. The laws and case law almost always deal with an employer who has a central location.

We instituted the GPS for safety reasons (we had a tech to get injured in an accident and could not find him) but it occured to me later that we could use that for keeping up with their hours. We do pay for a more detailed report than some might, but it offers what we need.

If they consistently fail, we retrain or if need be, rehire.

I wish you could be after my old boss, best job ever, but she said she was "letting go" for failing just one too many times. Just one! There was no "rehire if need be", and "DNR" was "all she wrote"

I am curious what manufacturers plan for and see from the field?? Are people calling in after the first thing they stumble on or are they getting more of the "I've tried everything I can think of"??

Alon, good question. I know manufacturers get a lot of really trivial calls and it's a widespread problem. People will call up asking for basic things like "What's the default IP address of your camera?" or "How do you change the frame rate?" Questions that are almost always answered in documents readily available online.

This is why you see tier 1 support people often just reading from a script of the X number of idiotic / obvious questions people ask. Related: Which Company Has The Most Useless Tech Support Staff?

I can't speak for manufacturers, but, speaking as a person who resells to end users via a website, my calls seem to be pretty evenly divided between "I can't figure out how to open a box and the fact that I was able to dial a telephone number is a minor miracle in itself" and "why didn't you call me last week?".

I try to act as level one tech support. I mean, obviously I don't have a script, and we sell thousands of products from dozens of manufacturers so scripts are impractical in any case, but I try and use my common sense and my vast, vast experience consisting of having made pretty much every mistake possible, sometimes twice. I'll ask them basics (is it plugged in correctly? is it powered up? is it on?), which clears up about 80% of phone calls of both variety, and if that still doesn't fix it, I'll advise them to call the manufacturer for further advice.

Wow .. Hot subject. I'm one of those guys that calls tech support quite readily. I want the information to get the thing working and working quickly. They know way more about thier own product that I probably ever will. I'm not afraid to call tech support in front of the customer either. I have a blue tooth ear piece on, I have unlimited long distance to canada and US and I am able to carry on with my work while I am on hold. Give me the info so I can figure the thing out and move on to the next task. I find it's much easier that way. That's my style, I noticed my employee doesn't do that at all, but once we have the guy on speaker phone and he's telling us what to do, everyone can't deny the results speak for themselves.

"They know way more about thier own product that I probably ever will."

That's great when it works out that way... unfortunately it's not always the case. We've been dealing with one product for close to 10 years... they've seen a lot of turnover in their support department, especially in the last 3-4 years. Near as I can tell, all the first-level and second-level techs have moved on... I think maybe ONE of the original engineers is still around, but all the people I used to be able to rely on for REALLY knowing the products are long gone. Suffice to say I know more about their product than almost anyone there and about the only reason to call them anymore is for things like license upgrades or to generate RMAs.

Sounds like Pelco. Their Tech Support used to be excellent but now...

I would absolutely agree with this. I work for Infinias (manufacturer) and there have been many times when a customer has called in AFTER making changes to their system. Those changes caused issues which made the fix that much longer because we had to figure out what they had done, reverse their mistakes and then redo the steps properly.

I've waited to post on this thread to see what others said first...

I am surprised that nobody has mentioned the term 'RTFM' - and it's not so delicate indicator of at least one determiner to be used when deciding whether of not to call support...

I will admit that many years spent answering end user calls has jaded my opinions on this subject, but I live by one rule when it comes to calling technical support:

If the answer is in the manual, do not call support and ask for this answer.

Note also, I am a technical trainer for a VMS company... so I've got that bias to carry around as well... if the question starts with 'How do I...?' - that is my job - not technical support.

If it's broke or not working properly - fire away. If you just don't know how to do it, RTFM.

Assuming a manual exists. And is written clearly. With a good index.

And is readily available online without having to login to a partner portal.

I agree with Marty that reviewing documentation is an important first step. I think we would all agree, though, that manufacturers should make every effort to make it easy to find the right information online so support requests can be minimized.

Yes, without question - both Ari and John.

If a manufacturer doesn't want to take support calls about any particular thing, then it is on them to provide both documentation and training - and make it easily obtainable by those who work with that particular thing.

I think this could be another discussion John. “Who has good, readily available manuals and installation guides” or something along those lines. I think that AXIS is great, but you do have to log in to see the “good” stuff. Pelco has decent stuff, but it is a pain to locate what you actually need. Lenel (at least the OnGuard line) is ridiculous with a mish mash of manuals, install guides and troubleshooting documents with some of them over 400 pages and saying completely opposite things.

Aiphone has some of the best installation manuals I've ever seen. Example. Their programming manuals are very good, too.

RTFM! used be boss, but now is often pre-empted by incredulous cries of WTFM?? (Where's the...) and YCTAFM??? (You call this a...).

Anyone have any insight into why even when you are on the company portal in the knowledge base search, you still are more likely to find anything about your problem by just googling it?

A friend worked in NYC at a financial tech company called RTFM Consulting(?), they would answer "RTFM Tech Support?", just because they could...

We recently started to make our VMS servers more appliance like by creating UserIds and giving the installed NICs a name that matches the intended function (not all NICs perform the same). To go along with this we have a nice colorful 11x17 Quick Start guide that is in hardcopy form inside the box with the system that documents all this and more.

Our Customer Care team has now fielded WAY TOO MANY calls of... "what is the password for the userid?".... which is right on the front of the QSG inside a red box in bold letters!

Talk about 'RTFM'.

I was visiting a customer recently and had a chance to observe how they start working with one of our servers. The tech opened the box... grabbed all the stuff on the top (which included the QSG) and tossed it to the side and proceeded to do his normal thing. I asked if he noticed the QSG... and he said no. <sigh>

We are now thinking that we will tape it directly to the system.

We had a manufacturer print the QSG on the interior of the box itself, so the only way you could miss it is if you literally tore the box open. Cut down on tech support calls like you wouldn't beleive. There are a ton of unemployed and underemployed cartoonists on Craiglist and Fivr who would love to create a graphic version of your QSG suitable for printing on your boxes, so your customer doesn't even really need to be fully literate in English.

LOL - man, I do not miss my tech support days!

How about using an up-front message on your tech support wait queue?

Half the callers will ignore that and wait to ask a human what the recorded message just told them anyway, but it might knock some of them out. I sound jaded? ; )

How about using an up-front message on your tech support wait queue?

Like "please make sure you've turned your device off and turned it back on again. Please be sure that you have ready access to your device, and are able to troubleshoot. Please don't yell at the tech support person that you have a dentist appointment and that they better get your device working in the next finve minutes or else. Before attempting to reach tech support, please ensure that you have basic knowledge of technical concepts, such as how to operate a mouse. Please keep in mind that your tech support person did not design your device, and yelling at him or her about decisions made before the product was manufactured is not your tech support person's fault, so please stop yelling at him or her. Please have a pen ready. Please do not curse, threaten, or menace your tech support person. RTFM. Please do not lie to your tech support person; your tech support person is only trying to help. Thank you."


Liberal use of my mute button was the only thing that kept me sane.

That and the occasional Touch Tone Terrorist customer support call