[rt-users] RT Newb Queue/Group Strategy question

[Kenneth Crocker]

David,


	I think that the way YOUR infrastructure is set up is the key. If you 
have different technical support groups that work on tickets from a 
specific set of customers OR specific products, then I would create a 
single queue for either a) each technical support groups that works on 
specific products or b) each product with a select technical groups that 
are the only ones to work on said tickets for said product(s).
	Once you have decided how you want your work to be segregated (by 
product, or group or customer), I would then created the groups that 
will work on ticket in those queues, perhaps with the queue name as a 
prefix to the group (i.e. "Queue1-Tech-Support"). Once that is done, it 
is merely a matter of deciding how you want users (both customers, tech 
support, and admin personnel) to be able to use the system and grant the 
appropriate rights. We like keeping ALL users in some sort of group, 
that way rights' maintenance is MUCH less of a pain. That's why we use 
the naming convention for groups, it makes it easier to know who can do 
what in which queue.
	Then there is the ticket metadata. You might need special information 
to be retained for tickets in one queue that is different from that for 
tickets in another queue. What should they be named? What values? Who 
Admin's the values? Who is allowed to see the data in a ticket? who is 
allowed th CHANGE the data in a ticket? All that good stuff.
	Now the EASY stuff. What kind of communication do you want sent to 
customers? Tech support? Admin personnel? What should it say? Under what 
conditions?
	We have created a set of RT guides for general users, tech support, and 
RT system Admin types that we use for All of our users and we have well 
over 100 queues and going on 200. In some cases, we have an Approval (I 
like to call it the "Bucket" queue) queue that acts as an 
evaluation/approval/prioritization stage (for the requests of a specific 
set of related support queues) before we even assign the ticket for work 
(the problem might be just a training problem, so why bother the 
technicians?). All in all, RT has been able to do all of this and then 
some in a variety of flexible ways for many different types of support 
because we set up the infrastructure concepts first. So, take a look at 
what makes sense for you guys in processing ticket s and go from there.


Kenn
LBNL

On 5/28/2008 10:38 AM, David Nalley wrote:
> Hi All, 
>  
> I am a relative newb who has just deployed RT in pilot to replace our
> aging, inadequate and hated support tool. 
> A little bit of background - my employer, among other things, provides
> support for a wide range of software and hardware products to several
> hundred customers. Most of these customers have 1 or 2 employees who act
> as the first-line support prior to bringing the issue to us. Some of the
> larger customers may have a dozen or more people who are authorized to
> contact us for support. Generally regardless of how large the
> organization is there is a desire for a customer to be able view all of
> the tickets created by anyone at that customer. 
>  
> I have thought about creating a queue for each customer and then
> creating rules for moving tickets to the proper queue - but that seems
> messy. (Proliferation of queues doesn't sound like a good thing based on
> my reading thus far) 
>  
> I think perhaps a better solution, at least conceptually, is creating a
> 'customer manager' group and magically granting permission for that user
> to be able to see any ticket created by someone with a matching
> 'Organization' in their user info. This sounds easier long term, but
> requires more effort up front I think. 
>  
> Anyway - I seek to leverage the wisdom of the group as I imagine that I
> am not the first person to have had a need to deal with this situation. 
>  
> Thoughts? 
>  
>  
> David Nalley
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
> 
> 
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com
>