Tracking Ticket transfers out of your RT queue

Context
Answer

Introduction
1. Creating a new ticket in the destination queue
2. Creating a tracking ticket in your queue
3. Using a custom field to tag tickets with their queue of origin
4. Reporting on receiving queue from the Data Warehouse

See also

Context

Request Tracker (RT) on help.mit.edu
Request Tracker queue administrators

Answer

Introduction

This article discusses keeping track of ticket transfers out of your RT queue. There are many reasons you might want to do this. The two most common are reporting on the number of tickets that began in your queue but were transferred to other queues for resolution, and keeping a handle up on transferred tickets in case the customer contacts you for information rather than the group the ticket was transferred to.

Our Request Tracker instance has several mechanisms to do this. You should choose the one most compatible with your requirements and work processes.

1. Creating a new ticket in the destination queue

This method is ideal for groups that escalate customer issues to operations groups and other behind-the-scenes teams for resolution, but remain the primary point of contact for the customer. Following this method, you create a new ticket in the destination queue that is linked to the original customer ticket, which remains in your queue.

1.1. Benefits

Easy reporting - all customer tickets stay in your queue to report on
You remain the primary point of contact
You control what meta data and processes are attached to the customer ticket

1.2. Limitations

Manual steps needed to create escalation ticket
Escalation ticket will be in your name, not customer's
You need to keep in touch with operations group to make sure ticket is resolved
If the group you're escalating to does not have access to your queue, you need to make sure to include enough information in the escalation ticket so they can work on the problem.

1.3. Quick tip

You can quickly create a linked, cloned ticket from the Display ticket screen by clicking on the (Create) link next to the desired relationship in the Links panel.

2. Creating a tracking ticket in your queue

If you frequently move tickets to other groups' queues, but don't need to stay in the critical path or remain the primary point of contact for the customer, hanging on the customer ticket and creating new escalation tickets in other queues can be a lot of extra work. It is often easier to just move the customer ticket to the appropriate queue.

Our instance of Request Tracker includes a feature to automatically create a "Tracking Ticket" in your queue whenever you move a ticket to a different queue. This feature is enabled for any queue that includes a custom local template called "Create Tracking Ticket". RT's create ticket template allows you to control the status, content, and many other parameters of these tracking tickets via the template. For example, you can create a template to automatically create a resolved ticket with the subject "Tracking ticket linking to ticket transferred to outside group", to later easily report on all the tickets you transferred.

2.1. Benefits

Easy reporting - you can just report on tickets in your queue, but will still get a count of tickets you moved elsewhere
Quick to move tickets - just change the queue of the customer ticket to the desired destination queue
Standard tracking tickets - via your template you can control the content and format of the tracking tickets so they are consistent and easy to report on
No need to worry about permissions for reporting - because you can report on transfers from your own queue, you do not need to have permission on all the queues you transfer to
Automatic linking - tracking tickets can automatically link to the transferred tickets, should you need to pull up the original customer ticket

2.2. Limitations

Tracking tickets will usually not include customer demographic data (although you could create a template that does so)
Any queue move will create a tracking ticket, even if you move a ticket to another one of your own queues (watch out for double-counting)

2.3. Details

For more information setting up tracking ticket functionality for your queue, please see How to create Tracking Tickets for RT tickets transferred out of my queue.

3. Using a custom field to tag tickets with their queue of origin

Custom Fields in RT are flexible and plentiful, and you can create one to tag tickets with their queue of origin. This method might work well for you are already setting several custom fields on your tickets as part of your normal work process, and if you mostly transfer tickets to other queues you have control over, or have permission to report out of.

3.1. Benefits

Flexibility of custom fields - for example if you frequently transfer to several known queues, you can create a popup custom field with those queue names in them to select from
Indicate transfer after it happens or if it didn't happen - because custom fields are manually set, you can set them long after the ticket was actually transferred, or set them for tickets you created in the receiving queue (i.e. they were never actually in your queue)
Reporting out of the destination queue - unlike the other methods, this method will allow the owner of the destination queue to easily report on tickets they received, because their queue will have both the received tickets and their custom fields

3.2. Limitations

Manual steps required - custom fields must be manually set (see exception in note below)
Can be changed - custom fields can be manually changed or unset by others working in the queue
Reporting requires permissions in receiving queues - you will need to be able to see tickets in the receiving queues to report on them
Custom fields must be attached to all receiving queues - custom field visibility is controlled on a per-queue level; to report on this field, it must be attached to each queue that receives tickets from you
Reporting must be done across many queues - because tickets are moved out of your queue into many others, you will have to report across all the receiving queues, rather than just reporting out of your queue

Note: rather than a field which you set to the name of the receiving queue, you could have a simple "origin" field set to your queue name, or indicating that the ticket began in your queue. This field could then be set automatically whenever a ticket is created in your queue. This simplifies the creation and transfer process for you, but it complicates issues for the receiving queue, if the receiving queue is likely to get tickets from a variety of sources. Tickets would need a different custom field for each source queue, and the receiving queue would need to include all custom fields from these queues.

3.3. Details

For more information on creating, managing, and automatically setting custom fields, please see:

4. Reporting on receiving queue from the Data Warehouse

As data is transferred from RT to the Data Warehouse for reporting, the ID of the queue a ticket was created in is added to each ticket record. This means if you are reporting on your tickets out of the Data Warehouse, you do not actually need a custom field indicating where a ticket came from. In other respects, the benefits and limitations of this method are similar to those of the custom field method.

4.1. Benefits

No manual steps required

4.2. Limitations

Reporting must be done out of the Warehouse - reporting out of RT will not include this information
Reporting requires permissions in receiving queues - you will need to be able to see tickets in the receiving queues to report on them
Reporting must be done across many queues - because tickets are moved out of your queue into many others, you will have to report across all the receiving queues, rather than just reporting out of your queue

4.3. Details

The table RT_TICKET includes a field called TKT_ORIGINATING_QUEUE_ID, which maps to a queue ID in the QUEUE_ID field in the RT_QUEUE table. This allows you to report on the queue a ticket originated in, in addition to the queue a ticket is currently in. For more information, see table detail for RT_TICKET and RT_QUEUE. For more information on reporting out of the Data Warehouse please see MIT Data Warehouse.