http://www.xoops.org is another one to look at. They have a bunch of support/help desk modules. I have a xoops site, but I haven't used it. Anything more modern than texinfo + ht://dig would rock. On Nov 10, 2007 9:33 PM, Bob Hartmann <bob.hartmann at gmail.com> wrote: > > 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/20071111/d88206d0/attachment-0001.htm