Friday, June 15, 2007

Know What You Know

Wayne posted a note here: that got me thinking about how we handle vendors and 3rd part technical support.

One of the mantras in our company is "Know What You Know."

When you know something -- really understand it well enough to teach it -- then don't let vendors trick you into not trusting yourself.

If you don't know something, then you need to assume the technician on the other end of the phone does.

But if you do know something, explain that to the technician and make him work with your assumptions.

Here's an example.

We had a client whose new laptop would not connect to RWW via a Verizon Wireless internet card.

RWW worked. This user could log in by other means. This laptop could log in if connected to the internet by other means.

Called Verizon. Technician has never heard of RWW (can't blame him for that). Asks what the port number is.

Verizon technician says "We block port 4125."

Not "Maybe we block . . ." or "I wonder if we block . . .."

He said "We block port 4125."

And we said "No you don't." Because we know what we know. We know it worked before, and we know it works with other clients.

You're stabbing in the dark. So unless you can prove that you block port 4125, let's work under the assumption that you don't.

Of course we found the problem, and of course the ISP didn't block 4125.

The point is: We didn't waste a bunch of time wandering down the wrong path just because the tech on the other end of the phone sounded confident when he was grasping at straws.

It's very important, in a potentially stressful situation, to know what you know. Don't let someone else's fishing expedition send you off on the wrong path.

Along these lines, we always have a TSR Log -- Troubleshooting and Repair Log -- for any incident that lasts more than fifteen minutes. With this log we can state very clearly what we've tried and what the results were. We can make a change and then undo it with confidence because we have a map of where we've been.

The TSR Log also helps us keep the phone support people on track. They don't get to try the same "fix" three times. This is especially important when the call is escalated. The tech on the phone my be doing due diligence as far as he's concerned, but to us it's just burning time if we've already tried the fix.

Save yourself time, money, and frustration: know what you know.

For another example, see


  1. Can you tell me more about you solved the port 4125 problem as I am having the same issue thanks

  2. Again, the point of this post is to slow down and make sure you're chasing the right ghost.

    In this case, the case notes say that this client was trying to connect to the wrong machine name.

    Once we duplicated the problem, and were able to duplicate success, we then proceeded to educate the client.

    The point remains: If we had listened to the "professional" on the tech support line, we would have wasted a lot of time, effort, and energy trying to solve a problem that really wasn't at the core of the issue.


Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!