I have brought this up in numerous discussions, but we struggle with this too.

Our situation is a little more complex, because we have a lot of overlap and have people in multiple teams.

I posted this idea to limit who a ticket can be assigned to based on the assigned team, with the caveat being that you are required to assign it to a team first.

This area desperately needs attention IMO - it throws our metrics off without being able to control it. Some groups do a great job of it, others don’t care and just assign or resolve without paying attention to the team at all.

I think you could do a ‘When Assigned’ rule that would accomplish this. Set it to fire when the ticket is assigned to Jane, the action performed is to assign it to Team B. 

For example:

 

@NStevens_iiQ that’s ok for small districts where team membership is simple, but wouldn’t always work for larger districts.

For example, members of our helpdesk are also SME’s in certain area. A ticket for a VOIP issue would route to a “Phone” team, which consists of a member of the helpdesk (we’ll call them John) and a couple of people from the network admin team.

I can’t set a rule for when a ticket is assigned to “John” to always assign to team “Helpdesk” because of that.

We have over 100 employees in IT alone, most of which exist in multiple teams because of overlapping work. The number of rules we’d have to create to account for all of them in order to accomplish this would be impossible to manage.

That’s the main reason for the idea I linked above. A site option to A: require team assignment first, and if that’s enabled, then B: limit agent list to members of the assigned team.

Hi @jclark !

Thank you for the additional information, I completely agree the suggestion above would work well for a small team, but does not scale well. In your example, you could put an issue filter for the VOIP issue, so that when the issue is for VOIP and the agent is John, it would change it to the Phone team. But, as you said, it would be challenging to manage if you had many overlapping teams. The district I came from had about 300 IT people between the central office and schools and had similar complexities, we had literally hundreds of created, updated, and assigned rules that while complex did work for complex routing. We did write our rules to route exclusively to teams rather than individuals so that we just needed to keep the teams up-to-date with the correct agents rather than having to update the rules. 

Thanks,

Nick

@NStevens_iiQ glad you understand the struggle! lol. We actually have over 800 agents between IT, Facilities, and school technology coordinators. It can become cumbersome.

We have other departments using iiQ for tickets as well.

We already have rules in place to route to teams based on issue/category on creation, but to account for every scenario via various rules isn’t feasible, we’d have to correct countless rules every time we add new issues/categories, when we have employee turnover, etc… when the problem could be fixed with a couple of site-wide controls as I mentioned - I’m not suggesting that’s an easy implementation, but it’s a huge need.