On Nov 10, 2007 8:27 AM, Josh Welch <josh at joshwelch.com> wrote: > 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 > > I heard Wiki too. Many Wiki's offer templates and forms for structure, but also have whiteboards for "X is being Y'd this week." Support people can follow a process tree and still have search capabilities. Wiki also has the benefit of a sense of ownership, which was implied in Wayne's original post. I was once a TWiki freak; I still think it's a good solution, but I've been scolded here for being too retro or something. Maybe geeklog. I dunno. My main point is that this can be done well within any of a number of already-built web frameworks without much if any coding. And it can be implemented and grown rather quickly. _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20071110/e295ed71/attachment.htm