After several years working with OpenText support I have a few suggestions that I have found helpful in reducing the time that it takes to resolve an issue that I report to the support desk :
- Prepare a clear problem description so that the problem can be worked through AND replicated if possible.
- Try exploring the issue yourself and tell support what you did and what the results were.
- Do some research yourself before logging the call.
- Get the logs together before logging the call.
- Set the correct priority on the call.
- If possible provide OT with a copy of your system.
Investigate the issue yourself, try and replicate it, ensure that the user is following the 'correct' procedure for their task, check their browser settings to ensure that they are correct, read the thread and connect logs, and if present any trace files and see if you can see the problem. Can you replicate the issue on your system ? If so document what you did as this may also be useful. In some cases this exploration of the issue will itself yield a solution.
In many cases it is worth checking out a variety of sources such as the Knowledge Center as the problem may already have been reported by others and there may be discussions on a workaround or link to a patch or solution for you. Sometimes you may be able to point the support guys to an article that discusses the actual or a similar issue that they can use as a starting point, this will save them time and effort, remember that they are human and don't know everything - although it often seems like that ;-) - about the product, so you may on occassion find the solution for them.
Gather together all the files that you need to send to OpenText. In the case of log files it is ideal if you can restart your server with logging up high and then replicate the issue before reducing logging and restarting again - as this will result in a smaller, more relevant set of logs. Generally the requirement is for the thread and connect logs along with any trace files that are generated. If these files are relatively small they can be zipped up and mailed to support with the other supporting documentation when you open the call, if not then you may need to put them on an FTP server or in your Personal Workspace in the Knowledge Centre.
When logging the call, ensure that the correct priority is set, if it is a low priority for you, then ensure that they are aware of that. This allows them to focus on the calls - including your own - that are more business critical, for example a 'my server has crashed' is generally more urgent and important than a 'how do I configure Livelink to do X' for example.
Some firms may allow you to 'clone' your Livelink environment using tools such as ArcServe or Norton Ghost. These images can then be send to OpenText so that they can load them up and recreate your system on their site to ensure that they are replicating the error exactly. This also saves them having to contact you every time they want you to try something to see if it resolves the issue, and should also remove the problem where the issue you report can not be replicated on their systems.
In conclusion, do your homework first, gather the evidence second before contacting support. Providing them with as much relevant information in a clear and concise manner can greatly improve the chance of your issue being resolved. Try and stay calm when you speak to them, even if the situation at your end is a major one, a clear head and a calm manner is more likely to help the situation than getting irate, remember they are trying to help you.
About the Author
profile or on his site.