How to Ask for (Tech) Help

Though I don’t work in tech support, I am asked for help fairly often.  Friends or coworkers as well as people who are doing one of my tutorials reach out to me.  I’m always willing to try to help someone, but I’m often surprised by the vagueness of some of the messages I receive.  To be fair though, I’m sure there are many tech support people out there who have looked at my requests for help and either rolled their eyes or yelled at their screen.  So in the spirit of trying to make things better for those of us who need help and the people who are trying to offer help, here is a primer on how to ask for tech support.  Take a cleansing breath, gather your thoughts, and remember the tech person you are speaking to can’t see what you are seeing and doesn’t know the context of your problem.

What operating system?

This is a super basic question, but with a few different applications.  Obviously, which version of console software is the first thing you should provide.  But if you are having a problem between the console and a fixture, be sure to include the firmware that the fixture is running.  If you are running a PC version of the console, be sure to include the operating system of Windows or Mac.  If you are using a node, what make, model and firmware version is it running?  Developers are constantly changing things and it’s important to know what software you are working with to solve a problem.

Console or Computer?

This is included up above, but be sure to explicitly state if you are running a console or a PC solution.  Are you using a built in DMX port, or a networked DMX port?  Are you using wireless DMX, and if so, what make, model and firmware?

What network configuration?

Often when I receive requests for help on networking issues, people will not tell me anything at all about their setup.  Make, model, and firmware of switches is vital.  Is it a managed or unmanaged network?  How have you configured your network with multicast (or without)?  sACN or Artnet?  What priority are the protocols set at?  Are you sharing the network with other traffic or consoles?  All of these details matter so much.

What were you trying to do?

Usually people do a pretty good job of relaying what they were trying to do, but try to be thorough.  Take a moment and ask yourself if there is context that is important to why you were trying to do something the way you attempted it.  

What happened instead?

I cannot describe how many times I receive “It didn’t work” as a tech support “request”.  This is very frustrating communication.  It seems pretty obvious by the fact you are asking for help that it didn’t work.  So instead, please tell me what “it” (the console, the light, the node, the switch) DID do instead of what you wanted.  Often the problem is the operator, not the equipment.  I include myself when I say that.  So telling your support person what DID happen gives us tons of clues about what may have gone wrong. 

Documentation

Context is everything.  Pictures of command lines, lights, and nodes are often helpful.  Show files saved at the moment the issue happened are great. Pictures of your network configuration data.  Short videos of how the light is reacting.  All of these things can be the difference between getting the answer right away or having to spend several days communicating to get your issue resolved.  The more efficient you are in communicating, the sooner things can get solved.

I’m sure there are other things to remember, so definitely post in the comments to get people thinking in the right way.  Also- let’s celebrate the best tech support we’ve ever gotten.  Who helped you out under what dire circumstances?

Photo by Jonas Jacobsson on Unsplash

Leave Comment

Your email address will not be published. Required fields are marked *