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
LBNLOn 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
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com