A design question: Queues vs Owners?

RT Users
1

I’m trying to decide on how to organize our RT.

Right now, our RT is just for the IT department and internal task assignment and tracking.

We have 5 users, including the VP of IT.

I set up 5 queues, one for each user, because I really liked the QueueList portlet. Everyone has full viewing and full control over each other’s queues.

Now, however, the question is: Should I…

a) Continue the status quo and have a queue for each individual? This way, the tasks can be assigned simply by changing the queue they are in. The advantage is that no one has to “own” a ticket; if it’s in your queue, you are the “owner” and that task is assigned to you. This is simpler, as users don’t have to both 1) change the queue of a ticket and 2) change ownership.

My question is, is option a above going to create unforseen problems later on down the road? Are there problems that occur when the Owner field is not actively used?

Or…

b) Tell the users they need to pay attention to both the Queue AND the Owner when creating and assigning tickets?

Or…

c) Do away with the five queues, use only one queue and rely on changing ownership for task assignment? This is easier for the users to grasp, but you lose that QueueList portlet, which my boss really likes and wants to keep (and I agree). However, I haven’t been able to find or code an equivalent portlet based on ownership.

EDIT: Thanks, GreenJimII, that helps! If you all want to, do please let me know how you have your RT set up with your departments, as all examples of how other people use queues and groups helps. I think, since we have a small IT department, we will be starting small, but eventually I’d like to spread this out to the entire company (35-40 people, 6 departments). Thanks!

2

We (with a far bigger IT department) use a mix of options a) and c), along with groups to give various ACL controls on who can see, interact, own, etc tickets and queues. We have queues per team, and then its up to the team whether they just work on tickets collectively (so don’t assign an owner) or take tickets individually so you know who is working on what. Indeed its often a mix of the two - short tasks are just responded to and resolved, longer tasks are taken ownership of. The QueueList is on the home page which shows the status of the various queues an individual can see (which is usually more than just their team queue, but not all queues - security and HR related queues for example have much tighter ACLs than general IT help queues for example).

2 Likes
3

I would stick with c option so that
a. the number of queues don’t increase if the IT staffing increases. Maintenance increases if there are other teams using the RT system and each of them asking for separate queues for each staff. More so, if the CEO has access to all queues of all departments s/he should see 6 queues and not 35-40 queues.
b. I guess there is a portlet where each IT team staff can see what tickets they own or are assigned to.
c. The queuelist portlet, from my understanding, is relevant to the manager/boss as he gets to see the count of tickets each team member has, but is less relevant to the staff/team member. I would have created some custom charts for the IT queue grouped by owners and shared its access with the boss such that he gets to see the ownership count.

option c will keep system simple and easy to use for team members and maintain for the IT maintainers.
Charts and save searches would cater to the needs of manager/bosses and CEO, who would be more interested in the reports.

2 Likes