Support and Maintenance Portal

A defect is needed for Maintenance. The better the reported defect is described the quicker it can be solved and the less ping-pong has to take place between Support and Maintenance to complete the required information about the defect. The required details should directly lead to the place the error need to be solved.

Clear and Concise described defects are required 

When a defect is not clear enough Maintenance could solve indeed an error but is it the error of the customer? Creating solutions in Maintenance mode is very expensive. The more solutions you make the less is left of the amount your customer paid for his Support and Maintenance contract. The less net income you can to spend on new development for example. So getting Maintenance directly on the spot of the error is very important.

A defect requires a clear and concise error description. All reproductions steps have to be written down including used reproduction data (batch numbers, order numbers, etc) as well as session names and error messages. When parameters are involved they have to be mentioned as well.

Next to the reproduction description the follow provides Maintenance with more insight on the reported problem. Always provide the following:

1. Business requirements of the customer. Why is the fix needed?
2. Impact of the error on the customer. How bad is the situation for the customer?
3. Expectation of the customer. Why does the customer expect a fix for this problem?

Template could be of help 

When several product versions or even localizations and translations are installed at different customer sites, details about versions etc are very important for Maintenance to get to the right spot and the right spot only. To help make sure you provide all information you could introduce a template. The information will always be provided in the same format.

The correct filling of the template over time requires management attention. People tend to loose focus on the correct filling for several reasons. The Maintenance colleagues, for example, often know precisely what is meant although it is not described. When attention slips for sure Maintenance is not always brought to the spot of the error. Without Management attention it will occur more and more and thus more and more money is not properly spend.

Although your customer reported a defect it is not always necessary to provide a software fix as solution. When a work around is available you should consider not to solve it in the version of the customer. When the work around is acceptable for the customer close the reported issue. Of course you have to log a defect. Such defects should be considered for the product currently in Development mode.

For customers work arounds are very acceptable as long as you do solve their real serious issues.  

It is not  up to you to decide if a work around is acceptable for your customer. When a work around is annoying or not workable for the customer, he will not agree with the proposed work around. He will demand a solution. Discuss the matter with the customer to get a clear view on his arguments. You require these arguments to convince maintenance to create a solution. Maintenance has to follow the same policy as you have. When you have no good argument they should not solve the defect in maintenance mode.

The tasks of Second Line Support are almost the same as First Line Support. The difference is that when reported support issue is picked up in Second Line Support it should be handled by only one Support Analyst and he should never let go untill it results in a solution, an advise, an explanation or a defect.

Every time an issue is picked up it requires rework to come to a level where the activities can continue to come to a final. It becomes even worse when a new analyst has to pick up the same issue. The amount of rework in such cases is even higher. Rework always cost time and thus money. Pick up an issue and never let go of it untill a final stage is reached costs your company less.

Read the articles of First Line Support to get what is expected at Second Line Support.

The reported support issue has moved to Second Line Support. So a solution for the reported problem was not insight. fThe analysis of the issue starts by reading what the customer and your (First Line Support) colleague have reported on the matter. The focus is on the problem description and reproduction material of the customer as well as on the description of actions already taken by your colleague. Focus on the latter is needed to avoid performing actions twice.

Ask the right questions

Always question yourself after your first analysis of the available material if you understand the raised issue. If not, question yourself on what is not clear to you. Formulate questions that, when answered, should provide you with enough insight to get the analysis on an higher further. The formulation of the questions you raise is enormously important. An easy example to explain to you how important:

When does the first train leave the station? The answer is: at 8.00 am. But is that the answer you are looking for when you need to know how late the first train to London leaves the station on Saturday July 12th 2008. The answer could be 9.00 am instead of 8.00 am? So make sure all relevant data to get the correct answer back is put into your questions.
When you send your questions to your customer always propose to go thru them together so you have the opportunity to explain a bit more about them but also to provide your customer the opportunity to asks questions.
When you receive the answers do precisely the same. The customer could elaborate on the provided answers and you have the opportunity to asks for more in areas that remain unclear.By having contact with the customer, your customer knows you are working on his reported issue. When asking the correct questions he will be more convinced he will receive in time a well motivated answer.

The asked questions and the provided answers only give you a picture of the reported issue. Based on this picture you decide what actions to undertake.

When you are not sure it is a defect you have to investigate manuals, help instructions, etc, or even ask another (more experienced?) Support colleague. When it turns out not to be a defect you inform the customer and explain in detail how the functionality is meant and how it should be operated. Always make sure the answer is registered on the reported support issue and in a solution database (FAQ database?). Other customer or support colleagues could face the same problem.

Reproduce the customers problem

When you think it is a defect you start to set up a scenario on an internal system to reproduce the error to gain proof of the error reported. After gaining proof of the software error you have to take two actions. The order of the actions is up to you.

When the problem is clear you can easily reproduce the problem on an internal system. When the error is not clear login remotely on the customer system.

The login on the customer system helps you to diagnose the problem quicker, if often shortens the reproduction time, and it increases often the level of satisfaction of the customer. You are working on his problem. Another big advantage of login remotely is that it is less costly then going on site.

There are several tools for remote login. Analyse them well before you choose one. In your analysis take at least the following into account to increase usability.:

• Desktop sharing options
• (Unattended) Remote control
• Reboot and Reconnect options
• File Transfer
• Chat options
• Voice over IP
• Fast connection options
• Recording

First step after reproduction - create defect

The first step is that you create a defectf for Maintenance even if you know they might not solve it. Describe all the involved reproduction steps clear and concise. Always mention the sessions and reproduction data involved as well as the system you reproduced the error on. For some defects it could be an option to provide a screen dump of the error. Keep in mind that a screen dump can never replace a proper reproduction description. If you can not explain the error in words, you need to question yourself if you understand the error well enough.

A reported defect always has to be made and send to Maintenance even if the policy of the organization is not to solve all defects. The defects that will not be solved in the current outstanding version (for what ever reason) need to be taken into account in future releases. Cherish the source of points of improvement mentioned by customers using your product.

Second step after reproduction - inform customer

The second step is that you inform your customer about the gained proof of his reported support issue. Explain to the customer what will happen next. This way you manage the expectations of the customer. The policy of your company influences directly on what the customer may expect, act accordingly. When long waiting times are involved, for example, make sure your customer is aware of this.