RT - Request Tracker for Departments and Groups

• Requests (or Tickets) can be initiated by email or Web.
• Appends and status changes are tracked.
• Tickets can be assigned to queues.
• RT has a rich privilege system, so that different users may have different rights to change or assign a ticket, based on queue, etc.

• Tracking request history.
• Sorting related tickets into queues.
• Allowing a ticket to be assigned to a given staff member.
• Allowing priorities to be assigned and automatically escalated.
• Sending copies of changes by email to the staff and to the original requestor.
• Consistently using a departmental email address, so that personal staff email addresses are not involved.
• Allowing some changes by email if convenient.
• Using bluestem, so no additional passwords need to be remembered.
• Allowing interaction via the Web, with any Web browser. No special client is involved. Further, the original requestor can check the status of his ticket and view appends on the Web.
• Allowing administration -- new queues, ticket assignment, new users, etc. -- to be done directly by a departmental administrator.

Typical departmental usage:

• A department might have 2-3 students assistants and a supervisor who answer inquires about admissions. RT would allow the supervisor to assign a given request to a specific student or let any student answer any unassigned request. The supervisor can add or remove students assistants as needed.
• If the department also provides tech support to its faculty, those requests could be tracked in a separate queue, either using the same email address as used for admission queries or a different one. A different set of staff would review the requests for tech support, and the student assistants answering admissions questions don't have to know about this queue.
• Additional queues, groups of people, and email addresses can be added, perhaps for classroom support or for a specific classes. Tickets can be moved from one queue to another as needed.

One Instance

• Easiest to set up and administer.
• Trivial to move tickets between queues.
• Multiple email addresses allowed.
• One URL works for all queues.
• A user can see all his tickets in all queues on one page.

Multiple Instances

• Use if the instances must be customized very differently.
• Use if the admins of the multiple instances can't work together.
• Use if you will never transfer tickets between instances and there are serious privacy concerns about ticket contents.

If you already have an RT instance in your department, see your admin/REACH member about creating a queue for your needs. However, if you need a new instance, send a note to systems@uic.edu with the following:

• Name of Instance. Probably related to the name of your department, no spaces are allowed. This will be used in the URL and possibly in outgoing email, so keep it reasonably short.
• Principal administrator. Probably you. You'll have superuser privs to configure your RT instance, add users, create queues, assign privs, and create new superusers. Pretty much everything but fool with the code base.
• Email address. This is optional. If you want to advertise "Send requests to whatever@uic.edu", this is the place.