Technical Support is More Than Just Technical

When you get that call from a customer about technical support, what comes to your mind? What conversation will be running in your head? Most of the time, what comes to your head are procedures, techniques, and the step-by-step processes of resolving a technical issue by the book. I know. I did most of these things all the time.

There is also a lesson I learned about responding to a customer call. The lesson is: Not all calls for technical support are actually technical.

There were two identically configured servers serving a company manufacturing slippers for export. One December day it just refuse to make identical copies of their database into each other's hard disk as it is supposed to. The call came in a few days before Christmas. I always get these calls a few days before Christmas.

The company cannot afford not to have their servers back up each other's database because they are supposed to shut down the servers on Christmas Day for maintenance. The backup ensures business continuity after the Christmas season. The main office in Japan will be cut off from their manufacturing plant completely without the servers.

The company adopts a "Just in Time" manufacturing scheme which makes real-time connection critical to the manufacturing division. Added to this is the fact that the new design of their system is just one of only three in the whole Asia region. This means it's been tried only three times. There are no precedents yet of a downed server under this design. There are no ready answers if these servers crash. There are no references. There are no manuals to help us out once a crisis unfolds.

Our customer's representative naturally is the Manager for Management Information Systems. She was the one who recommended the system, the service provider of the database management system, and of course the hardware (from us). She put her reputation on the line in putting the system in place, now it is about to fail not just her department and company but her personally.

The provider of the software and database system also arrived on the same day. They were the first to be informed of the problem. We were all in a huddle: the MIS team of the customer, software provider, and us the hardware provider.

We knew that if the system will not be up by Christmas, top management will be looking for answers and eventually someone who will provide the answers for the fiasco. We did not need to hear from her who that someone will be because she knows the bucks stop at her doorstep.

I pulled out every piece of information about our hardware including references to the same installation in other countries. It was functioning as it should. Our contacts from systems design and software development were not very sure if they can work around the software and the database.

There was no technical reference to find out what exactly was happening to the software but there was also no reference that the problem is supposed to happen. In this industry, if the problem did not happen yet, it will not be in the manual. The software provider has not encountered the technical problem themselves. We were in a situation where we had no answers.

I was no longer concerned about the technical issue, I was concerned about her, the MIS Manager who trusted us. We are about to fail her. Technically, we can always blame the software but it does not help our customer, the MIS Manager. She will still be responsible if the system crashes due to a faulty systems design. We have to give her confidence again not in the design or the system but confidence in us.

As soon as I got a chance to talk to our own Business Systems Manager who also is our most experienced systems engineer, I confirmed that there was no way to go around the problem based on the existing design. The system will not be online as long as we start up the system using the existing design.

The problem shifted from tweaking with the design to simply getting the system up by Christmas. My solution was to let the database management system run on a single server but to do that we have to roll in hardware with a lot higher configuration and possibly a server from a different brand because it was available.

This server will be available within 24-hours. The alternative was to get it via Hongkong or Singapore which will take weeks. We have only several days before Christmas.

I was now asking our Business Systems Manager to stick his head out together with mine. I was recommending a course of action out of the books and totally against our protocols. We were recommending a solution that was not in our procedure plus I was about to recommend a brand replacement which was against marketing policy. Of course, I got a call from our CEO himself a few hours after they got wind of what we were about to do.

The position I shared with my CEO was to choose between the protection of a brand or the retention of a customer. My boss of course responded by giving me the classic "chicken and egg" logic. If we lose the brand we have nothing to sell, if we lose the customer we have nobody to sell to.

My response was, I can always reposition the same brand with the customer but we can not reposition customers in the greater scheme of our marketing strategy once we have lost them. Besides, if we lose the confidence of our customers, especially this particular customer, it does not really matter what brand we carry. The customer will have nothing to do with us after this crisis.

We knew we could pull off technically the solution we had in mind, but we need also to act on our customer's fear. The fear of failure in the eyes of her superiors. The MIS Manager was up for more than 24 hours already.

We were also going to be up almost twenty hours if she does not go home and leave the factory. The lack of sleep was increasing her anxiety and stress. It was difficult talking to her. She had no breakfast when we met her that morning. It was a good thing we brought along food for her and her team.

Looking back this is what we did:

We did our homework - Research, research, research
We immediately formed a research team of two (2) people who will research both software and hardware issues of the problem using the most specific information we got about the design of the system.

Since we always have a profile of our customers right down to their favorite dessert, it was easy for us to know what will immediately cheer up our MIS Manager. Sweet food and in that very specific situation a bit of protein (burgers) and hot drink (coffee). Food can always calm people down.

Another thing I learned is that people are easier to talk to if they are munching burgers or doughnuts with steaming hot coffee. You think this is insignificant, try talking to someone who is hungry and without sleep for twenty-four hours about a problem she thinks you have caused. I have not read about this approach in any customer or sales manual but it always worked for me for many years.

Informed Top Management - Yours and Your Customer
After we have the facts straight from a direct interview of the customer and our research, we prepared a brief background of the issue, what we are currently doing to resolve the technical issue, and sent it via email to our superiors.

In the case of our customer, we have to ask the permission of the MIS Manager when to start informing her superiors, who will do the disclosure, how to deliver the information and how much detail to disclose. It has to be her call because she has a lot more at stake.

Our own CEO however was already advised of the pertinent perspectives of the issues in the event our customer's superior starts calling. The main objective was to keep things in perspective and to keep stakeholders calm since there is no crisis to speak of yet.

Get the Blessing of Top Management
We informed our superiors of what we intended to do. I had no choice. I was asking them to roll in an asset worth thousands of dollars just as a stand-in solution. It was not a sale. There were no margins to speak of. It was just a plain and simple first-aid solution to help a customer. Only the blessing of top management can get the wheels rolling towards resolving the issue. An expensive one at that.

Get Other Stakeholders in ASAP
Finding the right hardware specification was just one part of the solution. The other part is the software that runs the database. Although we can handle the technical aspect of the hardware design, we still need to talk to the software guys to make the whole system work.

We also need to talk to the MIS team of the customer to understand how the database is supposed to work for the company. All of them need to hear the plan because each of them has technical capabilities to execute different aspects of the plan.

Form a Unified Plan
Each team has a role to play but roles only work if it moves under a cohesive plan of action. You can learn how to come up with a great plan or you can learn it as you go but make one. Get all the stakeholders and put the plan together. More importantly, execute.

I said a lot of things that really only boils down to a simple thing: Not all technical issues call for technical solutions. What seems to be a technical issue may just require some form of human understanding and discernment and acting on them.