Fine Tuning: How to build your ideal workflow (Part 1)

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.

Questions to ask yourself:

Can your agents accomplish what they need to in their current roles?

How many different roles do you have in your Zendesk?

Are any roles unnecessary?

Are there any roles you could add or modify to improve your workflow?

Using custom roles

To view and manage custom agent roles

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

For more information about creating and managing custom roles, see Creating custom roles.

Part 2: Organizations, organization fields and user fields

Organizations

Organizations allow you to group your end users (also called customers). You can use them to:

Group users from the same company or department.

Add important information to tickets for routing or reporting.

Report on which end users are creating the most tickets.

Potential pitfalls:

Each ticket can only belong to one organization. You may have users that belong to multiple organizations, but each user’s tickets will be automatically assigned to their default organization. This means that you will need to make sure to assign everyone’s default organization in their user profiles.

Organization tags are only added to tickets when the ticket is created. If you change the associated organization on the ticket after it has been created, the organization tags isn't passed on to the ticket.

If you are using Zendesk for HR issue tracking, make sure that your organizations do not allow users within the organization to see each other’s tickets. If you overlook this single setting, you could face a scenario where your employees could read each other’s potentially sensitive communications with HR.

Best practices:

You can use organizations to tie your customers’ tickets together automatically based on email domain. This especially helps for B2B use cases. You can add a domain (or multiple domains) to an organization, and it will automatically add users (and tickets) with email addresses containing those domains. This will keep you from having to continually maintain your users in each organization.

Organization tags will be added to all tickets created by users within the organization. This is a great way to tie in business rules, especially for email tickets. Simply adding tags like “vip” or “product_x” will allow you to set priority, route tickets to specific groups or agents, or set specific SLA policies.

You can sync your organizations with your CRM to keep them up to date. Check out a list of apps available in the Zendesk Marketplace.

Questions to ask yourself:

Are you syncing user or organization information from an external CRM?

Should you be?

Do you want to enable your users to belong to multiple organizations?

If so, which organizations should be default for your users?

What tags should you add (if any) to your organizations?

What do your organizations represent - companies, departments, classifications, etc...?

Using organizations

To add and manage organizations

In Support, click the Organizations icon () in the sidebar.

For more information about creating and managing organizations, see About the Organizations page.

User fields and organization fields

User fields are used in user profiles. They can influence business rules and communicate important information to tickets that are requested by the user.

Organization fields live in organization profiles. They communicate information to tickets that are requested by users in the organization.

You can create the following types of custom fields:

Drop-down list

Text

Multi-line text

Numeric

Decimal

Checkbox

Regular expression

Date

Both drop-down lists and checkbox fields can add information to tickets requested by the user. Each of these field types will add a tag to the user or organization, which will then be added to any ticket created by the user.

Potential pitfalls:

Too many user fields can create unnecessary noise when looking at a user profile.

Be aware that organization tags are not passed down to user profiles. This is a common assumption among new Zendesk admins.

User and organization tags are only passed on to tickets at ticket creation. If you change the ticket organization or requester after the ticket has been created, the new user and org tags will not be added to the ticket. This could potentially keep some tag-based workflows from taking effect.

Best practices:

Use drop-down and checkbox fields whenever possible. This allows you to get consistent information on each user or organization, and will allow you to pass information through tags to tickets created by the user. These are also easier for your agents to update, and will give you more options for reporting (For example: Tickets Created by Demographic/Industry, Ticket Satisfaction of VIP Customers, etc…)

In addition to reporting, there is real value in using user or organization fields for ticket routing or prioritization. You can configure your Zendesk to route specific categories of customers to specific groups of agents, or set priority based on service level, plan, or disposition.

It helps to limit the information in user profiles to only functional information. If you are syncing with a CRM, it should only be passing information that is necessary to solve, route, or prioritize tickets in Zendesk. If you just need to reference information, it may be easier to utilize a ticket sidebar app that integrates with your CRM.

You can find dozens of pre-built CRM and e-commerce integration apps available in the Zendesk Marketplace.

Questions to ask yourself:

Are you syncing user or organization information from an external CRM?

Should you be?

What information needs to be stored in Zendesk (agents, end users, organizations)?

What information would you like to pass onto the user’s or organization’s requested tickets?

What information is important to know when routing or prioritizing a user’s tickets?

Using custom user and organization fields

To create and manage user fields

In Admin Center, click People in the sidebar, then select Configuration > User fields.

To create and manage organization fields

In Admin Center, click People in the sidebar, then select Configuration > Organization fields.

For more information, see Adding custom fields to users and Adding custom fields to organizations.

Part 3: Ticket fields and ticket forms

Ticket fields

Ticket fields live in the ticket sidebar and allow you to store information, route, and prioritize each ticket. They are a key component of your Zendesk experience.

You can create the following types of ticket fields:

Drop-down list

Text

Multi-line text

Numeric

Decimal

Checkbox

Regular expression

Date

Credit card number

Potential pitfalls:

Using text fields can be tricky if you plan on using the information for anything other than for helping the agent understand the problem. Text fields are unreliable for reporting or for enacting actions via business rules because users will inevitably use different phrasing to mean the same thing. Multi-line text fields aren't available at all in reports.

Custom date fields are a great way to build in due dates and fire automations, but be aware that you can't sort your views by a custom date field.

If a field is marked as required by the end user, Zendesk will prevent a user from submitting a ticket until the field is set. This is still true for fields that may be hidden by custom code in your Help Center or through the Conditional Fields app.

Best practices:

Ticket fields can have different names for team members and end users. This means that you can use the field names as questions for your end users, which may help gather the information you need without confusion. This is especially helpful if you have shorthand internal names for your ticket fields (the ticket sidebar does have somewhat limited space).

For example, if you want to record your end user’s troubleshooting steps when submitting an IT ticket, you can name your field Troubleshooting steps internally and What troubleshooting steps have you taken? on the ticket form for the end user.

It is almost always best to use drop-down fields when possible. Drop-downs allow you to have nice clean reporting, apply simple business rules effectively, and simplify the experience for your agents and end users. Drop-downs can also be used in place of checkboxes if you want to require that your agents acknowledge a question with a yes or a no because setting a checkbox field as required means users are forced to check it.

Take advantage of nested drop-down fields. This will allow you to add multiple levels to one field in order to simplify the user experience.

In order to use ticket fields effectively, you will want to make sure that you are using ticket fields only for the following purposes:

Routing the ticket to a specific group or team member

Performing various custom actions on the ticket via triggers or automations

Applying SLA policies

Helping a team member identify the problem and solve the ticket more quickly

Categorizing your tickets for views or reports

Questions to ask yourself:

What do I need to know in order to route my tickets?

What do I need to know in order to solve my tickets?

What do I need to know in order to report on my tickets?

Which fields need to be visible to end users and which need to be internal-only?

Which fields should be required for end users to submit tickets?

Which fields should be required before an agent solves tickets?

Using ticket fields

To create and manage ticket fields

In Admin Center, click Objects and rules in the sidebar, then select Tickets > Fields.

For more information, see About custom ticket fields and Adding custom fields to your tickets and support request form.

Ticket forms

Ticket forms live in your ticket sidebar, and allow you to display ticket fields. You can use multiple forms to gather only the relevant information from your agents and end users.

All Zendesk accounts use a default ticket form. Some accounts have the option to create additional custom ticket forms.

Potential pitfalls:

The more end user visible ticket fields you have in your form, the greater the barrier to entry for your end users to submit tickets.

Longer ticket forms may also negatively impact agent productivity, especially if you have required fields near the bottom.

Having too many forms to choose from may also lead to confusion for your end users or agents.

Best practices:

Make sure that you are only asking your end users for information that is relevant to the ticket.

Pay close attention to the order of your fields. If you have fields specifically for reporting purposes, it may be best to put them at the bottom of the form. Place information that is important for the agent to see near the top of the form, so they will not need to scroll down in the sidebar.

(Multiple ticket forms) The ticket will retain the information in every ticket field, regardless of the current selected ticket form. This means that if you have fields that are important for system use (reports, routing, views, etc…) that are not set by or important to your team members, then you can create a separate (internal) form for these fields or leave them off of all forms entirely. This will keep your Zendesk UI as clean as possible. The information in the fields will still be available for reporting and business rules.

(Multiple ticket forms) Just like custom ticket fields, you can give custom ticket forms different names for your end users and your team members. This allows your end users to select the type of request they are submitting in a way that is meaningful to them, while allowing you to keep the official form name internally.

Questions to ask yourself:

Do I need multiple ticket forms or just one?

Am I asking for the right information from my end users?

Does the flow of my ticket form(s) feel natural? If not, what is out of place?

(Multiple ticket forms) Are my forms named clearly for my end users?

(Multiple ticket forms) Are my forms named clearly for my team members?

Using ticket forms

To create and manage ticket forms

In Admin Center, click Objects and rules in the sidebar, then select Tickets > Forms.

For more information, see Understanding and optimizing ticket forms and Creating multiple ticket forms.