When we talk about working with remote technical support, even the word with is a useful starting point. It’s a word with several meanings, some of which contradict each other. In the Merriam-Webster dictionary, the first definition is “in opposition” or “against” (as in, “I had a fight with my brother”). But over at the Oxford dictionaries, the first meaning is “accompanied by” (as in, “We had wine with our dinner”).
In using the word here, I’m hoping to suggest a scenario in which people are working together and helping each other. And that is the best-case scenario. When we’re working with a support engineer, it’s never supposed to be a fight. Ideally, we are collaborating to try to solve a problem. But how do we make that a reality?
Most of us working regularly with a vendor’s remote support have experienced anger or frustration at least once. In my twenty plus years of experience working with different vendor’s support engineers, it is not unusual. One example that comes to mind is when you open a ticket and while you think you have provided all of the necessary information to troubleshoot the issue —the vendor support engineer continues to ask more and more questions.
Sounds familiar, doesn’t it? And in some cases, the frustration might be justified. Perhaps the support engineer is asking about some trace files or logs you had already uploaded a couple of weeks ago. Or, in some cases, the request to action something which may require significant effort but the support doesn’t provide any reason or explanation on how it can help solve a problem. You may get the feeling that it is just a way to keep you busy instead of working on a solution.
When this happens, I usually try to put myself in the shoes of the support engineer. He or she has never worked on your system before and has no idea about configuration, workload and the business needs of your environment. You, on the other hand, work with the system on a daily basis and know it thoroughly. The support engineer cannot connect to your database or server when the issue is happening and cannot test or verify behavior. It makes the task difficult even for some trivial cases. A proper diagnosis or solution entirely depends on the information provided. If a trace or a log file doesn’t contain enough information about the problem, or has the wrong information (for example, the incorrect time interval) they are useless and may even lead to the wrong conclusion.
Of course, it would be great to have a support engineer who could read minds and know everything about your system, who could then provide an answer right after opening a ticket. But we are not quite there yet.
So the question becomes “how can you make your work with remote vendor’s support more effective?”
Let’s start with the ticket that has priority, or is the most urgent. If you open a case that has been identified as an emergency, it will need to be assigned to a support engineer right away and the problem will be worked on around the clock. This means that the problem will be handed off from one engineer to another since support folks are going to work 24×7 even if you are willing to do so. Is switching from one hand to another the most effective way? In some cases, it can be, but in my experience this is not really productive. Still, if you are ready to work with support around the clock and accept the inevitable overhead when the issue is being passed on from one engineer to another —that’s your prerogative.
When you open a case after business hours or the end of the day on Friday evening, your problem may be assigned to somebody working in a different timezone. So, by updating a ticket at 9 am your time, you may get the answer by around 9 pm the same day. Try to get an engineer physically located close to or within working hours in your time zone. It will make communications and collaboration much more efficient. Of course, it is not always possible but worth investigating.
Make it personal and truly collaborative. Request a call with the engineer and be ready to reproduce or show the problem on a shared screen. One short session can save hours if not days of communications going back and forth.
Try to clearly understand any actions or requests from the engineer and what kind of consequences it may have on your system. Trivial actions like a dump of a memory sub-pool can crash a heavily used system. Don’t be shy if you don’t understand something or suspect it can impact your system.
Try not to be a passive observer and work together with the engineer. If you think there was data that was not requested but in your opinion can provide useful information for the case, don’t hesitate to reach out to support and seek out the information.
If you think that the proposed solution is not acceptable don’t hesitate to discuss it and, in some cases, request a second opinion and alternative ways to solve the problem. It’a entirely possible that the proposed solution is not the only way to tackle the issue.
And in the end, I will stress again that the information you provide is the key to successful resolution of your problem. Wrong or insufficient information may lead to wrong conclusions. Remote support is not the place for guesswork. I have seen experienced support engineers making false assumptions and jump to wrong conclusions due to insufficient data. Don’t expect a wizard with a crystal ball and hidden sacred knowledge of your system to magically appear. Their knowledge of your system is based on what you tell them.
Of course, everyone has their own way of working with support and must do what works best for them. However, I still hope that in some way this article will be able to help someone that is working with support to be more productive and appreciative of support engineers. Let’s work together, not against one another.
Interested in working with Gleb? Schedule a tech call.