1. I imagine that it should be possible to manage the support process better. In almost every instance (and as you may know, there have been many recently), I have been asked for the name of the customer, the version being used, sometimes the drivers used, etc. I must admit that this is the first time I have been asked what the actual Product is, however, despite submitting the initial report with a fully detailed sample file, from which it should be easy to determine the product. In every case the answers have been the same, but I have had to reiterate them.
If I had to manage this, I would provide the support technician with a profile of the person/organisation submitting the request, which could easily include the details of the environment(s), and list all previous tickets, especially those still open. This would save everybody concerned a great deal of time. I am sure you can imagine what software tool I might use to build such a system (and I actually have built a similar system with exactly those goals). [Note: this seems to be possible in the OT system, but we have not tried this yet]
2. In most instances, my support requests have been answered by completely different people. Whilst I understand that the organisation is large, and workloads are varied and must be balanced, I do feel that limiting requests from one source to a much smaller group of people would reduce your own workloads, and definitely improve customer satisfaction. As it is, I often have to go through whole sequences of Q & A that could be circumvented merely by the support technician being at least vaguely familiar with our situation and level of experience. [Note: this did seem to get fixed - we dealt with two or three mostly after that]
3. [not relevant, customer specific]
4. This situation is now extremely urgent. We have had an embarrassingly long sequence of failures and faults to contend with in this upgrade from 6 to 9, and it goes back about 3 years. Version 7 migration failed. The fix to that failed too, and we had to do this manually ourselves. Version 9 migration failed in both systems. We have had to do all of that manually (with help from Development, which we do appreciate), and it is not a simple matter. The version 9 file migration has had several interesting faults causing errors and additional work. Version 9.1 has had a wide range of faults, and you have persuaded us to go with 9.3. When we try out 22.214.171.124 that you tell us has fixed these issues, we discover a serious fatal fault almost immediately, although it did take us some time to identify it from the (once again) almost completely useless error message. [Note: this is the getemailaddresses which fails in Oracle. This is fixed in a later hotfix, I noticed, even thouugh OT have never admitted being able to reprodcue it. It may be due to backslashes in the user names]
5. The level of testing does not appear to be adequate from our, nor our customers', perspectives. We have reported a significant number of faults that have been introduced into version releases and hotfixes over the last few months. We have offered to provide testing resources, as we have a wide range of applications and environments we can use to test releases. I have been told that OpenText feel they cannot afford this, but I feel the need to point out again that if this is true, I feel that OpenText cannot afford NOT to increase the level of testing of new releases of this product. The cost benefit analysis should be very simple: Fewer faults means fewer support tickets being opened. That is even before intangibles such as customer satisfaction and market reputation are considered.
6. Error reporting in version 9 needs a serious overhaul. In version 7 we finally had a decent level of error reporting, although there were still a few oddities and we learned to recognise them. When version 9.0 was introduced in 2009, we were prepared to accept a little gap in the fault reporting. Unfortunately, the gap has not been closed at all in nearly 4 years. I almost never get a report that identifies the source of the problem. Once again, the cost benefit analysis should be very simple, as it is the same as noted above.[Note: this still not fixed, and it is the major cause of our dissatisfaction with the product]