A ticket's life through multiple queues

RT Users
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,
I have a little “philosophical” doubt about RT, so to say.

In my institutions, we have several groups, most of which have their own
queue set. They mostly work on their queues, but occasionally need to
transfer the ticket under another queue. In some cases, a ticket need to
pass through 3-4 queues.

My questions…

Is this a common scenario?
How do other institutions deal with this kind of issues?
For statistical purposes, do you assign the ticket to a given queue
before closing it?

Thanks,
Giuseppe

Giuseppe Sollazzo
Senior Systems Analyst
Computing Services
Information Services
St. George’s, University Of London
Cranmer Terrace
London SW17 0RE

Email: gsollazz@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQWHROAAoJEAqigArPBfJXGfIH/0DjKotSQbypQhnzK7coywO5
prQqoU5HRXtyWckCjDEfFlCYCX6ieb4JsWw5Fzrgr8Gy6wNBUwkeF0+tCr8JOGpt
rW5/kZ+ui8/fREnTnBRHhWRlwoiSj+NEkd4KkD9QlVYIfK0YonBIuy+35Mz7b1Rk
V+koWBG4PQOhULUA8TGasp2YiRmYmTilnke3/Ji+kL0fk3giI88Sll3eq0pHkEYL
vKXzylFlKCWR74vCqt61fPW0E9cfpL8nXzL37j54Co7uogcDYiTTiY79xhehEMmb
lV6xaznU/gL8TqnhbBweMD3b4Y10P7XFU9sDYaF9SaqFp35kWU7h6kJQoVf0XLM=
=qujX
-----END PGP SIGNATURE-----

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,
I have a little “philosophical” doubt about RT, so to say.

In my institutions, we have several groups, most of which have their own
queue set. They mostly work on their queues, but occasionally need to
transfer the ticket under another queue. In some cases, a ticket need to
pass through 3-4 queues.

My questions…

Is this a common scenario?

Yes.

How do other institutions deal with this kind of issues?

With difficulty, I think. :slight_smile:

For statistical purposes, do you assign the ticket to a given queue
before closing it?

As you’ve noticed, passing tickets between queues makes it very difficult to measure how much time was spent by each person on the ticket, making your performance metrics pretty meaningless.

I think the orthodox argument goes like this:

If the task actually requires multiple people to work on it, then it isn’t a single task. It’s multiple tasks.

So, you spawn dependent tickets of the current ticket in the appropriate queues, each containing one of the sub-tasks, and only resolve the parent ticket when those are completed. This is a bit more work, but it makes your results measurable. If you want to measure how fast the end user got their request resolved, than you compile stats based on the parent tickets, but you now have individual tickets in other queues which you can perform stats on to identify how well those queues are working. You also can now have different owners for the different aspects of the work, so you have a better view of who’s responsible for what.

Ruslan’s SpawnLinkedTicketInQueue extension can be useful for this:

and if the sub-units of work are predictable, you can even generate the sub-tickets with Scrips, in theory, although I’ve never gone that far.

Regards,

Tim

The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

3

Hi,

I once worked at a managed helpdesk company as a support agent. At the time we used an in house solution, but it was very similar to rt in it’s queue, owner, requestor setup (the only difference being that there could only be one requestor in this solution, but that doesn’t really pertain here). The way we did it was that we would have the ticket from a user in the helpdesk queue, do our bit of work on it, and if we needed work from another department done we would create a child ticket in, say, the Sydney systems queue, which they would resolve once finished with (or pass ownership of back to the agent requesting extra details, who would pass it back with the details, etc etc). In out setup the owner of a ticket is emailed when a child ticket is solved, I’m sure this could be done in rt with scrips. Once they see the child ticket resolved they contact the user and resolve the original ticket. That way you have stats on what work everyone has done, as well as less worry about which queue to resolve in.

Hope this helps

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,
I have a little “philosophical” doubt about RT, so to say.

In my institutions, we have several groups, most of which have their own
queue set. They mostly work on their queues, but occasionally need to
transfer the ticket under another queue. In some cases, a ticket need to
pass through 3-4 queues.

My questions…

Is this a common scenario?
How do other institutions deal with this kind of issues?
For statistical purposes, do you assign the ticket to a given queue
before closing it?

Thanks,
Giuseppe

Regards

Chris O’Kelly
Web Administrator

Minecorp Australia
P: 07 3723 1000
M: 0450 586 190

Minecorp Australia
37 Murdoch Circuit
Acacia Ridge QLD 4110
www.minecorp.com.au