I think it can depend on the type of ticket one submits, and which department(s) it ultimately gets sent.
I think it would be a fair assessment to conclude that Steinberg support has some weaker areas, but I would not go so far as to say ALL Steinberg support is ‘Terrible’.
It can also depend on things like web-site outages or problems. I.E. If the support site has some problems with servers, software updates, etc. (could even be third parties doing this for Steinberg), a lot of data can truly get lost, and the lowly service rep can’t do much about it.
My experiences have mostly been positive, but not always ‘instant’ or without a little push on my part. In my experience, this is common with just about ANY company that makes and services ‘system components’.
I.E. I needed a HALion 5 key after updating to version 6 (So I could roll back to 5 for some of my old 32bit systems). I got the key within a day of submitting the request.
I.E. I filed some bug reports with crash dumps, dxdiag profiles, and a long list of steps and example projects as to how I reproduced the problem. That transaction somehow got ‘lost’ in the shuffle; however, it did not take long for my issue to be acknowledged, as I’d also discussed it in various threads here on the forum, and the HALion team leader personally picked up on it, and requested I re-transmit my reports to him personally. The issue I’d encountered was immediately addressed in the very next beta release within a few days, and ultimately made it into the first official releases for H6, as well as an official fix patch for H5. It did take time for H6, and the H5 fixes to roll out, but this is normal, as things need to be documented, checked, and tested before they get sent out as an official release. Behind the scenes however, my issue was put into the jira, and teams started working on it immediately after they confirmed my issue was reproducible on a wide variety of systems.
The thing to realize is that no communication chain is bullet proof. Sometimes things get lost, misunderstood, or otherwise mishandled. It happens in all companies. The more complex and system specific your situation is, the more important it can be to follow up…do a little research on who in a company is responsible for what, and get information directly to them.
I do agree that it should NOT be the user’s job to have to ‘dig deeper’ to get the kind of support he might need…but in the real world it is sometimes necessary. People are people…and how we treat each other has a LOT to do with where our individual cases get parked ‘in line’.
Some people choose to get bent, and spend a lot of time and money voicing rants with no helpful details/information, while bouncing around from product to product any-time they get upset or feel ripped off. Others take a deep breath, work up a good report explaining the problem in detail, call a meeting with someone with the power to address it, and then serve up some coffee and doughnuts in the quest for solutions. Humans generally work better, and respond faster when communication is supportive, helpful, relative to their particular area of expertise, and to the point. The world class programmer deep in the cogs of some laboratory somewhere has no control over what someone at the service desk is doing (or not doing)…and sometimes you just need to find a way to politely, and as briefly as possible get your message directly to him/her.
