Have You Been Burned by a Tech Guy Before?

Written on May 4, 2010  |  by RP Mickler  |  Leave a Comment  | 

This week I had the good fortune to run into a new client. Ironically though it was in the course of their misfortune that I was introduced to them.

Apparently, a previous tech had given them a poor experience. The tech had bilked the company out of thousands of dollars in support and maintenance fees. Problems were never resolved and the tech eventually became unreachable. Beyond that, when I was able to look at the environment, I found the extent of the problem larger than just fraud and questionable professionalism: there were severe configuration issues that placed handicaps on how their computing environment was working, and, had introduced big security risks.

I wish I could say that I run into situations like this infrequently. Unfortunately, I can’t. Inevitably – and this is true of any professional discipline and not just tech – somebody will deliberately dupe their customer in an attempt to conceal their inexperience, failures, or mistakes; they might even bail, just as they did in this example. And because tech is such a black box, it’s difficult for non-technical managers to ascertain outcomes. All of this is unfortunately pretty common.

Myself, I try to tackle this problem head-on when I see stuff like this. My goal is to establish trust by wrapping myself in a blanket of accountability and to give all decision-making to my client. There’s a process that I follow. Have you been burned before? This is what I think your technical professional should do to make themselves accountable and trustworthy of your business.

1. Clarify the Concern. Especially in tech, it’s difficult to explain exactly what’s happening. The technician, though, should take the time to really understand the problem from the users and managers. The tech shouldn’t rush to judgment or assumption. Instead, they should clarify what the problem is before taking any action.

2. Clarify the Outcomes and Expectations. In plain and simple language, the tech should then clarify what their solution should do: network scanning and fax will work on all PC’s; the server will complete and error-free backup; the users will be able to access the desired website. Clarifying demonstrates an understanding of the problem, the expectations for resolution, and a simple measurement for success.

3. Explain the Options and Get Approval. After evaluating the situation technically, the technician should never – ever – simply act. Instead, the tech should be taking notes and looking at possible options. Then, those options, risks, and expenses should be totally explained to a decision-maker. The client, then, chooses the option and approves the action.

a. Think About a Second Opinion. If you’re a business owner and you’re concerned about the options available, make a phone call to another technical professional. Ask them what they think. See if the option sounds reasonable.

b. Get Recommendations. If you’re a business owner and you’re concerned about the tech’s ability to execute, make a phone call to their former clients. Ask them how the tech did. See if they would trust the contractor again.

c. Ask Questions. Now is the perfect time for the client to raise additional ideas or questions. Instead of just accepting what’s being handed to them, clients should ask critical questions that further defines outcomes and instills accountability.

4. Execute the Option. The technician should never be in a position to do something unilaterally then stick the client with an invoice. Instead, they should execute the option a client approved. That way, the client is in control.

5. Review the Concern. Afterwards, the client should be able to sit down with the tech and review the outcomes everybody agreed on. Does the network faxing process work? Is the webpage available to everyone? Does a log from a backup demonstrate no errors? Does the outcomes meet or even exceed expectation? Hopefully so. If not, the technician should go back and review additional options.

What’s important to note here is that management’s in charge. Management’s got a red-light/green-light to authorize action or suspend action; management has vested accountability into the technician’s results; management expects results. The next time you’re hiring a professional of any kind, think of this management process. A little bit of vendor management like this can go a long way in saving you money, time, and frustration. It will also help an IT vendor establish trust with you, so you can count on them in the future, and build a solid working relationship with them that’s based on delivering value.

All the best -

R