Thursday, October 12, 2006

Interface & communication - part 3 "the helpdesk"


Interface & communication - part 3 "the helpdesk"

Now I'm going to tell an help-desk story that shows in detail what happens when clear communication occurs among company segments and, in this case, the customer. The company shall remain nameless and a few key points will be changed to make it not identifiable. The companyThere was a software house. It made a couple of successful consultingware applications for media agency and media resellers. In its niche, it was the dominating company. They achieved this position because of lack of competition and because of the huge expertise they could count on. In few years they really ate up the market in an important European country. The problemUnluckily, founders where all programmers, who lacked, by that time, the experience required for managing a real company. As their unparalleled products made their way in the market, management requirements grew as well. So did the necessity for user assistance. Being a bit naïve, products lacked the administrative and auditing features and the ease of configuration required to let the users manage them by themselves. After all, a real programmer can check logs, execute sql statements, test connections, debug code, etc. etc. If a user signalled an anomalous behaviour, the programmer, could log on remotely to the customer system and sort the problem out. This is ok, but what if 5000 almost untrained users phone in each time they start the application? It was soon evident that no real work could be done with all those calls and e-mails coming in. Programmers were overwhelmed by the amount of the support required. Solution #1The growing company hired a help desk assistant. A young girl joined the company and was appointed to answer to incoming calls. She was trained with the applications, this is normal, and she went out in the street. The idea behind the hiring was that developers had to focus only on technical related issues and she could answer all the other questions. Unluckily, they where wrong. She was able to reply to simpler questions about product usage, but the bulk of enquiries were about non obvious behaviours of the software that could not be investigated by her because she was not technical enough. More, she become an annoying voice in developers hears, always chasing them to have the tickets closed. Ah, yes, there was no trouble ticketing software for her, it was too much expensive. She was a cost, and service and workload did not improve. Solution #2Try to teach her how to execute sql, parse logs etc. and hire someone else to help her. The help desk crew grew to two and three and four, and one of the founders was appointed as the help desk supervisor. Maybe the activity was a bit more efficient, but the issues stayed there. Slowly, while the number of customers grew, the amount of work generated by help desk requests grew as well to an alarming level. There was no room left for new jobs. There was no shortage of new orders, there was the need to improve the products and, most of all, there was the need to complement products with those auditing and debugging features that could relieve the help desk workload. All of these tasks went deathly slow because of the distraction cause by assistance. More, being naïve as already said, the founders disregarded to sign consistent support contracts. Help desk costs were killing the company. Solution #3 the almost good trySlowly, the conscience that a modern process had to be set up rose and the founders had the humility to leave aside their previous experiences and begin to think manager-like. The first improvement was to provide the help desk operators with a home made agent-less monitoring software that allowed fast customers' log file parsing and execution of pre-built and parameterized queries against the databases. This step alone led to a great improvement. The operators were able to diagnose the bulk of the issues reported by the users by themselves. Even if they could not intervene directly, developers were provided with all the preliminary information required to fix the problem, thus sparing time. This may look like a techie solution but, if thought about, it focuses also on the quality of communication between the operators and programmers. If the responsibility for diagnose had to be moved to the help desk, it was also crucial that developers could receive complete information. The software was designed to produce a test log, which describes all the tests made, and that log is what developers receive. Always the same format attached or pasted in a mail or printed on paper. The second improvement was really a process improvement. A set of escalation rules was established. Company employees numbered in the range of 30's, split among developers, consultants and help desk operators. Two consultants were appointed to being the first escalation level. All the requests that the operators could not close by themselves were reported to those two, which, in turn, tried to close the requests or scale them again to developers. At the beginning was a bit of confusion while planning developers' time, reduced by blocking out in advance the time available for service requests. These two improvements greatly reduced the total workload required to assist customers but still two headaches were hanging around. First, all communications inside the company relied on e-mail and printed documents. People did keep long excel lists to monitor the requests flow, wasting time to keep them updated. There was no one-stop point where the status of a request could be assessed by everyone who needed. Some request got lost in the mail/paper clutter which plagues each company. Second, collecting precise statistics was extremely hard, since there was no central database for them. Solution #4 the good oneAt last, a help desk solution was chosen. It was a commercial web-based package whose name I'm not authorized to disclose, that allowed a fully integrated management of requests. The single feature that made the difference was its ability to collect all the data in a single central point. The software was able to collect service requests from mail, direct input and the web, and to analyze, organize and prioritize them in the way that seemed the most convenient. All the communication between the requester and the operator was managed within the package, as the requester was allowed to check a web page with the status of the request and each communication could be mailed directly from within the package. There was a single repository for all the knowledge required for the help desk process, which was kept under strict control. Lessons learnedGoing back to our initial argument, we can understand well that the real key point for each improvement is related to the quality of communication. A clear and standardized information flow streamlined the process to the point where it could flow with the least effort. Standardization of diagnose spared inquiry time. Standardization of escalation allowed better schedules. Standardization of communication interface shrunk the time required for requests management. There is no way in which a standardized interface has limited people's creativity or peculiar abilities. Definitely, there's a huge advantage in standardizing communication, but probably you already knew that.


Post a Comment

<< Home