Support and Maintenance Portal

To content | To menu | To search

First Line Support

Entries feed - Comments feed

Thursday 7 July 2011

When to move over to Second Line Support?

As explained in article "Customer is more satisfied when it receives quickly good answers" First Line Support should cover up for the first half hour. Only when a solution is in sight within a few hours the reported support issue should remain at First Line Support.
So when to send a reported issue to Second Line Support? Easy! in all other cases. Cool

Keep in mind that sending a reported issue to Second Line Support, cost extra money.

Another colleague has to dive into the same problem again. The amount of rework increases the amount of money spend. To keep the amount of money involved as low as possible you need to make sure you provided all information available on the reported request. You colleague should not have to come to your desk and ask for it.

With all information is at least meant:

  • The communication between you and the customer (emails, summary of phone calls)
  • Reproduction data of the customer system including a description of the error, used sessions and reproduction data.
  • Login information of the customer system (if not available automatically)
  • Reproduction data of the internal system (if available) including a description of the error, used sessions and reproduction data.
  • Describe what has been done so far to get the problem solved. Include the results of the analysis done so far.
  • Provide solution directions in case you have any.

Make sure all information is provided directly on the reported support issue so it can be accessed by anyone within support. When you use attachments make sure you name them properly and refer to them by mentioning their names.

Third party involvement

When your product uses products from other parties you need to make sure your First Line Support process can handle this. As soon as it is clear that the reported issue is caused by a third party product you need to transfer the issue to that party. This is easier said than done!

Let's take an example which makes it directly clear how difficult it can be. Open source product Birt, a reporting tool, provides lovely functionality. When you depend upon the Birt community to get a problem in Birt fixed you could sometimes wait for ages. This will not help you getting a solution (on time) for your customer. For such products you need to make sure your Support and Maintenance contract with your customer covers this.

When you use a third party product supported by support and maintenance contract you are better covered. Make sure your customer is aware of your dependence. For such products you need to make sure your Support and Maintenance contract with your customer covers this as well. Only garantee support when your verdor supplies it.

Another option is a third party product for which your customer should have a Support and Maintenance Contract with that supplier. The transfer of reported support issue should go, preferable, via your customer. Make sure you help your customer understand the issue is not located in your product. Provide evidence to help him convince the third party supplier.

Quick reproduction on internal system

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.

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.

Customer is more satisfied when it receives quickly good answers

The goal of First Line Support is to provide an answer as quickly as possible. Quick and good answers provide the customer with a good feeling about the provided service. The quicker you are able to tackle reported issues the less costs are involved... The knowledge level of Support analysts on First Line Support should be very broad to be able to tackle a large range of issues the customer could report.

Directives on how long First Line Support should take should be provided but not strictly followed. Half an hour is more or less a good time indication. If the situation is not clear after half an hour of investigating the problem it should move to Second Line Support for further analysis. When within half an hour the error is clear and it can be solved within two to three hours it should remain at First Line Support else transfer time will be too large in ratio to the handling time.

The findings should always be reported by the Support Analyst on the reported Issue. This information prevents asking questions twice or executing several actions twice.

Try to speed up but do as less as possible

Support Issues could come in via several channels like phone, fax, email or internet (Support System?). Phone, fax and email are unstructured and require action from your site... to put them in a format your organization can digest them. Having the customer register a support issue that contains all necessary data is a lot cheaper than doing it yourself. A Support System via the internet could do the trick for you. Such a system should have the following characteristics:

  • Customer master data (CRM?) 
    • Customer details 
    • Contract Details 
    • Active applications or versions 
    • Contact information 
    • Dial in information
  • Product Master data 
    • Application / Version Information 
    • Package/Module/Session information 
    • Toolset information 
    • Database information
  • Support Issue related data 
    • Customer Master data 
    • Product Master data 
    • Problem Description 
    • Reproduction Material (for example an attachment with screen dumps) 
    • Impact Description 
    • Expectation Description

A Support System should provide you as well as the customer a follow up mechanism. The follow up mechanism should manage the expectations of your customer. By providing data about progress for example by showing the current status (new, on hand or closed for example) the customer knows a bit more about what to expect from you.

The Support System should provide you with the option to move Support Issues to and from different people. After first analysis the support issue should move to a more knowledgeable analyst on the matter, sometimes it needs to move to a different group within your organization.

To get a support issue on the right spot the Product Master data, set by the Customer on the Support Issue, should be the basis to rotate issues to the different groups or individuals within your organization. Of course the Customer could be wrong about the product/package/module/session and the first contact person within your organization has to reroute. The quicker this process can be executed, the quicker you will be able to provide a solution, the more at ease (not satisfied) your customer will be

Phone and E-mail communication has it's limits

Be aware of the fact that Phone and E-mail communication has it's limits.  The way you handle phone calls and emails influences the service level experienced by your customers.

Your first response on a question of your customer influences the first-time-right rate. The better the response the higher your first-time-right rate. A first-time-right rate tells a lot (but not all) on the service you have provided. Often several calls or emails are required to provide a good answer.

On the phone or via the email it is difficult to get a good picture of the situation at the customer site. Often you are talking with a member of your customer' staff that is not familiar with the problem. You have a real problem when you do not speak the same technical of functional language. Identify the problem as quickly as possible and come to an agreement with the customer to solve the communication issue.

When the customer sends you an email always respond to it. Your service level decreases when you don't or respond late to emails. Treat an email like a phone call. Here as well it requires several emails before a proper answer is returned. Asking the correct questions is very important. Always question your self what it is you want to know. Make sure your questions raised make sure there is no doubt about the required answer.