We just went public with our Request Tracker (RT) instance here at Martin Luther College this past week and so I thought I’d do a little post on how I am currently using it to try to help me get stuff done … and more importantly, make sure I get the right stuff done.
We have a support email address which feeds directly into Request Tracker every five minutes and I’m trying to get into the habit of asking people to submit requests themselves so that I can better track what is getting done and what needs to be completed.
From there, a ticket is automatically created in the General queue and then an email is sent off to myself and our support supervisor so that we can triage and assign the tickets to whomever it might need to be. We keep a number of other queues for internal purposes and to easily see where our time is needed.
I then use RT to handle almost all communication between myself and the requestor so that I can easily look into the history to find what has been said. I have custom searches organizing my tickets first by status (open on top), then priority (higher number higher up), and then finally by most recently updated (via a reply). This gives me, at a glade, a look at what I am working on, which are the most important, and then which have been replied to most recently as well. It works for now but there will be tweaks.
I use one queue, Server, to keep track of the changes needed at the next maintenance period. Right now I have seven updates queued up which range from updating our XenServer stack to replacing the batteries in our network rack UPS. I can then pull those tickets together to plan for what we are going to try to accomplish at the next maintenance period. It also lightens my cognitive load by allowing me to dump things into RT where I can refer back when there is a need.
I also just setup an Outage queue where our intense of Icinga will dump its emails and then RT will create a ticket for each outage. Then I can track what was done to fix the issue and refer back if there is a question in the future. I need to look into automatically closing tickets or not sending the final online notice so that there isn’t TOO much noise in the queue.
The next issue will be reporting, but that is for another time. For now, it is “good enough” to have a place to put down our needs and keep track of what is being done. Having that has been a huge help and allowing people to send in their support requests and have a ticket automatically generated has been good PR for the department too.
There is always room for tweaking, and I’ll report on that in the future as well.