The ideal support policy
-
There have been many comments about support on this forum... Rather than focusing on specific cases, I would like to open up the discussion and talk about the ideal support policy. Of course, we would all like unlimited 24/7 free telephone support for life directly from someone who has unlimited access to and complete control over the development team. Unfortunately, companies have made this promise (in most cases with good intentions) end up getting in trouble by either not being able to live up to their promises, or going down because their business model doesn't make sense. I wanted to share the perspective of a programming tools vendor. Sax Software has been in the component business four about seven years, and over the years we've had different support models. We started out with a flat, unlimited free phone support model for everyone. Support was so easy to reach that people would call us for very simple questions they would probably have solved using the documentation in less than a minute. It also put a beginning VB developer who needed a walk-through at the same priority level as a seasoned corporate developer who's $80K project depended on our control. In short, it wasn't a good policy, neither for the company and nor for its customers. Over the years we've defined a few principles we use to determine our support policy:
- Quality Is More Efficient Than Support: Every dollar invested in testing and quality assurance will save a vendor between three and five dollars in technical support.
- Enable and Promote Self Help: Most developers are very self-reliant people who prefer to go on the web and solve their own problem, rather than relying on someone else.
- Be Open About Bugs: A hidden bug can waste hours or even days of a customer's time. The benefits about publishing all known bugs and fixes far outweigh any negatives.
- Make Financial Sense: Support doesn't need to be a profit center, but also can't be a money pit. It's important to do the math and make sure the support department can be self-sufficient.
- Set Correct Expectations: It's important that customers know what to expect. It's tempting to over-promise, but it's better to under-promise and over-deliver.
- Provide Multiple Support Levels: Different customers have different needs, and many customers actually prefer to have a premium paid support option so they can be sure to receive the attention they need.
-
There have been many comments about support on this forum... Rather than focusing on specific cases, I would like to open up the discussion and talk about the ideal support policy. Of course, we would all like unlimited 24/7 free telephone support for life directly from someone who has unlimited access to and complete control over the development team. Unfortunately, companies have made this promise (in most cases with good intentions) end up getting in trouble by either not being able to live up to their promises, or going down because their business model doesn't make sense. I wanted to share the perspective of a programming tools vendor. Sax Software has been in the component business four about seven years, and over the years we've had different support models. We started out with a flat, unlimited free phone support model for everyone. Support was so easy to reach that people would call us for very simple questions they would probably have solved using the documentation in less than a minute. It also put a beginning VB developer who needed a walk-through at the same priority level as a seasoned corporate developer who's $80K project depended on our control. In short, it wasn't a good policy, neither for the company and nor for its customers. Over the years we've defined a few principles we use to determine our support policy:
- Quality Is More Efficient Than Support: Every dollar invested in testing and quality assurance will save a vendor between three and five dollars in technical support.
- Enable and Promote Self Help: Most developers are very self-reliant people who prefer to go on the web and solve their own problem, rather than relying on someone else.
- Be Open About Bugs: A hidden bug can waste hours or even days of a customer's time. The benefits about publishing all known bugs and fixes far outweigh any negatives.
- Make Financial Sense: Support doesn't need to be a profit center, but also can't be a money pit. It's important to do the math and make sure the support department can be self-sufficient.
- Set Correct Expectations: It's important that customers know what to expect. It's tempting to over-promise, but it's better to under-promise and over-deliver.
- Provide Multiple Support Levels: Different customers have different needs, and many customers actually prefer to have a premium paid support option so they can be sure to receive the attention they need.
What kind of feedback are you looking for? You've stated the "problem" pretty well. What level of support should I expect... what level of support can I get? It really depends on the product doesn't it? If your company sells controls that developer's will use in their applications (as in your case), then the level of support I expect is "God-like" and much, much more than I expect from a company I buy a completed product from.... What's "God-like"? Well, as you said, we tech people are pretty self sufficient and you are right, in most cases I would prefer to figure it out myself. Forums are a great idea, but there should be SOMEONE from your support that monitors the forums for the harder questions. Also, forums make it easier for us... I don't have to wait online for someone to figure out what the ()*$)(#$* I'm talking about. However, if I can't figure it out on my own, I fully expect CLOSE support, and from someone that knows what the heck they are talking about. We, as developers, all encounter this. The truth of the matter is that the "help desk" people are simply not usually going to be qualified engineers. At my company, the support was probably MUCH better than it is today back when I personally took support calls. However, my company can't afford me to pay me a developer's salary for doing 50% phone support.... never mind that DOING phone support is possibly the most horrible job imaginable (for me anyway). So, now, we have a very technically savy help desk girl that catalogues and tracks issues as they come in. She's very patient and pleasant, and very smart. Now as the issues get tracked, there's someone that knows if it's a problem we're already aware of or one there is a workaround for and the problems only come to me as a last resort. This means sometime slower resolution, but a more pleasant experience (I'm no people person) and less stress for me... For main-stream applications... let's say Roxio's Easy CD Creator... possibly the worst written software in history I can't really see giving support past a certain point. The unfortunate truth is that your average user is only capable of so much. Maybe I'm more capable than my teacher-friend we'll call Bob at handling complex instructions... but Roxio doesn't know that and why waste hours with a guy that's just not going to get it? I have chosen to switch to Nero (MUCH better) because of this same problem.
-
There have been many comments about support on this forum... Rather than focusing on specific cases, I would like to open up the discussion and talk about the ideal support policy. Of course, we would all like unlimited 24/7 free telephone support for life directly from someone who has unlimited access to and complete control over the development team. Unfortunately, companies have made this promise (in most cases with good intentions) end up getting in trouble by either not being able to live up to their promises, or going down because their business model doesn't make sense. I wanted to share the perspective of a programming tools vendor. Sax Software has been in the component business four about seven years, and over the years we've had different support models. We started out with a flat, unlimited free phone support model for everyone. Support was so easy to reach that people would call us for very simple questions they would probably have solved using the documentation in less than a minute. It also put a beginning VB developer who needed a walk-through at the same priority level as a seasoned corporate developer who's $80K project depended on our control. In short, it wasn't a good policy, neither for the company and nor for its customers. Over the years we've defined a few principles we use to determine our support policy:
- Quality Is More Efficient Than Support: Every dollar invested in testing and quality assurance will save a vendor between three and five dollars in technical support.
- Enable and Promote Self Help: Most developers are very self-reliant people who prefer to go on the web and solve their own problem, rather than relying on someone else.
- Be Open About Bugs: A hidden bug can waste hours or even days of a customer's time. The benefits about publishing all known bugs and fixes far outweigh any negatives.
- Make Financial Sense: Support doesn't need to be a profit center, but also can't be a money pit. It's important to do the math and make sure the support department can be self-sufficient.
- Set Correct Expectations: It's important that customers know what to expect. It's tempting to over-promise, but it's better to under-promise and over-deliver.
- Provide Multiple Support Levels: Different customers have different needs, and many customers actually prefer to have a premium paid support option so they can be sure to receive the attention they need.
I agree with the points that Mike makes. And it is also true that Dundas has gone through using different policies, many of which did not work. Some of them were setup by the product managers, so each product had a slightly different policy, which of course caused much grief for technical support and our clients. We now have one simplified policy. This helps new clients greatly, but legacy clients still feel some of the pains of the old policies. To help any clients over this hurtle, I am more than glad to personally help out each client in need. As for support, we have a database driven support site that is continuously being updated with tutorials, add-ons, hints and tips etc. This has helped our clients greatly, and has allowed Dundas to provide better support; Since all of the simple questions are already answered there is no need for one on one help for these, thus freeing support for more complicated questions. Also, quality of a product is the largest factor. It is much easier to give support on a high quality product than a poor one. Reason... most of the questions about a poor product are to do with bugs, which is usually out the control of the support personnel. Troy Marchand