There are a couple of business rules that you'll need to take into consideration first. I don't know that you need to reply to this with the answers, but I wanted to toss these out there for guidance.

 

1. If a ticket is transferred to an agent, should the originator of the transfer really get the ticket back? Obviously there was a reason the ticket was transferred - maybe it wasn't the original agent's specialty, maybe they were going on holiday, etc.

2. If an agent transfers a ticket due to them being on holiday, it probably isn't a good idea to have the ticket sent back to them.

3. Depending on your ticket distribution model, it may be a better idea to transfer the ticket to the queue so another agent can then cherry pick it or even have the ticket re-distributed via round robin.

4. If a ticket doesn't get a response in X number of hours/days, it should probably be escalated so that a response can get sent out quickly.

 

Now, there are probably a number of other considerations as well, but those are just some things off the to of my head.

 

Regarding the event you have laid out, however, there's no way to set a ticket to be transferred back to the agent who originally transferred it in the first place - there's no action event that keeps that agent information so that it can be recalled later. So, what you'd have to do is either manually specify the agent to receive the ticket OR transfer the ticket back to the queue - or even transfer it to another group, like an escalation group. In fact, that's what I would recommend.

 

As for the event set up, here's what you'd want to do (this is taken from our own ticket idle events for tickets that are awaiting responses):

 

Idle Minutes - This condition is in minutes to increase the granularity of the ticket event. So, if you wanted a ticket that's been sitting for 24 hours to initiate the event action, you'd set this to 1440.

Group - if you want set different conditions for different groups, you'd specify that here. If you do not check the box next to this condition, then the event fires for all groups.

Status - Obviously, if a ticket is active and idle, that's when you'd want the event to fire. So this is checked and the status set to Active.

 

Since you want the ticket that meets the conditions to be transferred, the actual action you set is Transfer Ticket

Maximum Frequency - this is how often the event fires when the conditions are met. If you set this to 5 minutes, the even will fire every 5 minutes for every situation where the conditions are met. Ideally, I'd set this to 24 hours.

Group and Agent - here you select whatever group, and then whichever agent you want the ticket transferred to.

 

Regarding Group and Agent, if the ticket is escalated, you can certainly specify exact agents to get the ticket when the idle event fires. If you want the ticket to simple get re-distributed, then you'd want to select Queue as the agent so that the ticket goes to the group but is then either cherry picked or distributed via round robin, based on the distribution method you have set for the group.

 

I hope this helps. Idle events are a good idea, but they can also be a bit abused. We recommend AT MOST 6 idle events as they can tax the system, especially in cases where the maximum frequency is set below 24 hours as the system has to cycle through each ticket to check whether conditions are met.