Most of us have encountered a moment of frustration when using personal technology—a forgotten password, or unresponsive screen on a smartphone, or perhaps you have had an ongoing issue with your internet service provider or your bank. Once you’ve tracked down the support number and dialed in, many times, here is what happens:
-A really nice, well-intentioned representative of the company answers your call and asks you to describe the issue.
-Their questions are likely based on a flow chart-like decision tree that acts as a script to identify the most common issues with the product you are using.
-This works well if your issue is on the list, but if it isn’t, that’s when you start using stronger language, asking your own questions and become a bold advocate for yourself hoping to get “escalated” to Tier 2 Support.
-Reaching Tier 2 might seem like a minor victory in getting the help you need, but often it starts out just like in the Tier 1 setting. You redescribe the issue, answer questions (albeit from a more experienced support representative) and in this moment you feel like you’ve started all over again.
-While you are waiting on and off of hold for various resources, you start clicking around through the self-help section of the company’s website only to find descriptions of your issue paired with a recommendation to call support!
What we do in Red Hat Support is different than that.
At Red Hat we know a community is more capable than an individual and that a single perspective rarely develops the best idea. We create our products by leveraging the input and innovation contributed by thousands of members upstream.
Wouldn’t it be better to share this problem on a larger scale and receive input from knowledgeable people from all over Red Hat?
We organize our support teams around the product they support. We train our support engineers on the entirety of the product, and then deep dive into one of the many dozens of technologies that bring these products to life. By allowing this path to specialization, our Support Engineers rapidly earn credibility in their domain. Rather than learning a script, they learn the resources available to them for collaboration during troubleshooting with cross-functional teams. Rather than transferring ownership to another tier of Support, everyone within this specialty group already has access to the issue and works concurrently with their peers to make progress solving your problem.
While we direct the attention of the specifics of your case to specialized Support Engineers, we also share the takeaways internally to key stakeholders within Red Hat to improve our products and services. Teams in engineering want to know the problems reported by users. Teams in consulting want to know how to avoid issues when developing implementation plans for other customers. Teams in marketing want to know the best solutions already documented to share them with other customers proactively.
We believe in the benefits of sharing information to develop the best products and services, but in this case it also works directly to solve your problem as quickly as possible. Your ability to participate in the refinement of our products continues as you share your perspective through working your support case - Red Hat and our community of other customers thank you for your contributions!