I've had experience of doing Tech Support, and it's not the 'product'-related issues that gave my colleagues and myself problems.
Let me give you some examples I remember -
"What numbers do I need to put in the P, the I, and the D for my loop?" - this being asked by someone who quite openly admitted they knew nothing of process control, while you could hear a steam valve banging open and closed in the background.
"I've written my own VB application to interface with your PLC system, but your comms card keeps giving me errors." - it turned out, of course, that the errors were all Microsoft error messages relating to badly-written VB.
"I've got to update this old system, but I don't have a copy of the software, or any manuals, or a programming lead ..." - ahh yes, a 20-year-old PLC. Any profit made on that sale to cover support expired long ago. And he wanted a training course f-o-c over the phone on obsolete equipment to satisfy a contract he voluntarily entered in to with his customer.
"This PLC has been installed for 10 years, and last month it started going to fault every couple of days." OK then, what's changed? "Nothing - except the PLC keeps failing" Yeah, right. And eventually after an hour you would find out about the 250KW drive that had just been installed right next door on the same earth. "Oh that?"
As others have said "support" takes many forms. If the answers you get tend to sound as if someone is reading them out of a book it's just because 80% of the questions asked can be answered that way - simple Pareto analysis. A support tech's best odds of answering things have to start at that level - it's just the way things are, I'm afraid. If you happen to fall in to the elite 20% who have got beyond that stage yourself, you have to establish that credibility with the support team early on.
By the way, when your car breaks down do you call the manufacturer who made it, the dealer who sold it to you, or the recovery organisation you're a member of?
Does anyone take out support contracts with guaranteed levels of service and response for support, or just work on an ad hoc problem-by-problem basis?
More questions than answers I'm afraid.
Ken.