This is a bit more complex than just a feedback form, but it can be handy if you have a need for it. It's also possible to set them up so that email sent to a normal email address goes into the trouble ticket app automatically, so you can get the best of both worlds, using your trouble ticket app to help manage the normal email.

There are free and open-source trouble ticket/help desk web applications out there, but I haven't done extensive research on the topic. Bug-tracking applications are a subclass of software that is a bit easier to find, since open source projects have a need for bug-tracking. Mantis and Bugzilla are two bug-tracking applications that seem to be more popular. It's not uncommon for people to use a bug-tracking app as a help desk app.

Some googling turned up this web page; they're selling their commercial help desk app, but they also list several open source help desk apps:

http://www.opensourcehelpdesklist.com/

I wouldn't recommend building a help desk app from scratch, but the one down side to using an existing help desk/trouble ticket app is that they can be more complex than you really need. So if you have an IT guy who's good with web apps (php and mysql are a good tool set for this sort of problem) you might find it takes less time and effort to build a simple system from scratch than to "dumb down" a complex existing system.

Here's a quick "day in the life" of a help desk/trouble ticket system:

1. the customer contacts the system by sending email to an address, or filling out a form.
   
   
2. if it's a new request, the trouble ticket system creates a new a new trouble ticket entry in the database. The trouble ticket entry contains the contents of the email or form inputs, and has a unique number that identifies it. It also usually has a status flag, and it usually has some means of being "assigned" to somebody, and a priority flag.
   
   
3. The trouble ticket number is sent back in an automatic reply email, or displayed to the user on the website, so the user can note it and refer to it in later conversations.
   
   
4. If it's an existing trouble ticket, the information is appended to the trouble ticket entry already in the database.
   
   
5. The people on the inside log into the trouble ticket application to check for new requests; the trouble ticket application might send them email when the request is submitted, along with a link to click to log into the trouble ticket system and go right to that request.
   
   
6. The ticket is assigned to somebody on the inside to follow up on.

   The buzzword for this sort of stuff is "workflow management", and it can be simple or complex. Generally it's best for it to be simple and flexible. Let the human beings manage the process; they tend to be much better at it than a rigid system.

   A ticket might be assigned according to some criteria - maybe there's a category checkbox that the user selects when they submit the request, or maybe there's a supervisor who skims the stack of incoming requests and assigns it. Another alternative is to let a pool of help desk people take turns pulling requests out of the inbox, as they finish each request they're dealing with.

   More complex workflow systems can enforce a step-by-step process; Alice gets it first, reads it and sets the status to "diagnosed, hardware problem", at which point it shows up in Bob's inbox because Bob handles hardware problems, and so forth.

   This can be handy and useful, but it can also be awkward and painful, so be careful about buying into such a system. Keep it simple. Generally once somebody starts dealing with the end-user, you want to keep them with that person, so the end-user feels some continuity and doesn't feel like a pinball being bounced from person to person. Of course, this has to be balanced against making sure the right person is dealing with the problem.

   
   
   
7. Often more serious trouble ticket systems provide options for supervision and oversight, so somebody can check on the status of tickets, see who has what and what stage it's at, and raise the priority of requests that have been waiting too long.
   
   
8. Typically the people on the inside (help desk consultants, whatever) will copy all interactions into the database. Often they'll use the system itself to send responses and receive followup emails from the user, and the system will automatically include those in the trouble ticket entry in the database. This allows somebody else to step in, review the history to date and catch up, if necessary.
   
   
9. Once a ticket is closed, it's still available for reference, either for later interactions about the original request, or for reference in the event of a similar request later; help desk people can search on keywords and, if they find a relevant trouble ticket, copy the conclusion out of that and send it to the user.
   
   
10. Depending on the circumstances, the trouble ticket archive might be available to the public, or there might be an internal process of selecting particularly useful trouble ticket conclusions, sanitizing them (removing personal details) and migrating them to a public database. This is often called a "knowledge base".

Feedback

Verification Image:
Subject:
Your Email Address:
Confirm Address:
Please Post:
Copyright: By checking the "Please Post" checkbox you agree to having your feedback posted on notablog if the administrator decides it is appropriate content, and grant compilation copyright rights to the administrator. Message Content: