Tuesday, October 17, 2006
Software Vendor Customer Support
Having worked in technical support for software vendors for 4 years, I know a few strategies that can help customers get the best response.
1. Get training
Rely on the assistance of the software vendor for as little as possible. Invest in training your own people by signing them up for courses and, more importantly, giving them the time to learn the product and how your company uses it. Once knowledgeable, your expert can get the best results from the vendor.
2. Avoid customizations
No product is going to fit your needs exactly, and it's tempting just to make little fixes here and there, but resist the urge. Just because you can do something, it does not necessarily follow that you should. Consider leaving the software as-is and just changing your process. Customizations can cause problems, become (legitimate or not) obstacles preventing the vendor from providing you assistance, and make upgrades more problematic.
3. Stay current, but not too current
Generally the vendor offers the best support for versions immediately before the latest version. If your version is too old, they may have fewer people that know it and they may stop supporting it altogether. You don't want to stay too current - let the other customers find the bugs in the latest releases. Of course, if you need the functionality in the latest version and the vendor is prepared to give you extra support for being a guinea pig, go for it.
4. Allow for remote access
Generally you should never allow the vendors on to your system, but sometimes it will be necessary, so be set up to make that as easy as possible.
5. Wait until you have time
There is no point opening a ticket with them until your resources have the time to act on whatever they suggest. Take too long to respond and your item will be downgraded, perhaps permanently. If something is low priority and you just want it "on the record", then make sure you say so.
6. Assign the right priority
Every software vendor will have standard definitions where you define the severity/priority/impact of a problem. It is tempting to assign a higher priority, but once you're downgraded you may be given a lower priority than items that were opened correctly at this new downgraded level. You can also get a reputation that may cause truly important items to get downgraded in the future. Any way you slice it, clearly explain the business impact of your problem, regardless of priority, to avoid any problems.
7. Answer the standard questions in advance
Don't wait for them to ask you the usual questions: When did this start, what changed, etc. Anticipate their questions and answer them up front. Look back at the questions they usually ask as a clue.
8. Provide a complete, independent test case
Doing a little work beforehand can save a lot of time later. Eliminate distractions and narrow the problem down to a simple, reproducible step-by-step description that will work anywhere. Try to use default data wherever possible. A test case is worth a thousand words, so this will save you days or weeks of back-and-forth explanations.
9. Provide all logs, configuration files
Don't wait for them to ask, go ahead and attach all relevant configuration files and logs. Tell them what you've already tried (from standard troubleshooting techniques in the manual) and what the results were for those tests.
10. Make it as easy as possible
Try to make your case look as simple and clear as possible. Some vendors measure their service representatives by how many items they close to the customer's satisfaction. So they like to pick off the low hanging fruit. If your case looks hard, it may get neglected, or assigned to someone not new or skilled enough to dodge the tough ones.
11. Open separate tickets
Try not to lump everything into one ticket, or you risk having your problem only partially solved. Why not open a separate item, and have them work on your issues in parallel? If they're somewhat related, you can always say so in your description. Worse case scenario, solving one solves the other and you can just close both.
12. Escalate when you're stuck
If you're not getting anywhere, ask for the issue to be escalated to the manager. S/he will make sure the right people are working on it, that there is a resolution plan, and communicate that information to you. Keep going up if you have to, managers have managers too.
13. If you need extra, pay for it.
If, for whatever reason, you can't do certain things for yourself, or you need some extra help from the software vendor, offer to pay. Money talks! You will get results far faster and more reliably than if you just try to threaten or cajole them into it.
14. Make sure the solution is permanent
Try to keep the focus on identifying and solving the root cause, not the consequence. It is almost always advisable to end a resolution with a documentation enhancement or a new item in their solutions knowledge base. Volunteer to proof read it.
Note: I originally wrote this article in April, but it was on my personal blog. It occurs to me that the Oracle professionals that read this blog might be supporting 3rd-party Oracle-based applications, or perhaps dealing with Oracle support directly, and therefore would enjoy this article too.
Also, given my lack of material lately, this is the best way to confirm I am still alive. :)
1. Get training
Rely on the assistance of the software vendor for as little as possible. Invest in training your own people by signing them up for courses and, more importantly, giving them the time to learn the product and how your company uses it. Once knowledgeable, your expert can get the best results from the vendor.
2. Avoid customizations
No product is going to fit your needs exactly, and it's tempting just to make little fixes here and there, but resist the urge. Just because you can do something, it does not necessarily follow that you should. Consider leaving the software as-is and just changing your process. Customizations can cause problems, become (legitimate or not) obstacles preventing the vendor from providing you assistance, and make upgrades more problematic.
3. Stay current, but not too current
Generally the vendor offers the best support for versions immediately before the latest version. If your version is too old, they may have fewer people that know it and they may stop supporting it altogether. You don't want to stay too current - let the other customers find the bugs in the latest releases. Of course, if you need the functionality in the latest version and the vendor is prepared to give you extra support for being a guinea pig, go for it.
4. Allow for remote access
Generally you should never allow the vendors on to your system, but sometimes it will be necessary, so be set up to make that as easy as possible.
5. Wait until you have time
There is no point opening a ticket with them until your resources have the time to act on whatever they suggest. Take too long to respond and your item will be downgraded, perhaps permanently. If something is low priority and you just want it "on the record", then make sure you say so.
6. Assign the right priority
Every software vendor will have standard definitions where you define the severity/priority/impact of a problem. It is tempting to assign a higher priority, but once you're downgraded you may be given a lower priority than items that were opened correctly at this new downgraded level. You can also get a reputation that may cause truly important items to get downgraded in the future. Any way you slice it, clearly explain the business impact of your problem, regardless of priority, to avoid any problems.
7. Answer the standard questions in advance
Don't wait for them to ask you the usual questions: When did this start, what changed, etc. Anticipate their questions and answer them up front. Look back at the questions they usually ask as a clue.
8. Provide a complete, independent test case
Doing a little work beforehand can save a lot of time later. Eliminate distractions and narrow the problem down to a simple, reproducible step-by-step description that will work anywhere. Try to use default data wherever possible. A test case is worth a thousand words, so this will save you days or weeks of back-and-forth explanations.
9. Provide all logs, configuration files
Don't wait for them to ask, go ahead and attach all relevant configuration files and logs. Tell them what you've already tried (from standard troubleshooting techniques in the manual) and what the results were for those tests.
10. Make it as easy as possible
Try to make your case look as simple and clear as possible. Some vendors measure their service representatives by how many items they close to the customer's satisfaction. So they like to pick off the low hanging fruit. If your case looks hard, it may get neglected, or assigned to someone not new or skilled enough to dodge the tough ones.
11. Open separate tickets
Try not to lump everything into one ticket, or you risk having your problem only partially solved. Why not open a separate item, and have them work on your issues in parallel? If they're somewhat related, you can always say so in your description. Worse case scenario, solving one solves the other and you can just close both.
12. Escalate when you're stuck
If you're not getting anywhere, ask for the issue to be escalated to the manager. S/he will make sure the right people are working on it, that there is a resolution plan, and communicate that information to you. Keep going up if you have to, managers have managers too.
13. If you need extra, pay for it.
If, for whatever reason, you can't do certain things for yourself, or you need some extra help from the software vendor, offer to pay. Money talks! You will get results far faster and more reliably than if you just try to threaten or cajole them into it.
14. Make sure the solution is permanent
Try to keep the focus on identifying and solving the root cause, not the consequence. It is almost always advisable to end a resolution with a documentation enhancement or a new item in their solutions knowledge base. Volunteer to proof read it.
Note: I originally wrote this article in April, but it was on my personal blog. It occurs to me that the Oracle professionals that read this blog might be supporting 3rd-party Oracle-based applications, or perhaps dealing with Oracle support directly, and therefore would enjoy this article too.
Also, given my lack of material lately, this is the best way to confirm I am still alive. :)
Comments:
<< Home
Good list, but #2, good luck!
For #7-#9, Oracle has pretty good docs like Working Effectively With Support
which every 3rd party vendor should try to emulate to help customers help themselves.
Also regarding #7, most vendors these days seem to use fairly standard web packages for support, they need to remember to configure them properly to ask the proper questions (and allow the possible answers!), and get the analysts to read them.
Post a Comment
For #7-#9, Oracle has pretty good docs like Working Effectively With Support
which every 3rd party vendor should try to emulate to help customers help themselves.
Also regarding #7, most vendors these days seem to use fairly standard web packages for support, they need to remember to configure them properly to ask the proper questions (and allow the possible answers!), and get the analysts to read them.
<< Home