Nothing to hide

I remember being on an IT helpdesk as first line support. It was telephone support not face to face or email. This meant I was the first person people would speak to about their problem. So I gave the initial impression of the quality of support. I learnt a lot about how to build trust while supporting applications and products which weren't perfect.

I learnt that good support is more about explaining to people in their language what the problem is, or even that you're not yet sure so you've got to run a few tests, ask a few questions. I also learnt that long silences can build tension and anxiety. To prevent this I learnt to explain a little about what I was doing so that the person on the other end of the line knew that I was looking into their problem instead of ignoring it. Just a couple of words explanation at each point was all it took but it changed the tone of the entire call and frequently turned frustrated users into appreciative and trusting ones.

Since then it's what I've looked for as a mark of good service and of a good company. I don't expect perfect products and services because I don't believe they exist. I do expect good customer service because I know it does and should exist. Better to know you're in good hands if things go wrong than to pin all your hopes on it never going wrong.

I like working in an open source arena because I feel it encourages good customer service. Obviously not all cases are shining examples but the philosophy of openness and trust is what good customer service is grounded in. It's the idea of having nothing to hide.

What inspired this post is the experience I've been having recently with good support from Google and the guy behind android scripting environment. From google I found an issue in google docs in the chrome browser. I've already submitted a few tickets and was impressed how easy this was to do. This issue involving bullet lists in chrome is, I feel, a good example of how open they are prepared to be. There will be better examples of quality bug fixing. this is just a bug I've found and followed and I've seen things I like.

I didn't log the bug. It was easy to see it had already been reported and add my name to it to vote on its importance. So I already felt involved and I've been able to do my bit. I can see what's been done and that work is still going on. Obviously I'd like the bug fixed but sometimes things take time. Better to know that some one is looking at your bug and a fix will come in time. What I really like is the honest explanations and the diligence in which they put their thoughts down. They could have easily not included many of the little comments they've made such as http://trac.webkit.org/changeset/46200 That's the only patch in the revision range that touches editing and it's a followup to a patch that completely rewrites the way indenting is handled. I haven't tested it, but I'm confident that's the change we need to merge in. Is there a spreadsheet, tool or something I should update so this gets pulled in?

In my book admitting to the outside world that you don't know something is brave. It's also very trusting. yet for me I've learnt that by including the user in this conversation you're showing trust and that makes the user, in general, more likely to trust those involved.

Just seeing this, along with the responses to other bugs and the many that I see already listed makes me trust these developers and the products they produce mainly because they don't seem to hide away. They're willing to talk and open up about things that don't work and listen to my needs.

The same goes for the Android Scripting Environment hosted on Google code. This is a small example but it's been nice to see how quickly Damon Kohler, the developer, responds to issues and explains how things work. Again it's not rocket science. It's just about sharing the knowledge. I just find it's often the difference for me in whether I stick with a product or not. It's also often an underrated skill so when I see it I really like to notice it.