So, you’ve been on the phone with the Service Department for the past three hours. The agent has asked you the same questions over and over even though they clearly have nothing to do with the problem. He has asked you to reboot, reset, reload and repeat at least a dozen times. You have now lost whatever slight amount of confidence you had in the pleasant but incompetent Support yahoo on the other end of the line. The problem has not improved, and in fact may now be worse than it was when you first decided you needed “help?” You finally ask to talk with the manager…after a seemingly endless wait, the manager comes on the line to assure you the company and all its personnel are sorry you are having this issue and that they are working REALLY hard on the problem. He goes on to tell you he “HOPES” it will be fixed soon. That does it; this problem will never be fixed!
Support organizations continue to repeat this scenario every day. Hope is NOT a plan. Success is rarely achieved without some sort of plan. Problems are rarely solved without a process. Troubleshooting can’t be random; it needs to be done logically, systematically. So if we accept that successful troubleshooting follows logic, why don’t we let the customer in on the plan?
I’m a firm believer in Action Planning. A past mentor of mine once said, “Jim, tell the customer what you are going to do for them, do it, and then tell them how good of a job you did.” When a Support team engages with the customer by first expressing an understanding of the problem’s impact, then taking the time to clearly establish the problem statement with the customer’s agreement, customer confidence is high and the first step to a successful engagement is in the books. Now, given the agreed problem statement, an action plan can be established, communicated and agreed to by all parties.
I know this seems like a lot of trouble for an issue that will likely be solved in less time it will take to do all of the above. I contend that this is one of those times when “slow is faster”. Obviously, the depth of the plan can and should be proportional to problem complexity, but beware of the all too common trap of thinking the next step will surely solve the problem. You have to keep asking yourself, “But what if it doesn’t?”
Know the problem, develop a logical troubleshooting plan, communicate, get agreement, proceed to step 1, communicate, proceed to step 2, communicate and so on. And if the plan needs to change, don’t go off script. Go back to the customer with the changes and get agreement on the new plan before moving forward. By the way, it is also a good idea to establish what things will look like when the problem is resolved. Often expectations are missed just because they are not understood up front.
Action Planning: The process and methodology of establishing an agreed to problem statement, identifying roles, timing, resource requirements, troubleshooting steps with expected results, agreement as to what constitutes problem resolution, and a communications plan that when executed, will meet or exceed customers’ expectations.
Hope is NOT a plan!