Support and Maintenance Portal

To content | To menu | To search

Tag - Explain

Entries feed - Comments feed

Friday 8 July 2011

Many possible closures require skilled Support Analysts

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.

Reported Support Issue turns out to be an Enhancement Request

Frequently in Second Line Support a reported support issue turns out to be an Enhancement Request. Of course the customer will state it is a defect. It depends on the policy of your company how to act upon it. From an economic point of view you should not give in unless you will loose the Support and Maintenance contract with this customer and thus income. Of course the customer could threaten you but he can not do this every time he does not get what he wants. So your customer will pick his fight carefully.

By not giving in you could help your company earning more money by sending the customer to your customization department.

What you should do any way is to log an Enhancement Request for future usage. Such enhancements requests are very nice sources to improve your product further. When on the same area several enhancements requests are logged it is wise to consider it for future releases of your product.

An Enhancement request requires a bit of different approach than a defect. It has to explain the missing functionality in detail as well as the impact on the customer. Explain what the customer is capable of when the functionality is provided. Describe how much could saved by the customer within his business.

Thursday 7 July 2011

Customers ask more than you can provide (against acceptable costs)

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.