The Support Engineer’s Creed

What if Vince Lombardi was a software support engineer? He might make up a creed that sounded something like this…

My mission is to provide Best of Class product support in my industry

I am fortified by the singleness of my purpose and my commitment to excellence

Recognizing that I am the first responder, the first line of defense between the user community and my company’s software defects, I will react quickly to user issues and let users know their issue will receive *immediate* attention

I will effectively triage each issue to ensure the issues are quickly and accurately prioritized and handled in the proper order. 

I am first and foremost an engineer. As an Engineer, I will think and speak in objective terms, with economy of words. I will communicate only relevant information and communicate it logically, with focus and precision leaving out unnecessary “noise” or subjective commentary.

I will gather all important information and empirical data and thoroughly research all issues before making any judgments, recommendations or suggesting solutions – or even commenting on same. A slower informed response is better than a rush to judgment.

I will always presume our software is defective until proven otherwise and give all users full benefit of the doubt when posting an issue. 

I will never let support requests go unanswered. During the regular work week a response should never take more than 1 hour during work day or 17 hours in total (i.e. 5 PM to 9 AM). I will strive to provide off hours support to the best of my ability. I always be in the office by the time phone support hours begin and remain until they are over – only leaving my post when my desk is covered.

I will be mission capable – fully product trained, well versed in all product features, functionality and limitations. I will be a certified expert in relevant technologies.

I will be honest and direct with customers and recognize it is better to indicate what I don’t know (and strive to quickly learn) than speak from ignorance. In this way I will earn the users trust.

I will avoid questioning how a customer uses our software or attribute it’s unique use to source of problem / issue. 

I will leverage all resources at my disposal including developers, help files, search engines, and technical websites to obtain information required to answer support questions. It is better to succeed in answering question with help then fail on my own.

I will leverage technology to be able to remotely dial into and inspect user configurations when remote diagnostics fail to uncover the problem

I will always be courteous and professional in my correspondence with users. 

I will collect, organize and transmit all feature requests in an efficient manner to management for evaluation.

I will convert all applicable/relevant bugs and issues to reproducible test cases and transmit to testing in an efficient and organized manner.

I will collect and report potential FAQs and Help File content to technical writer in an efficient and organized manner.

Understanding that my team will personally bear the brunt of quality problems, I will test all builds myself before they are released and ensure that we aren’t foisting problems, defects or others issues onto the customers that QA may have missed.

“The best support issue is one that the customer never has to experience” – Brian Lockwood

I will recognize that the quality of support is ultimately measured in the time it takes to deliver a resolution, in the form of a fix. Defects need to be duplicated, fix and made available to the customer via patches, as rapidly as possible.

I will never consider customers difficult but challenging. I am able to overlook anger and frustration and empathize with the customer to validate their emotions. I realize the customer isn’t angry at me but problems that are our responsibility to resolve 

“Your most unhappy customers are your greatest source of learning” – Bill Gates

I understand that every time the user doesn’t know how to perform an action, do a task or otherwise use our software, it is a failure of usability that must be treated like a bug and fixed.

Documentation, knowledge base articles, FAQs and other resources should be high quality resources that are made available to the customer that may augment the support I personally provide, but I will never presume, expect or require that they read them.

 

July 4, 2018