New agent onboarding/Groups set up

Hi Sonja! Happy to share a few suggestions.

It may be helpful to create a ticket view for tickets your new agents can use for training. To separate these tickets from the ones other agents are handling, you can add your new agents to a dedicated group and use a macro to tag training tickets and assign them to the new agent group. Limiting the visibility of the ticket view to users in this group will ensure only these agents are working out of this view.

As agents complete training, they can be removed from the new agent group. This workflow requires a little time from an admin to set up and some user management to maintain over time, but I hope this gives you a good place to start. Let me know if you have any questions!

In addition to what Holly posted, you will want to look into what the settings for your existing views are, and that "any agent" isn't set up on views you do not want Training agents to see. You will probably want to make all your views have group requirements, so that trained agents aren't having to deal with the Training view cluttering up their precious 12 view limit, and Training agents don't accidentally get access to something that left open to view to "any agent". 

One easy safety feature you can do for yourself as well, is to make this Training group, the default group that new agents are assigned to. This will ensure that when you add new agents, you do not need to worry about immediately going in and changing the groups to keep them out of views they aren't supposed to have. Then, grant the Training group access to the set of views that you want them to see, which should be configured for those specific kinds of queries you want them to work. This can be based off the form, tags, etc. 

Offboarding from a training group has been the hardest part of this for me. This is actually a lot trickier than you'd think. If you do decide to make a group specifically for training folks, know that when you remove a member from a group, any tickets assigned to them in a status less than Closed, including Solved, with that group, will be re-assigned to the agent/admin in the group who has been in the group the longest (I think, it might just be member with the oldest UID?). Either way, offboarding agents from a group is extremely delicate and will totally bust up your performance numbers if you aren't careful. 

If you have required fields on forms, and automations that solve pending tickets that may not have all required fields filled out, which many folks do out of the box (typically solve a pending ticket after 7 or 14 days), you will not be able to just select all tickets and say, reassign them from Training/CJ Johnson to Tier 1/CJ Johnson, because the ticket state will conflict and throw a bunch of errors about you trying to set a ticket to solved when required fields are missing. And if you take the Training group away from CJ while they have tickets assigned to that group, those tickets will just seemingly suddenly disappear from their profile (and reappear on the oldest team member of Training's list, including solved). 

To get around this, when I offboard an agent from a group, I have a trigger set up that changes a solved ticket to closed if a tag (offboard_agent) is present. This allows the ticket to stay with the agent, and keep the solved date and group it had for reporting. If the customer follows up, it will create a new ticket, which because of our setup will auto-feed to the right views and get worked by a new agent for that team. This was clean enough of a solution for me, but it's still rather messy.

To use the trigger I set up, manually select an agent's solved tickets and apply the tag, or, if I'm offboarding a lot of people, I can even set up an automation to run overnight to apply the tag to solved tickets for that set of assignees. Then, I can use the API to update their groups en masse, without having to worry about the solved numbers for teams going wonky. 

You may also need to set up a re-assigning view, if you anticipate the agents in this group may be working tickets that are incomplete when their training is done. This can be done via an automation, to tag all tickets with a status less than solved with something like "needs_reassign", and then a special view for leads or managers, based off that tag. Alternatively, if you want them to keep working the tickets even after they have left the training group, you can set that automation up to be "if assignee group is Training, ticket is less than solved, and Assignee is Name A, then set ticket group to Tier 1, and assignee to Name A". This is however, pretty time consuming and requires an automation per agent.