RT best practice

Hi everyone,

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:

  1. 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?

  2. 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?

  3. How could we use RT groups to better organizer our tickets?

  4. Is it possible to create a queue that only one person could see and work
    on?

Any ideas from the list would be appreciated.

-Tim

Timothy Wilson
Technology Integration Specialist
Hopkins ISD #270, Hopkins, MN, USA
ph: 952.988.4103 fax: 952.988.4311 AIM: tis270

Hi everyone,

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:

  1. 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
more queues.

  1. 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.

  1. 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.
  1. Is it possible to create a queue that only one person could see and work
    on?
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
mesh.

   bobg

-Tim


Timothy Wilson
Technology Integration Specialist
Hopkins ISD #270, Hopkins, MN, USA

inline

  1. 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?

My recommendation is that unless traffic is quite heavy, have all of the
schools in one queue. Especially if the architectures are similar.
There may be value from visibility into other sites. Then, you’ll
probably want the DO to have a queue of its own, especially if the
primary requestors are intended to be the school techs and your managers
and selves.

But, we’ve found that queues along department lines is most effective.

Another note…our primary queue is primarily for trouble tickets, ie,
tickets that are only open briefly. I created a separate queue for the
ongoing projects.

  1. 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?

Have a logical pattern to them.
it.rt@
helpdesk@

schoolabbr.it@
do.it@

You could have them all go to the same queue if you like. The last is
the most flexible because you can separate out the addresses, and not
have teachers react…plus, the pattern is pretty intuitive (to me).

  1. How could we use RT groups to better organizer our tickets?

Going with the two queue idea, I’d set one group with all the school
techs, and another with DO techs.

Then make all school techs admincc’s of the schoolabbr.it queue, and DO
techs admincc’s of the do.it@ queue. Dependending on how much
visibility you want into school incidents, probably at least on DO
person should be an admincc on the schools queue.

  1. Is it possible to create a queue that only one person could see and work
    on?

don’t see why not, though I haven’t done it. Probably just set the user
permissions rather than group.

Rick Rezinas
Unix Systems Administrator
Qsent, Inc.

When Gladstone was British Prime Minister he visited Michael Faraday’s
laboratory and asked if some esoteric substance called `Electricity’
would ever have practical significance.
“One day, sir, you will tax it,” was the answer.
– Science, 1994

Tim Wilson wrote:

Hi everyone,

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:

  1. 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?

I’m no guru, but I’m supporting three different installations of RT3 in
totally disparate environments. There’s no doubt in my mind that the
"less is more" approach provides the most value and flexibility with RT.
One enormous advantage of handling your tech support in one queue is
that techs can help each other, even if they are from different schools.
We all have different strengths, and allowing techs to see other tickets
gives them an opportunity to share their knowledge. In fact, I see that
as one of the principle strengths of RT.

  1. 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?

Well, you seem to be aware of the problem already: Why place an extra
burden on the end user? There’s no question that support issues are best
handled with a single address, like support@example.com, but if your
categorization is efficient, other addresses can be useful. For example,
it makes perfect sense to have a webmaster@example.com address and
corresponding queue to handle issues related to your web site.

  1. How could we use RT groups to better organizer our tickets?

Groups are for administering users, queues are for organizing tickets.
Even if you have only one queue, it makes sense to create a group. You
add users to the group, then assign the group rights, either globally or
for each queue. This is a lot easier than setting up individual user
rights for every queue. I repeat: a LOT easier.

For example, one model I’ve been using is to have an admin group and a
staff group for each queue. The only real difference is that the admin
group has the right to delete tickets. I can easily move members between
groups to alter their rights.

  1. Is it possible to create a queue that only one person could see and work
    on?

Yes, of course. But keep in mind that root sees all. If you can’t trust
the administrator, you should run your own instance of RT.