Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

You've delivered your application to your user community and now you're finished, right? Wrong! From your users' point of view, things have just started: Now they expect that someone will support the application you just delivered—and that someone may even be you. The objective of application support is to respond to incoming requests from users, to identify a resolution for the request, and to oversee the implementation of that resolution.

Although developers put an application into production, support engineers keep it there, making your support staff and process key to your application's ultimate success. By helping your users solve problems, the support staff directly influences your users' productivity—and a productive user base is any organization's greatest asset.

The Support Process Pattern
The input to the support process is a support request from someone whom I call a requester. A support request may be in the form of a phone call, an e-mail message, a fax or an entry into a support request database (likely via a Web page). Furthermore, there are several types of support requests: Users may ask questions ranging from how to use your application to how to obtain training for that application; someone may submit a change request, which describes either a new application feature or a potential defect; a user may also request an environment change, such as a hardware upgrade or operating system upgrade; or the request could indicate that a software license has expired.

Support Task #1: Respond
Three main tasks comprise the support process. First, respond to the support request by communicating with the person making it. Your support engineers should immediately acknowledge each support request upon receipt, so the requester will know that the request is being looked at and by whom, and be given either a solution on the spot or an estimate of when to expect one. Never forget that your users will judge your application based on the speed and accuracy of your support personnel's responses. The best support engineers respond promptly and politely, convincing the requester that this problem is the most important issue they have to deal with.

Support Task #2: Determine a Solution
There are four primary resolution strategies: provide information, identify training for the requester, describe hardware and/or software upgrades, and create a software change request (SCR) that potentially leads to a change in your application. To select an effective combination of these four strategies, the support engineer first works with the requester to gather information and determine the request priority; then simulates the problem if necessary, and perhaps escalates or refers the problem to someone with greater authority if required.

Often overlooked when deploying an application, a problem reproduction environment (a copy of your application that simulates user problems) is an essential support tool. Support engineers will often have the requester walk them through a problem while they simulate it on their own computer. By simulating a potential problem, the support engineer gains a better understanding of what the requester is describing. In this way, the engineer can determine if there is a problem with the application or with the requester's hardware or software configuration, or if the requester needs further training to use the application effectively.

Occasionally, a support engineer will encounter support requests that he either doesn't know how to resolve or doesn't have the authority to resolve. When this occurs, the support engineer will confer with a more experienced support colleague, potentially his manager, and perhaps a few developers to determine a resolution. When a support request is escalated, the support engineer should remain involved to expand his knowledge of the application and to avoid a support request escalation when a similar issue pops up.

Support Task #3: Resolve the Problem
Your support engineers need to understand a wide range of issues pertaining to your application and your corporate environment. They must be able to assign requesters to training courses and therefore will need access to your organization's human resource systems that perform this function; they need the ability to request upgrades to the hardware and/or software configurations of requesters; and they need access to your organization's change control system to in-put new features or eradicate bugs.

The output of the support process is a solution provided to the requester. Furthermore, a software change request (SCR) can be created so that new requirements and bug fixes may be implemented in future versions.

Defining Your Support Environment
How do you organize the support process within your organization? First, you need to choose a support-flow model, also known as a call-flow model. This is the process through which support engineers receive requests, find solutions and return answers to the requester. There are two basic strategies to choose from: the front-line/back-line model and the touch-and-hold model.

With the front-line/back-line model, often called the tiered model, support staff are organized into two groups: a large group of less-experienced support engineers who take incoming support requests and try to resolve them within a short period of time, and a small group of experienced support staff who handle the difficult requests fielded to them by the front-line staff. This model utilizes experienced staff efficiently, provides a handy way to train new staff, offers a career path for support engineers and supplies users with a predictable model. Its main disadvantage is that more than one person may deal with the support request, potentially decreasing the quality of the service provided to the requester.

The touch-and-hold model promotes a more individual approach—the support engineer who responds to the initial support request handles it directly, though occasionally requiring collaboration with experts for a given issue. The success of this model depends on getting the right support request to the right support engineer, perhaps through an automated phone menu. The advantages are clear: Fewer handoffs reduce the occurrence of repetitive requests; support engineers have greater opportunities to increase their skillsets; and throughput is higher due to fewer handoffs between support engineers. However, this model has several drawbacks: Support engineers must command a reasonably high level of technical expertise; your organization must have access to a large pool of good support engineers; and service can be uneven because of support personnel's varying levels of expertise.

Secrets of Support Success
If you take the following tips and techniques to heart, you'll increase your chances of success at supporting your system once it's in production:

1. Every support request is critical to the requester. The most successful support engineers are those who recognize that from the requester's point of view, the only thing that the support engineer should be concentrating on is resolving their problem.
2. Support engineers are the sales team for your application. When your support engineers project a positive image of your application—they teach users "neat tricks" to use it more effectively and do their best to resolve requests efficiently—your users will be satisfied with your application. On the other hand, if your support engineers have a bleak attitude or bad-mouth the application, your user community will quickly become disenchanted with it and with your support staff.
3. Your objective is to support your user community. The main objective of every information technology department should be to support their user community. Support should be your IT department's first priority—not the last.
4. The support request is not resolved until the requester is satisfied. This is a basic customer service issue, based on the precept that truncated service transactions result in unnecessary grief and frustration for the requester. To close a support request, you must first ask the person who made it whether he feels that the resolution met his needs.

Not only do you need to develop and then deliver your application to your user community, you also need to keep it running once it's in production. Your organization's approach to system support is an important part of your overall production processes, one that is ignored at your own peril. Successful software developers take support issues into account when they're building systems, and ideally, they work with support staff to ensure that their needs are met. Effective support engineers enable effective users, and effective users are what defines the success of your system. I prefer to work on successful applications, don't you?

RELATED ARTICLES ZigBee Alliance, DLMS User Assoc Collaborate on Metering Data Compatibility Embarcadero Takes DBMS Admin Into the Cloud McObject Updates eXtremeDB Real-Time Database System IBM Offers Free Public Cloud Beta For Software Development Zend, Oracle Hook Up for Enterprise-Class Linux and PHP		TOP 5 ARTICLES No Top Articles.