Technical support

Not every company has a staff dedicated to Technical Support, but all applications are supported in one shape or form. This is accomplished by the developer who wrote the application, or by other developers (inside or outside of your organization), super users on site, or by the help desk support staff.

The need for support of a release varies depending on the business environment, the type of application, the hardware configuration, contractual obligation, and your relationship with the client. For instance, a corporate developer might be developing on-site and just need to walk into the next room and walk cubicle to cubicle with the bug fix CD or stop in to answer a question. On the other hand, when we were corporate developers our applications were running in sites across the United States and Canada, and some in South America. The support for this environment was quite different. Other developers might have to drive across the city and do the same or might connect into the server via the Internet and inspect the situation.

We also encourage users to inform technical support of problems they are experiencing. We cannot tell you how many times we went on-site to review something with a client and when we poke our nose into the application error log we find a slew of records. At this point you can ask the $64,000 question: ‚“How long were you planning on suffering with this error? ‚½ The users usually hide these things thinking it was entirely their fault because they did their job incorrectly. While you could ride this excuse and not take blame for a bug, it is important to inform them the software can only get fixed if you know something is wrong.

You also need to set up a schedule of when you are available to perform technical support. It is not uncommon for developers to have applications running 24 hours a day, 7 days a week. You all need sleep. You also need to understand the support structure. You might want to get a time applet like Clock Rack ( Figure 4 ) that shows what time it is in the different time zones where your applications are running.

Figure 4. You can use a software applet like ClockRack (free to subscribers of PC Magazine ‚ s online Utility Library) to show what time it is in different time zones where you have customers running your applications.

Note ‚  

Clock Rack is available to PC Magazine ‚ s online Utility Library subscribers at http://www.pcmag.com/article2/0,4149,31649,00.asp .

Communication mechanisms

The fundamental mechanism of technical support during a production deployment is communication of issues from customers. In today ‚ s world it is easy to be connected with telephones, beepers, cell phones, e-mail, fax machines, and Instant Messaging. Whichever communication mechanism is being used, make sure you are available for the customer during implementation of the production application. After all, their business may succeed or fail with your application and this translates to the possibility of your business succeeding or failing as well.

What are reasonable hours? The answer is: it depends. We have worked for a number of companies both large and small. You might be one of the very fortunate few that never had to be woken up in the middle of the night to handle a support call. It depends on the location and time your customer is using the application. Deployments can be done any time of the day or night, but the reality of the situation is they are done when it is most convenient to the users. Typically this means after hours or during lunch when the application is not used. Sometimes it means working a weekend . This is something you should negotiate long before the setup CD is inserted into the computer and run.

Frequently Asked Questions (FAQ)

The easiest thing to keep track of is a list of Frequently Asked Questions (FAQs). This allows the developer(s) or technical support staff to quickly learn about the most common issues handled from the customers. This list of questions can be developed as soon as you start collecting specifications, will certainly be developed during beta testing, and added to after the application is in production. This list can be included in the user documentation, Help file ( Figure 5 ), in the readme.txt file, and on the support web site. Larger companies like Microsoft, Symantec, Adobe, Corel, and the like have created a KnowledgeBase of white papers based on issues related to the different applications they support. Who is to say that even the one-person shop cannot leverage these concepts?

Figure 5. A Frequently Asked Question list provides the users with a common list of questions other users have asked technical support to address.

Help file

We can already hear the laughter from all corners of the world. Who the heck writes help files for custom software? The reality is many custom projects do not have Help files because they are written directly to the users specifications and the clients are continuously using and testing the software and know it intimately before it is released to production. This can be perfectly acceptable. Some customers might not pay for the development of the help system because it can cost as much as the development of the software. Some users are corporate IS departments and assume the responsibility of developing the User Manuals, Help files, and training materials themselves .

However there are advantages to developing a Help file. Naturally it can be useful to the people using the software each day. Would you develop applications without the VFP Help file? The second advantage is it is a place to document the specifications to the end users. It describes the business rules, the process re-engineering, and the various decisions made on their behalf by their peers or superiors when the software was developed. It can also be used to validate a problem that does not meet the specification.

Training

Training can be a one-on-one with the user, or it might be a formal class for all the users, or even a train-the-trainer session. What ever the needs are for the users, training should be handled initially long before the application is moved into production. Ongoing training is sometimes required based on user turnover , a loss of a trained super user, or new customers coming online with an application.

Web site

A number of developers have asked us our feelings on the topic of Web sites and the roll they can play for developer shops . We think a Web site can have a significant roll in the arena of technical support and customer service as you move an application into production. It provides one stop shopping for the three previous topics of communication, FAQ, and Help file, as well as place to publish white papers about the products and services you have available, downloads of demo products, and secure updates for existing customers.

First and foremost it gives your customers and future customers a place to find out how they can contact you. The company address, phone number, fax line, and e-mail are all important communication methods to make available.

Users can download installations from your Web site (see Figure 6 ). One of the nice advantages of allowing them to download the package is they decide when they want to take the hit on their bandwidth. If we send it in e-mail, they take the download hit just after we send it. This can be a problem if it takes 30 minutes when they are waiting for an e-mail order from one of their customers. This is an ideal transfer mechanism for vertical market apps as well because it reduces the distribution costs of duplication and packaging. Web server security also gives you a chance to have clients log in and provide the transfers over a secured socket layer. This also works well for those patches made during the production and post- implementation phases of deployment.

Figure 6. The Wise Solutions support site is one of the better product download sites we have used. The Web site first has a customer login, and then displays the full versions of the products you registered and any update versions you can download.