Seeking queue setup wisdom

RT Users
1

I’ve been running/using RT (V3.2.3, just upgraded to V3.4.5) for some
months now for a small group of network/sysadmin folks and I’m not 100%
satisfied with the RT operation that I currently have.

Background: My initial setup of queues was based on type of gear, e.g.
Routers, firewalls, servers, etc. All of these queues have a default
priority range of 0 to 29 and escalation period of 7 days from min to max.
I also have a queue for ‘projects’ that are long-term, back-burner kinds of
things, so the escalation period is very long (6 months). I have a daily
script that does the auto-escalate of priorities.

The problem is that the ‘one-priority-scheme-fits-mostly-all’ approach
isn’t working too well… calls that are ‘hot’ don’t escalate as fast as
they should from their initial logging (via email interface), while others
get worked for a while and then need to migrate to a ‘back-burner’ lower
priority and escalate much more slowly than default.

I like the ability to do end-of-month type reports and use the queue name
to simply categorize the type of calls that have been worked, so I’m
reluctant to create a plethora of queues with name based on priority +
equipment category. Ick.

I’ve been toying with creating a custom field that mimics my current queue
names and then have the queues be strictly named according to priority
(urgent, important, routine, low), but then I lose my nice end-of-month
ease of reporting what kind of gear that was worked on. (Read: Yes, I can
craft reports on that custom field but I guess I am trying to avoid that.)

Big Question: For those of you that are successfully using RT to track
technical requests and tasks, are your queues equipment/activity centric or
priority-centric? Can you describe your RT implementation and how/why it
works well for you?

Thanks!

Lee Roth
Email: bwc_lr1@easy48.com

2

I’ve implemented queues based on where the work originates, and which group
it involves.

General (research computing administrative business)

Operations (network and server operations) for tickets originating within
the research computing system administration group

ICPSR - for duties related to the inter-university consortium for political
and social research, such as the Summer Program for Quantitative Methods in
Social Research.

Helpdesk - for tickets related to applications running on LAMP servers, or
for troubles with rsearch computing applications software; these come from
outside the systems group. Also, trouble reports for the research computing
network that have to be referred to another group go here.

ComputerScience - for work relating to computer science doctoral program (I
may get a request to referee a paper, give a talk, etc).

I’ve found categorization by general areas of responsibility and the
affected group to be useful. This cuts down on the number of queues (I don’t
have queues by product line, for example, though I might if RT implemented
queue collections, as opposed to individual queues) and it simplifies
configuration of the different views of the system that the various
interested parties have.On 2/15/06, Lee Roth bwc_lr1@easy48.com wrote:

I’ve been running/using RT (V3.2.3, just upgraded to V3.4.5) for some
months now for a small group of network/sysadmin folks and I’m not 100%
satisfied with the RT operation that I currently have.

*Background: *My initial setup of queues was based on type of gear, e.g.
Routers, firewalls, servers, etc. All of these queues have a default
priority range of 0 to 29 and escalation period of 7 days from min to max. I
also have a queue for ‘projects’ that are long-term, back-burner kinds of
things, so the escalation period is very long (6 months). I have a daily
script that does the auto-escalate of priorities.

The problem is that the ‘one-priority-scheme-fits-mostly-all’ approach
isn’t working too well… calls that are ‘hot’ don’t escalate as fast as
they should from their initial logging (via email interface), while others
get worked for a while and then need to migrate to a ‘back-burner’ lower
priority and escalate much more slowly than default.

I like the ability to do end-of-month type reports and use the queue name
to simply categorize the type of calls that have been worked, so I’m
reluctant to create a plethora of queues with name based on priority +
equipment category. Ick.

I’ve been toying with creating a custom field that mimics my current queue
names and then have the queues be strictly named according to priority
(urgent, important, routine, low), but then I lose my nice end-of-month ease
of reporting what kind of gear that was worked on. (Read: Yes, I can craft
reports on that custom field but I guess I am trying to avoid that.)

Big Question: For those of you that are successfully using RT to track
technical requests and tasks, are your queues equipment/activity centric or
priority-centric? Can you describe your RT implementation and how/why it
works well for you?

Thanks!

*Lee Roth
*Email: bwc_lr1@easy48.com

The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at
http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at
http://bestpractical.com/services/training.html