People want a quick answer. As suggested by your comments, these people want help or explanation on issue x or feature y; they don't want to know how to use the program from start to finish.
It's the new wave in Technical Documentation, the advent of wikis and the accessibility of the web means people can search for exactly what they want, rather than sift through an entire manual. Even the index isn't s useful as you'd think, if the user wants to know how to change skins on the web interface, the index is likely to list 'Web Interface', or even 'Skins' - but not their specific query.
People are lazier than ever, because they can afford to be. Products are becoming easier to pick up and use, and specific issues can be googled, or in your case, phone support can be contacted. As far as I'm concerned, Technical Writing is experiencing a massive change, fueled by open information.

DS Techwrite - Australian Technical Writers and LinkOne Resellers.

I don't care if no one reads the documentation I create. The docs are there if the user needs them.

If I help one tired, frustrated, angry, confused user -- just one over the lifetime of the document -- then I have done my job well.

If no one ever reads the user guides I produce, that does not diminish the fact that I poured my blood, sweat, and tears into creating them. The guides still exist and I wrote them.

If no one ever reads the user guide I create, so be it. Life rolls on.

A long-time writer, Tom, used to say that we're writing for the one person in that company who will read the manual. Most of the time, users (including yours truly) will stand on a chair to ask someone in the next cube about a problem with a product. Not only is it easier, but the answer is more likely to be fit because that other person knows, or can easily discover, my context. Remember, my job is not to learn Framemaker; it's to write a document. So, my asking my colleague helps me learn enough to get my primary job done. My colleague has probably read the manual, used Google to track down a bug, and maybe even spoken to the product's tech support team; my colleague did that willingly because my colleague is a nerd. (I've been on both sides of the cube wall.)

So, IMO, it's OK to target the resident smart person at the customer's site rather than trying to find way to trick end users into reading our fine manuals.

I loved this post. It does get to the heart of something that twists our insides -- the praise we receive about how valuable our contribution is, while at the same time knowing that few actually use what we contribute.

You might try delivering more than just a manual. Maybe your users would like a list of top ten FAQs or videos, or something else.

But even if you just give them a manual that has a pretty cover and terrible content, it will act as a pacifying placebo in the same way your car manual in your glovebox functions. Sure I like to have that manual in there, but I've only glanced at mine when I'm totally bored. I rarely use it, but if I were to lose it, it would pain me greatly.

By the way, I added a link to this post on WriterRiver.com, a social media news site similar to Digg.com but for technical communicators. You can view the post here.

I understand your frustration. I wrote mortgage loan and engine analyzer software manuals for years. I found that people are not crazy about reading a monolithic book. We, as writers, see the value of the book, but we are not necessarily our audience. Not sure how your manuals are delivered but maybe it's time to try something new. If you're not already doing so, think about online FAQs with short answers and links to the long answers in your manual. Be creative...try something new. Hopefully, the users will thank you and it may save your sanity!

As long as the support team continue to provide your users with a more convenient option of bypassing the manual altogether by answering questions directly over the phone, then I expect your disappointment to continue.

However, if everyone in the support team were to persistenly refer users to the manual instead of repeating the same answers over and over then users will gradually cotton on that actually the manual is the best first point of reference. It's all about educating the users to help themselves and stop being lazy which the support should embrace as a goal because that's less strain on their resources...

Only then can the real test of how good your documentation actually is can take place...

Best

LW

Same as it ever was, alas. Seems manual-readers still enjoy minority status; perhaps the same is true of readers in general. Technical or not, writing is a thankless gig.