Customers really depend on their software to earn their living. When they for example can not send out invoices, they have a major problem. When they can not send invoices they will not receive money from their customers. When they do not receive money they can not pay their own bills. Such a situation could end in bankruptcy.
Do not think such a scenario is exaggerated. It is a nightmare for your customer. He will act accordingly. When you do not respond properly he will strike back furiously. You will go down under with him.Tag - Inform
Thursday 18 August 2011
Hurry! Hurry! Hurry! when a business stand still is logged
By Jan Verlaan on Thursday 18 August 2011, 11:13 - Business Stand Stills
Friday 8 July 2011
Reported Support Issue turns out to be an Enhancement Request
By Esther Verlaan on Friday 8 July 2011, 10:25 - Second Line Support
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
Analysis of the reported issue
By Jan Verlaan on Thursday 7 July 2011, 21:37 - 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.Quick reproduction on internal system
By Esther Verlaan on Thursday 7 July 2011, 10:54 - First Line Support
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.