I’ve spent more than 9 years in a customer-facing role for one of the largest IT product companies in the world. I had the opportunity to successfully led multiple teams across different time zones (APGC/EMEA/North America) to deliver wonderful technical support experience for the cloud productivity suites that impact millions of users.
These are some of the best practices or key requirements I feel can be useful if you’re planning to build a team of technical support engineers.
Customer Empathy
This is supercritical. Often technical engineers tend to focus more on the technical part of an issue and try to resolve it as soon as possible, which is not bad. Ultimately, customers always want their issues to be resolved faster.
Support engineers often get first-hand feedback on a broken software or system and the impact the customers have to bear. A great support engineer listens to the customer patiently and let them share their bad experiences and vent out their frustrations. He keeps documenting those and identifies the key impact areas that need to be fixed apart from the main technical issue.
It may not be realistic for a Support Engineer to fix all the problems (as some may need the engagement of support leadership, customer success, or engineering team) but a support engineer can let the customer know that he is also thinking about the challenges from his position as well. We often term this as putting ourselves in a customer’s shoes to feel the impact and pressure he is going through.
Driving Accountability
Everyone understands that a support engineer may not be able to solve one or multiple issues by himself. But most customers really want someone to be accountable and liaise internally to drive those issues toward resolution.
I’ve noticed a general trend of support engineers just owning the issue that they deal with and would not like to show the intent of owning anything which is not in their support knowledge or boundaries. This is a mistake and an opportunity lost.
Adhering to Compliance
Support engineers need to be very careful with the various information security guidelines, and country and regions specific data handling procedures while troubleshooting an issue with the customers. Unknowingly or unwillingly, support engineers can cause compliance breaches which can cause huge financial and legal impacts not only to the customers but also to the product organizations too. It can jeopardize years of hard work and the reputation of a company.
The other aspect is transparency. Support engineers are expected to be transparent with the customer in terms of how data is handled, sharing progress or any bad news, etc. This helps in building customer trust in the long run.
Utilizing feedbacks
But there are times when customers carry their past bad experiences and perceptions. I’ve seen engineers tend to ignore that. It’s a mistake and an opportunity lost to turn around customer experience and change perceptions. In such instances, it’s a good idea to attempt to ask customers about their past experiences and what went wrong. Some valuable feedback can be received from the customers to improve the process. Acknowledging the same and engaging leadership or a customer success team can win back customer trust not only at the individual level but also at the organizational level.
Support engineers should also encourage customers to share product improvement feedback. Understanding the customers’ needs and evolving products or services around it is one of the crucial factors for successful products, and services.
Resource-fullness
Let’s be realistic. A support engineer may not be able to resolve issues on his own all the time. But, he should be able to get the job done by reaching out to the relevant resources, and experts within the organization. Finding out the root cause and helping customers to avoid repeating the mistakes in the future can be extremely helpful and customers mostly appreciate it.
Expectation Management
Defining the scope of the support engagement and sharing a clear set of documented expectations in the entire lifecycle of the support engagement can be helpful. This can help support engineers to avoid getting into a conflicting situation and at the same time, it makes the engineer accountable to meet the customer’s expectations. It brings clarity and helps in maintaining transparency.
Strong Communication Skills
Communication skill plays a crucial role to provide an awesome support experience to customers. One does not need to be a native speaker to master this art. I’ve seen many people not so fluent in the customer’s preferred language but still aced to provide wonderful support experience through their effective communication skills. They used to listen actively, cross-question/probe, focused on building trust and transparency, and were always accountable.
Strong Troubleshooting Skills
Troubleshooting skills should be the strongest weapon in a support engineer’s arsenal. Fixing an issue with the least amount spent significantly contributes to a positive support experience. Customers want their issues to be resolved faster so that they can move on with other priorities. It’s a win-win situation for both customers and providers.
The following are the key troubleshooting skills needed:
- Probing and cross-questioning to scope the issue
- Solid isolation techniques to narrow down the specific scenario or environment when the issue occurs
- Avoiding assumptions wherever possible
- Knowledge of relevant customer-facing and internal diagnostic logs and tools to troubleshoot issues
- Identifying technical or operational roadblocks as soon as possible so that the right resources can be engaged
- Good understanding of the product features (different use cases), architectures (including the technology used to build the product)
- Quick learning and swarming with different resources to gain knowledge or arrange experts to resolve the issue
Consulting skills
This goes a long way to drive product adoption and best practices. It also helps reduce support tickets thus optimizing cost as the incorrect or sub-optimal implementation of any products or services often results in users facing issues or the products, services may not work as expected.
So, whenever a support engineer works on a support ticket with the customer, he should evaluate and advise the customer whenever possible on how best the product should be used. Support engineers should also try to understand if there are any powerful product features that customers do not use due to lack of awareness or training and educate them if it’s a quick thing to do or else engages the Customer Success or relevant team to get the readiness session delivered.
Building Partnership
If the support team can do most of the above successfully then it can help create a strong partnership with the customers. Without an active and engaging customer base, products or services lose a very crucial opportunity to evolve and the competitors often take the benefit.
Structured Escalation Matrix
Both customer and technical support engineers should be aware of the external (customer-specific) and internal escalation paths. If a customer knows the escalation path then he can easily reach out to the correct person instead of escalating it to company executives or through social media or legal routes.
Similarly, if an engineer is well aware of the technical or operational escalation paths then the right resources can be engaged on priority to mitigate the customer escalation.
Strong Knowledge Base:
Known and possible support issues related to product features should be well documented in a centralized knowledgebase. The knowledgebase should clearly mention the data collection, isolation, troubleshooting steps, and escalation guidelines. Knowledgebase should be frequently reviewed and updated based on product or feature changes.
An organization needs to have a solid customer support framework or process. It should document all the necessary activities, to-dos, and not-to-dos lists stored inside a centralized repository to ensure everyone has access to it. The process should be regularly reviewed to incorporate required changes based on the lessons learned or regulatory, compliance-related changes.
Please note that these are completely my thoughts and personal opinions. I’m more than eager to learn from your experience so please feel free to share your thoughts and perspectives.
Thanks for your time.
