The Technical Support Scientist… Deductive Reasoning at its Best

By Bill Foster, Director of Technical Support, Optical Image Technology, Inc.

(Note: This article was originally published in the September 2006 edition of Document eNotes)

View printable PDF (opens in new window)

Thoughts of scientists conjure diverse images: an astronomer whose perseverance in astronomical calculations leads to the discovery of a new planet; a chemist who utilizes a Bunsen burner to facilitate the reaction of a chemical mixture; or a paleontologist discovering the existence of a fossil in a painstakingly excavated area. Scientists are notorious for active, diligent, and systematic research and testing. Software Technical Support Representatives (TSRs) possess similar traits. Scientists yearn to understand the complexities of the world. TSRs strive to answer customers’ questions.

Scientists and TSRs follow a consistent course of action when seeking solutions. This methodology, known to scientists as the hypothetical-deductive method, enables them to identify problems, predict outcomes, and confirm solutions. They must support their hypotheses with trials and tests that prove the validity of their data and results. By following the hypothetical-deductive method, answers can be tested and recorded. A TSR must be able to support and prove every answer that is provided, and ensure that customers are satisfied with the resolution. Interaction and communication between the TSR and the customer, when coupled with this methodology, help to ensure success.

Identify the Issue

Good scientists and TSRs listen, observe, and collect facts. A TSR asks endless questions, much like a scientist. Why isn’t the module functioning properly? Why isn’t the software achieving the desired results? Is the system searching through the proper database?

Through astute questioning, the TSR can assess the environmental variables and begin to identify the issue. This process leads to more observation and refinement, until he is able to positively identify the specific situation that is causing the problem.

Example: A customer repeatedly fails to retrieve files. The TSR attempts to isolate the problem with a series of questions and ultimately identify the situation in which this problem occurs. Does it only occur on one computer, or are co-workers experiencing similar problems?

Not all customer inquiries are so simple. Software issues can range from an improper value setting to a multifaceted problem. During the question and answer period, a TSR will discover the user’s capabilities; customers vary from entry-level technicians through technical gurus. A TSR must be able to interact with customers at all levels. Explaining a menu option to an entry level person differs dramatically from passing key information to the high-end administrator who is experiencing system-wide problems. For a TSR, each day is an education!

Predict the Outcome

Identifying the issue may not be easy. One way a TSR assesses the situation is to make a prediction regarding the outcome, which helps to direct the questions. Once the situation is assessed, the TSR will begin to test his theories and attempt to redirect the outcome.

Example: A TSR speaks to a user who is unable to retrieve files. The TSR has the user review his computer settings and network access because he predicts that the problem stems from improper configuration. If the error is system-wide and every worker experiences problems, the TSR might have the caller examine the global settings because the prediction might be related to network access.

Prediction is defined in terms of how the software is expected to respond, and is subsequently tested to accept or deny the prediction. Through deductive reasoning, and trial and error, the TSR will test different scenarios. Depending on the results of those tests, a TSR will adjust his prediction and propose new questions and key steps for the user to take.

Confirm the Outcome

The prediction must be correct in order to move on and confirm the outcome; otherwise the TSR will continue with the prediction phase. Ideally the outcome, at a basic level, will reflect the exact prediction that the scientist or TSR expected. Based on scientific reasoning, all hypotheses will have been ruled out or modified. During the outcome confirmation phase, the user will be asked to test functions for proper performance and expected results.

Example: The TSR confirms that the customer’s inability to retrieve files is due to “out of sync” computer settings. He provides a solution by working with an administrator to restore the settings and ensure that all executable codes are directed correctly.

Pinpoint the problem. Ask the right questions. Isolate the problem. Reproduce it if necessary. Finding the right solution quickly is fundamental to the support process. Scientists and TSRs will engage their counterparts — for TSRs, that includes members of the development, quality assurance, or testing teams — for a second opinion when necessary. Ultimately, it is human nature to find answers because humans are innately curious. Good TSRs have both a natural curiosity and a strong desire to serve their customers.

Sharing Knowledge

Scientists and TSRs are specialists. They are required to know chemical configurations or software products in their entirety, since they are professional technicians. TSRs are valued by their customers as experts. A customer expects a TSR to have a high level of knowledge about the systems he is utilizing. In a software company, product knowledge must be disseminated to provide the TSR with the expertise the customer requires. A TSR is expected to be educated about different operating systems and how they interact with the software. He should be aware of the various databases that the customers utilize, and coding languages that make up the systems.

To broaden the knowledge and help the TSR identify and isolate the potential problem, customers need to inform TSRs of new system upgrades or other software installments that are scheduled. Upgrades or system changes can affect other global software packages. If the TSRs are given advance notice of upgrades, they can be prepared if questions arise.

Adding Human Care to Scientific Methodology

Identify, Predict and Confirm — the Hypothetical-Deductive Method — is good methodology for any software support team. Combined with a sincere desire to be helpful, this method provides scientific application for technical issues.

Comments from technology users about technical software support put these requirements into perspective. Phil Nielsen, a manager at Kinecta Federal Credit Union, states, “Good vendors should stand behind their products from top to bottom. They should provide the best service possible to get their customers up and running. Good support representatives should listen and want to solve problems. They should want their clients to succeed.” Steve Emrick, CDIA+, Senior Director of Imaging Technology at BMI, adds, “A good technology company is never too big to care.”

The American Consumer Satisfaction Index (ACSI), which evaluates factors such as complaints and retention on a quarterly basis, polls customers of various industries who play a major role within their sectors. Industry respondents from the Information Industry, which includes software, reported a 75% satisfaction rate. As mentioned in Baseline magazine (December 2005), personal service prevents customer loss. A wise vendor takes the time and makes the effort to ensure top-quality, personal service, not only through their support department, but company-wide.

Bill Foster is Director of Technical Support of Optical Image Technology, Inc. The quotes were provided by customers using Optical Image Technology’s DocFinity software and services. For more information, please visit www.docfinity.com or call 814-238-0038