TWiki Success Story of TakeFive

Note:

The SNiFF+ knowledge base content has been merged into the Wind River support web site. The sample links in this topic are no longer valid. See also TWikiSuccessStoryOfWindRiver. -- PeterThoeny - 13 Nov 2002

Summary

TWiki was developed at TakeFive Software (a Wind River company as of mid February 2000) to be used as a dynamic intranet tool and as a knowledge base for technical support. TWiki helped to increase the information flow within the company and reduced the number of customer support calls.

Situation before using TWiki

(1) We had an Intranet that had limited amount of technical information and was kind of outdated. The main problem was the "one webmaster syndrome", e.g. it was too complicated to request an update of the content.

(2) The SNiFF+ product of TakeFive is a powerful, but rather complex piece of software, sometimes challenging to support. Also, our support engineers are located in different time zones and countries like USA, Austria, England. That means it is not always possible to ask a question to the colleague sitting in the next cubicle.

Deployment of TWiki for Customer Support

(1) All the intranet content for customer support has been moved into TWiki. Our support engineers can maintain the content, thus eliminating the "one webmaster syndrome". One concern of the management was that this could lead to chaotic content. This is not the case because all changes are authenticated and under revision control. It is easy to fix incorrect or insufficient information.

The intranet content now is comprehensive and up to date. This is because it is so easy to add or change content. This in turn helps to disseminate information from the software factory into the field.

(2) We set up a TWiki web as a KB (knowledge base), similar to the sample setup in the TWiki.Know web here on this server. Our support engineers entered hundreds of entries over time. The TWiki KB allows our support engineers to have access to extensive information that is always up to date. Content is created and updated by support engineers on a daily basis, if a support engineers sees outdated information he/she can fix it on the spot.

A very important aspect is the email notification when KB content changes. This is used by senior engineers to review and update content. It is also a nice way to hone trouble shooting skills of less senior people who regularly read the changes of the KB.

Our support engineers search the internal TWiki knowledge base when a customer calls or sends an email with a problem. Many times it is possible to give an immediate answer, thus increasing the customer satisfaction. If no solution can be found it can be easily added to the KB once investigated, ready to be used by other team members.

We used the TWikiCategoryTable feature to maintain and categorize our KB for support. Based on the category we publish a subset of the internal KB automatically to our web site:

Public Support Knowledge Base at http://www.takefive.com/support/kb.html , searchable at http://www.takefive.com/nav/searchfaq.html

Public FAQ at http://www.takefive.com/faq/

Publishing FAQ and KB entries to our web site is done daily by a Perl script and then replicated to all mirrored web servers. (The publishing script is very company specific and therefore is not in the TWiki distribution.)

kbCreateAndModifyPythonVcsAdaptors.html
is a sample KB entry on our web site that shows a file attachment (analogous to email attachments). It also shows automatically generated links to other FAQ and KB entries.

Not all information in the internal KB is published, there are other categories for confidential information or for internal use only.

Human Issues

People in the field were used to using email for communicating with the factory. Email is a one to one communication, a mailing list a one to many. The problem with email is that useful information does not reach everybody, email is not easy to search and email gets lost over time. Collaborating the Wiki way solves these problems, however changing habits is a difficult issue that needed to be coached.

Initially we also had a chicken-and-egg problem, i.e. voices like "why should I use this collaboration tool, the content is so limited". The solution was to assign a support engineer who monitored the mailing lists and entered useful information into TWiki.

Successful deployment took over 6 month, longer then expected. But now everybody is used to browse, search, collaborate and document the Wiki way.

Conclusion

To summarize, TWiki helped us to

Increase the information flow between the offices (e.g. from and to the factory)