Yup. I have never had much luck with support except sort of some big known problems or something where you can afford a lot of time. Most of the time you end up figuring out the problem or a workaround long before it gets pushed to some real engineer. And even when you diagnose the problem partially they will simply ignore you and ask rota questions and 5 days later give you the solution you have come up with in case they come up with one.

I think those happen at completely different levels and there are a lot of places where the communications process either doesn't work at all or has significant translation issues. Here's what it looked like at one job:

My level:

1. Internet Explorer 8 is released. Our users start to get the automatic update and our very expensive Oracle reporting app breaks.

2. I contact Oracle's support and get a very snotty customer “service” person:

“I noticed a bug in your JavaScript code which now triggers an exception on IE8.”[1]

“We don't beta-test Microsoft's software for them. We'll start testing IE8 when it ships.”

“That was last week. How's the testing going?”

pause

“We'll get back to you”

“Please do. I deployed a patch but am worried there are more subtle problems.”

3. <days pass with no contact>

4. “Hi, this <senior support manager>. Can you give us a copy of the patch you mentioned so we can distribute it to other customers who are dead in the water?”

5. <time passes>

6. “You'll need to upgrade to $NEXT_MAJOR_VERSION, which was just released and is a paid upgrade”

The executive level where the decision to buy was actually made:

“Hey, heard you guys had a problem or two but the support group worked it out”

“Yeah, the usual. Are we still on for our normal tee time?”

The problem was that the executives didn't have any experience somewhere dramatically better functioning and both the outside sales team and their staff who had invested much of their professional development in that stack had an incentive to downplay problems and come up with reasons why any particular outside comparison wasn't valid. No large organization works exactly the same as its peers and so you can always come up with some argument for why they can do something but it won't work for you. The only thing which seems to disrupt that is either a failure too big to be excused or the emergence of an alternative which is either dramatically cheaper or does something new such as support mobile/BYOD or a cloud service which removes the need to have the staffing and equipment in-house for a major app.

1. This was actually a neat class of failure: the IE7-emulation mode solved most of the display problems but it was still using the IE8 JavaScript engine, which raised an exception when a library attempted to set zIndex to a completely invalid value like null, unlike the real IE7 engine which simply ignored it. I pity whoever at Microsoft maintained the test suites for those enterprise compatibility modes…