O'Reilly logo

Practical Zendesk Administration by Stafford Vaughan

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 1. Introduction to Zendesk

Zendesk is a customer service solution that is designed to be beautifully simple, and is used by many of the worlds largest organizations to provide support to their customers. It’s a Software-as-a-Service (SaaS) product, which means that your organization will pay a monthly fee for every registered member of your support team using the product. Zendesk will take care of the hosting for you, as well as the other logistics of running a complex website, which allows you to focus on the important tasks—such as providing great support to your customers.

In this book I use the phrase Zendesk instance, which refers to the Zendesk environment of your organization, and presumably the environment that you’ll be administering. Unless your organization is very large, you will typically have one Zendesk instance. The domain name of the instance will be something like mycompany.zendesk.com. That is one Zendesk instance, and all of the settings discussed in this book can be applied to that instance.

Explanation of the Zendesk Plans

There are four different Zendesk Plans, the features of which will be applied to your entire Zendesk instance:

The name of this plan suggests that it’s well suited to customers just getting started with Zendesk, which is true, but it’s also a great fit for smaller shops with limited customization needs for the product. The total cost for this plan is only $20/year, which includes up to three agent accounts. The best part is that the entire $20 license fee is donated to a charity (currently the UCSF Benioff Children’s Hospital), and by the time this book is published, customers on this plan will have contributed to raising one million dollars for children’s health.
The regular plan is designed for customers that don’t need the bells and whistles of the higher plans. The cost for this plan is $29/month per agent, and there are no limits on the number of agents that can be enabled on this plan. This plan is particularly well suited to customers who are satisfied with basic reporting functionality, and who are running Zendesk for customers in a single language and time zone. The support offered by Zendesk on this plan is limited to email support only.
This plan is the most used of the set, and is the perfect plan for mid to large organizations. Features of this plan include advanced business analytics with GoodData, as well as complete internationalization features and a number of tools to improve team collaboration. The cost of this plan is $59/month for each agent (or $49/month for each agent with an annual commitment), and there is also no restriction on the number of agents. I highly recommend this plan to customers, and this plan comes with both email and phone support from Zendesk.
For larger organizations, the Enterprise plan adds security and compliance features, as well as the ability to maintain multiple connected Zendesk instances with separate branding for each. These features will not be useful for everyone. On the other hand, a feature that is only available on the Enterprise plan—Agent Roles—is one of the most useful pieces of the entire product (see Enterprise Agent Roles and Light Agents for further details). This feature alone can be worth the extra cost for some customers. I recommend that all Zendesk customers take a second glance at this plan, and don’t be scared by the "Enterprise" label, because it’s something of a misnomer. The price tag is not cheap ($119/month per agent or $99/month per agent with an annual commitment), but when you consider that Light Agents are free accounts, it doesn’t necessarily have to be more expensive than the other plans. As a bonus, this plan offers 24x7 support from the Zendesk support team.

For further information about the set of plans and the features contained in each one, visit the plan comparison page for more information. Throughout this book I specifically state if a feature is only available on one of the more expensive plans, which should help you to make the decision.


Once you select a plan, all of the agents in the system will be on that plan. It’s not possible to pick-and-choose plan features to delegate to certain agents in the system. If you have 100 agents on the Regular plan and you’d like to upgrade to the Plus plan, the additional cost will be for every agent currently enabled in the system.

Terms and Definitions

Rather than explaining all of the product terms up front, the most important concepts will be explained here, then I’ll wait until the individual chapters to introduce the terms more comprehensively. The following list of terms are so fundamental to Zendesk, that many of the topics in this book won’t make sense until you understand them.

A support request submitted by a customer to ask for assistance. The term is selected to be as generic as possible, to capture the broad range of requests submitted to your customer service team.
When a ticket is submitted, a user will provide details about their request by entering values into the ticket fields. Examples of default System Fields are Subject, Description and Priority. It’s also possible for administrators to add Custom Fields, which capture more specific information in the ticket.
These are pieces of text that are added to a ticket, and form the conversation that will help solve it. Comments can be Public, which means that the comment is visible to end-users that have access to the ticket, as well as agents and administrators. Comments can also be Private, which means that only members of your internal support team and administrators will be able to read the comment.
A user is anyone with an account in the Zendesk instance. All users are classified as one of three types, which are End-Users, Agents and Administrators.
An end-user account is usually one that has been created by a customer when they submit a ticket. End-users typically have access to their own tickets and sometimes tickets requested by other people at their organization, but never tickets requested by other user accounts. End-users are also restricted as to the fields that they can view or edit, unless an administrator has enabled access to those fields.
An agent is typically a person who works for the support organization, and will be providing assistance to customers. Agent access to tickets will vary according to permissions set up by administrators, but typically, agents can access a wide range of tickets submitted by customers.
Administrators are the users who have complete access to the Zendesk instance. They can control all settings, and read all tickets reported by all users. Administrator users are also classified as agents in the system, meaning that their access includes all of the agent functions, and that every administrator user is billed by Zendesk as an agent account. For the purposes of this book, I’m assuming that you’ll have full administrative privileges in your Zendesk instance.
When you collect your agents together for the purpose of applying business rules, or to restrict visibility of a Zendesk feature, you’ll use groups to do this. Groups can only contain agent or administrators accounts, and cannot contain end-users. Tickets in your customer service portal may be assigned to groups, which indicates the team of agents that are currently working on the ticket.
When an individual member of your support team is working on a ticket, they will be set as the assignee of a ticket. The assignee of a ticket must always be an agent, although in rare circumstances the assignee may be an administrator.
The person who is seeking assistance on the specific ticket. Requesters are typically end-users, and will receive email notifications when the ticket is updated.
There are nine different ways for customers to create a ticket in Zendesk, and these are referred to as the channels. The options include the web portal, email, chat, phone, feedback tab, Facebook, Twitter, ticket sharing and the API. The various channels are one of the great advantages of Zendesk, because allowing customers to contact your support team using the method in which they’re most comfortable is the first step to creating a positive customer service experience.
Part of the agent business process will involve checking a specific list of tickets every day to find tickets to work on. Views are configurable saved searches that make it possible for agents to repeatedly find tickets according to the same criteria. Zendesk starts with a number of default views, but as an administrator, you can add new views according to the specific business process of your organization.
When your agents solve tickets, they’ll probably find that the same processes or questions are often repeated. Agents and administrators are able to create macros that capture a specific set of actions and store them in the form of a shortcut. The use of macros can save agents considerable time when solving support requests.
The forums feature is sometimes also called the "Knowledge Base", which reflects more accurately its primary function, which is to publish information to your community. Forums are designed to support a self-service customer workflow, by anticipating requests from customers and providing articles that answer these questions in advance.
When tickets are created or updated, triggers will be fired to execute a specific set of actions. Typically the actions will include sending an email notification to users to notify them about the update, but other triggers might be used to change a field on a ticket according to a certain criteria.
Automations are similar to triggers in that their function is to automatically execute a set of actions, but the difference is that automations will be executed after a certain amount of time passes. Typically automations are useful for setting reminders or defining escalations.
Email Notifications
These are simply emails that are sent from Zendesk to your users. Zendesk uses email notifications to keep in touch with users in a number of contexts, including triggers, automations, user creation, or when forum topics are added. The template for all of these email notifications is consistent, which will be explained later in this book.
Web Portal
This is the web interface that you’ll use as an administrator, the interface that agents will often use to solve tickets, and the interface that your customers will often use when submitting tickets through their web browser. Your Zendesk web portal is accessible via the URL defined for your Zendesk instance, as explained earlier in this chapter.
Business Process
Generally I use the term "business process" to refer to a process that is followed or defined by your organization. The business processes of organizations are usually what makes them so unique. Some processes are less tangible, and will involve a set of instructions being provided to your support agents. Other processes can be defined in Zendesk more tangibly, and when this happens, they are termed Business Rules.
Business Rules
These are the automated processes that are defined in Zendesk. Business rules can be agent rules—such as views and macros—or global rules—such as triggers and automations. Other rules can also be configured through the administrator interface of Zendesk.

User Interface Experience

The Zendesk user interface is separated into three distinct experiences, each representing one of the types of user profiles—end-users, agents, and administrators.

After logging in as an administrator, you can open the product administration section directly by clicking the Manage icon in the bottom-left corner of every screen. This icon looks like a cog, and is visible in Figure 1-1. Once inside the administration console, you will have a list of the administration menu options on the left side of the screen, grouped by category. After opening one of the administration menu items, the options for that section of the product will appear on the right side of the menu. Figure 1-1 shows an example of the Zendesk administration screen, the toolbar on the left side of the screen, the administration navigation beside it, and the Apps administration page occupying the rest of the screen.

Administrator user interface, with the Apps administration page selected

Figure 1-1. Administrator user interface, with the Apps administration page selected

When agents are logged in to Zendesk, they have a slightly different experience to administrators. Their experience will be focused around the toolbar icons in the top left, including the buttons to view a list of tickets, or to create new tickets. The end-user experience also differs, because end-users are very limited by what they can see in Zendesk, and are usually restricted to editing their own profile and viewing tickets created by themselves.

Examples of the ticket screens from the agent and end-user interfaces are shown in the Data Capture Lifecycle section of this book.


Administrators are often not aware of the interface seen by Zendesk end-users and agents, unless they use a function named Assuming a User Profile. It’s worth reading that topic to learn how to validate if the user interface for end-users and agents meets your own expectations.

Most of the user interface design elements in Zendesk use standard conventions, with a tendency on the side of simplicity. There are two unconventional design elements worth mentioning:

Deleting items
In some other software products, when you see a list of items, a "delete" button will often appear beside the item that you want to delete. This allows you to delete the item from a list directly. In Zendesk, this delete button is hidden on the "edit" page, so you’ll first need to click the edit link for the item, then find the delete button beside the button to submit the form. There’s a very good reason that this button is hidden—while it might be common practice to make it easy to delete information, it’s not really best practice. Maintaining the historical integrity of items such as ticket is important in customer service tools, which is the reason that the delete button is placed where it is in Zendesk.
Secondary hover operations
Usually when you read a list of items in Zendesk, the edit operation will be available via a "edit" link on the far right column of the list. If you hover over an item in the list, you may also notice some secondary operations only visible when hovering. The most common example is the "deactivate" link, which is a hover operation, or the "assume" function, which is also only visible when hovering over an item in a list. To execute these operations, you’ll need to hover over the item in the list then click the link. There’s no way to make these hover operations visible on the page permanently.

Steps to Administer Zendesk

There’s no single set of steps that every Zendesk administrator must follow, and there is no specific order in which the steps must be taken to configure your Zendesk instance successfully. It’s quite possible that your production Zendesk environment will leverage the default configuration available out of the box, and you’ll only make minor changes before your agents log in and get started. It’s also possible that you’ll change every one of the settings in the product, or it’s possible that you’ll find ways to configure the product to do something new and creative, just because it suits the needs and processes of your organization.

I’ve tried to order the topics in this book in a logical sequence that works for most administrators. I recommend that you follow along with the topics in the order in which they are presented, and configure the product in the same order. By the time you’ve finished the book, you will have fully configured your Zendesk instance. This is not a requirement though, and if you’d like to jump, say, to Chapter 5 because you’d like to know specifically about the topics in that chapter, that might work as well.

Internal Versus External Customer Service

Most of this book is dedicated to the idea that you’ll be providing support to your customers. I described end-users in the Terms and Definitions section as your customers, and your agents as your support staff. This is the most common usage of the product. It’s not the only usage of the product though. As a customer service tool, Zendesk can also be used internally within your organization. For example, it could be used by your IT Operations team to provide support to the rest of your organization. If you’re using Zendesk in this way, you’ll need to do some mental translations as you’re reading this book. When I describe the "customers", I’ll be referring to people at your organization who will be getting support. When I refer to your "support team", I’m referring to the agents in Zendesk, who would be your IT Operations team in this example. In general it doesn’t hurt to still consider the team members at your organization as a "customer", because in a way anyone who submits a ticket deserves outstanding customer service from the team that is using Zendesk.

If you decide to use Zendesk to support a team internally within your organization, and all of the people at your organization are end-users and your support team are the only agents in Zendesk, there’s not really going to be a big difference from the standard use of the product. On the other hand, if you give your employees—who are the people submitting tickets—agent profiles in your Zendesk instance (instead of end-user profiles), there are a few configuration items that you might want to customize:

  • The automated actions described in Ticket Status that will move a ticket from the Pending or Solved statuses into Open will not be fired if the email is from an agent account. The workaround will be that your business process should monitor updates to tickets on a regular basis.
  • If the requester is forwarding an email and Agent Forwarding is enabled, the most recent comment on the email will be removed from the ticket. Zendesk will also request the ticket on behalf of someone else. To avoid this, you might want to consider reading disabling the Agent Forwarding feature.
  • Agents cannot provide Customer Satisfaction rating feedback.

Many organizations run Zendesk very successfully as an internal customer service tool, but the list above is just a few items to consider if you decide to take this route for your Zendesk instance.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required