How many groups is too many

Groups multiply quietly and nobody ever removes one. Three questions tell you whether yours have gone past useful, and merging is an afternoon's work.

Groups multiply quietly and nobody ever removes one. Three questions tell you whether yours have gone past useful, and merging is an afternoon's work.

Question one: does anybody work it?

Look at each group's ticket volume for the last quarter. A group receiving a handful of tickets a year is not a queue; it is a place work goes to wait.

Those are the clearest candidates for merging.

Question two: is it covered?

A group with two members and no cover arrangement stops when one is away. If you cannot name who works it in August, it is too small to exist on its own.

Question three: does the handling differ?

Two groups doing the same work with the same skills, split because they report to different managers, add routing complexity for nothing.

Group by the work, not the org chart.

What too many costs

• Routing gets complicated, and complicated routing misroutes.
• Tickets get lost in queues nobody watches.
• Reporting fragments into groups too small to be meaningful.
• Agents hesitate when reassigning, because the right destination is not obvious.

A rough guide

Most support operations run well on somewhere between three and ten groups. Beyond that, check whether the extras are real distinctions or historical ones.

Merging is straightforward

Move the members, update the routing, keep the old group briefly to catch stragglers, then remove it. An afternoon, and the routing gets simpler.

One thing will stop you at the last step: a group cannot be deleted while it is the default group for the account or for any team member. Change those defaults first, or the removal fails and you are left holding the group you meant to retire.

See also

• What a group is and how to organise them
• How are our queues performing
• Managing groups and memberships