If you’re a vCommander admin, what’s the best way to report issues to Embotics® Support effectively?
I’ll stop myself right now to say: I get it. You’re responsible for a lot of technology and users, and doing a deep dive into vCommander™ events and logs is not something you have time for in your already busy day. That’s our job, after all. I agree wholeheartedly. But at the same time, it’s important to provide relevant details from the outset to avoid back-and-forth over email and to make sure your situation is resolved in as timely a manner as possible.
So, how do you know what details are relevant? Simple. Use the five Ws.
- Who experienced the problem?
- What were the symptoms?
- Where in the product did it occur?
- When did it occur?
- Why is it a problem?
First, tell us Who experienced the problem. For example, was it a vCommander user or a Service Portal user? Was it a local vCommander account or an account integrated from a directory service? What role was assigned to this account, and, for a vCommander account, what access rights were assigned? Just this one piece of data can provide a wealth of information about the problem. And if we have to parse logs to find details of what occurred, knowing the user who experienced it can help narrow our search.
One of the best things a customer can do when opening a case is to provide details about What happened. If you’ve got an issue that is reproducible (every time I try and save this service, I get kicked out of vCommander), you can use a tool like Screencast-O-Matic or Jing to record what’s happened so we can actually watch it. Doing this also removes any ambiguity that could creep into a description. If you can’t provide a recording, screenshots of error messages can be incredibly helpful.
On the other hand, sometimes screenshots are the problem! Where in vCommander did I take this screenshot?
It’s difficult to tell, isn’t it? Our engineers aim for a uniform, graceful user interface, and as such screenshots may not always easily distinguish one area from another. To fix this, include a brief description of how to browse to the area in which you were working when the issue occurred. This is how Embotics Support reports issues to our engineering and product verification teams, because it works.
Knowing When an issue occurred simply allows us to narrow down the scope of any search we’re doing on your events or logs. As with the other points I’m making here, the more specific the better. It’s not always necessary to provide an exact timestamp, but letting us know an issue occurred last night introduces a 10 hour window of logs to pore over.
Okay, the last one might seem a bit counter-intuitive. I mean, it should be obvious Why something is a problem, right? Well, not exactly. Sometimes people lock onto one possible solution to solve a problem, and can’t get it working the way they want it to do. When this happens, it’s easy to miss other solutions that are available. So it’s always a good idea to explain why something is standing in the way of your goal, because we might be able to offer alternative solutions.
All this said, the Embotics Support team is very proud of the positive relationships we’ve built up with our customers, and how truly collaborative they are. We’re always happy to help, and are always looking for ways to empower our customers further. Over the next few months, we’re putting some extra effort into developing out more self-help troubleshooters like the one we have published for Troubleshooting Deployment Placement. Check it out.