Quoting Wayne Johnson <wdtj at yahoo.com>: > I know this is a bit off topic... > > Our support organization is trying to create a problem determination > guide for our product. What I mean is a "scripted" flow chart that > they run through to try and isolate (or even fix) a customer's > problem. The biggest issue I see with this is that as a product > changes over it's lifetime, the contents of this guide will change. In > addition, we'll want this to be developed by the support personal as > they gain experience with the product, finding new diagnostic > procedures and tools. > > This is likely something built on a > hierarchical database with a bunch of questions like, does this work? > Does that error occur? Is there this message in a log? > > Anyone seen this? Any suggestions. > Yeah, I've seen this to varying degrees of success. If the product for which you are trying to do this has any degree of complication, then it's damn hard to put together a document of this sort. There are too many ways that a troubleshooting process can fork. I'm assuming the point here is that you're looking to get new people up to speed in a rapid fashion, correct? Your best bet is to identify the low hanging fruit, those simple issues which address a large number of your problems, and tackle those. That should get you part of the way there. Your next bet bet would likely be to break down the product into specific areas of functionality. Perhaps have a top level guide that helps your support staff to determine which area the issue lies in. They then turn to the document for that particular area which drills down more deeply into specifics. It would seem that this format lends itself well to a Wiki, I've never actually gotten to implementing such a thing but it's great in theory. Josh