|
|
|
RT Best Practice
Frontline Support Team / Support Queue
1.The support queue should be checked regularly for new tickets, the aim being that all new tickets will be looked at within 1
working day and requestors receive some form of response within 2 working days. (Even if it's just to say "sorry, we haven't
had time to look at this yet". You can send such responses to dozens of tickets pretty quickly using the Update all these
tickets at once link on the Search page)
2.Try to resolve problems yourself where possible, and respond to the requestor. The resolved ticket should then be put in
the correct team's queue where there is one. (Putting a ticket in the team queue, even if you've already dealt with and
resolved the ticket, makes the team members aware that the problem exists and has been resolved. This way they'll get to know
if one of their bits of software is being particularly troublesome and is attracting a lot of complaints, for instance.)
3.Get good information. Keep asking questions (of the user) until you get real information instead of vagueness! For example,
if there's trouble with a file, what's the file called? Where is it exactly? If the trouble is on a particular machine, what
is its name? Is it a DICE machine? The person's own laptop? If a software error is being reported, what was the exact error
message? Ask them to paste the entire message into a message to you. And so on. It may also be helpful to search RT for a
possible solution. (This is one of the most important parts of your job, a key task of the frontline support team: if there's
a ticket you can't solve yourself, please gather as much information as you can about the ticket before passing it on to anyone else.)
4.If you can't answer the request, transfer the ticket into the appropriate queue. By doing this, an automatic message is sent
to the team members and the requestor. Change the owner back to Nobody and set the status to 'new'. This should happen within 2
working days of the ticket being received in the support queue.
Everyone / All Queues
5.Take ownership. When you're dealing with a ticket, take ownership of it. This tells everyone else that you're dealing with
the ticket, so they don't have to. Take ownership by clicking Take.
6.Categorise. Classifying the ticket properly will really help people to find your ticket in future. Click The Basics, set Status
to open and choose appropriate values for Category, Site, Domain and Message Type. This should take no longer than a minute
to complete.
7.Check for new tickets. Each team leader is responsible for ensuring that their queue(s) are checked for new tickets and an
owner allocated. All tickets should be allocated an owner within 2 working days.
8.Check for new tickets. A weekly report should be circulated by the RT team indicating all unresolved tickets without owners
that are older than 2 working days. It will be distributed to the team leader, group leader and optionally the team members.
9.Be nice to ticket owners. Tickets should not be 'stolen' without the owner knowing except in certain circumstances
e.g. sick leave.
10.Be nice to ticket owners. If allocated an owner, tickets should not be moved to another queue except by the owner.
11.Be nice to ticket owners. If you have any advice, send a comment to the owner.
12.Avoid embarrassment. Be careful what you say! You should always assume that what you write is public. Things that started
as comments can be quoted and appear later in replies visible to the requestor.
13.Avoid super-long messages. When replying, be selective on the text that you include from previous context. Only include
parts that are relevant to your response. Be as brief but informative as you can.
14.Use a signature. Make sure that you identify yourself when you are responding to a ticket. You can add a signature using
the Preferences option.
15.Be careful when merging tickets. We will shortly be introducing the ability for users to view their own tickets. Be cautious,
therefore, when merging tickets as each requestor of a merged ticket will be able to see what the other requestors have written.
In some circumstances it will be perfectly reasonable to merge tickets e.g. 10 requestors have reported "Printer x needs toner".
16.Cross-team tickets. Sometimes a user query or fault report can not be handled entirely by a single team. The policy and
procedure below addresses this situation.
Policy
The handling of a query or fault report from a user should be handled by the
teams that need to be involved concurrently rather than sequentially wherever
possible and practical.
Procedure
At any point in the handling of an RT ticket, if the owner of the ticket
identifies that another team from the one in which the ticket is queued needs
to also participate in the handling of the request or fault report then a new
ticket should be created (e.g. by using the 'New ticket in' button with the
appropriate team selected) that:
* has the requestor(s) set to the requestor(s) of the original ticket;
* is assigned to the queue of the other team that needs to be involved;
* has its status set to 'new';
* has its subject set to that of the original ticket (optionally with
the new team name as a suffix);
* has an adequate description of the original request/query/fault
report (including the original request date and time) that is
relevant to the new team's involvement;
* is a child ticket of the original ticket (the original ticket being
the parent ticket).
How to deal with tickets that have been flagged by the requestor as URGENT.
1. Wherever possible, the support team will attempt to solve
any URGENT tickets. They will, in the first instance, be treated
as taking priority over tickets not marked as urgent (see point 2).
If after assessment, they turn out not to be urgent they should then be
dealt with,in order, along with the non-urgent tickets.
2. The support team will make an initial assessment of the urgency and complexity
of the ticket and decide whether additional advice is required.
If an URGENT ticket cannot be resolved easily and quickly, or the urgency
is unclear, then the Duty CO and the support team leader must decide whether
or not the problem is really urgent.
3. If a ticket doesn't warrant being marked as URGENT, then the Requestor must
be contacted immediately and given a reason as to why the URGENT
status has been removed. At this point, the requestor may provide
additional information which results in the URGENT status being
re-instated. If the URGENT status is to be removed, then the word URGENT
should be removed from the ticket subject line.
4. If the ticket must be passed on to another queue, then the ownership/
responsibility remains with the support team until there has been a
confirmed handover, either by mail or phone. It is not sufficient to
make the queue change.
5. In certain circumstances, e.g. when a vital service has failed (mail, network,
file services) then the leader of the team who is going to be dealing with
the problem should be contacted by phone. If they are not around, then the
Duty CO should be contacted. If they are not available, then the team members
should be contacted. If this is unsuccessful, then the group leader needs
to be informed.
6. If there is any doubt as to the urgency of a ticket, then the support team
should seek advice from the most appropriate person.
In addition, there will be 3 automatically generated nag scrips:
1. A weekly reminder to all individuals of all their 'open'/'stalled' tickets.
2. A twice daily reminder to all teams showing 'new', 'nobody' tickets.
3. An hourly reminder to all teams showing 'new', 'nobody', 'URGENT' tickets.
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|
