I've implemented queues based on where the work originates, and which group it involves.<br><br><span style="font-weight: bold;">General</span> (research computing administrative business)<br><span style="font-weight: bold;">
<br>Operations</span> (network and server operations) for tickets originating within the research computing system administration group<br><span style="font-weight: bold;"><br>ICPSR</span> - for duties related to the inter-university consortium for political and social research, such as the Summer Program for Quantitative Methods in Social Research. 
<br style="font-weight: bold;"><span style="font-weight: bold;"><br>Helpdesk</span> - 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.
<br style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;"><br></span>ComputerScience</span> - for work relating to computer science doctoral program (I may get a request to referee a paper, give a talk, etc).
<br><br>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.
<br><br><br><div><span class="gmail_quote">On 2/15/06, <b class="gmail_sendername">Lee Roth</b> <<a href="mailto:bwc_lr1@easy48.com">bwc_lr1@easy48.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


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.<br><br>
<b>Background: </b>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.<br><br>
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.<br><br>
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.<br><br>
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.)<br><br>
<b>Big Question:</b> 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?<br><br>
Thanks!<br><span class="sg"><br>
<p>
<b>Lee Roth<br>
</b><font size="2">Email:  <a href="mailto:bwc_lr1@easy48.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">bwc_lr1@easy48.com</a><br>
</font>


</p></span><br>_______________________________________________<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users" target="_blank">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
</a><br><br>Be sure to check out the RT Wiki at <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wiki.bestpractical.com" target="_blank">http://wiki.bestpractical.com</a><br><br>Download a free sample chapter of RT Essentials from O'Reilly Media at 
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://rtbook.bestpractical.com" target="_blank">http://rtbook.bestpractical.com</a><br><br>WE'RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
<br>San Francisco - Find out more at <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://bestpractical.com/services/training.html" target="_blank">http://bestpractical.com/services/training.html</a><br>
<br></blockquote></div><br>