Almost daily I come across at least one support request from a user that reads the way Miss Teen South Carolina answers this question:
It’s always frustrating for me not because I’m bothered, but because more often than not this kind of request means this user is likely to get frustrated with me for the increased time it’s going to take to figure out what their issue actually is and get it resolved for them.
I’ve always encouraged our support team to ask three questions, and recently we just went ahead and added these questions to our support form and we’ve already noticed a decrease in our RPR (Replies per Resolve) stat, meaning users requests are getting answered faster our overall customer satisfaction has increased.
When you encounter the issue, what specific actions are you taking? – What is the user interacting with? What page are they on? What button/link are they clicking? Which tools, specifically, are they interacting with? The number of support requests we get where users tell us something is broke but not what or where they’re seeing the issue is pretty frustrating…but the reality is that most users simply aren’t aware how the extra context can help in troubleshooting their issue. Asking them for it up front makes the experience better for everyone.
After taking those actions, what are you expecting to happen? – What is the outcome the user is looking for? This question is especially useful in determining how well the user understands how the product works, including whether it is appropriate to send the user documentation on how to achieve their goal, or even whether or not their goal is something your product is designed to do. For the latter, these can also reveal some pretty interesting feature requests or improvements for the product, so as far as we are concerned this question is a double win.
What is happening instead of your expected outcome? – Here’s where you’ll get the meat of your response. What is broken? Is the user getting an error message? This question can also help you find potential breaks, misses, or confusion in the design/UX of your product. Simply put, this is the question that helps you understand what in your product or service doesn’t meet the customers expectations. Sometimes it’s a bug, sometimes it’s a feature request, and sometimes it just means we have more room to create clarity for the user and their experience with our product.
If you don’t want to add these questions directly into your support flow, they can help in other ways as well. As an example, we’ve just implemented a policy at Ninja Forms where our support techs are required to restate these questions with answers in their own words before escalating to our development team.
It’s also not a bad practice to make sure that before sending any kind of a response to the user you can answer these questions regarding their issue. If you can’t, it’s likely you’ll end up wasting a response or two while you figure out the root of the users issue.
I’ve seen some pretty great benefits from adopting these questions, but I’d love to hear if/how any of you are solving these issues in your support queue. Leave a comment or hit me up on the contact page!
Leave a Reply