Practical Zendesk Administration, 2nd Edition

Chapter 4. User Management

Anyone who interacts with your Zendesk instance, in one way or another, will have a user profile. The extent to which your customers use their user profile will differ greatly. Some customers like to sign into the Zendesk Help Center and customize their profile when they’re getting support from your company. Others prefer to sign in but don’t care to update their name or upload a photo. Other customers may never sign into your Help Center, preferring instead to interact using one of the external channels, such as email, Twitter, Facebook, or Voice.

Regardless of the level of interaction, every person who interacts will have a user profile, and that user profile will be classified as an end user, an agent, or an administrator. Each of these levels is described in this chapter.

All user management is done from the People administration page in Zendesk, with just a few links at the top of the page (shown in Figure 4-1). The section at the top of the page can also be used to search for users and to filter the results shown on the People administration page.

Figure 4-1. User management functions on the People administration page

Administrators

Every new Zendesk instance is created with one administrator user account. The details of that account (name and email address) must be entered by the person who originally set up the Zendesk instance. The first administrator is also called the account owner of the Zendesk instance, and she is the only user who can make changes to the billing details and plan of the instance. If you’d like to change the account owner of your Zendesk instance, you can do so by going to the Invoices tab on the “Account administration” page and selecting another administrator in your Zendesk instance.

To add an administrator in the product, select the “user” link from the People administration page, and then select Administrator as the user type. If you’re on the Enterprise plan, the process will differ slightly (refer to Adding an Agent on the Enterprise Plan).

Limiting the Number of Administrators

Technically, there’s no limit on the number of administrator accounts that you can create in Zendesk, but we advise against using any more than three administrator accounts. We often see IT companies with a team full of people with the technical competence to administer a Zendesk instance. However, although they may be technically competent, it’s difficult for more than three people to communicate effectively with one another on proposed administrative and business process changes—and communication is an important aspect of managing a cohesive administrative design for Zendesk.

Small Zendesk instances might have one or two administrators, and large instances should stick to the three administrator limit. Even if you have a thousand agents, it’s still very difficult for four or five or six administrators to stay synchronized on the administrative design.

Having a smaller number of administrators is also a recommended practice to improve security. Phishing is a social engineering technique used by hackers to gain unauthorized access to your username and password. The smaller the number of users with access to administer your Zendesk instance, the better your chances of preventing one of these attacks.

Agents and Roles

Agents are the people on your team who provide support to your customers. Every agent is a paid account in the system, and every agent will have greater permissions in your Zendesk instance than your customers. Agents are trusted with the privacy and security of your customers, but most importantly, they are trusted with your company’s customer service reputation.

Groups

Groups are a simple way to collect agent accounts together, for a wide range of purposes that will become obvious as examples are given throughout this book. Agents can belong to several groups, and the choice of groups is made when you add an agent. It’s also possible for an administrator to add or remove agents from groups at any time.

Adding a group is very simple. In fact, there are almost no configurable options for adding a group. The reason is that group configurations are spread throughout the product, not the other way around. As an example, visibility of views (covered in more depth ) can be limited to only a specific group. Another example is a trigger (you can find more information about triggers ) that would assign new tickets to a specific group according to relevant criteria. But the most common example is that groups will appear in the Assignee field on the ticket screen as a funnel into a subset of agents to which the ticket should be assigned.

Tip

Zendesk doesn’t support hierarchies of groups, but it’s possible for every agent to belong to more than one group. For example, if you create a group for Level 1 Support and another group for Level 2 Support, you cannot categorize the latter as a subgroup of the former, but it is possible to add an agent to both groups.

To create a new group, open the People administration page, then click the “group” link beside the word “add” in the upper-right corner of the page. The user creation form will ask for the name of the group and allow you to select which agents should be added into the group. Select “Create group” when you’re finished. This will immediately create the group, which is ready to be used in some of the ways just listed.

Defining Groups

Each organization defines its groups differently. Generally speaking, your groups can be informally classified by their use as follows:

Funneling

On the ticket screen, the Assignee field will include both groups and agents. If one of your agents would like to escalate a ticket to a member of your user interface development team but doesn’t know the specific members of that team, she can select the User Interface Development group in the Assignee field. After this group is selected, the Assignee field will drill down to include just the members of that group. The agent then has the option to select the entire group by clicking User Interface Development again, or selecting one of the specific agents in the group. To accommodate this use of groups, as an administrator you should create a group for every team that can feasibly handle tickets in your organization.

Sharing

As described in Views and Macros later, it’s possible to create views and macros, then share them with specific agents, meaning that those agents can access the views and macros directly. The agents with whom the rules are shared will all need to belong to the same group. So if you want to share a view with your entire product team, you should create a group called Development Team so that you can easily share it. Combining this with funneling, you now have a set of at least two groups: User Interface Development and Development Team.

Permissions

If you’d like to restrict access of certain Zendesk features to various team members, you can use groups to achieve this. One example is the Twitter channel (covered ), which allows you to restrict the Twitter feature to authorized users only. Because Twitter is typically a feature that would be used by your marketing team, you might create a Marketing group, the members of which are the only users who can use the Twitter feature.

Business process

Triggers and Automations provide several examples of business rules that leverage groups to assign, reassign, or escalate tickets. The groups that you define for this purpose might be specific to the use case. For example, if you’re defining an escalation process using automation, you might set up a Development Team Managers group.

It’s very likely that a single group will meet several of these criteria. For example, a Development Team Managers group could simultaneously be used to manually escalate a ticket via the ticket screen (funneling), support sharing of views to find all tickets that have been escalated (sharing), and work in conjunction with a business rule (business process).

Agent Signatures

Similar to most email applications, Zendesk allows all agents to include a unique signature at the end of every comment they add to tickets. From an administrator’s perspective, it is often important to build a level of consistency into the format of these signatures, which is a setting that is configured on the Agents administration page.

You can format an agent’s signature using Markdown, a simple text formatting syntax that allows you to create headings and bullet lists, apply bold and italic formatting, and so on. Markdown can also be used to insert your company logo into the signature. Markdown is applied to plain text and then displayed to your customers as HTML.

Tip

The agent signature will be visible in the Help Center as well as outgoing email correspondence, but it will not be appended to comments added to tickets created via the Twitter or Facebook channels.

To configure the standard template for your agents’ signatures, you will need to edit the Signature option on the Agents administration page. By default, this field contains the text {{agent.signature}}. This is another example of a placeholder (described in more detail in Placeholders); the code shown here will be replaced by the individual agent’s signature.

It is the administrator’s responsibility to add the extra pieces of text that are not included in the individual agent’s signature. A very common example would be the company slogan, or some useful information about hours of support (e.g., “Phone support offered 9 a.m. to 5 p.m., Monday through Friday; email support at other times”). Again, this information will appear at the bottom of every comment added to a ticket, and it’s very likely that your customers will read this information.

Warning

We’ve seen advertisements used in this space, but you should be careful not to make customers feel like you don’t take their support requests seriously. Customers can be very frustrated during the support process, and telling them about the new 3D version of your widget might just frustrate them more.

Adding an Agent Account

The steps that you’ll follow to create an agent account on the Starter, Regular, and Plus plans will differ slightly from the steps on the Enterprise plan. The topics in this section cover the first method.

First, the pricing model of Zendesk requires you to pay a fee for every agent account in your instance. End-user accounts are free. So basically, you should create an agent account only for people who need to sign in to the system to answer support requests, publish content to your knowledge base, or run reports as a manager. Also, administrator accounts are counted as agent accounts for the purposes of billing.

To create an agent account, open the People administration page, then click the “user” link beside “add” in the upper-right corner of the page. You are then prompted to enter the user’s name and email address as well as choose his role as agent. After you’ve done that and clicked the Save button, the new user’s profile page will appear. Most of the options on this page—such as Phone, Time zone, Language, Details, and Notes—are self-explanatory. If you’re using the Plus or Enterprise plans, there will be a field labeled Alias, which is the name that will be displayed to end users instead of the agent’s real name. This feature is provided mostly for privacy of the agent, and some customers use this field to abbreviate the agent’s last name. For example, Stafford Vaughan might have an alias in Zendesk of “Stafford V.”

Warning

The “role” listed on the user creation page is different from the “role” functionality available on the Enterprise plan, which is explained in Enterprise Agent Roles and Light Agents.

When “agent” is selected as the user’s role, the user’s profile will contain profile options that are not added to an end user’s profile. The options include a list of groups of which the agent will be a member, the agent’s access to tickets within your Zendesk instance, the option for the agent to publish comments that are visible to your customers, and whether she has Help Center viewer or manager privileges. Help Center managers are users who can edit or delete any article in your Help Center. Even if you don’t grant this permission to your agent, you can allow agents to edit the articles in sections of your knowledge base that you have explicitly given them permission for. This is discussed in more detail later in the book.

The option to restrict agent access to tickets will be discussed in Restricting Agent Access to Tickets, but our general recommendation is that agents have access to all tickets.

Tip

By default, your new agents are placed into the Support group (this is a group that is added to every Zendesk instance). This is because a group is required to assign and solve a ticket. As you add groups to your Zendesk instance, you can add your agents to other groups and set one of those other groups as the default group so that the next time you add an agent he will be assigned to that default group.

Enterprise Agent Roles and Light Agents

One of the best features of the Enterprise plan is the ability to configure agent permissions at a more granular level than the Starter, Regular, or Plus plans. This feature is known as agent roles (or sometimes just roles). The process of adding a new agent to your Zendesk instance on the Starter, Regular, and Plus plans provides the administrator with four different options (listed in the previous section), but the Agent Roles feature on the Enterprise plan extends this list to 20 different options, each of which is described in Configuration Options for Agent Roles. To make the management of these options more convenient, Zendesk captures the selected options in a single role, which can then be assigned to a specific set of agents.

Out of the box, Zendesk comes with five roles already defined. To find these roles, click the “roles” link beneath the search box on the People administration page. A quick summary of each of these roles is as follows:

Administrator

This is a special role that replaces the administrator user type on the other plans. On the Enterprise plan, the options for the Administrator role cannot be customized.

Light Agent

Like Administrator, this is a special role with limited options for customization. The purpose of this role is to allow team members outside the support team at your organization to sign in and assist the support process. Light Agents can never update the fields in a ticket, which means that they cannot solve a ticket, assign a ticket, add tags, or anything else. The only task that can be performed by a Light Agent is to add a private comment to a ticket, which is a comment that will be visible only to other members of your support organization. A common situation in which you’d use this feature would be when you involve your development team in the process of solving a customer’s support inquiry, especially if it was related to a bug in your software. Another example is a finance team, who would provide status updates on financial matters. In both of these cases, private comments will be added to a ticket by the development and finance teams, and it is the responsibility of the support agent to pass on the relevant information to the customer, and maintain the status of the ticket.

Staff

This is the standard role that you would assign to your support team. The default configuration of this role is quite restrictive, so we usually recommend changing some of the default settings for this role. In particular, you should probably change this role from restricting access to tickets in the agent’s groups to allowing access to all tickets instead.

Team Leader

This is not a special role, and seems to be mostly added for example purposes. This role is useful for someone who should have slightly higher access than most support team members, which would usually be, as the name suggests, a team leader.

Advisor

This is also a role that is mostly for example purposes, but might typically be used for an agent who should have some administrative privileges, but not all. This is typically someone who will not be solving support requests but who assists administrators with defining business rules or provides guidance on other Zendesk settings. Unless you have a large team of administrators or a very large customer service team, you probably don’t need to use the Advisors role and can delete it.

Legacy Agent

This is a special role for organizations that upgrade from the Starter, Regular, or Plus plans to the Enterprise plan. When you upgrade, Zendesk does not automatically assume that all of your agents should be granted one of the Enterprise roles listed in this section. Instead, all existing agents are assigned to the Legacy Agent role, and will have the same permissions as the previous plan. I recommend that after you upgrade, you immediately open your agent profiles and move your agents onto one of the dedicated roles in Enterprise, if for no reason other than to take advantage of the granularity of those roles. After you move your agents into one of the newer roles, it’s impossible to move them back onto the Legacy Agent role.

Tip

Agents using the Light Agent role are completely free, which I consider to be the very best feature of the Enterprise plan. Because these accounts are free, Enterprise customers often add every member of their organization as a Light Agent inside Zendesk, which means that all conversations about support tickets will stay inside Zendesk, rather than conversations with the development or finance team being scattered in email.

Configuration Options for Agent Roles

For each role, there are approximately 20 individual options to be configured. Most of the options are self-explanatory, but the decision process for each option is not always so obvious. In the following list, we explain some of the more common considerations for these options, in the context of the other features explained in this book.

What kind of tickets can this agent access?

This option is discussed in Restricting Agent Access to Tickets.

Agent can assign to any group

If you specifically select the “All within the agent’s group(s)” option in the “What kind of tickets can this agent access?” drop-down list, a new option will pop up that allows you to determine whether the agent can assign a ticket to groups other than those of which she is a member. By default, this is unchecked. The problem with leaving it unchecked is that the agent cannot escalate a ticket to whichever group is necessary. On the other hand, leaving it unchecked prevents agents from lobbing tickets away from their group, if they don’t want to take care of it themselves. I would err on the side of the first choice, which is to enable this option to give more control to agents, and trust them to make a wise decision as to whether the ticket is suited for their group. (Perhaps those are famous last words.)

What type of comments can this agent make?

To put it simply, some people just shouldn’t be making publicly visible comments on tickets. You’ve probably met someone like this—the person who is less than diplomatic with difficult customers. Most customer service team members have the necessary skills to be polite or, at the very least, professional. If you’ve opened up your Zendesk instance to other teams (e.g., the development, finance, or marketing teams), those customer service skills may not necessarily exist. I don’t want to stereotype, but I do encourage you to limit direct customer access to the pros, and enable public comments just for your trained customer service team.

Can edit ticket properties

This option can be used to restrict agents to read-only access on tickets. The functionality is very similar to the Light Agent role, but if you create a custom role for this purpose instead of using Light Agents, the benefit is that you can provide other privileges to the user. If this option is disabled, the next three options in this list will not be enabled. If you’ve disabled this option, you should also consider allowing these agents to add only private comments (see the previous item in this list), which means that the agent is restricted to communicating internally within your organization only.

Can delete tickets

This option does exactly what it suggests. You should be aware that there is no audit trail of deleted tickets in Zendesk, so this privilege should be given sparingly.

Can merge tickets

There aren’t many compelling reasons to prevent agents from merging tickets, because merging a ticket is a relatively innocuous task. As a side effect of merging tickets, one ticket will be closed for further comments, but it’s still possible to create a follow-up for that ticket.

Can edit ticket tags

Some organizations elect to link specific tags very closely to strict business processes, and therefore the tags should not be editable by agents. For example, a tag of “vip” might be so important to your organization that it would be damaging to allow an agent to add this tag to arbitrary tickets. If this is the case, you should disable the tagging privilege using this checkbox. Otherwise, agent tagging is a very useful feature that supports a great many functions in the product, and we encourage you to enable this feature for your agents.

What access does this agent have to end-user profiles?

If there is a very strict list of end users to whom you should provide support, you might want to use this option to prevent agents from creating new end-user accounts arbitrarily. On the Starter, Regular, and Plus plans, agents are trusted to be able to create end-user accounts. If you’re on the Enterprise plan and have access to the roles function, you could use this option to prevent agents from adding new user profiles.

May this user view lists of user profiles?

It’s not possible to block agents from viewing the details of individual end-user profiles, regardless of the plan you’re using. Using this option, it is possible to prevent agents from finding user profiles en masse, or prevent them from searching for user profiles. If you disable this option, agents may use the user’s profile link on a ticket only as a channel to find out further information about the user.

What can this agent do with customer lists?

Customer lists are collections of customers that you define based on system attributes, tags, and custom fields. They are similar to what views are for tickets. As with the previous permission, if you want to prevent your agents from viewing customer data and user profiles, you disable this option.

Can add or modify groups & organizations

If the option “What access does this agent have to end-user profiles?” is configured to give agents the privilege to create new user profiles in Zendesk, the option to also modify groups and organizations will appear to the administrator. The organization portion of this option is particularly useful, because it allows agents to create organizations to categorize end users. It also allows the agent to add groups and include fellow agents into those groups, so there’s a high amount of trust involved in granting this privilege to agents.

Can manage Help Center

Administrators, and agents given this permission, are responsible for managing the Help Center, which means setting up the structure of the knowledge and community, defining user acccess, and customizing the design.

What can this agent do with reports?

Zendesk has a reporting feature that shows simple reports to agents and administrators. It’s a good idea to share this information with agents, because it allows them to make informed decisions, particularly if there is a spike in a certain area. A high-level view of the status of your customer service team might be more information than you’re willing to share, though, and if it is, you can use this option to prevent agents from viewing reports.

What can this agent do with views/macros?

We’ve grouped the separate options for views and macros into the same item here, because the same principles apply to both. They share first place for our favorite option for roles. Basically, they allow administrators to delegate the responsibility of creating agent rules to the agents themselves. Later in this book, in Shared Views and Adding a Shared Macro, we explain how to share these features with your agents if you’re an administrator, but if you’re on the Enterprise plan, these rules are instantly democratized for your agents.

Can access dynamic content

If you have a small list of agents whom you trust to publish reusable content for all users, this option allows you to grant that privilege to those agents. Dynamic content was explained in Dynamic Content for Text Translation, but we mentioned that it’s typically the domain of the administrators to create new strings of text. If you enable this option, you’re effectively allowing your agents to assist with the translation process.

Can answer chat requests

For the same reasons described earlier in the discussion of restricting agent access to public comments, it might be worth preventing some of your agents from taking chat requests. This just ensures that the right people for the job are interacting with your customers directly.

Can access Twitter saved searches

Because Twitter is a very public communication medium, it’s generally a good idea to restrict Twitter access to users who have demonstrated an understanding of its sensitive nature. As described in Twitter, an accidentally published tweet can have very negative consequences for your brand’s reputation.

Can manage Facebook Pages

If you’ve set up a group of agents who will be managing your social media presence but you’d prefer not to give those users full administrative privileges to your Zendesk instance, use this option.

Can answer phone calls

Similar to the concept of chat and public comments, this feature allows you to restrict phone privileges to only certain agents. Some people are just better on the phone than other people.

Can manage business rules

If you trust some of your agents to manage your customer service workflow but would rather not give them full administrative access to your Zendesk instance, enabling this option for those agents is a good compromise. By using this option to give workflow access to particular agents, you and the other administrators can focus on more important features of your Zendesk instance (e.g., security).

Can manage channels and extensions

If you have some team members who are technically inclined and who manage the integrations on your Zendesk instance, then you might decide to give them this privilege, without giving them full administrative access. Just like the “can manage business rules” option, this is a compromise, and supports the idea of spreading the administrative load without foregoing control over the security of your system.

Adding an Agent on the Enterprise Plan

Now that you’ve configured your roles and selected the options for each role, the process to add an agent on the Enterprise plan is quite similar to adding an agent on the other plans. The first step is to click the “user” link next to the “add” section on the People administration page. The only difference between this process on the Enterprise plan and the other plans is that when you’re prompted to enter the agent’s name and email address and to select his role, you’ll see the end user, administrator, and all the Enterprise agent roles listed in the drop-down (not just the standard end user, agent, and administrator roles).

End-User Access

End users are usually your customers (although in the case of an internal customer support environment, they may be colleagues), and they will be the people who are seeking help. It’s possible in Zendesk to grant end users access to more than just their own tickets, though you must take into account some important considerations around privacy before enabling this setting.

The most common method by which end users are created in Zendesk is that a person creates his own account via the “sign up” link in your Help Center. Alternatively, end-user accounts may be automatically created when a new email is received in your Zendesk instance. For the situations in which the person has not created his own account, this section will explain how to create an end-user account as an administrator.

Creating an End User

Just like creating an agent and administrator, creating an end user involves clicking the “user” link next to the “add” section on the People administration page. There is a slight difference with adding end users, which is that some agents—depending on their permissions—can perform this function as well as administrators. The end-user fields are a subset of the fields that are included in an agent’s profile. For example, the Alias field will not appear for end users. End users are also much more likely to have a value in the Organization field, which is explained in Organizations.

Tip

A shortcut method of creating end-user accounts is available to agents during the process of adding a ticket, which is very convenient when the ticket requester does not already exist in the system. This process presents only a few core fields to the agent, just for the sake of simplicity. If an end user is created using this method, it’s always a good practice to visit the end user’s profile again at a later date and ensure that all fields for this user account have been set correctly.

Bulk-Importing Users

Another method for adding agents and end users to your Zendesk instance is a bulk import of user profiles. You may have done this in other SaaS business applications you’ve used and therefore may already be familiar with how this works.

Start by creating a CSV file containing your list of users. Most people start their list in a spreadsheet program such as Microsoft Excel or OpenOffice.org Calc and then save it as a CSV file, which formats the rows and columns of the spreadsheet as plain text with column values separated by a comma and each row (or record) terminated by a newline in the file. Upload the CSV file into Zendesk, which will match the columns to fields in the user profile and create new user accounts with all the parameters you specify. Of course, you need to create a spreadsheet that matches the exact order required by Zendesk to successfully map the data into the correct user profile fields.

You can also use this method to import a list of organizations into your Zendesk instance. In fact, you’ll need to do that first if you use organizations because they need to be there before you bulk-import your list of users. The details of the bulk-import process are described in the Zendesk knowledge base article on the subject.

Merging End Users

When you’re using multiple channels to provide support to your customers, you’ll occasionally have a situation where the same person submits a ticket for a single topic using several different channels. As an example, your customer might start by tweeting her concern, then escalate her inquiry by sending an email, then call into your Voice phone number if she does not receive a timely response with the other channels. Because each channel is different, every new submission from the same customer will be a separate ticket with a separate ticket ID, and—if the user profile does not already exist in Zendesk—the requester of each of these tickets will also be a different user profile in the system. This becomes difficult to manage from an agent’s perspective because he must search through several user accounts to find tickets from the same person, and it’s a problem for customers because they could potentially have tickets scattered throughout various user accounts and not know which one to use when signing in.

To solve the problem of multiple end-user accounts for the same person, Zendesk has a feature that allows you to merge end-user accounts. When you merge these accounts, Zendesk applies the concept of a source and a target user account. The idea is that the details of the source user account will be merged into the target, and any tickets requested by the source will also be merged into the target. Once the process is complete, the source user profile will be deleted entirely and only a single user profile will remain.

Tip

The Zendesk Voice channel is a very common example of when merging users will be valuable, because often your customers will have an existing profile without a phone number. When they call your support team for assistance, a new profile will be created for the phone number from which they are calling. By merging this new user profile with an existing profile that has an email address, your agents can continue the support conversation using email.

Because Zendesk allows only a single value for some of the user profile fields (e.g., name, phone number, and time zone selection), only the values on the target user account will be retained. In the case of fields that support multiple values (e.g., email), all values will be kept from both user profiles.

To merge an end-user account, you first must find the user and view his profile. When you click the “User options” link for this user, one of the options is “Merge into another user.” The dialog box to merge end-user accounts has two sections, as shown in Figure 4-2.

Figure 4-2. Dialog box to merge user accounts: source (top) and target (bottom)

The top section represents the source user profile and the bottom represents the target user profile. An arrow indicates this visually. To find the target user, start typing his name, and Zendesk will autopredict the user based on a text search. After you’ve selected the user, follow the prompts to merge the user accounts.

Warning

It’s not possible to undo the process of merging users.

Suspending End Users

Occasionally, emails will get past the suspended ticket filters, or someone will sign in to your Zendesk instance and create a ticket when she really shouldn’t. There are dozens of situations in which this would happen, but common examples are spam or solicitation. If this situation occurs, it’s possible for you as an administrator, or your agents, to suspend that end user. If you’re an administrator, you can also suspend agent accounts, though this function is used less frequently.

There are two ways to suspend a user. Outside the context of a specific ticket, you can suspend a user account by clicking the name to open the profile and then selecting the “Suspend access” option from the “User options” menu. This will suspend the user immediately without a confirmation screen. It’s possible to immediately unsuspend the user by selecting the “Unsuspend access” option in the same menu.

Rather than suspending a user from her profile screen, you’ll want more often to suspend a user from a specific ticket. To perform this function from a ticket screen, select the user’s profile name from the navigation at the top of the page, and then select “Suspend access” from the “User options” menu. This will immediately suspend the user, which prevents her from signing in to Zendesk or submitting additional tickets via any other channel.

Assuming an End User’s Profile

As you’re configuring your Zendesk instance, you may periodically need to troubleshoot issues that registered end users are having using your Help Center. The “Assume identity” feature allows you to do this.

When you use this feature to assume an end user’s profile, you will be signed in as that end user, and that user’s view of the Help Center will be opened in a new browser tab. At the top of the Help Center, you’ll see a message indicating this and a link to revert to your own identity. If you flip back to the browser tab in which you’re signed in to your Zendesk instance as an administrator, you’ll see a similar message. While you’re assuming an end user, you cannot also access your administrator account in your Zendesk instance. It’s one or the other.

Warning

Any changes you make while assuming an end user cannot be traced you, so be careful with your use of this feature. It may raise some eyebrows if an end user appears to be making comments on tickets and he has no knowledge of the comments himself.

Organizations

The Organization feature is an easy way to collect your end-user profiles together, then apply specific rules to those profiles. This particular feature is generally useful only if you’re operating a business-to-business (B2B) support service, where you are aware of the organizations that you are supporting. If you are business-to-consumer (B2C) support service and you are generally unaware of your customer list, or your list of customer organizations is extremely diverse, it doesn’t make as much sense to use the Organizations feature (although there are a few exceptions).

The first step to set up organizations is to visit the People administration page, and click the “organization” link next to “add” in the upper-right corner of the screen. The organization creation page has a number of fields to be completed. The Name of the organization is a required field, and would typically be the business name or brand of the organization. This name will be visible to agents when they are answering support requests. The Details and Notes fields are optional pieces of information that you can add to the organization, again for the reference of support agents.

To make it easier to link end-user accounts to organizations, Zendesk allows you to specify the email domains that are associated with that organization. The option is labeled “Domains.” If you add several domain names to this field (separated by spaces), Zendesk will retroactively find all user accounts with an email addresses that matches that domain name, and automatically add the users to the organization. Whenever a new user account is created, Zendesk will also check the email address of the user against known domain names, and add them to an organization if there is a valid match.

On a basic level, organizations are useful to support agents because they will identify to which organization their ticket requester belongs. On a more advanced level, rules can be set up that will allow escalations based on certain organizations SLAs, or triage tickets automatically based on rules defined for certain organizations. Many of these examples will be explained later in this book.

Warning

Unfortunately, many customers confuse Organizations with Groups. The difference is simple. Organizations are for end users (customers), and Groups are for agents (customer service staff). End users cannot be added to Groups. Agents can technically be added to an Organization, but there are so few examples of where this is useful that it’s definitely the exception more than the rule. One situation in which it is useful to add an Agent to an Organization is explained in Restricting Agent Access to Tickets.

Shared Organizations

For privacy reasons, it’s generally best to restrict end users to accessing their own tickets only. In some unique situations, it might be useful to allow a person from an organization to read tickets submitted by other people at the same organization. This feature is known as Shared Organizations, and is useful only if you are using the Organizations feature from the previous topic.

Shared organizations can be enabled on an organization-wide basis or an individual user basis. You can enable it on an organization-wide basis by setting the Users option to “Can view all org tickets” when adding or editing the organization. This setting will immediately add a link called “Organization requests” to the “My Activities” page in the Help Center. An example of this is shown in Figure 4-3. Clicking the “Organization requests” link in the screenshot will show the tickets from other end users in this organization.

Figure 4-3. End user navigation bar, demonstrating the Organization name

Warning

In general, we don’t recommend sharing an organization unless you are completely sure that your users will not have privacy issues. It’s risky to assume that an end user won’t accidentally publish a credit card number or password in his ticket, or that an HR person will not publish sensitive details about an employee, which could result in other users at the same organization accessing that information.

The alternative to the organization-wide sharing setting is to allow only certain users at an organization to view tickets requested by other users at that organization. An example for this would be a situation where an organization has a primary point of contact, or a senior staff member who needs access to all tickets. This person should be trusted with sensitive information within the organization. To enable this setting on the Starter, Regular, and Plus plans, change the Access option to “Tickets from user’s org” by editing the end user’s profile. If the organization-wide sharing setting has been disabled, the setting on the individual user’s account will override the organization-wide setting, and the end user will have full access to tickets from the organization. If the organization-wide sharing setting has been enabled, the setting on the individual end user is redundant. The same principles apply to the Enterprise plan, but the setting is an option under “What kind of tickets can this agent access?” called “Requested by users in this agent’s organization” when you are defining the agent roles.

Multiple Organizations

For some time, Zendesk customers were asking for the ability to add a user to more than one organization. This feature was added in early 2014 and is available to Plus and Enterprise plan customers.

Why would you want to add users to more than one organization? Most often, your company simply has an organizational structure that allows for (or requires) your users to belong to more than one organization and you want that reflected in your Zendesk instance. For example, your users may belong to a specific business unit in your company (let’s say marketing) but work on multiple products. With multiple organizations, you can create organizations for the business units and separate organizations for each product and then associate users with each organization that they belong to.

The point of organizations is that you can assign groups or specific agents to provide support to organizations based on such things as their areas of responsibility, their location, or their expertise. So using multiple organizations, you may have one group providing support to the business unit organization and another providing support to the product organization.

Multiple organizations don’t mean that you can create hierarchies within a single organization. All organizations are at the same level. You just have the option of placing users into more than one.

No administrative configuration is required to use multiple organizations other than creating the list of organizations. By editing a user’s profile, you can assign her to as many organizations as needed and then select the organization to be used as the default.

One of the user’s organizations is the default organization, which is used if no organization has otherwise been selected. This will be the case if a user in multiple organizations sends a support request via email. An end user can mention the organization name in the body of the email message, but there’s no way for that to set the Organization field in the ticket. That’s when the default organization is used. When using the support request form, however, users can explicitly select the organization they want support for—so long as you make the Organization field visible on the form.

Customer Lists

Another new feature that Zendesk recently introduced is customer lists. You can think of these as being similar to views, in that they are dynamically generated based on a set of criteria. For views and tickets, that criteria includes data such as priority and status, whereas for customer lists, the criteria includes user-specific data such as the organization the user belongs to, the user’s ID and name, the date the account was created, the custom user fields you’ve created, and so on.

As with views, you can create as many customer lists as you’d like and organize your customers in many different ways for many different purposes. If you’re just starting out with Zendesk and don’t have many users, the value of this feature may not be immediately apparent to you. However, all of the user configuration you do in your Zendesk instance now (like creating and using organizations, user and organization tags, and custom user fields) will bear fruit later when you’re ready to leverage this feature.

So how might you use customer lists? You could start by creating lists of users by organization or language or tags, for example, just so that you have a quick view of those users. If you wanted a list of all the customers that have created an account in your Help Center in the last 30 days, you could do that as well. Based on a custom user field or a tag, you could create a list of all your VIP customers (Figure 4-4). These lists are useful on their own, of course, but the real value of this feature may be in the actions you take to manage these segments of customers.

Figure 4-4. An example of some of the uses of customer lists

For example, you could take the list of VIP customers you created and then load it into one of the customer engagement apps (e.g., SurveyMonkey or MailChimp) available as add-ons to your Zendesk instance. Perhaps you want to run an email campaign offering your VIP customers a special discount on a new product or service. Loading your list into MailChimp makes that easy to do. You can also export a list as a CSV file and use it in an application outside of your Zendesk instance.

This feature is available in the Regular, Plus, and Enterprise plans, where you’ll find it in the side toolbar just below Views. Both administrators and agents can use this feature, with the caveat that agents can create lists only for their own use (personal lists) whereas administrators can create personal lists, lists that a specific group can see, and lists that all agents can see. Only administrators can install the MailChimp and SurveyMonkey apps in Zendesk, but agents can use those apps to create email campaigns or surveys from customer lists if you allow them access to these apps. When you install these apps, you can set role restrictions if you want to prevent agents from using them, which is probably a good idea if you want to control communications with your customers.

In the Enterprise version of Zendesk, as mentioned earlier in Configuration Options for Agent Roles, you can restrict agents to just see customer lists but not create them, or you can allow them to create personal, group, or global customer lists.