Other than some final email configuration, my RT install is ready to go. I
wonder if some of the RT gurus on the list would be willing to offer a
suggestion or two about how to configure RT for my organization.
I work for a fairly large school district (about 9,000 students K-12). We
have 10 different schools plus a district office where we have several
district-wide tech support people and network managers. Each of our schools
has at least one dedicated tech support person.
Most day to day tech support issues get handled by the tech support people
in the schools. Occasionally they run into problems that need to be
addressed by one of us at the district office. The district office staff
work on network issues, servers, and the like.
I have questions like:
- Should I have lots of queues with each building having its own complete
set, duplicating queues in other buildings, or should I have relatively few
with the building techs managing their own tickets within the larger queues?
How do your techs like to work? Do they want to see everything
all the time, or just what they need to see to get the
work done? If you have a lot of queues, you’ll have to
build more complicated queries to get an overall picture.
But too few makes it harder to separate tickets. How
many outstanding tickets do you figure to have? If you get
20/day and usually resolve them quickly, you don’t need
many queues; if you get 200/day and many stick around, get
- A related question… Should I have lots of email address for our
teachers to try to remember, or should we create a bare minimum and have our
techs sort tickets as they come in?
You did say most problems are resolved at the school level,
and the tickets are escalated only occasionally. So I’d
suggest one queue and email per school plus one queue for escalation.
That way the tickets are routed most quickly to the proper tech,
and staff in each school have only one email address to remember.
Also remember you can have CustomFields if you need to tag
each ticket with specific info but don’t want to increase queues.
- How could we use RT groups to better organizer our tickets?
Groups are groups of people. If you give privs to groups,
then it is easy to add new people -- you just add them
to the proper groups, rather than add a set of detailed
privs to each person.
- Is it possible to create a queue that only one person could see and work
I'm sure, but is this what you really want? I'm an RT newbie
myself, my above advice is based on how we work with other
ticket systems. But I'm trying to get us converted from Clarify
to RT, and one of the things we don't particularly like about
Clarify is the wipbin, really a personal queue. The problem is
that "assigning" a problem in Clarify means transfering it to
the personal wipbin, in which case it is removed from the
general queue. So I, as a manager, have to go inspect everyone's
personal wipbin to check status, rather than getting a single
list of my queue contents. In RT, ownership of a ticket and queue
assignement are separate, and that makes lots more sense
the way we work. So if you want a personal queue to be
a personal to-do list, fine. But if you think a person
will transfer a ticket out of a more general queue into his
personal queue as a way of owning it, then it makes the
manager's job a lot harder.
Any ideas from the list would be appreciated.
Start as simple as you can, and add features as you discover
you need them. We've never had a ticket system work "out of the box"
because we never knew what we really wanted until we used it
in production a little while. Every ticket system and political
organization has its quirks, and you just have to see how they
Technology Integration Specialist
Hopkins ISD #270, Hopkins, MN, USA