Troubleshooting versus support
When we talk about 'support', especially things like 'vendor support', I think that there are actually two general things that are getting lumped under the same label: issues that you could have dealt with on your own if you knew enough, and things that are broken.
Although I don't have really good names for them, let's call the first sort of issue 'troubleshooting' and the second sort 'support'.
Unless the vendor dropped the ball on their documentation (which is certainly known to happen), calling the vendor up for troubleshooting is your fault, because you've failed to read or to understand (or you have decided that calling the vendor is faster than reading). In a sense you are wasting the vendor's time and asking them to do your work for you.
Support issues, genuinely broken things, are the vendor's fault, not yours. No amount of understanding the documentation or reading the FAQ can help (except perhaps to say 'this is a known bug'). Fixing the problem is not your work, it's the vendor's.
The difference matters in part because reasonable pricing is different between troubleshooting and support. It's hard to object to being charged each time you want a vendor to hold your hand, or to a vendor with flat rate troubleshooting saying 'you're asking for too much hand holding'. But being charged for each broken thing you discover, or hearing 'this is costing us too much to fix, go away' is infuriating for reasons I covered in more depth in SupportMythPartII.
Working in a heavily technical environment as I do, I don't care very much about a vendor's ability to do troubleshooting; we'll handle that ourselves. I do care quite a bit about the vendor being sane about support.
|
|