Fine Tuning: How to piece together your ideal Zendesk

This Fine Tuning session is about how to build out your Zendesk instance piece by piece, including:

Groups and roles
User fields and organization fields
Ticket fields and ticket forms

Launch Manager Don Newton has been with Zendesk since October of 2014, and has over fourteen years of experience in customer support, software training, and implementation.

Also, be sure to check out Part 2 of this Fine Tuning where Don shares best practices and valuable workflow advice.

To find more Fine Tuning articles, see Fine tuning resources.

Part 1: Groups and roles

What was your favorite toy as a child? Was it something that kept you active? Did it help you pretend you were someone else? Did it allow you to be creative?

I grew up in a world full of action figures, footballs, squirt guns, and even video games, but my favorite toys were always LEGOs. Nothing else could match the creativity and control that LEGOs offered. Give me enough time (and enough pieces), and I can build ANYTHING.

In the ‘80s and ‘90s, it was every kid’s dream to grow up and get a job designing complicated things with simple Danish building blocks. Today I can safely say that I’ve made it - and so have you!

Building your Zendesk is a lot like building with LEGOs. Like those wonderful plastic building blocks, Zendesk is modular, and each component is made to work in harmony with the others. Together, you can use them to create the strongest spaceship (or ticketing system) that you can imagine.

In this Fine Tuning, we will be walking through each brick in your Zendesk, and discussing potential pitfalls, best practices, and questions to ask yourself when building your instance.

Watch out for stray pieces!

Groups

Groups help you organize your team members. There are a few ways to utilize groups in Zendesk:

Assign tickets to a specific group of team members (usually agents).
Create views for a specific group of team members.
Create macros for a specific group of team members.
Send notifications to a specific group of team members (agents or admins).
Report on performance within a group of team members.

Potential Pitfalls:

Groups should not necessarily be a complete reflection of your organization’s structure. Many administrators want to create parent groups for their teams, but this can add confusion when re-assigning tickets, and tickets may be lost or delayed as a result.

Tickets that are assigned to parent groups may not show up in the proper agent views.

Best Practices:

Try to ensure that every group in your Zendesk has an explicit purpose. Your goal should be to use as few groups as possible in order to keep everything simple for your team.

Many companies create a handful of groups for the purpose of assigning tickets. Those same groups could have dedicated views, macros, and notifications. This is the most straightforward way to use groups.

Questions to ask yourself:

Do you have groups that might be unnecessary?

Do you have groups that are empty?
Do you have groups that are duplicates of other groups?
Can you identify a specific purpose for every group you've defined?

What groups (if any) can you create to add value?

Using groups

To view or edit groups

In Admin Center, click People in the sidebar, then select Team > Groups.

For more information about creating and managing groups, see About the Groups page.

Roles

Roles define the permissions of your agents. Each user can only have one role. Creating custom user roles allows you to set your agents’ permission and access. For example, you can permit or prevent agents from:

All tickets, or just the tickets assigned to them or their groups.
Comment publicly on a ticket.
Update ticket fields or tags.
Merge or delete tickets.
Edit end-user profiles.
View and build reports.
Manage your Help Center.
Manage business rules.
Manage macros and views.
Manage channels and extensions.

Potential pitfalls:

If you have sensitive information in your tickets, it may be important to limit which tickets individual agents have access to. The first permission in every role determines which tickets users in the role can see. If you allow your agents to see all tickets, you are giving them the ability to see any ticket in your instance - even if it does not appear in any of their views.

If you limit your agents to only tickets within their groups, they will not be able to see complete ticket histories of users or organizations, and will not be able to search for any tickets outside of their groups. This can potentially limit an agent’s ability to research a previous or ongoing issue with one of their customers.

If possible, avoid creating roles for individual users. It can become difficult to manage a large number of roles as you grow your team. Remember that roles are just permission sets, and should not be confused with groups - which can determine views, macros, and ticket assignments.

We all know the risks of having too many cooks in the kitchen. The same concept applies to the administration of your Zendesk. Having a large number of users with Admin permissions can lead to inconsistencies in naming conventions for views, macros, triggers, automations, etc., and in turn can lead to inconsistent business rule configuration and workflow.

If you have specific shared views that you want your agents to work from, giving them permission to create their own personal views may allow them to circumvent your workflows if they chose to work from their personal views instead. Their views may be showing different tickets, or sorting them in different ways. The same is true for shared and personal macros.

Best practices:

Determine which of your agents should have access to all tickets. You cannot set Zendesk to give an agent access to all tickets except x tickets. You can set Zendesk to show them only x tickets. This can be done by allowing these agents to see only tickets within their groups, and then adding them to the applicable groups. In this case, x is determined by the collective tickets assigned to the agent’s groups.

Try to create as few roles as possible. Creating a handful of general roles is a much more scalable solution, as it is easier to maintain as you grow and evolve.

Limit the number of users with Admin permissions. The general recommendation is that you have no more than 4-5 Admins. This will ensure that no one will accidentally (or intentionally) make changes that can be far-reaching and detrimental to your success. This includes changes to channels, business rules, roles, schedules, or anything else that can impact your workflow.