Support and Maintenance Portal

A customer only wants you to build his requested functional fchanges and not those of other customers. A functional change, especially an unexpected one, could severely upset the customer system or his systematics.

You have to decide how you will coop with such requests. Keep in mind that there will always be a big grey area. An area under the influences of threats of contracts breaches or lawsuits.

When to consider and when not

Sources programmed clear, concise and readable require less maintenance time than those who are complex, large, and non-readable.

You require directives on the way sources are written. This starts all ready in Development. Make sure Development provides proper code that is easy to maintain. Depending on the language used directives should be given. The re-use of functionality (functions, dll's, etc) is one of the most important points next to a readable source.

Each product has a Product Life cycle. You have to inform your customers upfront about the Product Lifecycle of your product. How long will the product be supported by your organization is important to know for customers.

Lifecycle times depend on:

After you have pulled a reported defect of got one pushed, you start with the analysis of the reported defect. You keep on working on the reported defect until a solution is delivered. Re-work and hand-overs lead to longer waiting time. The less hand-overs and the less re-work the lower the waiting time for a customer.

Ask for help when the problem is not clear after analysis

After analysis (and reading design and development documents) the error should have become clear. When this is not the case you have two options:

• ask the Support colleague who created the reported defect for help
• ask you Maintenance colleagues for help

It is up to you who you contact. When you are more experienced you know your Maintenance and Support colleagues better to make a good choice.

Reported Support Issues end in different ways. Here is an overview of the several options:

• Answer to a question
• Explanation about the functionality
• Data correction
• Workaround
• Reference to the Customization Department
• Enhancement request for future usage
• Software fix

What ever the end may be, a customer has to agree, else the ping-pong between you and the customer will go from bad to worse. A clear Support and Maintenance policy as well as a well considered Support and Maintenance contracts will help you. But what the most will help is to act consistently. The role of the Support Analyst is the most important role when the company wants to increase net income from the Support and Maintenance contracts.

Train your Support analysts well. Not only on the product but mentally as well. They have to face difficult and demanding customers. The more the Support Analyst can stop from going to Maintenance the more money can be earned for the company. The more money the company can invest in creating (new) products your customers want, the better your company can compete with the competition.

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.

The majority of the reported issues are not related to software defects. When a product is recently released the amount of defects will be higher...

When a product is on the market for years the amount of enhancement requests and legal requirements will increase.

Another trend of an elder product is that farthest corners will be investigated for usage by your customer.

The larger the product and thus the more possible options to use the more complex reported issues could become. The elder a product becomes the more complex the reported issues become. defects (labels, zoom sessions, etc) in the User Interface are easier to find. They will be reported quicker.

Often the same questions or software defects are reported. Some customer follow every step of the product and install (and probably use) the latest version of the software. You should cherish these customers. They help you fill up your solution database for customers that are behind. A large majority of your customer choose intentionally to stay behind. They let other customers find the defects before they work with the newer version of the software.

Put all answers and solutions with a clear and concise description in the solution database. Make sure the text is tuned on to your customer base. They have to understand the answer or solution to be able to digest it into their organization. They will return to you again when answers or solutions are not clear and you have to work again on the topic. You spend money that could easily have been saved.

Explain the functionality

When a customer reports an issue, always ask yourself what the product was meant to do. Some customers interpreted the functionality differently. Explain clear and concise how the functionality is meant and how it should be operated. Refer to documents like user manuals. Provide examples to the customer to show him how it should be operated and what the expected results should be.

Stand up for your product

When a customer doesn’t get his way he could become really nasty. Yelling, threatening (with a lawsuit), asking to speak to your boss is the order of the day. Very unpleasant! Why do you think a customer operates this way? Easy, because it helps, he gets what he wants, a change in the functionality.

A change in the functionality of a released product is very expensive. Maintenance and sometimes even Development need to make a software change. It is also expensive because it hits your entire customer base. They need to digest the new introduced functionality as well. Do you think they will be pleased with it? Not all, and they probably will do the same as the customer who started all this.

To avoid all this you have to stand up for your product. When customers know that you will not change the functionality they will stop asking because “what’s the use”. On defects of course you need to be fair. But some defects require a functional change. With those you need to be careful. Don’t promise the customer it will be solved.

Telling to a customer that the request will be send to Maintenance or Development means that you agree with the customer. You think it is a defect as well but are you really sure? By working this way you set the expectations of your customer. What will happen when Maintenance or Development says no, especially when you could expect such an answer? Are your hands washed of innocence because you worked so hard for your customer to get things done? It is Maintenance or Development that are not willing to cooperate, isn’t it? When this is your attitude you should ask yourself who is paying your salary.

All issues that you send to Second Line Support, Maintenance or even Development cost your organization money. When you know that the functionality will not be changed, for what ever reason, do not send it any further. Stop spending money by informing the customer it will not be solved what ever his reaction will be. Work with the customer to find other solutions like customizations, workarounds, etc. Always inform you manager about the issue and the reaction of the customer to prepare him for the worst.

Advise on how to overcome an issue

When the functionality of the software doesn’t fit in the daily operation of your customer you have to advice the customer on how to continue. There are several ways:

• Customer adjusts his daily operation so he can work with the functionality as is. This is, unfortunately, often not accepted by customers.
• Workaround in the software. Explore the functionality together with your customer to see if another way of working could do the trick. The workaround should fit within their daily operations.
• Customize the software. The customer gets precisely what he wants. Point the customer out to the department within your organization that builds customizations. Your organization could earn extra money instead of spending it.
• Exiting solution. Check if the solution is already solved. If this is the case inform the customer about the solution. 

Correction of the reported issue at the customer site

A part of the reported issues relates directly to data problems. When the quick analysis shows a data problem, login in at the customer site and have a look. Only change data when you are completely sure you will not upset the system. Make sure you register what you have changed. When data is corrected ask the customer to have a check and let him continue his actions. This way the customer knows the status of the problem and is informed about your actions. He can also easily report back if the problem still occurs or another problem occurs.

Never run correction programs during First Line Support. They require time and a thorough check of the situation. This often conflicts with the time span of First Line Support. Improperly done they could easily ruin the system of your customer. Your organization will pay the price for that, no doubt about it.

To avoid long waiting times make sure all information to login is available. This alone is not enough, access should be allowed as soon as you want to log in. No long or difficult procedures should be followed to get access to the customer system. In the Support Contract this needs to be arranged. If the customer is not willing to provide this access you should not consider a Support and Maintenance contract that easily. You need to make sure you can keep your side of the Support and Maintenance contract.

Errors occur in customizations

When the reported error occurs in a customization, request the customer to contact their customizations supplier. If your own organization provided the customization rotate the reported support issue to those responsible for the customization. Inform the customer about your action. Make sure all results of analysis done is registered on the support issue of the customer.