Most technical issues are resolvable. A well-trained, capable technical support representative will usually be able to find a good resolution to nearly any problem – given enough time. Time, however, is a very expensive commodity. In the technical support market, where billing is based on the number of minutes on the phone and contracts may be in the millions of dollars, it only makes sense to minimize the time a representative spends on each issue. And, of course, the sooner a resolution is found the happier the customer will be. This means that the most crucial tool in a support environment is a well-populated database containing known problems and solutions. Traditionally such a database has been a slowly-changing and maintained by a small group of contributors. This approach has value, but also has a great many drawbacks. There is a need for a faster, more accessible database which can be updated by any user – a wiki.
It’s unavoidable that the first instance of a new problem will be very time-consuming to resolve. New problems can be baffling, frustrating, and call for a large amount of research. There’s no way around this fact of life in the technical support world. What can be avoided, however, is needlessly duplicating that effort. Costly enough that there is a major investment when a problem is first encountered, but what sense is there in forcing technicians to reproduce that same work over again?
Yet that is exactly what happens in a company with poor knowledge management. Even though one or more representatives have found the solution to a difficult problem, if that solution isn’t shared then each technician is doomed to walk the same path until each representative has become experienced with the problem. In spite of the clear inefficiencies of this arrangement, it is the de facto standard on most helpdesks!
The obvious solution is to create clear documentation anticipating the issues a support representative will face and providing straightforward instructions for resolving them. Provided with such resources, the representatives can focus on implementing fixes rather than costly and time-consuming research. It may seem very attractive to devote a small cadre of highly skilled workers to creating such documentation, and save money by higher less technically-savvy personnel to handle the calls. Such a solution fails to comprehend the magnitude of the problem.
The number of new scenarios is nearly truly remarkable. Consider the possibilities simply for an online service: there are thousands of broadband internet service providers in America today. Hundreds of different modems and routers are on the market. And the possible hardware and software configurations in a home computer are almost infinite. This can be a major problem from a technical support perspective: seemingly minor changes may prevent a crucial service or component from working. This means that there are a nearly infinite number of possible support problems facing any helpdesk. Even if the environment has a very limited scope, there are invariably enough factors to constantly produce new and different problems.
This means that a small, dedicated team of high skilled technical workers simply cannot hope to produce all the procedures which the lower support tiers will require. While the higher tier personnel fall behind in creating new procedures, the lower tiers grow frustrated with the inadequate documentation provided to them. They revert to creating their own processes. Call times rise, customers grow angry, and the overall effectiveness of the support structure suffers.
It doesn’t have to be this way.
The key is in capturing knowledge when it is discovered. Knowing that the technicians will work to find new solutions when new problems are encountered, harness that knowledge for later subsequent instances. Doing so will allow the knowledge base to accumulate information as it becomes relevant. No need for a separate group of people developing procedures which may prove difficult to implement nor for each technician to treat each problem as a unique one: just a database containing the experience of the entire organization.
But how is that knowledge to be captured? That’s where wikis come in. The concept of a wiki is simple, but can seem very scary to a traditional organization. The idea is to let people with knowledge enter that knowledge into a database. This means bypassing the entire request, review, and dissemination process. The result is much faster than traditional documentation processes – in fact, the term “wiki” comes from the Hawaiian word “wikiwiki”, which means “faster, faster”. With only one step, information reaches a wiki as soon as it is discovered, making it immediately available to all tiers of the support structure. Rather than months to populate a knowledgebase, a wiki grows organically as the knowledge becomes available – usually at a far greater rate than such knowledge can be accumulated using traditional processes.
Of course, speed does come at a price. A lengthy review process does serve to cull out inaccurate information. The beauty of a wiki, however, is that changes can happen just as quickly – including corrections. This means that as soon as an entry is found to be inaccurate it can be corrected. This is especially valuable in dealing with rapidly-changing environments, where a correct procedure may be broken or rendered obsolete without warning.
But, what good is a fast tool which takes forever to implement? Fortunately, wikis are relatively simple pieces of software, able to be added to existing servers quickly and cheaply. In fact, there may already be an unused wiki installed on an organization’s servers! Wikis are frequently bundled with other knowledge management software, especially with Microsoft Office SharePoint Server and Windows SharePoint Services v3.0. This means that setting up a wiki may be one of the simplest – and wisest – changes an organization can make.
Wikis are an invaluable tool in disseminating information in a high-speed business environment. It can be scary to allow all levels of an organization to contribute to the knowledge base, free of direct oversight. However, the flow of information provides benefits which far exceed these concerns.