White dot for spacing only
The Dice Project

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.

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

 : Units : User_support 

Mini Informatics Logo - Link to Main Informatics Page
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh
Spacing Line