Communication in a busy support environment is vital. Nothing happens in isolation and the free flow of information from you to your co-workers and back can make for an efficient environment and also help present a unified front to customers.
There is nothing that makes you and your company look unprofessional to external customers and suppliers more than someone calling or emailing them about something a) you have already been notified about, such as planned downtime, b) having to repeat the exact same information to yet another tech about the problem they logged earlier in the day, or c) two techs calling about the same problem within minutes of each other.
They may not say it to you on the phone, and if they do count yourself lucky that they have as you are now aware of it and can catch this bad habit and hopefully with managements cooperation nip it in the bud. But you have no idea what they are thinking and saying to the right people in their company that could affect the next contract renewal when it comes around. Sure you are just a "low level support grunt" how can this affect you, yeah it is going to suck for the sales guy but hey that comes with the territory, right? Well if enough companies decide to do business elsewhere than your current workplace, there goes your livelihood (as with most of the people in this world you probably rely on one income source) and replacing that is not going to be as fast or as easy as you imagine from within "safe" employment.
So how can you improve communication, well in a support environment, be it the traditional internal IT department or an outsourced help/service desk, you should have four (well five) lines of communication.
So what are these lines you speak of?
1. Talking
Yep that old fashioned get up and go talk to someone and tell them something technique (or if you want to tech it up and save burning a few calories, telephone them). But nothing beats a quick face to face information dump and you also make sure that they have got the information. Though just to be sure you should follow it up with the next line of communication.
2. Email
Email is great for two things, the communication is asynchronous, you can fire and forget and carry on with what you are doing. Say for example you have a router down to site a quick email fired off to your team even with a one liner subject like "Main Campus Building A router down, working on it" will alert your team that the servers behind this router are inaccessible so they don't need to waste time problem solving that. It also allows your first liners to smoothly handle calls or even call designated department contacts to stem the inevitable flow of "is the network down?" calls. Another advantage of email is it gives you an audit trail (always good if you need to talk to management post outage) and also covers your butt as you have something with a time stamp showing when you were aware of the problem and working on it (though of course this would have been logged in your ticketing system, as any good sys admin would). Which brings us to our third line of communication.
3. Your ticketing system
Not a lot of people think of the ticket/case/incident logging system as a form of communication but it is, say you are working on a complex case and encounter a bus incident. No I don't mean the bus in your PC dies, I mean you get hit by a bus and are not able to communicate with your co-workers, having good call notes that are able to communicate the problem and the steps and logic you have used up until the bus incident will go a long way to help your colleagues out while you are mending and not thinking about work (you aren't thinking about work, right?) It also ensures continuity of service to the customer even if you experience a less catastrophic event such as a long boring, er... I mean productive meeting that you absolutely can't get out of. Someone else can pick up where you left off and carry on providing that gold level of service you and your team are renowned for.
4. Instant Messenger (or IM to the internet generation)
Instant messengers are really useful in a support environment as they are for gossiping or organising that night out on the town with your buddies or gal pals. They can allow you to fill someone in live while they are on the phone to the customer with helpful information so y'all can look smooth to external clients. Much like a news reader reading autocue while listening to their director over the in ear thingy. IM is also great for asking quick questions or pointing people at useful technical articles and other on-line resources. IM is pretty easy to set up, there are even some free Jabber based servers and clients if you are on a tight budget. I would not recommend using a public based IM service such as Google Chat or MSN Messenger simply because you may need to send things like server IPs and names, and other bits of sensitive information via IM and you want to control where this flows through. I should not have to mention that you should never send a user name or password via IM (or even email for that matter, but secure thinking is whole other topic).
But wait you said there were five lines of communication, and I sure did. The final line of communication is your documentation. You do document the systems you support? Of course you do. Having good, or even some documentation can go a long way to fill in the gaps without the newly hired staff and administrators needing to trek up guru mountain to ask those on high how it all hangs together. Duct tape and bits of string normally, if anyone asks. So having a good, well populated documentation system can go a long way and save money and time in the long run. Something as basic as a network share with sub directories of documents is better than nothing. Or you could use SharePoint from Microsoft for an on-line collaborative project. Another option going down the open source route would be Mediawiki, the same technology that powers that great source of movie and comic book lore, Wikipedia. As this was designed for the common man on the street to contribute to editing and updating for System Administrators should be a breeze. And for the text config file editing averse Windows admins out there it can even be set up on Ubuntu server (sudo apt-get really is not scary at all) with the very friendly Cherokee web server (no need to edit Apache or Nginx config files in Vim or even *shock* Nano). Pop that into a VM on your ESXi/Vsphere set-up and you are good to go.
Communication does not need to be hard and there are multiple ways in the technical support sector to achieve this, if you take away one thought from this article I would want it to be communicate well and communicate early. If you think something is going to bite someone in the ass, give them a heads up, they'll appreciate it and you.
No comments:
Post a Comment