RT Best Practice

Triggers

  • When a ticket is created an automated message goes to the requestor giving them the ticket number and an email is also sent to the appropriate Unit.
  • When the ticket is moved to another queue, the requestor is notified and also the team members associated with the queue.
  • When the ticket owner changes, the existing owner, new owner and requestor are notified. This doesn't happen when the owner is changed to "Nobody in particular".
  • Any correspondence to the ticket will go to the owner (if not sent by the owner), ccs (if ticked), adminccs and requestor. (You can deselect recipients if required).
  • Any comments to the ticket will go to the owner (if not sent by the owner), adminccs as a bcc and anyone else ticked as a cc but NOT the requestor. (You can deselect recipients if required).
  • Should any correspondence be sent to a ticket after it has been resolved, the ticket will be set to 'open'.
  • Optionally, Units can ask for their team to become Watchers on their queue which will result in all correspondence and comments being sent to all team members for all tickets in the queue.
  • If a ticket is deemed to be spam, you should set the status to "spam". The rtx-shredder tool can then be used to remove these tickets.

Note: When a ticket is 'resolved', the requestor is NOT notified by any trigger. They should however be sent some correspondence from the ticket owner to say that the ticket is resolved.

General Guidelines for all tickets

  • Queues must be checked regularly with all new tickets being looked at within 1 working day. Requestors should receive a response within 2 working days at the latest. Some sort of communication with the requestor should be made as soon as possible, e.g I am looking at your ticket and will back to you. A response, of course, doesn't necessarily mean a resolution.

  • Support may perform some initial information gathering without taking ownership of a ticket. However ownership of the ticket should be assigned to the person who intends resolving the ticket as soon as possible. If you don't, any responses from the requestor can get lost as no individual is responsible (unless, of course, your Unit have opted to be watchers on your Unit's tickets). It also avoids other people replying to the ticket and duplicating effort.

  • If you feel that you can contribute to resolving a ticket, add an appropriate comment. You can leave the ticket 'un-owned' as long as you haven't corresponded with the requestor. Please do NOT resolve un-owned tickets.

  • All communication with the requestor should be in the ticket. (Even if they email you directly, if it is relevant to a ticket, ensure that you copy the details in to the ticket.)

  • For tickets that are not routine, add the solution to the ticket rather than just saying “Fixed”.

  • Avoid super-long messages by being careful what you include in replies from previous correspondence. This isn't such a problem with rt4 now that the "Show quoted text" toggle has been introduced.

  • Every ticket should be given a category. This will make searching much easier.

  • If you correspond with a requestor and provide them with a solution, take ownership of the ticket and resolve it. If you don’t, someone from support has to give ownership which results in the requestor receiving an email to say that “person x is now looking at their ticket” which is confusing since they already have the solution. The ticket can remain in the support queue – it doesn’t have to be moved to a Unit queue.

  • Avoid merging tickets into a resolved ticket as the merged ticket remains resolved. Always merge into the ticket that is new/open.

Passing routine tickets to other queues

  • Before passing tickets to other queues, support will gather as much information as possible.

  • Support will only pass a ticket to another queue when they feel that they cannot answer the request or it’s something outwith the US unit remit. Before passing on to another queue, ask the rest of the support team for comment/advice in the us-unit chatroom. We want to avoid passing tickets unnecessarily to other Units. They may, however, cc a Unit with a comment asking for advice. These comments need to be answered as quickly as possible.

  • When passing the ticket to another queue, make the ticket owner “Nobody” and status “new”. It is courteous to add a comment to the ticket with a brief explanation of why it has been passed on.

  • Tickets should not be passed to other individuals unless the other person is in agreement for obvious reasons. Therefore, Units are responsible for checking for new tickets either via RT itself or by checking the nag emails and allocating appropriately.

  • Particular attention should be given to tickets that have had no update for more than 7 days. As a minimum, the requestors should be provided with an update.

Comment or correspond ?

  • Requestors can see all comments and correspondence related to their tickets via the self-service portal. However, there are very few people who use this facility. When a comment is added to a ticket, it is not sent to the requestor nor do they get any notification to say that a comment has been added to their ticket. So, comments should only be used when you wish to add a note to the ticket which the requestor does not need to see e.g. giving a fuller explanation of how the ticket was resolved, asking another team for advice etc. Comments should always be written bearing in mind that the requestor can see the content of the use the self-service portal!

  • Any contact with the requestor should be done using correspondence and not via a comment. All correspondence is sent to the requestor and as an absolute minimum, correspondence should be sent advising the requestor when the ticket has been resolved. If the request is complicated or may take some time, you should also send updates to them via correspondence at regular intervals.

Dealing with URGENT tickets

  • Due to the number of false urgent tickets that we get, these are a judgement call - if you feel it is not urgent feel free to remove that flag and let the requestor know that you have done so. Real urgent tickets should receive a response within 4 hours either with a resolution or as a minimum some indication of when the ticket might be resolved.

  • If an urgent ticket needs to be passed to another queue, support should contact the Unit representative before the ticket is passed to ensure that the unit are in a position to respond to it. If they aren’t available, another member of the Unit should be contacted. If this is not possible, then a CEG member should be approached. It is not sufficient just to make the queue change. The chatroom is also an option for communication.

  • In the case of major service failure (e.g. mail, network), then the appropriate Unit should be contacted by phone or in person.

  • If there is any doubt about the urgency of the ticket, support should seek advice from the Unit.

  • Once it has been passed to another Unit, it is their responsibility to communicate timescales with the requestor.

-- CarolDow - 06 Dec 2019

Topic revision: r13 - 13 Dec 2019 - 10:46:14 - AlisonDownie
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies