Troubleshooting requires both the ability to understand what’s happening technically in the product and the ability to communicate effectively with customers to get the full details. Troubleshooting in support is half human fixes and half product fixes.
Is the issue happening consistently or intermittently?
Based on the answer, you want to test. Attempt the action your user is stuck on and see it on your end. Then, try to reproduce the behaviour on your test site or instance. You may need to configure your test instance to mimic the customer’s configuration to successfully reproduce the issue. You will then end up with these categories: only reproducible by the customer, only reproducible on the customer’s site, reproducible everywhere.
Issues that are reproducible for the customer but cannot be reproduced internally tend to revolve around the customer’s technology. So, things like poor internet connection, an outdated browser version or a browser extension not playing nice with your product.
When it’s reproducible on the customer’s instance but not others, it’s likely due to a configuration issue in your product. These are the toughest ones to handle as it’s often difficult to pinpoint the root cause. Timebox the troubleshooting efforts on these issues as they can just go on and on. Then, escalate to the most knowledgeable CS team member. You can also consider bringing in a technical person to help with these issues as they often have a quicker way to identify the issues by looking at the developer tool/network logs.
The last type is when the issue can be reproduced everywhere are bugs. This goes through your bug reporting process.
Can you provide an example of one that worked and one that didn’t?
This question provides you with a nice start to the troubleshooting process. You can compare two outcomes and identify differences. One of those differences is likely the root cause. Then, start testing. Make sure to change only one thing at a time to narrow down the scope of what could be wrong.
What is it doing now and what are you expecting it to do?
Asking your customer to frame the issue this way ensures correct expectations. Customers often report issues that are not actually issues because they don’t know the intended functionality. When this is the case, provide training and/or documentation for the customer.
Was it working before or is this the first time you are using the functionality? When did it stop working and did you make recent changes around that time?
Four questions but they hone in on the same thing. If it’s the first time they are using the functionality, chances are it’s a configuration issue and not a product bug. They are likely just learning about the feature and misunderstanding something.
But if it was working before, then it’s likely due to a change in either the product or customer’s configuration. Check with your development team if the feature or area is recently worked on. It’s possible the issue is a downstream effect of a recent code change.
What are you trying to accomplish?
Customers use your product to do a job that arises in their life. Your product is designed to solve some jobs and not others. By asking this question, you determine if the customer is using the product in a way it’s designed for. A certain behaviour may be perceived as an issue in a given situation but is actually a feature in a different context.
