What NOT To Do With Groups
I'm going to share what NOT to do -- assuming you are a company like ours. I am in the IT department and we have about 15 techs, 10 of which are "front line" Help deskers as we call ourselves.
We answer the phones and field emails for our 5,000+ healthcare professionals (internal employees). Some of us have strengths in various areas but we all are trained to do almost everything.
I made two mistakes with groups:
- I created too many groups.If you are like us, you probably don't need 7 groups for 15 people. It makes assigning tickets to agents more time-consuming than necessary.
This sounds like a small thing but since everyone was in about 5 groups, there was also a lot of overlap in the group membership and it was very confusing. I'd recommend having your agents in a maximum of two groups, and only in one if at all possible. That way, when you type their name to assign a ticket to them, they only show up once in the drop down list. - I created a group that became a bottleneck to expediency.We called it the Triage group and the idea was that all new tickets would automatically (via a trigger) get assigned to this group. And then two agents were supposed to monitor that group (via a view showing only those tickets). They were supposed to be the gatekeepers. They were to assign the tickets out to the other Helpdeskers and also email back to the requesters to get more info if they had forgotten to include something that was necessary for us to solve their issue.
问题是这两个守门了公共汽车y and became a bottleneck so that I had to allow access to the Triage group to everyone and then it became meaningless. In fact, the problem got compounded because I had set up a trigger that would re-open any ticket that was solved in the Triage group because I thought I would be running reports on groups and Triage was not what I considered a "real" group.
I suppose if you have a larger organization and can devote 2 people to the task of triaging your tickets and passing them on to the other agents this might work but for us it was a major failure.
The interesting thing is that our agents got used to this inefficiency and have made our Zendesk work in spite of my ill-conceived plan. Anyway, I just spent 2 hours fixing all of this - triggers and groups and views and automations. What a nightmare. I hope my pain and experience will save you some of the same.
I'll let you know if our new system works better. Fingers and toes crossed.
-
Thanks for sharing this Justin. We have 23 agents (only half of which are particularly active), we have 3 groups, and are just in the throes of adding another.
I can confirm that a maximum of 2 groups per user is best. I now have one user in three groups.
Groups are great for splitting tickets into clear groups; we have groups related to our business divisions; IT, Telcom and Frontline Support
We are fortunate that our helpdesk grew slowly, we started with only one group, then expanded to two, then three.
-
Thanks for the awesome insight, Justin!
-
thanx :)
-
Hey Justin,
Did the new system work better for you in the end? I'm conscious of having too many groups and bottleneck situations so any tips would be great :)
Thanks,
Sam
-
Yes. The new system worked much better. We went down to 1 helpdesk group and that provided some much-appreciated sanity.
I'll also say that my statement about needing a triage person when we got larger was also true. We have, in fact doubled in size as a department and as a company since 2013 when I wrote this post. As such, we now have 3 groups with 4 to 15 members each now. That setups seems to work pretty well for us.
Best of luck to you, Samantha!
-
That's great! Thanks for the update, Justin!
-
Justin, your post has made me go look at my Groups as I have 13. Was that too many? After review, it is not the number that matters but those rules that you gave (no-one in more than 2 groups etc) that are the key. I have five different departments using the same Zendesk instance and although I have decided that 13 real groups is the correct number (I actually have a few more that I hide with the Assignment control app that govern things like multiple groups being able to use one view etc), your guidance helped me to confirm that things are good.
Thanks
-
Thanks for the update Justin.
We're in the process of adopting Zendesk fully throughout our company, so we're looking at around 19 groups over 8 departments. One of our departments needs many groups (11), as the variety of work within needs definition by groups and we use custom SLA policies. Agents tend to only be in 1 or 2 groups each, unless they need to manage the workflow of more - so it sounds like that seems to be a good practice.
Thanks,
Sam
Post is closed for comments.
8 Comments