Support and Maintenance Portal

What do you know abofut the satisfaction levels of your customers? Are they satisfied on all levels? You have to ask them to get the picture. You have to execute on their complaints to get grip on the satisfaction levels.

Levels of satisfaction

A customer could be satisfied with the software but not with the way you deliver solutions. Customer satisfaction is based on how well you perform on several levels. Measure customer satisfaction on the following levels will give you a good picture:

• Functionality of the software
• Response times on Reported Support Issues
• Way of approach by Support Analyst (communication)
• Quality of the solutions provided (Bad fixes)
• Quality of the Self-Service options

Several ways to measure

Performance can only be measured when performance related data is available in the Support System.

Master Data

When you like to measure the performance for Individual Support Analysts, Teams, Departments, etc, you need to have this data as master data available in your Support System. So your organization structure needs to be somewhere in the Support System. Same counts when you would like to measure performance for Customers and Product (versions), service or feature packs, packages, modules, etc, as well.

Performance Data

Performance data is data that tells you how well you handled or are handling a reported Support Issue. The following aspects are important for internal and external usage:

The customer should be able to log their own Support Issue. You should promote that they do as much as possible themselves because this speeds up the process on your side. Customers should get the option to attach documents to support the clarification of their reported problem. Customers should also get the opportunity to state the importance of the problem to you via a priority setting.

Master Data

Of the customer master, contract, login and used product data need to be captured. This data has to be up to date. Every year you should ask your customer to check his data. Support Analyst must go blind on this data to be able to do their job properly. An error in this data could lead to a disturbance and possible to increased waiting time for the customer.

Rotation

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.

Of a small amount of the reported support issues it is clear that it is caused by a defect in the software. Wrong labels, incorrect working zoom sessions, incorrect sum at the end of a report, etc.

Gain proof by reproducing the error on an internal system

Such issues can easily be reproduced on an internal system to gain proof. These cases can easilly be handled in first line support. In most cases it will lead to a more satisfied customer, even when he has to wait for his solution.

After gaining proof of the software error you have to take two actions. The order of the actions is up to you.

First step after reproduction - create defect

The first step is that you create a reported defect 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 bugs 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.