Comments on: Does the good documentation increase the load of technical support? http://www.drexplain.com/isv-kaizen-blog/documentation/does-the-good-documentation-increase-the-load-of-technical-support/ Strategy of continuous improvement for ISV business Thu, 29 Jul 2010 14:26:46 +0000 http://wordpress.org/?v=2.1.3 By: Craig Prichard http://www.drexplain.com/isv-kaizen-blog/documentation/does-the-good-documentation-increase-the-load-of-technical-support/#comment-802 Craig Prichard Thu, 14 May 2009 14:27:10 +0000 http://www.drexplain.com/isv-kaizen-blog/documentation/does-the-good-documentation-increase-the-load-of-technical-support/#comment-802 Scott's observations are interesting. I agree that the goal of good documentation is to reduce service incidents. Striking a balance between too little and too much content is the challenge. Undoubtedly too little documentation will leave the end-user with few options for seeking support, such as newsletters, webinars or other training or educational rich media, and forums if they are available. Maybe the 1000 page manual is in the wrong hands? Maybe it should be an in-house support document and the end-user manual only contain a subset (single-sourced, I would hope) of all that content. Stimulating the imagination of the end-user to experiment and push the application might result in additional service requests, but my experience has been that the result of that quality of free usability testing should lead to a better product. Monkeying around can lead to "stupid user questions" but it can also exposing otherwise hidden bugs. That same creative imagination might help the forward development of the application by providing a fresh perspective on its use in the real world. It is possible to have too much of a good thing. A single man at a buffet could hurt himself trying to do justice to the opportunity alone. But accompanied by his football buddies, the buffet would serve them well. Massive documentation can certainly serve the support (football) team well but it might overwhelm all but the most gluttonous among the rest of us. My thoughts are my own. Craig Prichard Technical Communicator craig.prichard@gmail.com Scott’s observations are interesting. I agree that the goal of good documentation is to reduce service incidents. Striking a balance between too little and too much content is the challenge. Undoubtedly too little documentation will leave the end-user with few options for seeking support, such as newsletters, webinars or other training or educational rich media, and forums if they are available.

Maybe the 1000 page manual is in the wrong hands? Maybe it should be an in-house support document and the end-user manual only contain a subset (single-sourced, I would hope) of all that content.

Stimulating the imagination of the end-user to experiment and push the application might result in additional service requests, but my experience has been that the result of that quality of free usability testing should lead to a better product. Monkeying around can lead to “stupid user questions” but it can also exposing otherwise hidden bugs. That same creative imagination might help the forward development of the application by providing a fresh perspective on its use in the real world.

It is possible to have too much of a good thing. A single man at a buffet could hurt himself trying to do justice to the opportunity alone. But accompanied by his football buddies, the buffet would serve them well. Massive documentation can certainly serve the support (football) team well but it might overwhelm all but the most gluttonous among the rest of us.

My thoughts are my own.

Craig Prichard
Technical Communicator
craig.prichard@gmail.com

]]> By: Mike Wethington http://www.drexplain.com/isv-kaizen-blog/documentation/does-the-good-documentation-increase-the-load-of-technical-support/#comment-803 Mike Wethington Fri, 15 May 2009 20:06:55 +0000 http://www.drexplain.com/isv-kaizen-blog/documentation/does-the-good-documentation-increase-the-load-of-technical-support/#comment-803 ...Documentation has so much cool stuff described, that it makes people’s imagination stimulated and they start thinking of other, even more exotic stuff they want to do but can not figure out and start a service request for it... I would call this an opportunity to make more revenue. Either charge for the services that customers want delivered or, if enough interest, create new features/functionality in the product to upsell to customers. Sounds like Doc transitions from a cost-center to a revenue-center in the 2nd scenario. …Documentation has so much cool stuff described, that it makes people’s imagination stimulated and they start thinking of other, even more exotic stuff they want to do but can not figure out and start a service request for it…

I would call this an opportunity to make more revenue. Either charge for the services that customers want delivered or, if enough interest, create new features/functionality in the product to upsell to customers.

Sounds like Doc transitions from a cost-center to a revenue-center in the 2nd scenario.

]]>