Practical Zendesk Administration

Stafford Vaughan

Published by O’Reilly Media

Beijing ⋅ Cambridge ⋅ Farnham ⋅ Köln ⋅ Sebastopol ⋅ Tokyo

DEDICATION

This book is dedicated to my mother, Rosalind, who slipped away too soon but I know that she would be proud. It’s also dedicated to my son Ty, who is always in my thoughts.

Foreword

We built Zendesk back in 2007 because we were frustrated with the quality of the customer service applications that existed at the time. The vast majority of these "solutions" were big, clunky, on-premise enterprise applications, distributed on CDs, and took forever to deploy. Even proof-of-concept projects often took months to complete. And when all was said and done, no one, especially the customer, was really ever satisfied.

Zendesk was the first, true cloud-based application that you could sign up for online, subscribe to online, and configure and launch online. And all of this could be done instantaneously. All it takes is the click a button, and you are on your way to providing top-notch customer service across your entire organization.

Nowadays, it’s hard to imagine software being distributed or packaged any other way. We revolutionized an entire industry in only five years, yet that handful of years seems like a lifetime ago.

We didn’t have a very advanced business plan or go-to-market strategy when we started out. In many ways, we approached building Zendesk in the same way a carpenter approaches crafting a new piece of furniture. It was all about creating something beautiful and unique, imagining how people would use it, looking for form and function to meet and create new meaning.

Of course, when you set out to do something that changes everything, your goal is to do just that. Still, it is nonetheless a very humbling experience to watch your product become wildly successful. It is always a remarkable experience to meet people who spend their entire workday in your product and love using it. And to meet company founders who tell you how your product has changed the way they do business—well, it’s the kind of encouragement that spurs you on to do even bigger, greater things.

Getting acquainted with Stafford has been one of these equally humbling experiences. Here’s somebody who knows the product better than we, the founders. He can make even the most complicated concepts seem simple. It’s why we’ve trusted him to train audiences around the globe to configure and administer Zendesk. He has helped hundreds of businesses use Zendesk to transform their own customer service operations. Stafford has taken the furniture that is Zendesk, and through his passion and dedication, placed it in a beautiful surrounding and given it additional purpose.

I couldn’t imagine a better person to write a book on Zendesk administration than Stafford. Reading the chapters are like reading the notes we never wrote when we designed the product. Stafford’s ability to enlighten readers on how to use the product better and the reasons for the design decisions in Zendesk never ceases to impress us.

Passion is what drove Zendesk’s founders to build the product before you today. But it is the success of our customers that built our company. More than 20,000 organizations around the world rely on Zendesk for great customer service and engagement. We believe Stafford has been very central to this success and is the best man help you successfully implement Zendesk, and I praise him for his effort in making Zendesk administration easy. Happy reading.

—Mikkel Svane

Founder and CEO of Zendesk

Preface

In 2011, a survey was conducted to find out what people really value about the companies and brands that they use. It may surprise you to hear that when considering the product, price or customer service, 55% of people said that they would recommend a company as a result of a outstanding customer service experience.

The example that I often give is this: imagine that your friend bought a pen. Now imagine you wanted to buy a pen for yourself, and you asked your friend whether they like the pen that they own. Statistically speaking, your friend is unlikely to say "it’s a good pen because it writes really well". They also won’t say "I like this pen because I got it for a good price" or "I like it because it doesn’t smudge." No, statistically speaking, your friend is most likely to say "I like this pen because, on the day that it stopped writing and I called the pen company, they made me feel really good about owning this pen".

That is the sort of relationship that Zendesk helps you achieve with your customers. For more details on this statistic, see the full infographic.

The best way to describe this book is the Zendesk Consultant in a Book. The advice, best practices and pitfalls included in this book are the result of working in the trenches, launching Zendesk customer implementations, delivering training sessions, and answering literally thousands of questions from training participants in countries all over the world. Every question from a Zendesk training participant gives me a fresh perspective on new ways to use the product, which I’ve tried to capture and share in this book.

Zendesk is a popular customer service software tool, and the approach of the software has always been to deliver a powerful solution with beautifully simple design. In a blog post on the topic, Zack Urlocker (COO of Zendesk), describes a recent "renaissance in Enterprise software that embraces SaaS and beautifully simple design process to deliver an easy-to-use experience even in areas that have sophisticated functionality". Zendesk’s simple design philosophy should not lead you to believe that the product is not powerful. In fact, the entire purpose of this book is to bring the expansive set of Zendesk features to light, explain their purpose, demystify the best approach to use them, and to help you to get the most out of product.

In explaining the features of the Zendesk product, I’ve focused on best practices instead of the step-by-step configuration tasks carried out by an administrator. If you are completely new to the Zendesk product and you find that you’re having trouble understanding some of the concepts in this book, I do recommend that you take a look at the official Zendesk user guide before reading this book. This will ensure that you have a basic understanding of the features before getting the advice on best practices contained in this book. It may also help to build a solid foundation to the process of making important decisions about your Zendesk instance.

It’s also worth noting that this book focuses specifically on best practices for the Zendesk product without going into depth on the broader techniques to provide outstanding customer service. Zendesk is a tool that can be wielded in any way that works best for your organization.

In his book High-Tech, High-Touch Customer Service, author Micah Solomon describes the idea of "touching" customers as the starting point to developing a lasting relationship. It’s impossible to physically touch customers over the internet, but it’s possible to use Zendesk as the tool to reach out to those customers and deliver that touch. This book will get you to the point of using the tool to it’s full potential—all that’s left is for you to use it. As Micah Solomon says, "the goal in all this is to touch customers in a way that builds true customer loyalty."

I hope you enjoy reading this book, and I hope to have the pleasure of hearing your feedback in a future training session.

Chapter Overviews

Chapter 1, Introduction to Zendesk

Before diving into the Zendesk product itself, this chapter explains the most important concepts of the tool. By the end of this chapter, you’ll understand many of the terms used in the product and the benefits of implementing Zendesk as your customer service solution.

Chapter 2, Initial Setup

There are a small set of tasks that every Zendesk administrator should perform on their instance before allowing their users to log in. This chapter explains these initial setup tasks, and focuses on giving your Zendesk environment the same branding as the rest of your organization. It also provides details on setting up your Zendesk instance for an international audience.

Chapter 3, Security

Any website that captures personal information must be secure, and this chapter will help you to make decisions on the various security options in Zendesk.

Chapter 4, User Management

This chapter explains the various types of users that can be created (end-users, agents, and administrators) and the roles of each one, as well as the different permissions you can configure for them.

Chapter 5, Channels

Zendesk is a tool that leverages many different methods of creating tickets, from common systems such as email to the newer social media platforms such as Facebook and Twitter. This chapter explains each of these channels, how to set them up, the benefits of each one, and how to make the most of them.

Chapter 6, Fields and Data Capture

Out of the box, Zendesk has a number of default fields that capture the standard information required by any customer service team. As an administrator you have some control over these fields, as well as the ability to add new fields to your Zendesk instance.

Chapter 7, Agent Support Process

Making a support agent’s life easier is a good idea for everyone involved. This chapter explains some of the techniques you can use to make the support process more efficient, as well as the best ways to manage the decisions that agents make on a daily basis.

Chapter 8, Automated Business Rules

Automating your business process in Zendesk will not only save your team time, it will reduce the risk of mistakes. There are many Zendesk features that you can use—including Triggers and Automations—which are described in this chapter. This chapter also provides examples of common business processes and their associated business rules, which gives you an inside look into how other customer service teams operate.

Chapter 9, Forums

The Zendesk forums feature allows you to provide self-service support to your customers. This chapter will explain how to set up your forums initially, then control access based on rules and permissions associated with the various users in your Zendesk instance. This chapter also includes information on how to measure the use of your forums and constantly improve them.

Zendesk Version

The version of Zendesk covered by this book is the latest public release as at September 12, 2012. Zendesk has a frequent—often weekly—release schedule, with new features and updates to existing features. The release notes are made available to the public in the official What’s New in Zendesk forum. Throughout this book I’ve deliberately described features without giving detailed steps to configure the feature, and I’ve only included screenshots in situations when I believe that the explanation would not be complete without them. The purpose of this book is to focus on the advice and best practices for administering the product, rather than be a step-by-step guide. If you would like or need more detailed instructions with fewer best practices, the User Guide may be a useful accompaniment to this book.

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

TIP

This icon signifies a tip, suggestion, or general note.

WARNING

This icon indicates a warning or caution.

Safari® Books Online

NOTE

Safari Books Online is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business.

Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.

Safari Books Online offers a range of product mixes and pricing programs for organizations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and dozens more. For more information about Safari Books Online, please visit us online.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

O'Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938 (in the United States or Canada)

707-829-0515 (international or local)

707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://oreil.ly/zendesk-administration.

To comment or ask technical questions about this book, send email to bookquestions@oreilly.com.

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments

When I think about all the people who were involved in making this book possible, I’m truly humbled.

There are certain people whom, without their contribution, this book would not have been written. I’d like to give a very special thanks to:

Kenny Dembner

For your support every day while I was writing this book, and for having the patience to hear about customer service software over dinner every night.

Rob Castaneda

For seven years of support, and staying with me as my boss, mentor, and friend.

Zack Urlocker

For giving CustomWare the opportunity to become a Zendesk partner, leading to all the great things that we’re now doing 18 months later, and for your support with every aspect of this book.

Peter Vaughan

For inspiring me to excel at all things. 70 Ironman races finished (and counting), you’re a role model for achieving my dreams, and my hero!

This book would have not been possible without the support of the team at O’Reilly, and I’d especially like to thank the following people:

Andy Oram

For patiently and supportively editing every word of this book. Thanks for challenging me to make it the highest possible quality.

Mike Loukides

For helping to set the direction for this book, and giving me the opportunity to become an O’Reilly author.

Christopher Hearse

For working with the tight deadlines to get this book released, and for ensuring the quality of the finished product.

Maria Stallone

For assisting with the editing process.

Sanders Kleinfeld, Rune Skjoldborg Madsen, and Adam Witwer

For your prompt technical support during the process of writing this book.

Many people have been involved in the process of creating the Zendesk customer service platform. I’d like to pay special tribute to the founders of Zendesk, for having the vision of beautifully simple customer service software that could change the world:

Mikkel Svane

For supporting the effort to write this book, and for writing the foreword.

Alexander Aghassipour

For taking the time while I was still getting started with Zendesk, to answer the questions that only a founder would be able to answer.

Morten Primdahl

For your kind words of support while I was writing this book.

I would also like to extend a special thanks to the following people, who have helped and supported me greatly:

Andrea Garfield

For being the best mentor I could have hoped for in the past 12 months. You’ve made such a difference, I don’t even have the words to express my gratitude.

Matt Doar

For diligently helping me with the original book proposal, which was the spark that ignited this whole thing.

Erin Odell

For supporting me at the Zendesk office, enthusiastically, every single time.

My family—Karen, Damien and Matt

For your support every day of my life.

The following people were technical and non-technical reviewers on this book, and helped in the process of fact-checking and providing feedback during the writing process:

Mikkel Svane

Not many technical authors have the privilege of a founder reviewing their work, but I appreciate you taking the time to ensure the accuracy of this book.

Elliot Robinson

Thanks for being the best wingman in the world during the Zendesk European training tours, and for the memes that kept me smiling while I was writing the book.

Max McCal

For your detailed review of all of the topics, which resulted in a surprising amount of feedback, and thanks also for taking the time to discuss some of the topics face-to-face.

Anton de Young

Aside from having written the majority of the official Zendesk user guide yourself, which has always been a huge help, I appreciate your detailed feedback on the topics in the book.

Matthew Latkiewicz

Brutally honest feedback is sometimes the best, and you gave me a wake-up call midway through the process of writing this book, which—I hope—improved the final book overall. Thanks also for helping me so much when I was first learning Zendesk.

Steven Yan

For reading the entire manuscript and using your extensive Zendesk product management experience to provide feedback.

Erin Boyle

Thanks for your ideas on how to best describe a customer service portal, and taking the time to read the manuscript for accuracy.

Mika Rantala

I’ve told you a dozen times that if you ever want a job delivering Zendesk training, there is a place on the team for you. Thanks for your deep technical knowledge of the product as an attendee at the Helsinki and Amsterdam bootcamps, and for providing feedback on the overall positioning of this book.

Last but not least, I’d like to thank every person who has ever taken one of my training classes and asked a question. Without your feedback, curiosity, and enthusiasm for Zendesk, I could not have understood the product sufficiently to write a book.

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:

Starter

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.

Regular

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.

Plus

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.

Enterprise

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.

TIP

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.

Ticket

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.

Field

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.

Comment

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.

User

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.

End-User

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.

Agent

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.

Administrator

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.

Group

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.

Assignee

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.

Requester

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.

Channel

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.

Views

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.

Macros

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.

Forums

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.

Triggers

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

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.

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.

TIP

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.

COMMON CUSTOMER SERVICE CONCEPTS

Many of the terms used by Zendesk (for example, "agent" and "ticket") are standard in the industry. If you’ve used customer service software before, these terms will be familiar to you, as will many of the other terms in the product. Zendesk also has product-specific terms, some of which are explained in the Terms and Definitions, and some of which are explained throughout this book.

If you’re familiar with the Information Technology Infrastructure Library (ITIL), which is a framework for how to deliver customer service, some of the features of Zendesk may already be familiar to you. For example, Zendesk uses the incident and problem relationship for convenient resolution of a large number of issues at once. Two of the three Zendesk founders are ITIL Foundation certified, and when they created Zendesk, they included many of the best practices from ITIL in the product. ITIL tends to be an extremely complex definition for how to deliver customer service, so you should be aware that Zendesk is a more simplified version of this.

Chapter 2. Initial Setup

Every Zendesk instance has a set of features that you’ll need to configure once, and a set of features that you’ll configure on an ongoing basis. This chapter deals primarily with the former, and covers most of the options that you’ll choose during the very early phases of your implementation, and generally will not need to change afterwards.

Some of the topics in this section—especially the email and domain name setup—may require assistance from teams other than your own, so it’s best to get in early and configure these features now, even if you haven’t fully defined your business process.

Creating a Sandbox

Before starting the configuration of any Zendesk environment, it’s important to understand that for every Zendesk instance on the Plus or Enterprise plans, there is another instance known as a Sandbox. In a nutshell, the sandbox is an environment for testing, learning and making mistakes. I mention the sandbox at this point in the book, because if you’re on either the Plus or Enterprise plans, it’s something that you’ll probably want to use as you follow along with the topics in the book and start to configure your own environment. It’s not possible to transfer the settings from your sandbox environment directly to your production environment, but after learning how to use each of the features covered in this book, it should be fairly simple to repeat the configuration. I also find that it’s best to complete your configuration in the sandbox environment and confirm that all features are working in conjunction with each other, before starting the process of configuring your production environment.

To create a new sandbox as an administrator, select the "Create sandbox" administrative action. The first time you create a sandbox, you’ll receive a message shown in Figure 2-1, which lists the settings that be copied and which will not. Zendesk copies some administrative settings, but not all of them. Most notably, it does not copy live ticket or user data. The general rule is that only low impact settings are copied, such as your branding and channel options, to avoid messy mistakes with emailing live data to customers during testing. Also, all administrator users will be copied into the new sandbox with the same passwords as your production instance.

Figure 2-1. Confirmation screen for sandbox creation

The URL of your sandbox will be unique, and based on your production environment URL. If your Zendesk instance is available at <companyname>.zendesk.com, the sandbox URL will be something like <companyname>1325888214.zendesk.com. That URL includes a numerically incrementing number, unique to every sandbox created. To visit your sandbox next time you log in to Zendesk, you can select the "Go to sandbox" administrative action.

The great thing about the sandbox is that if you mess everything up, it’s very easy to create a new empty sandbox. To do this, simply open your production instance again and select the "Reset sandbox" administrative action. This will first delete the existing sandbox, then create an empty sandbox with a new URL, ready for more testing.

Web Portal Branding

As an administrator you can customize the branding options of your Zendesk instance, including the name of your customer service tool, a company logo, a browser bookmark favicon, and a simple color scheme consisting of two colors (header and background). All of these interface customizations will apply to the end-user interface only, as the agent interface follows a strict format defined by Zendesk.

The name of your Zendesk instance will be shown at the top of Zendesk pages, in the subject lines of the default email notifications, and—depending on your settings—the sender name of email notifications. Choose something that is simple and has your company name in it.

Some people get confused as to why the color scheme configuration panel only allows the administrator to control two colors, when there are three colors on the end-user portal, including the page background and two different colors in the page header. The simple answer is that when you select the "Page header" color, a darker variation of this color will be automatically selected by Zendesk and used for the navigation bar. Zendesk automatically switches between white and black text for the navigation, depending on the brightness of the colors selected. Colors that are in the middle of the spectrum tend to make the text hard to read though, so always test the colors before deciding on your final selection.

WEB PORTAL CUSTOMIZATION USING CSS

If you’re inclined and have the necessary skills, you can also use Cascading Stylesheets (CSS) and JavaScript technology to modify the end-user look-and-feel of Zendesk entirely. There are many examples of Zendesk instances with attractive interface customizations, including:

1. support.box.com

2. support.bornfreebooks.com

3. support.foursquare.com

4. support.rockstargames.com

5. reuters.zendesk.com

CSS and JavaScript customization instructions are not covered in this book, but Zendesk has a useful CSS Cookbook on the topic.

Aside from the options on the branding page, there is one more web portal option for administrators. If you open the Channels administration page and find the "Web Portal" section, you’ll see a checkbox to show the "Introductory text on portal home page". This is enabled by default, which adds a small piece of text to the home page of your web portal. Once you’ve confirmed that this option is enabled in your instance, you should navigate immediately to the home page, and look for the default content at the very top of the page that starts with the text "Stay updated with announcements, get answers from the community, and share your feature suggestions with us". To edit this text and customize it for your own use of the product, you can click the "edit" link in the top-right corner of this box, and update the contents of the text area on the page. The contents can include HTML, but be very careful to format the HTML correctly, otherwise your page layout may stop working correctly.

Customizing the Zendesk URL

The URL, or web address, of a new Zendesk instance will be based on the subdomain selected during the setup process. For example if your company name is "Blue Skies", your Zendesk URL might be blueskies.zendesk.com. For the purposes of this example, let’s assume that the company’s main website is blueskies.com. While Zendesk would love for all of their customers to have the word "zendesk" in their web portal URL, most customers prefer to change this to hide the Zendesk name, in favor of their own company name in the URL. If you’re on either the Regular, Plus, or Enterprise plans, you will be able to customize this URL. Customers such as Box, Born Free Books, foursquare and Rockstar Games use a method of prefixing the company URL with "support", whereas in the Web Portal Branding topic I mentioned that Reuters opted to keep the default Zendesk URL.

There are several benefits to customizing the URL of your Zendesk portal:

Customer convenience

If you use a subdomain of your primary domain name (for example, the subdomain of blueskies.com would be support.), this makes it easier for customers to predict the URL of your support site. It’s far more likely that your customers would visit the support.blueskies.com URL to get support from Blue Skies, than to visit blueskies.zendesk.com, which would require the visitor to have prior knowledge that the Blue Skies company uses Zendesk.

Portability

If, at a later date, you decide that you’d rather not continue to use Zendesk as your customer service tool, it’s much more convenient and reliable for you to redirect the support.blueskies.com domain name to your new support portal than to communicate a new URL to all of your customers.

White labeling

Rather than publicize that they’re using Zendesk as their support portal, some organizations prefer to white label their use of Zendesk, meaning that the support portal looks exactly like their website without using the word "Zendesk". The benefit for the company is that it keeps a cohesive brand throughout the website, without the appearance of many technologies connected together. Fortunately, Zendesk is very good with its integrations, which allow you to fully customize the end-user interface using CSS, and also integrate your user account with an internal database by using SSO (see Integrating with an External User Database for further information). I’ve been told (but please don’t sue me!) that it’s not a violation of Zendesk’s terms of service to remove the word "Zendesk" from your support portal using CSS.

Customization of your Zendesk URL involves two steps. The first step is to set up a Canonical Name (CNAME) record with your Domain Name Service (DNS) provider. The CNAME record is basically an alias for URL prefix, which redirects the user to another location. If you choose the support. prefix, which is the most common, you would need to set up a CNAME record in your DNS to redirect "support" to the full URL of the Zendesk instance, which is blueskies.zendesk.com in my example. Making this specific change (along with the following step) would allow customers to visit the domain name support.blueskies.com and it would load the same Zendesk instance that I signed up for at blueskies.zendesk.com. From the customer’s perspective, the domain name would always appear to be support.blueskies.com. If you do not have the experience or qualifications to make a DNS change yourself, you can ask a member of your IT team or service provider to do it for you.

After the CNAME is record is set up, you’ll need to wait between 2 and 48 hours, which is enough time for your settings to be propagated to all DNS servers in the world.

The second step is more simple, and is something that you can change inside Zendesk yourself. If you’ve set up your CNAME record correctly and the change has propagated, go to the Branding tab inside the Account administration page, and find the "Host mapping" option at the bottom of the page. Continuing the example above, the value for the Host mapping field would be support.blueskies.com. If the changes and propagation were successful, Zendesk will accept the setting. Otherwise you’ll receive a message that the CNAME has not been set up properly, and you’ll need to check your settings and wait longer.

TIP

If you’re on either the Plus or Enterprise plan and using SSL on your Zendesk instance—which is something that I strongly encourage you to do—you should read Secure Sockets Layer (SSL) later in this book. That chapter explains how to set up SSL on a custom domain name, which will ensure that Zendesk does not revert to the default URL when using a secure connection.

Once all of these changes have been made, you and your customers should be able to visit the new URL that you’ve chosen, and the word "zendesk" will never appear in the URL again.

Internationalization

At the time of writing, the Zendesk end-user interface supports 47 different languages. The administrator and agent interfaces support 12 different languages (English, French, German, Italian, Spanish, Dutch, Traditional Chinese, Simplified Chinese, Japanese, Korean, Brazilian Portuguese and Russian). For geographically dispersed users, Zendesk also supports every time zone in the world.

As Zendesk spreads to organizations throughout the world, they’re starting to pay much greater attention to the internationalization needs of these customers. In 2012 alone, Zendesk added a translated agent interface, the ability to create text translations, and some beta features for automatic language detection of incoming emails. Behind the scenes, Zendesk also has features that will check browser headers of web portal visitors, which adjusts the visitor’s language settings automatically. All of these features help you to ensure that a great customer support experience starts in the local language of visitors to your customer service portal.

Administrator Interface Language

The Zendesk administrator interface also supports the 12 languages listed above. To change your language selection, you’ll need to click your profile picture in the top-right corner of the screen and select the option to edit your profile. The profile page has a select list with all of the supported languages in the product. After updating your selection you should refresh your browser window, and… voila! Everything is in French. Or German. Or Italian. Or one of the nine other options currently supported.

Zendesk is constantly adding new languages to the administrator and agent interfaces, so if you don’t see your language, you can try asking the Zendesk support team how soon until your language is supported by the agent and administrator interfaces.

Setting the Time Zone

Accurate times and dates are important in every customer service tool, and Zendesk allows time zones to be adjusted on a global and individual user basis.

To change the global time zone of your Zendesk instance, you should open the Localization tab on the Account administration page, select from the list of available time zones, then clicking "Save tab". Once set, all times and dates will be displayed to users relative to the time zone selected. This is an important change to make, because customer service is a timely activity by its nature, and a time that suggests that the last update was eight hours ago, when it was really 1 hour ago, could cause a lot of customer confusion and anger. Setting the correct time zone for your instance avoids these problems.

If you’re on either the Plus or Enterprise plan, Zendesk has a feature that will allow all users to set their own personal time zone. All new user profiles will use the time zone selected as the global setting by default, but individual agents and end-users can adjust their own time zone by editing their profile and selecting the time zone from the list of options.

On the Localization tab on the Account administration page it’s also possible to select between 24 hour (military) time and 12 hour time. The default is 24 hour time, and this setting will be applied to all users, regardless of their individual time zone selection. Unless you’re literally in the military, I don’t think there’s a best practice associated with this feature; it’s a subjective decision made by the administrators and imposed on all users.

Multi-Language Support for End-Users

Administrators can enable or disable certain languages, depending on the location of their customer base, and they can also select a default language other than English for their instance. In general, I recommend enabling as many languages as you will possibly need, rather than only including languages that you’re absolutely sure you will need. It doesn’t cost anything to add a language, and there’s very little additional overhead (with the exception of Dynamic Content for Text Translation). Most of the Zendesk user interface is translated automatically, so adding a fringe language might only make one more customer happy, but it will be nice to have that happy customer.

To get started with a selection of languages other than English, open the Localization tab in the Account administration page. There is a select list to choose the default language, and below the select list there is a link to display the "Additional languages". The latter option is available only to users on the Plus or Enterprise plans. After opening the list of additional languages, you can use the checkboxes to select the languages in which you’d like to offer support to your customers, then click "Save tab".

As soon as new languages are enabled using the technique described above, end-users will see a pull-down menu as shown in Figure 2-2, allowing them to switch to a different language. When the user selects a new language, all text that is a non-editable part of the Zendesk user interface will be automatically updated. Behind the scenes, Zendesk will also detect the location of visitors based on their computer and browser settings, and will attempt to automatically select an appropriate language for the user.

Figure 2-2. Language selections on the end-user web portal

When viewing the web portal in a different language, many customers are surprised to find that several pieces of the end-user interface are not translated into the selected language. This is not an oversight on behalf of Zendesk. Much of the text content on the Zendesk interface is configurable by the administrators, and therefore the responsibility of translating that content is left to the administrator, often by using Dynamic Content for Text Translation. In situations where a dynamic content variant (translation) does not exist, the default language will be used, which in most cases is English.

WARNING

A few pieces of text—such as the name of your Zendesk instance—cannot be internationalized, and the same text must be used for all visitors, regardless of their language selection. The chat welcome message is another example of this.

Features such as forums, comments, and email templates can all be configured to display relevant content in the correct language selected by a user, and these will all be explained later in this book.

Dynamic Content for Text Translation

Dynamic Content is a feature that allows standard pieces of text to be defined and associated with a special code (known as a Placeholder). Translated versions of the text will then be displayed to users who speak a language other than English. Dynamic content is most useful in email templates and macros, and it’s a feature that is available to users on the Plus or Enterprise plans.

If you’ve enabled multiple languages in your Zendesk instance and you’ve also customized the text in your email notifications and web portal, you’ll find that these specific pieces of text are not translated for your users. For this reason, if you’re using multiple languages in Zendesk it’s also very important that you take advantage of the dynamic content feature. From the customer’s perspective, there’s nothing worse than visiting a support site and being confused by a scattered foreign language. This situation can be avoided with dynamic content, which allows you create those translated versions of text

To get started, open the Dynamic Content administration page. A brand new Zendesk instance will not have any pieces of dynamic content defined, but it’s quite easy to define your own.

To explain dynamic content, I’m going to use a simple example of writing a set of instructions to reset a forgotten password. In Referring Macros to the Forums I revisit this topic to explain an even better practice for doing this, but let’s start with the basics in this exercise.

After clicking "add item" on the main dynamic content page, the first field on the configuration page will be the Name. The value in this field will be used as a reference in several places throughout the product, so it’s important that you select something that is meaningful and descriptive. I’m going to call my piece of dynamic content "Forgotten Password Instructions". Next, I select my default language as English. The default language is the one that is used when a translation has not been defined for the specific language selected by the end-user. Finally, I’ll define the content. In my example, the content would be a series of steps for the user to change their password. An example of this process is shown in Figure 2-3. When I’m finished I’ll click "Create", and I now have my first piece of dynamic content.

Figure 2-3. Dynamic content creation screen

Every translation of a piece of dynamic content is called a Variant. It’s best to define a variant for every language that you have enabled in your Zendesk instance, otherwise users may end up seeing a default piece of text, which is probably in a language other than what they selected.

To add a new variant, click the "add variant" link, select the language, and enter the same instructions (in my example, the series of steps to change the password) translated into the specified language. Repeat this process for all languages to be supported, and your screen will look similar to Figure 2-4.

Figure 2-4. Dynamic content summary screen, showing two variants

The key to using dynamic content is Placeholders. This topic is explained in more detail later in this book, but for the moment, suffice to say that the automatically generated placeholder for my example is {{dc.forgotten_password_instructions}}. This is a special code used by Zendesk to refer to the piece of dynamic content. When I add this placeholder to an email or macro, it will be converted automatically to show text in the language selected by the user who will read the information. If the placeholder is used in an email template, the relevant user for the purposes of translation will be the recipient of the email. If the placeholder used in a macro, the relevant user for the purposes of translation will be the requester of the ticket.

TIP

In the case of dynamic content on screen elements, the language selection will be based on the viewer of the text. In the case of dynamic content in emails, even if the agent executing a macro has selected English as their language, the variant selected for the dynamic content in the macro will be based on the requester’s language selection.

There are many alternatives to using dynamic content, such as creating a different macro for every language in the system. I find that when it comes to text that needs to be translated, dynamic content is a bit more complex, but saves time and effort further down the track. It also decreases clutter in your Zendesk instance, and reduces the number of configurations required by administrators.

BULK TRANSLATIONS

Instead of translating your dynamic content one piece at a time, you can define the standard pieces of dynamic content, then export the list and update all of the translations at once. This makes the process of translating your entire Zendesk instance more scalable, and is particularly useful if you’re using a translation agency, because you won’t need to give them access to Zendesk.

To use this feature, start by defining all of the pieces of dynamic content using the technique described earlier in this section. Then, from the dynamic content management page, click the "Export content" link on the right side of the screen. When you click the "Export" button, you’ll see a message saying that the export is in progress, and you’ll receive an email when it is complete. You should check your email inbox and follow the link to download the ZIP file of translations.

Every language supported by your Zendesk instance will have its own file contained inside the ZIP file. The format of each of these files is Comma Separated Values (CSV), with each row representing a piece of dynamic content to be translated. If you provide this file to an agency, they should send back the file in the same format, but the contents of the "X text" column should be updated to include the translated versions. The letter X must be replaced with the unique code for each language; for example, the Danish language code is "da" and the corresponding column is named "da text" in the CSV file.

WARNING

The format of the CSV file is very strict when performing import operations. Common mistakes include opening the CSV file in Excel and then saving it as the wrong file format, or adding or renaming columns. If any of these changes occur, Zendesk will notify you that the file format is not valid when you try to import the translations file. It’s possible for you to remove columns from the CSV file, so long as you keep the two mandatory columns: "Title" and "X text", where X is replaced with the language code). Generally, I would recommend keeping all columns in the CSV file after exporting; otherwise you introduce risk into the process. It’s also very valuable to keep the "Default text" column in the CSV file, because it’s a useful point of reference for the person translating the piece of text.

After translation, you’ll need to import each of the CSV files into Zendesk individually. It’s not possible to import all files as a ZIP file and if you try, Zendesk will flag this as "Malformed CSV input". To start the import, select the "Import content" link from the same place as the link that exports content, then browse to the file and upload it. If your format is correct, your content will be updated immediately. If your format was incorrect, Zendesk will notify you via email.

Outgoing Email

Zendesk relies heavily on email for communication with users. In fact, email is so important that the email address is the only required field when creating a new user account. When you originally create your Zendesk instance, the default email address will be set based on the domain name of your instance, but most customers prefer to customize the email address to be something more simple or consistent with their branding. This section will provide instructions on how to configure your outgoing emails, and how to ensure that security and spam controls are set up correctly. For an explanation of how to find the email templates used by outgoing emails in Zendesk, see Email Notifications later in this book.

CUSTOMIZING THE EMAIL DOMAIN

Continuing our example from earlier, if my Zendesk URL is blueskies.zendesk.com, Zendesk will automatically assign an email prefix of support@ to my sender email address, producing a default email sender address of support@blueskies.zendesk.com. Again, this email address has the word "zendesk" in it, which many customers would prefer to avoid (and I personally recommend, for the reasons of customer convenience listed in Customizing the Zendesk URL). The other benefit of removing the "zendesk" part from your incoming email address is that it’s easier for customers to remember support@blueskies.com than it is to remember support@blueskies.zendesk.com when emailing your support team.

Before changing the sender address of outgoing emails, you’ll need to ensure that your mail server is configured to capture responses to the emails. Assuming that support@blueskies.com is the sender address of my emails, unless emails sent to support@blueskies.com are configured to make their way into my Zendesk instance, the responses will be lost in the ether.

In order to make this change, you’ll need to ask your mail server administrators to forward to your Zendesk email address all incoming emails that are addressed to your designated support address. The exact method to do this varies depending on your mail service provider, but the process is usually common knowledge for mail server administrators, and a list of the steps for the popular examples (Google Mail, Yahoo Mail, and Exchange) are available in the Zendesk forum post on the topic. As long as your email administrators understand that the objective is to take all emails to your main support email address (e.g., support@blueskies.com) and redirect the email to the Zendesk support email address for your instance (in this example, it would be support@blueskies.zendesk.com), then they can make the change and it will be applied immediately.

Email Notification Sender Address

When a change occurs to a ticket in Zendesk, a feature called Triggers generates an email notification to affected users. Other events—such as the creation of a user account—also generate an email notification to users. The email address used as the sender of these emails will vary, depending on the configuration options that you select in the Email channel administration page, and some other options for configuration are revisited in Bi-Directional Email Communication.

The first step in changing the sender address is to open the Email section on the Channels administration page, and update the "Default reply email address" to be whatever email address you’d prefer. After you’ve made this change, outgoing emails will be sent from this address. I find that it’s usually best to allow your customers to reply directly to email notifications—which will add their response into Zendesk—so the common convention of prefixing your email notifications with noreply@ is not my recommended practice. Choosing an email address prefix such as support@ is a good choice, because this will typically be the email address for your Incoming Email channel.

Another administrative option for the sender email address is the Pass through feature. In the Adding Incoming Email Addresses topic I explain how Zendesk can be set up for multiple incoming email addresses, such as support@blueskies.com, members@blueskies.com, and sales@blueskies.com. If a customer emails one of the latter two addresses, they probably want to feel like they’re speaking to the same group throughout the entire conversation, rather than emailing a membership department at members@blueskies.com and then being directed immediately to support@blueskies.com. The "Pass through email addresses" option on the email channel page will ensure that email responses to customers are sent from exactly the same email address as the initial correspondence, which would be members@blueskies.com in this example.

Personalized Email Replies

By default, the sender name of email notifications will be the same as the name you’ve given to your Zendesk instance. Some customers find this to be a little bit impersonal because, after all, the support experience should be with a real person and not an inanimate customer service tool.

To ensure the most personalized experience for your customers, Zendesk has a feature named Personalized email replies. This very simple feature will change the sender name of outgoing emails to be the name of the agent who triggered the notification. If this feature is enabled, Zendesk also changes the sender email address by prefixing your default address with notifications-.

To explain this by example, if this feature is enabled and an agent named Erin replies to a support ticket saying "Thanks for submitting this ticket, we’ll send a response shortly", the name of the sender of the email will be "Erin" instead of "Blue Skies Support", and the sender of the email will be notifications-support@blueskies.com instead of support@blueskies.com.

The reason that it doesn’t use your default reply email (for example, support@blueskies.com) is that Zendesk wants to ensure that your primary Zendesk email address is not labeled in your address book as "Erin". Most email programs have a feature so that when you email somebody once, their details are saved in your address book. If the name "Erin" was associated with the address support@blueskies.com in your address book, it would be a problem because the next time you try to email Erin, you might email support@blueskies.com instead and catch the whole support team. The opposite can also be true—you might be trying to email the whole Blue Skies Support team, but all you see in your address book is "Erin". For this simple reason, Zendesk prefixes the personalized email notifications with notifications-, and saves your default email address (for example, support@blueskies.com) for system notifications not related to a specific ticket or agent.

To use this feature, in addition to enabling the "Personalized email replies" option in the Email section of the Channels administration page, the administrator must also make a minor change on their company’s email server. Continuing the earlier example, where I configured support@blueskies.com as the default sender address, your email administrator should add notifications-support@blueskies.com as an alias to your existing support@blueskies.com email address. In other words, both incoming email addresses should forward to the same place, which will update your tickets when an email is received. If an email address prefix other than support@ is used, the sample principle applies for that account as well (i.e., if you are sending email notifications from the members@blueskies.com email address and have enabled personalized email replies, you should set up notifications-members@blueskies.com as an alias of this address).

Zendesk will perform a check to ensure that the correct email (with the notifications- prefix) has been set up, and if it has not, you’ll see an error message similar to the one shown in Figure 2-5.

Figure 2-5. Error message shown if the email address with notifications- prefix has not been configured properly

Sender Policy Framework (SPF) Settings

The protocol used on the Internet to send email, known as SMTP, is defined so that anyone in the world could send an email pretending to be any other email address, and the email would still be sent. The catch is that most people have spam filters, and spam filters are clever at recognizing fake emails (known as "spoofed" emails). Spam filters can identify spoofed emails by checking the location of the sender of the email, and comparing that to the location of the company that the sender is pretending to be. If those locations differ, there is a high chance that the email will be identified as spam.

When Zendesk sends emails on behalf of your company, this situation occurs. Fortunately, you can fix it easily. If you’ve customized the domain name of the sender address for emails, it’s very important that you also follow the steps in this section.

First, you’ll need your DNS administrator to change the Sender Policy Framework, or SPF, rules for the relevant domain name. Essentially, this causes your domain name to tell the world that it trusts Zendesk to send emails on your behalf, then if a spam filter checks for validity, the email is not flagged as spam. The specific SPF record to be added to most customer’s DNS settings is v=spf1 include:support.zendesk.com ?all, and there are more detailed instructions in an article on the Zendesk forums.

WARNING

The SPF record for your specific mail configuration may vary depending on which service your company uses to host its domain name and which mail server you are using, although most domain name administrators should have the required knowledge to make this change.

Chapter 3. Security

By its nature, customer service software captures personal information about people and organizations. This information is stored in the cloud as a SaaS solution. The idea of customer information being stored outside of a company’s firewall often makes administrators nervous, but the reality is that any company in a position similar to Zendesk understands the potential security concerns, and takes every possible precaution to mitigate risk. Zendesk have some extraordinarily large companies in their customer list, and their security team takes the privacy of the information in your Zendesk instance very seriously.

The topics in this chapter will help you, as an administrator, to take best advantage of the security features in Zendesk.

Social Media Logins

As part of its integration with popular social media platforms, Zendesk has integrated its user management system in a way that allows users to log in using these platforms—if this is enabled by an administrator. The benefit to your customers is that they do not need to memorize a dedicated username and password for Zendesk, because they’re using a username and password that already exists in another system. From Zendesk’s perspective, the tool is basically saying, "If you can successfully log in to one of these social media platforms, we trust that platform enough to accept their word on the fact that you are who you say you are."

The platforms supported by this feature are Twitter, Facebook, Google, and OpenID, and this section covers the first three.

TIP

Regardless of which platform you use, Zendesk will never have access to the customer’s password for that service.

The social logins are enabled on the Authentication tab of the Security administration page. Enabling each of the options is a simple process of selecting the relevant checkbox and saving the tab. When you enable each of the social media platforms, customers will immediately see that platform listed on the login page, as an alternative to entering a Zendesk username and password. Figure 3-1 demonstrates an example with the logins for Twitter, Facebook and Google enabled.

Figure 3-1. Login page displayed to users when the social media logins are enabled

In order for the user to log in using one of these tools, they must be able to authenticate with that service. This process relies on standardized security mechanisms (in the case of Twitter, this is OAuth) to ensure the security and safety of your user accounts. The Twitter login page is shown in Figure 3-2, which clearly indicates the permissions that the user is authorizing for Zendesk to use, and reiterates that Zendesk does not have access to the user’s Twitter password. When the user authenticates in this way, Zendesk also does not have access to post to the user’s Twitter timeline, so there’ll be no "Erin has just logged in to Zendesk" posted to the Twittersphere. These same concepts also apply to Facebook and to the Google login option.

Figure 3-2. Twitter’s authentication screen with the list of permissions requested

When a user successfully authenticates with the social media service, they will be logged in to Zendesk, and Zendesk will create a user account for that person automatically. If the user has logged in using Twitter or Facebook, Zendesk will immediately prompt the user to enter an email address. Zendesk relies on email heavily for its communication with users, which is the reason that an email address is required at this stage. In fact, the user cannot proceed using Zendesk—even after logging in—until they have provided their email address. In the case of the Google social media login, Zendesk will be notified of the user’s email address by Google automatically, so the user will not be prompted separately for their email address.

From an administrator’s perspective, it’s impossible to tell whether a user is choosing to authenticate using a social media service, or if they have a password configured in Zendesk. When you look at a user’s profile, you’ll see that their Twitter, Facebook, or Google account is linked to their user profile, but as far as you’re concerned, they could be using any one of the available mechanisms to log in.

In general, I find that this feature is useful, and worth leveraging as a convenience to your users. I don’t believe that the level of risk introduced by integrating with these external platforms is high enough to warrant steering clear of the service.

WARNING

By default, all Zendesk instances will have the Twitter login option enabled. If you do not wish to use this option, you should immediately change the setting using the method described above, which will ensure that your users can only log in using their Zendesk username and password.

Suspended Tickets

Zendesk has a number of rules to determine which tickets should be suspended. Examples of these rules include spam, emails from unauthorized users, emails from unverified users, out-of-office replies, mail loops, and automated notifications. Zendesk does not delete these tickets completely (unless the spam filter identifies an email as 99.9% likely to be spam), but places them in one of the Views named Suspended tickets. It is the responsibility of your support agents to periodically review this list of suspended tickets and take appropriate action. There is currently no way to disable the conditions for suspending tickets, either globally or individually.

If you or another member of your team would like to be alerted by email when tickets are added to the suspended tickets list, there is an option named "Suspended Ticket Notifications" in the Tickets administration page, which offers an email digest every 10 minutes, every hour or once per day. The recipients of the alert can be any email address, and are not restricted to users that already exist in your Zendesk instance.

The suspended tickets feature adds peace of mind that unimportant emails will be filtered out of your ticket inbox, but it’s still a good idea to build a practice that your agents check the suspended tickets list periodically. I consider the list as being similar to my junk email inbox. Like my junk email inbox, most of the contents of the suspended tickets list will have a valid reason for being suspended, so checking the list once per day is usually frequent enough. The occasional ticket that gets caught erroneously can wait until tomorrow to receive a response from your support team.

For your agents, working with items in the suspended tickets list is quite simple, and every agent in Zendesk will have access to the suspended tickets view. On a regular basis, ask your agents to open Suspended tickets in their list of views (it is the only view that appears in red), and browse the contents. If they find an item that looks like it shouldn’t be suspended, your agents can recover it automatically or manually. Automatic recovery is a one-step process but does not allow any changes to the ticket, and manual recovery allows the agent to update the ticket before submitting it. An example of a suspended ticket is shown in Figure 3-3. This item shows an automated response from an email server, which states that the target address for an email notification from Zendesk was invalid. Since this message from the email server is classified as an automated reply and this is one of the reasons for suspension, the email was added to the suspended tickets list.

Figure 3-3. Example of a suspended ticket, including all information fields

Depending on the exact reason for suspension, Zendesk offers a variety of actions that an agent can take to recover the suspended ticket. In some cases the issue is related to user accounts, so Zendesk will offer to create the user account while recovering the ticket. In some cases Zendesk may offer to add the email as a comment on an existing ticket, or to create a new ticket. Most of these options are intuitive. It’s also easy to perform the operations in bulk by selecting multiple checkboxes on the main suspended tickets list, including deletion of all tickets marked as suspended.

Public Creation of User Profiles

Probably one of the biggest decisions you’ll make about user management in Zendesk is whether to let your clients create their own user profiles. If you are working for a company with a broad or anonymous user base and you don’t know the names and email addresses of all of those users, it makes sense for you to enable open access to your Zendesk instance. In this situation if one of your users is seeking support, they can simply visit your Zendesk portal and create a new profile to submit a ticket.

The other option for user profile creation is to use the closed option, and there are two situations in which you might decide to use this:

Restricting ticket submission to known users

If you’re confident that you have a comprehensive list of user accounts, it’s possible for administrators to create those user accounts in the system (which can be automated using a CSV import), thereby restricting ticket submission to only those users. This would be useful if you want to ensure that support is provided to known users only. It ensures less work on behalf of agents, who won’t need to filter through invalid support requests, but slightly more work on behalf of administrators, who will need to create all of those user accounts before your customers can log in.

Dove-tailing with SSO

If you elect to use Single Sign-On (see Integrating with an External User Database), you might also elect to disable public creation of user profiles. This may not necessarily prevent any member of the public from submitting tickets—because that will depend on the way your SSO is configured, but it delegates the selection of who can submit those tickets to users who have an account in your company’s user database. If you have an existing list of members on your web application, for example, you can set up Zendesk to ensure that only the users in the web application database can create support tickets. Anyone else who wants to submit a ticket must create a profile with your web application to get access to your Zendesk instance.

A closed Zendesk instance does not allow the Feedback Tab channel to work, and all incoming emails from addresses not already in the system will be immediately added to the Suspended Tickets list.

INTEGRATING WITH AN EXTERNAL USER DATABASE

Single Sign-On (SSO) is a system that allows you to connect the Zendesk user database with an external user management system. Some companies like to save their users the effort of maintaining several sets of login information (a problem that leads people to keep long lists of user account names and passwords written on insecure pieces of paper at their desks), so they elect to use SSO. Implementation of this option requires some programming and is outside the scope of this book, though you can find further information in various forums online.

To enable or disable public access to your Zendesk instance, open the Customers administration page. The relevant option on this page is "Anybody can submit tickets", and it is selected by default. If you leave this option selected, you’ll have an open Zendesk instance where anyone in the world can sign up with an end-user profile and submit tickets. A sample of the form displayed to the user (with CAPTCHA enabled) is shown in Figure 3-4. If you uncheck the "Anybody can submit tickets" option, you’ll have a closed Zendesk instance.

Figure 3-4. Sign up page on an open Zendesk instance

Once you’ve enabled the open Zendesk instance option, you’ll be presented with another set of options. The option labeled "Ask users to register" simply means that yes, anyone can submit a ticket, but that the ticket will be marked as suspended until that user verifies their account and email address. This is a kind of middle ground between the open and closed user profile option, which ensures that everyone can submit a ticket, but only users who are willing to verify that they’ve entered a valid email address will have their tickets viewed by a support agent.

TIP

To most Zendesk administrators, it should be obvious whether they have intimate knowledge of their customer base or not, leading to the decision about whether your Zendesk instance should allow public creation of user profiles. My recommendation is this: if you don’t have a complete customer list or if you’re not sure who will be contacting you, start by allowing public creation of user profiles, use some of the methods described later in this book to automatically triage certain requests, then disable public profile creation at a later date if you find that you’re just getting too many invalid requests.

Blacklists and Whitelists

If you’ve enabled public access to your Zendesk instance, you still have several more levels of control over the people who can submit tickets in Zendesk. The blacklist and whitelist are used to define rules that determine which emails should be accepted or rejected when they are received in your Zendesk instance. To find the blacklist and whitelist settings, open the Customers administration page and make sure that the "Anybody can submit tickets" option is enabled.

There are several common scenarios for using the blacklist and whitelist:

Limited customer list

If you would like to accept incoming emails from only a limited set of customers, you can use the blacklist to block all emails, then the whitelist to create a limited number of exceptions. To achieve this, enter an asterisk (*) in the blacklist, and a comma separated list of email addresses or email domains in the whitelist.

Problem customers

If you find that a certain email address or domain name is sending emails that you do not want to receive in your Zendesk instance, you can include these in the blacklist without entering any values in the whitelist. The message here is simply "reject anything in the blacklist, but accept everything else". If you would like to specify a domain name, the format should be just the domain and the suffix, for example company.com, not *.company.com or another variation.

Valid notifications

Since automated email notices are suspended based on the standard rules of suspension, notifications that are sent from Google or other online services will typically be suspended. If these notifications are important for your company and should be accepted and processed normally, simply enter the email addresses or domains of the valid email senders in the whitelist field, and these addresses will no longer be suspended with the other automated emails. In this scenario it is possible to enter values in the whitelist without using the blacklist, although you can still use the blacklist for the other purposes described above.

Disabling email entirely

If you have decided that no users should be able to email your support team and that any emails received should be rejected immediately without suspension, it’s possible for you to enter the keyword reject:* in the blacklist, which will achieve this. If you were to just enter an asterisk (*) in the blacklist without the reject: prefix, all emails would be suspended. The "reject" keyword bypasses the Suspended tickets list altogether.

WARNING

The blacklist and whitelist deal with emails only, and do not prohibit users with these email addresses from creating a user profile in Zendesk and submitting a ticket manually.

Password Strength Policy

There are three options for the strength of user passwords in Zendesk.

Low

This option requires your users to select a password with at least five characters, and no other restrictions are applied. Some people criticize this option for being too weak, but many people like this option because they believe that most users are capable of managing their own rules for password complexity.

Medium

This option requires all passwords to be at least six characters, they must include mixed case letters, numbers, and a character that is not a letter or number. It’s a good middle ground option, which enforces simple requirements on the users. Let’s face it, any password these days that does not include characters other than a word is probably not a very secure password anyway.

High

This is the final option, but also in my experience it is the most criticized. The reason for the criticism is that this level requires users to change their password every 90 days. I’ve met a lot of IT folks who say that this is considered less secure, because users tend to write their new passwords down somewhere, which introduces the risk that someone else could find the password. Aside from this rule, the other conditions are that the password cannot be one of the previous five passwords used, and that it must have the same complexity rules as the Medium level. It’s up to you to decide whether you think that this is truly the most secure option for your Zendesk instance, and if the requirement for users to change their password every 90 days is a worthwhile inconvenience.

Whichever option you choose, the setting is available on the Password Policy tab on the Security administration page. After you select one of the options from the list of radio buttons, click "Save tab" and the new policy will be applied immediately. If you decrease the policy, existing users will be unaffected. If you increase the policy, all users will have up to five days to change their password, after which time they will be forced to change their password the next time they log in to your Zendesk instance.

Secure Sockets Layer (SSL)

To ensure the privacy and security of your customers, I strongly encourage you to enable SSL on your Zendesk instance. The reason is that SSL ensures that all data transmitted through your browser is encrypted, and any attempts by intruders to intercept the data transfer are less likely to be successful.

Fortunately, SSL is enabled by default on all Zendesk instances. If—for whatever reason—you would like to disable SSL, the setting can be changed in the SSL tab on the Security administration page. This page also has a notice that discourages SSL from being disabled.

If you followed the instructions earlier in this book to set up a custom URL (e.g. support.blueskies.com, you may notice that the Zendesk URL reverts to your default <companyname>.zendesk.com URL when the browser switches to the HTTPS protocol (HTTPS is the protocol used when SSL is active). The reason is that in order for SSL to work, your browser requires a certificate that matches the domain name of the URL being opened. Zendesk has a certificate for its own domain name, so any visits to a subdomain of zendesk.com will use the Zendesk certificate. If you change your domain name to support.blueskies.com, the browser can no longer use the zendesk.com certificate to validate the URL, and must use a certificate for blueskies.com instead. To guarantee the security of your Zendesk instance when SSL is enabled on a custom URL, Zendesk will always switch back to the <companyname>.zendesk.com URL unless you take some further steps.

To ensure that your custom URL shows in every situation, you’ll first need to be on the Plus or Enterprise plans. If you are, you’ll need to generate an SSL certificate for your custom URL with a third-party provider. Most webmasters should have the knowledge required to perform this task. The first step is to visit the SSL tab on the Security administration page inside Zendesk. If you have a custom URL enabled, there will be a link on this page to generate a Certificate Signing Request (CSR). The CSR is a file that your webmaster will use to generate the certificate for your custom domain name, and you should download it from this page and provide it to the person who can generate an SSL certificate with the third-party. Once the certificate has been generated, you should visit the SSL tab on the Security administration page in Zendesk again to upload your SSL certificate. The certificate will be installed manually by the Zendesk operations team, which can take a few days, and once the process is complete you’ll receive an email with details of next steps.

TIP

While you’re waiting for the certificate to be installed, there’s no problem with running your Zendesk instance on a <companyname>.zendesk.com URL. Users will still be able to start by visiting your custom URL, but Zendesk will redirect them to the more secure URL as it deems necessary to guarantee a secure connection.

Enterprise Security and Compliance

On the Enterprise plan, customers are able to control Zendesk user access based on the IP address of the visitor. A typical use case for this feature is when you need to restrict access to people who are physically located in your office. Alternatively, a Virtual Private Network (VPN) can allow a user to access your corporate network securely first, then they can open Zendesk from that IP address, and it will appear as if they are connecting from your office network. The options to control user access can be found in the Access Restriction tab on the Security administration page.

Access can be restricted globally for all user accounts, but this is often useful only if you’re running an internal customer service solution and your end-users are also members of your team. This is the default setting when access restriction is enabled.

Access can also be set to restrict just agent and administrator accounts, which is useful in a broader range of Zendesk environments because it still allows customers all over the world to submit tickets. Put simply, this means that if an administrator wants to change a Zendesk configuration setting, or an agent wants to read the complete list of tickets, they must be physically located in your office. To enable this option, click the checkbox for "Allow customers to bypass restriction".

WARNING

When you enable this feature, the restriction will also have an impact on API calls by external applications, including the mobile apps. If your agents need to use the Zendesk mobile apps from any location, the final option on the Access Restriction page is "Allow agent access via mobile apps", which will allow them to do this.

The other compliance feature required by some heavily regulated organizations or industries is the ability to Blind Carbon Copy (BCC) absolutely every email notification from Zendesk to a specific email address. This option is named "Email Archiving" on the Tickets administration page, and is also available only for customers on the Enterprise plan. The use case for this feature is when a company, for regulatory or compliance reasons, needs an archived copy of all email communication with users. For most other companies, this is an unnecessary feature.

Chapter 4. User Management

Any person 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 log in to the Zendesk web portal and customize their profile when they’re getting support from your company. Others prefer to log in, but don’t care to update their name or upload a photo. Other customers may never log in to your web portal, and prefer 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 either an end-user, an agent or an administrator. Each of these levels are 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 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 they are 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 must contact the Zendesk support team.

To add an administrator in the product, you’ll need to select the "user" link from the People administration page, then select Administrator as the user type. If you’re on the Enterprise plan the process will differ slightly, which is described in 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. I do think that any more than three administrator accounts is a bad idea, though. I often see IT companies with a team full of people with the technical competence to administer a Zendesk instance. But even though they may be technically competent, I find that it’s difficult for more than three people to communicate effectively with each other 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.

TIP

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 number of users with access to administer your Zendesk instance, the better your chances of resisting one of these attacks.

Agents and Roles

Agents are the people on your team who will be providing 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 the reputation of customer service at your company.

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 when 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 can be limited to only a specific group. Another example is one of the Triggers that would assign new tickets to a specific group according to relevant criteria. Another example, and probably the most common, 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 "Support" and another group for "Level 2 Support", you cannot categorize the latter as a sub-group 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 top-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 the Views and Macros sections later in the book, 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 which 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 of "Development Team" to share the view. Combining this with the item above, you now have a set of at least two groups: "User Interface Development" and just "Development Team".

Permissions

If you’d like to restrict access to certain Zendesk features to various team members, you can use groups to achieve this. One example is the Twitter channel, which allows you to restrict the Twitter feature to authorized users only. Since Twitter is typically a feature that would be used by your marketing team, you might create a group "Marketing", 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 an automation, you might have a "Development Team Managers" group.

It’s very likely that a single group will meet several of the criteria listed above. For example, a "Development Team Managers" group could be used when manually escalating a ticket via the ticket screen (Funneling), it might support sharing of views to find all tickets that have been escalated (Sharing), and there might be a business rule that uses this view as well (Business Process).

Agent Signatures

Just like most email applications, Zendesk allows all agents to include a unique signature at the end of every comment that 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.

Because Zendesk supports only plaintext comments, the agent signature will always be plaintext. This does not mean that you can’t include URLs in your signature, but they might not be clickable for the reader.

TIP

The agent signature will be visible in the web portal 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 placeholder {{agent.signature}}. This is another example of a Placeholder (described in more detail in the Placeholders section), where 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, for example "Phone support offered 9-5 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

I’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.

Firstly, 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 if you really think that this person will be logging into the system and answering support requests, or if they will be publishing content to your forums, or they will be running 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 top-right corner of the page. Most of the options on this page, such as Name, 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 using 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, my name Stafford Vaughan might have an alias in Zendesk of "Stafford V".

To ensure that this new user account is an agent, select the "Agent" option in the Role section. The other alternatives are administrator and end-user.

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.

After you select "Agent" as the user type, you’ll be presented with a small number of options. The options include a list of groups of which the agent will be a member, as well as the option for the agent to publish comments that are visible to your customers, and whether they have forum moderator privileges. Forum moderators are users who can edit or delete any topic in your forums. The option to restrict agent access to tickets will be discussed in the Restricting Agent Access to Tickets section, but my general recommendation is that agents "Have access to" all tickets.

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 last topic), but the Agent Roles feature on the Enterprise plan extends this list to 20 different options, each of which is described in the Configuration Options for Agent Roles section. To make the management of this list of 20 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 log 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 only be visible 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. I find that the default configuration of this role is quite restrictive, so I usually change some of the default settings for this role. In particular, I would 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 would be assisting administrators define business rules, etc. Unless you have a large team of administrators or an extremely large customer service team, you probably don’t need to use the Advisors role and can simply 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. Once you moved your agents onto 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. Since 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. I’ve explained some of the more common considerations to make for the options below, in the context of the other features explained in this book.

What kind of tickets can this agent access?

This option is discussed in the Restricting Agent Access to Tickets section.

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" select 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 they are 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 not-so-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 such as your development team, finance, or marketing, 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 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 only add private comments (see the previous item in this list), which means that the agent is restricted to communicate 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, I think that agent tagging is a very useful feature that supports a great many useful functions in the product, and I would 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 only use the user’s profile link on a ticket as a channel to find out further information about the user.

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.

What can this agent do in forums?

On the Starter, Regular, and Plus plans, the option to create new categories and forums is given to Zendesk administrators only. This means that if you’re the manager of the public side of your Zendesk instance, on those plans you’ll need full administrator access to be able to manage the forums. The "What can this agent do in forums" option in Enterprise roles is my second favorite option in the list, because it allows you to delegate all of those forum privileges to a member of your team, without giving them administrative access to any other parts of Zendesk. The select list item to grant full forum administrative privileges to your agents is the last one, labeled "Add, edit, and reorder all forum content".

Can access organization-restricted forums

As you start to publish content in your forums, you might use the privacy features described in Forum Access Restrictions to restrict user access to certain forums. The reasons may be simply that the information is relevant only to a certain group of people, or it could be due to serious privacy or security concerns. If it’s the latter, you should consider these concerns before giving your agents access to all information in all forums with this option.

What can this agent do with reports?

Zendesk has a reporting feature that shows simple reports to agents and administrators. I like the idea of sharing 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. This option is also linked to the search and forum analytics features, which means that if you select the "Cannot view" option, agents don’t have access to any of these features.

What can this agent do with views/macros?

I’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 my 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, I 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 earlier in Dynamic Content for Text Translation, but I 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 when 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

Since 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 (for similar reasons as described above in the forum options), this option will support this goal.

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 users to manage your customer service workflow but would rather not give them full administrative access to your Zendesk instance, enabling this option for those users is a good compromise. By using this option to give workflow access to your users, it allows you and the other administrators to focus on more important features of your Zendesk instance such as security.

Can manage channels, and extensions

If you have some team members that are technical in nature 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 option above, 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 big difference between this process on the Enterprise plan and the other plans is that instead of scrolling down and choosing between end-user, agent, and administrator, on the Enterprise plan there are only two radio buttons near the top of the page: End-user and Agent. When you select the Agent option, you will be presented with a select list of the available roles, and once you’ve selected the role, you can click Create to create the new agent account.

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 there are important considerations around privacy to be made before enabling this setting.

The most common method used to create end-users is that the person will create their own account via the "sign up" link on the Zendesk web portal. 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 their 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. All of the end-user fields are the same as agents, with the exception of the Alias field, which 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

An 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.

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 their concern, then escalate their inquiry by sending an email, then call into your Voice phone number if they do not receive a timely response with the other channels. Since each channel is different, each new submission from the same customer will be a separate ticket with a separate ticket ID, and—if the user profile does not exist in Zendesk already—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 they 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 logging 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 together. When you merge these accounts, Zendesk has a concept of a source and a target user account (also called the winner and the loser, but the first phrasing sounds more polite). 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 in to 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, it’s possible for your agents to continue the support conversation using email.

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

To merge an end-user account, the first step is to find the user and view their 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. The top section represents the source user profile and the bottom represents the target user profile. An arrow is used to make this visually explanatory. To find the target user you’ll need to start typing their name and Zendesk will auto-predict the user based on a text search. Once you’ve selected the user, follow the prompts and the user accounts will be merged.

Figure 4-2. Screen to merge user accounts: source is on the top and target is on the bottom

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 log in to your Zendesk instance and create a ticket when they really shouldn’t. There are dozens of examples 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 their name to open their profile, then selecting the "Suspend access" option from the user actions 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 their 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, then select "Suspend access" from the user options menu. This will immediately suspend the user, which prevents them from logging in to Zendesk or submitting further tickets via any other channel.

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) and you are generally unaware of your customer list, or your list of customer organizations are 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 top-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 "Map email domains to organization". 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, I meet many customers who 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 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 on 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 only accessing their own tickets. 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 selecting the "Shared organization" checkbox when adding or editing the organization. This setting will immediately add a link to the navigation on the web portal of end-users, which is labeled as the name of their organization. An example of this is shown in Figure 4-3, where my profile is associated with the "Zendesk" organization on the CustomWare support portal. Clicking the "Zendesk" 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, I 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 their 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 "Has access to" to "Tickets from user’s organization" when adding or editing an end-user. 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. On the Enterprise plan the same principles apply, but the setting is a checkbox labeled "Allow access to tickets in end-user’s organization" when defining the agent roles.

ASSUMING A USER PROFILE

As you’re configuring your Zendesk instance, you may periodically need to understand the end-user and agent experience from their perspective. The feature named Assuming allows you to do this. This feature is currently available in the classic version of Zendesk, but is being retired from the product over the next 12 months and replaced with a feature that lets you only assume the identity only of an anonymous user. I’ve kept the old feature in here because Zendesk instances that use the old interface will still have the option available.

When you use this feature to assume another user’s profile, you will be logged in as that user (for most intents and purposes), except you’ll see a "revert identity" link in the page, which is your way of logging out of the assumed user’s profile and back into the administrator mode of your regular user account.

To assume a user’s profile, you’ll need to hover over the user’s account name in the People administration page, and click the "assume" link. This will immediately log you in as that user’s account. It’s also possible to assume an anonymous user’s account by clicking the "anonymous user" link in the boxes on the right-hand side of the screen. Anonymous users are those people who have not logged in to your Zendesk web portal, so you’ll be essentially viewing your instance from the perspective of a new visitor to your site.

WARNING

Any changes made in your Zendesk instance while assuming a user’s profile cannot be traced to the administrator who is assuming the profile, 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 they have no knowledge of the comments themselves.

Chapter 5. Channels

There are nine different ways in which a ticket can be added to Zendesk, each of which is defined as a Channel. Some of the channels, such as the web portal and email, are so common that almost every organization uses them. Other channels, such as Chat or the Feedback Tab, would probably be used more frequently if customers were aware of them. The Voice channel is the only channel that has an extra cost associated with it. The Facebook and Twitter channels are probably best suited to organizations with a certain social media awareness (although I’ll expand on this in the Twitter section). The Ticket Sharing channel is a advanced feature used to integrate several Zendesk systems, or Zendesk with other software platforms. The final channel, the Application Programming Interface (API), is a way of programmatically connecting Zendesk with other software systems, or adding new tickets into the system without direct user intervention. Technically speaking, tickets created using the mobile applications are created using the API, though I generally consider them in the same category as tickets created via the web portal.

According to a study, 58% of online retail customers prefer email as their medium for customer support, 22% prefer phone, and 20% prefer chat. These metrics might provide some useful context to what is most important to your customers, and further details of the study are available from the full infographic.

The reason that Zendesk has so many channels can be summarized as follows: Zendesk believes that you should be able to provide support to your customers in as many different ways as possible. Every person will be more comfortable contacting your customer service team using one specific channel, and providing that person with the option to use this channel is the first step in creating a great support experience. For this reason, I would encourage all Zendesk customers to leverage every possible channel. With a small amount of setup by administrators and education on behalf of your agents, you should be able to support all of these channels without any difficulty.

This chapter does not include the Web Portal channel, because most of the important concepts are already covered in the Web Portal Branding, Customizing the Zendesk URL and Internationalization sections of this book. There is a "Web portal" section inside the Channels administration page, but most of these options aren’t really relevant to the process of customers creating tickets using this channel. Most of the settings are related to the Forum options, and will be revisited in Chapter 9.

The Zendesk API channel is not covered in the current version of this book, though you can visit the Zendesk Developer Portal for more information about programmatically interfacing with your Zendesk instance.

Incoming Email

Email is probably the most frequently used channel in Zendesk, for the simple reason that most people are already familiar with it. The benefit of email to customers is that it’s easy for them to assume that the support@ prefix on your corporate domain name is going to connect with your support team somehow. This is also less effort for your customers than if they were to visit your website, navigate to the support section, and fill out the potentially extensive set of mandatory fields that you’ve added to your Zendesk instance (I’ll discuss why having too many Required Fields is not usually a good idea later in this book). The beauty of email is that it’s also universal, and a very effective bidirectional channel of communication. Zendesk relies on communicating with users via outgoing emails as much as it relies on email as an incoming communication channel.

Adding Incoming Email Addresses

When you create your Zendesk instance, you’ll select a subdomain that is relevant to your company name (see Customizing the Zendesk URL for more information). In my fictional company "Blue Skies", my subdomain is blueskies and my Zendesk URL is blueskies.zendesk.com. Immediately after creating this Zendesk instance, emails sent to the support@blueskies.zendesk.com email address will be created as new tickets in Zendesk. Also, emails sent to the sales@blueskies.zendesk.com email address will be created as tickets, and emails sent to members@blueskies.zendesk.com. It doesn’t matter which email prefix is used, since any email that is sent to the @blueskies.zendesk.com email address suffix (based on the domain name) will create a new ticket in Zendesk. The broad scope of incoming email addresses might sound like there is a risk of spam entering Zendesk, but the Suspended Tickets feature will take care of this for you.

If you elect to use several email addresses, such as support@blueskies.com, sales@blueskies.com and members@blueskies.com, your mail server administrators should set up three forwarding rules. The process to set up a custom domain with forwarding is described in Customizing the Email Domain. Each rule should forward one email address to the relevant email address inside Zendesk. If you leverage the ability to have multiple incoming email address, it also adds a lot of value as an automatic triage tool. An example of this is provided in the Trigger Examples later in this book.

TIP

Just like the web portal settings, most of the incoming email channel settings are changed outside of Zendesk, and the Email section inside the Channels administration page is dedicated mostly to outgoing emails instead.

Agent Forwarding

It’s not uncommon to find that some support agents provide such a high level of customer service that their customers seek out their direct email address and start emailing them directly to request support. Unfortunately, this causes a number of problems. The first problem is that support requests answered in email don’t have all of the benefits of requests submitted via the usual Zendesk channels. Another problem is that your superstar support agent might not be working on that day, so any requests sent directly to that agent via email will go unnoticed. Even if the agent is working on that day, she probably doesn’t want a barrage of emails sent to her, and would prefer to be delegated requests at the same rate as all other agents on the customer service team.

To make it as easy as possible to take the support conversation out of email and redirect it into Zendesk, the product has a feature named Agent forwarding. This feature allows an agent who receives a support request directly via email to forward that request (by clicking the Forward button in their email application) into Zendesk. Zendesk will receive the request and detect that the sender of this email is an agent. It will understand that the agent is submitting a ticket on behalf of a customer, and will start to read the contents of the email to find the name of the original sender. When it finds a section of text that says "From:", with a name and email address, it will create a new profile (or use an existing profile) for that user, and create the ticket as if it was submitted by them directly.

All that is required for an agent to use this feature is to forward emails to the standard incoming support email address. In the examples that I’ve been using, the agent would forward the email from their customer to support@blueskies.com. From an administrator’s perspective, this feature must be enabled before it can be used. By default, this setting is disabled in Zendesk. To enable it, open the Agents administration page and check the option to "Enable email forwarding".

Voice

The Zendesk Voice channel adds call center capabilities to your Zendesk instance, via the Twilio platform. The best part of this feature is that it’s seamlessly integrated into Zendesk, which means that incoming calls will be immediately matched to existing end-user accounts, and those end-users will be able to listen to a recording of the conversation after the call has ended. The support conversation can continue via comments and emails, and the full record of the initial conversation is easily available within the support request.

Voice is the only channel that has an additional cost in Zendesk, which is due to Zendesk’s partnering with Twilio, a separate paid offering, to provide the service. At the time of writing, the cost of this service is 1.6c per minute for incoming calls accepted via the browser, plus $1 per month for the phone number or $2 for a toll-free phone number. There are additional fees associated with other features such as forwarding to cell phones and landlines, and voicemail transcription to text. Full details of pricing are available from the Zendesk Voice pricing page.

Adding Phone Numbers

To get started with Zendesk Voice, you’ll need to set up a phone number on which to receive incoming calls. This phone number can be a local number with a specified area code for your location, or a national toll-free number in the US, Canada or the UK. You can also elect to have several phone numbers configured for Zendesk Voice, or phone numbers in many different countries. At the time of writing, Zendesk Voice supports phone numbers in the US, Canada and the UK, plus 12 other European countries. In the near future, Zendesk will add support for most countries around the world.

To add a phone number, open the Voice section inside the Channels administration page. Before any of the Voice administration tabs appear, you must create at least one phone number. The first step when creating a number is to select the country, then you will have the option of entering a few digits into the phone number search field, which will narrow the results to include phone numbers only that contain those digits. Some organizations like to select phone numbers in a certain regional area, or numbers that match existing phone number patterns for their organization. It’s also possible to select a number based on a text phrase.

PUBLISHING YOUR VOICE PHONE NUMBER

For some organizations, the choice of Zendesk Voice phone number does not matter very much, because they will be forwarding an existing phone number (often a national toll-free number) to the new number set up in Zendesk Voice. The immediate benefit of taking this route is that there’s no need to distribute a new phone number to your customers, because you can use your existing phone number. The potential downside is that there may be a cost for this service, which you’ll need to confirm with your phone provider.

If your existing support phone number has an answering service with a selection process like "Press 1 for Sales, 2 for Support", you should forward customers who press 2 to the new phone number you’ve set up inside Zendesk.

The other benefit of keeping your existing phone number and routing it to Zendesk is that it makes it easier to migrate away from Zendesk Voice at a later time if it becomes necessary. It’s currently possible to port your number in and out of Zendesk Voice if you’re in the US and Canada, but in other countries the Voice number is not currently transferrable, so having a phone number independent of any customer service tool gives you the most flexibility, similar to the way that your URL can be configured to be transferrable in Customizing the Zendesk URL.

After finding a number that you’re happy with, click "Choose number" then "Purchase this number" after reading the terms and conditions. Immediately after confirming the number, you can publish the new phone number to customers and they can call your customer service portal on this number. When a customer calls, Zendesk Voice uses a round-robin system to direct the call to the agent who has been waiting the longest to receive the call. The agent will have 30 seconds to accept the call before it is passed onto the next agent in line.

After creating at least one phone number, the Voice channel administration page will change to include several tabs, each of which serves a purpose for administration of the Voice channel. The Numbers tab will contain a list of the numbers added, and may be visited at any point to change the settings for your Voice phone numbers.

WARNING

It is not currently possible to forward incoming calls to certain agents directly, based on specified criteria. For example, a common request is that all calls to a Canadian Zendesk Voice phone number should be directed to agents in Canada, whereas calls to a UK phone number should be directed to support agents in the UK. It’s also not possible at this time to transfer incoming calls between agents, and it’s not possible to make outgoing calls. All of these features requests are on the radar of the Zendesk product management team.

Call Center Configuration

Once you’ve set up the incoming phone numbers for your Zendesk instance, you’ll also need to select the options to determine how the call center operates. Most of the options on the General Settings tab on the Voice channel administration page are intuitive, but I’ll focus on a couple of the options in this section.

Firstly, you’ll need to make a decision about how many callers should be waiting in the queue before redirecting new callers to voicemail. This option has a maximum of 10, so it’s impossible for you to determine that all callers, regardless of the length of the queue, should wait in line. The default option is 5. The other option associated with the queue size is the queue wait time. This option checks the length of the wait of each caller in the queue, and any caller who has exceeded the specified time limit will be forwarded to voicemail. The purpose of this option is to impose a hard limit on the level of frustration your users may experience waiting to speak to a customer service representative. The maximum wait allowed by Zendesk is 10 minutes and the default is 1 minute. As I explained in Adding Phone Numbers, incoming calls will alert an agent for exactly 30 seconds before being forwarded to the next waiting agent. Therefore, a maximum wait time of 1 minute will only give two support agents the opportunity to accept the call, but will relieve the frustration of the person calling your support team, because after 1 minute they will be redirected to voicemail and have an opportunity to leave a message to be contacted by a member of your support team.

The other important option on the Voice administration page is the "New live call recordings are public?" option. I really like the idea that calls to your customer service team are not only recorded for agents to review, but also recorded for the caller to review. I have a feeling that the level of transparency offered to customers by this option will be far more common in the future, and I encourage you to use it. The default option is that recordings are "public", meaning that end-users can listen to them. If you are uncomfortable with this option and prefer for your customers not to be able to hear the recordings of their calls, then you can set this option to "No", which means that the recordings are private. There is no option to disable recordings completely.

TIP

If you are an administrator and also the Account Owner for your Zendesk instance, you can configure a voicemail transcription service, which has an extra cost of 5c per minute (at the time of writing). It currently only supports the English language, and can be used on voicemails only (i.e., this feature does not transcribe all incoming calls). This feature is enabled automatically for English language instances using Zendesk Voice, but if you’d like to disable the feature, you can change the settings from the Subscription tab on the Account administration page.

Recording Greetings

The Zendesk Voice greeting is the first thing that customers who call your organization will hear, so make it professional and as friendly as possible. Fortunately, the Voice service has some default greetings, which feature a female voice and some soothing music that is played while customers are holding for a representative. Most of the time, these greetings will be sufficient. The voice has an American accent, so being from Australia myself I can understand that some customers would want to change the greetings. To change the greetings, open the Greetings tab in the Voice channel administration page.

There are two ways to submit a custom greeting using the administrator portal: upload a file in MP3 format, or instruct Zendesk Voice to call your phone to record your own voice as the new greeting. The MP3 option is probably the most reliable, and has a better chance of avoiding background noise. If you’re not able to create an MP3 or you’d like to get something set up quickly (but you’re not happy with the defaults), select the "Record using a phone" option and prepare your best telephone operator voice, because Zendesk Voice will call you immediately and prompt you to record the greeting.

For legal reasons, the "Available agents greeting" should always mention to the customer that the call will be recorded. The default greeting states the following message, and if you are going to record your own greeting, it’s usually best to emulate this spiel:

"Please hold while we find an available support agent to assist you. Your call may be recorded for monitoring purposes. If you would like to leave a voicemail, you may dial 1 at any time."

Call Activity Dashboard

The Call Activity Dashboard is a tool that allows administrators to view metrics on incoming calls on Zendesk Voice. It also allows administrators to monitor the activity of agents using Zendesk Voice. This dashboard can be found by opening the "Call Activity" tab on the Voice administration page, and most of the values on this page, such as "Calls Waiting" and "Average Wait Time", are intuitive. Aside from these metrics, it’s also useful to scroll down this page to find out how many of your agents are actively marking themselves as being available to take calls. You can also find a report of the total number of hours in the past 24 hours that agents have marked themselves as available to take calls. If you find that your agents are not marking themselves as available as often as you’d like, this dashboard can be used as a reminder to your agents about the benefits of providing phone support to customers.

The status options listed on the call activity dashboard are:

Available

Agent has marked himself as being available to take calls.

Not Available

Agent is not online, or has not marked himself as available to take calls.

On Call

Agent is currently on a support call.

Wrap Up

Agent has just finished a call, and is making notes on the support ticket before taking more calls.

Feedback Tab

The Feedback Tab is probably my personal favorite incoming channel. It takes the same form that users complete to submit a support ticket on your web portal, and adds the form to any other website of your choice. It’s a way of bringing the support link directly to your customers. Not only that, but it also allows customers to submit a ticket in the context of something else that they’re doing on your website, then continue browsing the website after the request has been submitted. The alternative methods of submitting a ticket—such as sending an email or visiting your support web portal—would almost certainly take the customer out of the context of the task they were already performing.

An example use of a Feedback Tab is on the Zendesk University website. This site lists the details of training courses, and the schedule on which they are delivered. I’ve added a Feedback Tab named "Questions" to the left hand side of every page on the website. If a customer is browsing the site and has a question about one of the courses, or the schedule, they can click the "Questions" button, enter in a few personal details and the description of their inquiry, then submit the form. Afterward, they’ll be immediately returned to the page on the Zendesk University website that they were viewing before submitting the inquiry. From the Zendesk side, I will receive a new ticket in my Zendesk instance, with a note that indicates the specific web page from where the customer submitted the question. This gives me some context for the inquiry, and the members of my team can answer the ticket like any other support ticket in our Zendesk instance.

If your organization has leveraged the Forums feature in Zendesk (see Chapter 9), the other great feature about the Feedback Tab is that it can provide self-service support to your customers. Later in the book I explain the Ticket Deflection feature in Zendesk, which checks the keywords typed by the user when submitting a support request, and suggests topics from the forums that might be related. Ideally, one of the topics would answer the customer’s question and the customer will no longer need to submit their support request and wait for a response. The options to configure this aspect of the Feedback Tab will be explained shortly, and the feature in general is only valuable if you’re using forums in Zendesk.

WARNING

If you have disabled public creation of user profiles by following the instructions in Public Creation of User Profiles, the Feedback Tab channel cannot be used. The technical reason is that the Feedback Tab relies on customers being able to create a user profile while submitting a ticket, but the browser cookie used to recognize a logged-in user in Zendesk cannot be accessed by an external website for security reasons.

Creating a New Feedback Tab

In order to get this feature working, visit the Feedback Tab section on the Channels administration page. A form on this page asks for the parameters of the Feedback Tab, including the name, color, positioning, and some other options. The option "Knowledge Base Search and Topic Suggestions" is probably the most important one on this page, because it will determine the customer’s workflow to submit a ticket. If you’re actively using the Forums feature inside Zendesk and you feel like your forum articles should be the first port of call for your customers, you should enable the "Enable Topic Suggestions & Knowledge Base Search" option. This option will match keywords in the customer’s question with keywords in forum articles, and suggest a possible answer based on the likelihood of a match. The process is very similar to Ticket Deflection, described in the forums section later in this book. If you don’t have relevant articles in your forum, no results will be displayed and the support ticket can be submitted from the Feedback Tab.

Another option on this page is whether the Chatting feature is enabled or disabled on the Feedback Tab. Allowing customers to chat from a Feedback Tab is a good idea if you’re actively using chat, because it allows them to get immediate assistance and answers.

It’s also important that you indicate whether you’d like for your custom fields to be displayed in the Feedback Tab. The option is labeled "Display custom fields to end-users?" and the default is "No", but my recommendation is to set this to "Yes". My logic is simple - if you’re asking users to complete a certain set of custom field when they create a ticket on your web portal, there’s no reason that you shouldn’t ask for the same information when a ticket is submitted from a different channel. Since I consider the Feedback Tab to be an extension of your web portal that you can add to your website, I like to keep the user experience the same, so I always enable this option. The only caveat is that if you’ve created a cascading list of options in a select list as described in Custom Fields, the menu will be flattened and shown to the user with the :: syntax included in each option. It’s not really a big problem, it just looks a little strange.

Before you submit the Feedback Tab configuration form, be sure to visit the second tab, named Advanced Customization, and confirm whether you want to change any of the words on your Feedback Tab. You can also use Cascading Stylesheet (CSS) technology to customize the appearance of your Feedback Tab. This is typically useful if you’d like the format of your Feedback Tab to match the look-and-feel of your existing website.

An example of an open Feedback Tab—based on the default Zendesk settings—is shown in Figure 5-1.

Figure 5-1. Default Feedback Tab shown to the customer

WARNING

It’s not currently possible for users to submit attachments with tickets submitted via the Feedback Tab, but those users can always visit your web portal directly to submit a ticket, and if the attachments is enabled, they can submit attachments with that ticket.

Publishing a Feedback Tab

Once you’ve filled out the form to create your Feedback Tab, you can click "Preview & grab code snippet", and Zendesk will take you to another page that has a small piece of JavaScript code, similar to the code below:

<script type="text/javascript"

src="//assets.zendesk.com/external/zenbox/v2.5/zenbox.js"></script>

<style type="text/css" media="screen, projection">

@import url(//assets.zendesk.com/external/zenbox/v2.5/zenbox.css);

</style>

<script type="text/javascript">

if (typeof(Zenbox) !== "undefined") {

Zenbox.init({

dropboxID:   "20079071",

url:         "https://yourcompanyname.zendesk.com",

tabID:       "Support",

tabColor:    "black",

tabPosition: "Left"

});

}

</script>

You don’t need to be an HTML or JavaScript expert to use the Feedback Tab. You just need to copy-and-paste this JavaScript into an email addressed to your webmaster, with instructions to add the JavaScript immediately before the </body> tag on the website where you’d like the Feedback Tab to appear. They’ll do the rest, and the next time you visit your website, you’ll find a button similar to the one on university.zendesk.com.

Managing Existing Feedback Tabs

TIP

This feature may not be supported by Zendesk and is not documented in the official user guide, so please be advised before you use it!

Using the administrator portal, it’s not currently possible to find the Feedback Tabs that you’ve previously defined, and edit their settings. Fortunately if you’re savvy and can follow the instructions below, it’s not difficult to do this manually.

After completing the process defined in Creating a New Feedback Tab, a new Feedback Tab will be created with a unique ID. If you open the Feedback Tab administration section in Zendesk again tomorrow, you’ll find that the settings have been returned to the defaults, and you’ll need to customize them again and submit the form to get a new Feedback Tab ID. The fact that each new submission creates a new tab is a good thing, because it allows you to create many different Feedback Tabs with many different settings. You might like to have a whole set of Feedback Tabs depending on the language selection of visitors to your website, or many Feedback Tabs with different labels on the fields presented to the user.

Of course, if you want to just change a single option on an existing Feedback Tab, it would be a lot of effort to reconfigure all options entirely just to achieve this. If you’ve ever created or edited a Feedback Tab, you may have noticed that the URL contains the unique ID of that Tab. If you visit the URL /account/dropboxes/NNNNNNNN/edit on your Zendesk instance, replacing NNNNNNNN with the unique ID of your own Feedback Tab, you’ll be able to update the existing Feedback Tab settings by submitting the form again. To find this ID, check the source code of your website hosting the existing Feedback Tab, and look for the number following dropboxID:.

At some point in the future, it may be possible to use the web interface to edit existing Feedback Tabs, and Zendesk may change the behavior so that it’s not possible to perform the steps listed in this section. For the moment though, this is a neat trick that will save you time and effort when editing existing Tabs.

Chatting

The ability to chat in Zendesk is a feature that provides real-time support to your customers, without adding a significant burden to your agents. It is the only channel that is not available on the Starter plan. The common misconception about the chat channel is that if it’s enabled, you must chain your agents to their desks so they are available to your customers every minute of the day. This is not really an accurate assumption, because Zendesk deals very well with situations when no agents are available to accept a chat request. If this occurs, the customer is simply instructed that an agent is not currently available to answer their request, and is prompted to submit a ticket using the usual method.

Setting Up Chat

The chat channel is disabled by default in Zendesk. If you want to use it, enable it from the Chat section of the Channels administration page. The first option on the Chat administration page is the option to enable or disable chat entirely. On this page you’ll also have the option to modify the welcome message, if you’d like to welcome your customers with something other than the default, which is:

Hi there. How can I help today?

It’s rare to change the chat message because the default is so generic, but I did once train one very enthusiastic organization that changed the chat message to include several smiley faces and exclamation marks.

The other option on this page, "Maximum chat requests per agent", has a dual purpose. The first purpose is to prevent an agent from trying to accept more chats than they can handle. This will prevent context switching that might result in incorrect information being provided to a customer. The other purpose, and probably the most important, is to identify the maximum number of requests able to be handled in your entire Zendesk instance. For example, if you have set the maximum chat requests to 2 per agent, and 5 agents have signed in to chat, your Zendesk instance can handle 10 active chat conversations in parallel. Once your agents reach the total limit, the "chat about this ticket" link will disappear entirely from the end-users' ticket screen. This is a simple way to manage expectations with your customers.

Chatting from a Ticket vs a Feedback Tab

When I refer to the chat function in Zendesk, I’m really talking about two different features. The first feature is the "chat about my ticket" function. This function is enabled only if the option is selected in the Chat administration page. When this feature is enabled, a link that says "chat about my ticket" will be added to the top of every comment box viewed by an end-user, as long as there are agents who are currently available to chat. It basically gives customers the ability to quickly seek help on their ticket, while they’re already in the context of the support request. This chat function is used exclusively for existing tickets.

The other chat function is used exclusively to create new tickets, and is available only from the Feedback Tab. As noted in Feedback Tab, the Feedback Tab—and implicitly the ability for customers to chat from the Feedback Tab—will only be available if you’d enabled public creation of user profiles on your Zendesk instance. See Public Creation of User Profiles for details on how to do this. If you have chat enabled in your Zendesk instance, you’ll see the option "End-users can chat with agents?" on the configuration form to create a Feedback Tab. If this is set to Yes, the Feedback Tab workflow will include a new step (shown in Figure 5-2) that asks the user whether they would like to chat immediately or submit a new ticket instead. If the customer elects to chat with an agent, the resulting chat conversation will be created as a new ticket, and the customer will have access to the entire conversation afterward.

Figure 5-2. A Feedback Tab with the option enabled to chat or submit a ticket

In the Setting Up Chat topic, I explained that the chat function disappears from the end-user interface when no agents are currently available to chat. The Feedback Tab is quite different: even if there are no agents available, the chat option will always be displayed in a Feedback Tab if the chat option is enabled for that Feedback Tab. The reason is that Zendesk will not make a query back to the Zendesk servers when a Feedback Tab is opened to validate that an agent is available to chat. It is only after the user selects to chat with an agent that the Feedback Tab will check agent availability, then politely inform the customer if an agent is not available. If the chat cannot proceed, the user is always encouraged to complete the process of submitting their ticket to your customer service team using the standard Feedback Tab form.

TIP

Many customers have asked me why there is no chat function on its own in Zendesk. In other words, why is chatting always embedded in the Feedback Tab? The answer is simple. There will rarely be a situation in which your customers will want to chat with an agent, but then not want to submit a ticket if no agents aren’t available. This is the reason that Zendesk keeps the chat feature inside the Feedback Tab. Thus, the Feedback Tab essentially has a dual purpose if chat is enabled.

Twitter

I mentioned earlier in this chapter that Twitter is a channel suited for organizations that have an active social media presence. Actually, this does a small disservice to the Twitter channel. A more accurate description would be to say that the Twitter channel is useful for companies whose customers have a social media presence. It doesn’t matter quite as much whether your own company is on Twitter, because the purpose of the Twitter channel is to find what your customers are talking about, and if they’re talking about your organization, you can take those conversations and turn them into actionable tickets inside your Zendesk instance.

According to Micah Solomon, "Twitter and other social media tools do have the power to bring about regime change in the business world". According a study of the use of social media for support, 62% of all consumers have used social media for customer service issues (see the full infographic). Another study on Twitter found that 19% of all consumers use Twitter on a monthly basis for the specific purpose of seeking customer service (the full infographic has more details). A study by ISMDealers identified that 58% of the people who tweeted about a bad customer service issue expected a response from the target company, but according to another study, only 13% of complaints received a response.

The implication is clear: Twitter should be considered a key piece in the customer service strategy adopted by any organization.

TIP

Before getting started, here’s a piece of trivia that usually makes people laugh: when you convert a "tweet" into a "ticket" in Zendesk, it’s called a "twicket". It’s funny, but also serious in a way. Twickets are a big deal, because comments added to twickets will be automatically tweeted back to the whole world. For a support agent who isn’t expecting this, it can be quite a surprise when they write something perhaps not suited for the Twittersphere. It’s important that your agents are aware of the difference between a ticket and a twicket. It’s more than a "w".

Selecting a Twitter Handle for Zendesk

Before you can start using Twitter inside Zendesk, you must create a Twitter handle via the Twitter website. Most organizations have a corporate Twitter handle already, which is probably named after their brand. For example, Wells Fargo Bank in America has the Twitter handle @WellsFargo. Generally, I don’t recommend using this corporate Twitter handle to respond to tweets from Zendesk. There are a few reasons for this:

Risk of Mistakes

Your biggest risk on Twitter (whether or not you’re using Zendesk) is that someone will post an inappropriate tweet and the whole world will read it. In Zendesk, where there are many ways in which to post information to the world via Twitter, this risk increases.

Focus

Should the focus of your corporate Twitter handle be on exciting news about your organization and links to useful information for your customers, or individual responses to support requests? Most people would say the former. While you have the podium, I advise you to use it for the highest valued purpose.

Noise Pollution

If you’re offering support to your customers via Twitter, you might find that your Twitter handle starts to contain so many support requests that it’s common for customers to tune out. It’s never a good thing if your customers tune out of your primary Twitter presence entirely.

For this reason, Wells Fargo Bank also created the @Ask_WellsFargo Twitter handle. In fact, I discovered this handle in 2009 when they responded to a tweet that I posted to say that I was happy with the customer service at my local bank branch. The memory of that customer service incident on Twitter is etched in my memory, which is an example of the potential value of using the Twitter channel to support your customers.

On the other side of the coin, it’s worth noting that Zendesk itself uses their corporate Twitter handle @Zendesk for all responses related to support requests. That’s a conscious decision that they’ve made by weighing up the factors that I explained.

Authorizing a Twitter Handle

To authorize a Twitter handle, visit the Twitter section of the Channels administration page in Zendesk. The "Twitter accounts" tab allows you authorize Zendesk access to Twitter accounts. If you have multiple corporate identities and would like to give your agents the option to tweet from a different one occasionally, you can set up multiple handles. Otherwise, one authorized Twitter handle is usually enough. Authorization of the Twitter handle uses the industry standard OAuth authentication protocol, which means that even when you authorize the Twitter account, Zendesk will never have access to your Twitter password. The list of permissions requested by Twitter are shown in Figure 5-3.

Figure 5-3. Authentication screen for Twitter

After you authorize a Twitter handle and you are returned to the Zendesk administration portal, click the "edit" link for that handle. There are four settings on this page that are important for you to configure immediately. The Primary option will determine whether this is the account from which all Zendesk tweets should originate. The "Capture incoming direct messages as tickets" option is useful only if you expect your customers to Direct Message (DM) you on Twitter. The "Track favorites" option simply means that all favorited tweets on Twitter will be automatically added as new tickets in Zendesk.

WARNING

The Track favorites option is enabled by default, and I usually recommend that you disable it, unless you’re sure that you’ll be using the favorites feature of Twitter for this purpose. If your social media team are using favorites in Twitter for another purpose, this option will cause twickets to be created unnecessarily.

Finally, the "Capture public mentions as tickets" option can be used to ensure that all mentions of the authorized Twitter handle in tweets are automatically converted into twickets. The decision whether to enable this option should take two considerations into account:

Percentage of complaints

If you’re a company with such a strong reputation that the vast majority of your customers who mention your organization on Twitter are praising you, it’s not going to be worth your time to have all of those tweets converted into tickets automatically. You’ll spend more time closing out unnecessary twickets than replying to the valid ones.

Volume

If you find that, on average, you only get 50 mentions of your Twitter handle per day, it might be OK to convert all of them into twickets automatically and then triage them as necessary. If you find that you get 5,000 mentions of your Twitter handle per day, it might be a lot less manageable. Make the decision whether to process your tweets automatically or manually based on the number of tweets that you can reasonably process in a day.

Linking in Tweets

When one of your agents adds a comment to a twicket in Zendesk, they will have the option to tweet that comment to the requester, and continue the conversation. The agent may like to continue the conversation on Twitter—in which case they would choose not to provide a link to the ticket in Zendesk—or they might like to encourage the requester to log in to Zendesk to continue the conversation and solve the support request.

As an administrator, you have some control over the way that links in your outgoing tweets are configured. By default, Zendesk uses the bit.ly URL shortening service to shorten the full URL of the Zendesk ticket into a shortened URL. There are many URL shortening services that allow you to measure metrics on the number of visitors to your links, and of this list, Zendesk supports bit.ly, ow.ly, and is.gd. To use one of these services, you must first sign up with an account on that service, then select the correct option from the list in Zendesk and enter your relevant credentials for that service. I do recommend that you enable one of these URL shortening services, because most of them measure the number of visitors that click the relevant links, which helps you to understand the traction that you’re getting with your customer service tweets. You should create a dedicated account with the URL shortening service for this purpose, otherwise the overall visitor metrics may be polluted by other shortened URLs not related to Zendesk.

If you prefer to tweet to customers but not to continue the conversations inside Zendesk, you can disable the "Append ticket links to outgoing tweets?" option entirely. Alternatively, you can give agents the ability to make this decision on a case-by-case basis. There is a checkbox labeled "Always include shortened ticket URL" on the Twitter settings page, but I think that this option is confusing. What it’s essentially saying is "Do you want to give agents the option of whether to include a link to the ticket in the tweet?". I like this option because it gives control to the agent. If your customer tweets, "I can’t log in to your website", the proper agent response is to reply to the twicket and include a link to continue the conversation in Zendesk. If another customer tweets, "The colors on your website are too dark", an agent can respond to notify the person that they’ve received the comment, but elect not to provide a link to continue the conversation, which does not necessarily warrant further dialog inside Zendesk.

TIP

I highly recommend that your agents take the Twitter conversation into the Zendesk web portal as quickly as possible, and solve the support ticket more privately. 140 characters is very restrictive when trying to communicate on a support request, but the bigger problem is that Twitter is a public platform, and it’s often difficult to solve a support request without providing at least some personal information. There are also other benefits of moving the conversation into the Zendesk web portal, such as reducing the noise on your Twitter stream, preserving the conversation for future, and attaching files more conveniently.

Saved Searches

Authorizing a Twitter handle with Zendesk and selecting the options listed in the previous sections is really just the first step to using Twitter. Unless you’ve selected the option to automatically capture public mentions as tickets, no twickets will be created in your Zendesk instance. If you’d like to have more control over the twicket creation process, you will need to create Twitter Saved Searches. Saved searches allow administrators to define specific keywords that will be monitored by agents in Zendesk. There are certain keywords that I always encourage Zendesk administrators to monitor:

Your corporate Twitter handle(s)

In the Wells Fargo example, this rule would include @WellsFargo and @Ask_WellsFargo (two separate saved searches). The purpose of these searches is to find all users who are tweeting something directly to you. I’ll tell you a trick for this one. If you create a search for @WellsFargo, you’ll see all tweets that mention this Twitter handle, but also all tweets from this Twitter handle in the search results. To avoid this, you can write your search query as "to:WellsFargo", without the quotation marks (and replacing "WellsFargo" with your corporate Twitter handle). This syntax in Twitter will include only tweets to your organization and exclude the ones from it, and you’ll have slightly fewer tweets to read before finding the ones you care about.

Your brand names

Sometimes customers don’t tweet to @WellsFargo, but tweet or mention "Wells Fargo" instead. It’s a good idea to create a separate saved search for your company name, and even common misspellings of your company name. All of these saved searches will increase the likelihood that you’ll catch a comment from a customer who is expressing some sort of dissatisfaction with your company, which is an opportunity for you to satisfy the customer with the help of your excellent customer service team.

Once you’ve created these saved searches, they will appear on the dashboard of every agent who is authorized to view them. Agents can click on the tweets listed in the search results, then convert the tweets to twickets and start the conversation with the customer.

Facebook

Unlike Twitter, the Facebook channel is really useful only if you have an active social presence on Facebook. The reason is that this integration relies on your organization having a Facebook "page", which is similar to a Facebook personal profile, but is set up for a company or brand instead of a person. This integration will allow you to automatically take all posts on the timeline of the Facebook page, or messages sent privately to the Facebook page, and create them as new tickets inside Zendesk. Your agents will be able to respond to the tickets, and comments will be automatically posted back to the Facebook timeline, or added to the private message conversation.

An interesting Facebook metric appears in a study by ISMDealers, which finds that "46% of Facebook users say they would talk about or recommend a product on Facebook." This means that if you’re not leveraging this channel in Zendesk, there is a risk that you’re missing a lot of conversations about your product or brand. Some of these people posting might be open to a conversation with your customer service team, improving the social perception of your organization.

TIP

When you take a Facebook post and create a ticket, it’s not called a "ficket" for obvious reasons.

Authorizing the App

To set up the Facebook channel, visit the Facebook section of the Channels administration page. From this page, click the "Add your first Facebook page" link. Unfortunately, there’s one aspect of the Facebook integration that is a little bit unusual. The way that Facebook works is that in order to log in to Facebook, you must have a personal profile. Facebook pages can exist on their own, but the way that Zendesk accesses a Facebook page is by going through an authorized Facebook personal profile. This means that the user with administrative access to the relevant Facebook page will need to enter their Facebook username and password and add the app (shown in Figure 5-4) then authorize all permissions for the Facebook app (shown in Figure 5-5) to access the Facebook page on their behalf. The good news is that this authorization needs to be done only once.

Figure 5-4. Facebook confirmation to add the Zendesk app

Figure 5-5. Facebook confirmation to authorize permissions for the app

Once that process is complete and the Zendesk app is authorized by a Facebook user, Zendesk is able to access the Facebook pages to which that user has administrative access.

Monitoring Posts and Messages

Users on the Regular, Plus, and Enterprise plans are allowed to authorize two Facebook Pages in Zendesk, and users on the Starter plan can authorize one Page only.

After you’ve authorized the app, Zendesk will list the Facebook pages to which the authorized user has administrative access. For each one of these pages, the list of options shown in Figure 5-6 will be presented, with the default selections shown in the figure. If you’d like to hit the ground running and import recent activity in the past week from your Facebook page, select the third option, "Import recent activity". Once you’ve selected your options, click the Add button. The page will be linked immediately and new posts will be created as tickets. Once this process is complete, the Facebook page will never need to be authorized within Zendesk again.

Figure 5-6. Options when linking a Facebook page for monitoring

You can change options later. For example, you might discover that most of the posts on the timeline of the Facebook page are supportive and not related to support, but that the Facebook messages are predominantly used for customer service inquiries. To change these settings, navigate to the Facebook channel administration page and click the "edit" link beside the name of the page.

If you’re collecting wall posts from your Facebook page, there is an option for you to "Include Wall posts authored by the Page". This option will determine whether posts that were authored by the page itself should be copied into Zendesk as new tickets. At first glance, it might seem like this option should be disabled, since the posts made by members of your own team will never be requests for support. Actually, it’s the comments on this post that are important to capture, and enabling this option will allow you to do this. So I do recommend that you leave this option enabled, which is the default.

WARNING

It’s possible to selectively convert tweets into tickets using Twitter, but currently it’s not possible to selectively take posts from the timeline of the Facebook page and add them into Zendesk. The simple reason for the difference is that the Facebook API is a lot more restrictive than the Twitter API, and doesn’t have the same mechanisms that Zendesk uses for the Twitter functionality. The Facebook integration currently draws every post from the timeline into Zendesk, regardless of the subject matter.

In the Default Automations section later in the book I describe an automation that will automatically close tickets from Twitter and Facebook one day after the ticket is solved, and I also explain the reasons why this is important.

EIGHT REASONS TO MONITOR SOCIAL MEDIA

Not every organization currently has a social media presence, and not every organization needs one. But social media is growing, and if your customers are on social media, it’s something that you should address in your customer service program. I’ve identified the following eight reasons for building a social media customer service program:

People are doing it

The fact that 62% of all consumers have used social media for customer service issues suggests that Twitter and Facebook are no longer fringe technologies for communication. Regardless of whether you have enabled the Zendesk Twitter integration, your customers will probably still be tweeting about your product, brand, or service. There’s a lot of value in recognizing that those tweets exist and starting to do something about it.

Low barrer to entry

Throughout this book I’ve mentioned the relative ease of submitting tickets using the various channels. I mentioned that email tends to be a customer favorite, because most people are already familiar with email. Increasingly, customers are also becoming more comfortable communicating via Twitter and Facebook. In the very near future, this may be the preferred communication method for people who need to voice a concern with your company, rather than email. The risk with social media is that when customers express themselves using this channel, other people can also read the conversation.

Opportunity for positive publicity

Most of the time, you’ll solve support requests quietly and privately. This is because the customer service process is typically private. When social media is thrown into the mix, the conversation becomes more public. You can take advantage of this fact and demonstrate to your customers that you are speaking to your customers positively and supportively. As an example, I bet that if I went to @Ask_WellsFargo on Twitter right now, I’d be able to see Wells Fargo Bank offering proactive assistance to their customers. This gives me a very positive impression of the bank.

Social media is loud

This is the other edge of the social media sword. I mentioned in the previous item that Twitter gives you an opportunity for positive publicity, which is true, but it also gives you an opportunity for bad publicity. Unless you quickly defuse negative customer service situations with your customers, a simple tweet could very easily escalate into an embarrassing situation for your brand.

Proactively solve customer complaints

Not every customer who tweets to your organization expects a response. A great example of this occurred in 2011, with what has been described as "the greatest customer service story ever told". Peter Shankman (a well known social media expert) was having a busy day and missed dinner at his favorite steakhouse, so casually tweeted to Morton’s Steakhouse to ask them to meet him with a steak when he landed a few hours later. At the time, Peter wasn’t expecting a response. When he landed, he was greeted by a member of the Morton’s Steakhouse wait staff, who had bought him a steak. Obviously a member of the Morton’s customer service team had seen Peter’s tweet, and realized the potential to satisfy one of their customers. The amount of publicity that Morton’s received from this event was huge, because Peter Shankman blogged about the incident on his website. This is a great example that shows the opportunity you have when customers tweet to your organization. I can’t guarantee that Morton’s are using Zendesk to provide customer service, but if you implement the Twitter integration in your Zendesk instance, you are certainly one step closer to this kind of experience.

Reactively response to customer concerns

According to a study that I mentioned earlier, 58% of the people that tweet a complaint expect a response from that company. The sheer volume of this number—which is the majority of customers—reiterates the importance of having a social media presence on Twitter. A tweet that goes unnoticed could lead to customer dissatisfaction, and a quiet departure from the use of your product or service.

Announcements can be broadcast

As you start to build your social media customer service presence using Zendesk, you’ll find that the number of followers on your Twitter handle also increases. A side benefit of having these additional followers is that when your company needs to make an important announcement, it becomes very easy to communicate with a large number of people. Nurturing and building the size of your community, whether you’re on social media or not, is a key pillar in the process of providing outstanding customer service.

Distribution of ideas

If one of your customers tweeted to you, "I can’t log in to your website" and you reply—via Zendesk—with the tweet, "We have a list of possible causes for this issue in our support forums", this has the obvious benefit that the recipient will get the message. It will also have a secondary benefit, which is that other people who are monitoring your Twitter channel will see the same message. These people may be customers or members of your community, or they may be your own team members. The information in your tweet may come to mind when another person needs the same information, and they will know the answer to their question without submitting a support ticket. As your social media presence builds, people will start to subscribe to your channels just for these tips and tricks, which builds your community and increases your ability to broadcast important messages, as described in the previous point.

Ticket Sharing

In 2011, a few organizations got together and launched an initiative named Networked Help Desk. The goal of the project was to create a framework for better communication between various software tools, particularly the tools in the customer service space. Zendesk is one of the founding members of Networked Help Desk, and one of the first tangible benefits of the new framework was the Ticket Sharing feature released inside Zendesk. In a nutshell, this feature allows your organization to seamlessly, transparently and automatically synchronize support tickets with other systems. This is the ninth and final channel in Zendesk.

A very common use case for this feature is when your organization is using Zendesk, and your partners, customers, and/or vendors are also using the tool. Using ticket sharing, there is no need to take customer service conversations out of Zendesk and into email when your organization is working with another company. This feature is offered on all Zendesk plans. It supports non-Zendesk applications (such as Atlassian JIRA) and custom applications as well, but in this book I will focus on Zendesk-to-Zendesk integrations.

To get started with this feature, you’ll need to open the "Ticket sharing" tab on the Tickets administration page. The two different types of agreement can be summarized as follows:

Sending agreement

This is when your organizations would like to send tickets to another Zendesk instance. For example, if you are a software company and you have a vendor that writes integrations for you, you might use this type of agreement to send tickets over to your vendor when a bug with an integration is reported. On the vendor’s side, they’ll receive a new ticket with a message saying that it has been shared from your instance.

Receiving agreement

This is an agreement that says that you’ve authorized another Zendesk instance to share tickets with your Zendesk instance, meaning that another company can create tickets in your Zendesk instance via ticket sharing. For example, if you’re the vendor writing a software integration and the other company is the provider, this type of agreement would allow the other company to share bug reports with you.

TIP

Sending and agreements are not automatically reciprocated. If you request to send tickets to another company and they accept the invite, that will mean that you can send tickets to them, and that the contents of those tickets will be synchronized, but it does not automatically mean that they can send new tickets back to you. If you’d like a reciprocated relationship, both parties are required to create a new sending agreement, originating from each Zendesk instance. Setting up a reciprocal arrangement is not necessary in all situations, though.

TICKET SHARING EXAMPLE

Another good example of this feature is the ticket sharing agreement that I have configured between the Zendesk Support instance and my Zendesk University instance. Since the support team and the training team are different departments at Zendesk, we each have our own Zendesk instances. When the support team receives a new ticket saying "I’d like to request a custom training time", they click the button to share with my Zendesk instance and a new ticket is created on my side. As my team answers the inquiry, the comments and status are updated over on the Zendesk Support instance automatically. Alternatively, when I receive a ticket on my Zendesk University instance that says "I can’t log in to Zendesk", I’ll share this with the Zendesk Support team. When the support team answers the inquiry, the synchronization will automatically update the ticket on my side, and the status will be set to solved when the ticket is complete.

From the ticket sharing tab, you’ll need to click the "add sharing invite" link and select Zendesk. This is the process to create a sending agreement, which will allow your Zendesk instance to send tickets to another instance. There are four options on this page:

Partner Zendesk domain

This is the subdomain selected by the partner when they set up their Zendesk instance. They’ll need to tell you this domain so you can set it up on your side.

Comment and status permissions

The question to answer here is: do you want to allow your partner company to be able to make comments that are going to be visible to your customers, and to update the status of your tickets? This is an important decision, because there might be a situation where your partner company should not communicate with your customers directly. If this is the case, you would set this option to only allow private comments. The status field is linked to the comment visibility in this option because the use cases to update each of these fields are highly coupled. In other words, if give your partner control to publish public comments, you are effectively giving them ownership over the ticket, so they should also be able to solve the ticket. If you’ve restricted the partner to only making private comments, then it’s logical that you would want to control the status of the ticket on your side. By default, all comments and statuses are shared in ticket sharing agreements.

Tag synchronization

Synchronization of tags means that any tags that are added to the ticket on the partner side will also be added to the ticket on your side, and vice versa. This would usually not be an problem, except that tags can also have an impact on custom fields. If a tag is shared and it matches a tag that you’ve assigned to one of the select list options in your custom field, that option will automatically (and probably erroneously) be selected in your ticket. This can cause problems if you have a strict business process or business rules connected to the tags, so it might be safest to keep tag synchronization disabled in this situation. If your business process is less closely tied to tags, I would recommend that you enable synchronization of tags, just to provide better communication of information between tickets. By default, tags are not shared in ticket sharing agreements.

Allow the syncing of custom fields

If you’re working very closely with your partner and have a strong knowledge of their custom fields—or even better—access to configure their Zendesk instance, you might use this feature. It adds a new level of synchronization to the tickets in both instances by automatically ensuring that all custom field values are kept the same. If the Zendesk instance of the other company is relatively unknown, though, it would be risky to enable this feature. This option is disabled by default on new ticket sharing agreements.

After you’ve selected your options, click the "Send invite" button. This will send an email to all administrators of the other Zendesk instance, asking them to confirm the sharing invitation. One of those administrators must confirm the invitation before tickets can be shared, but after it has been accepted, you can start sharing tickets immediately. Ticket sharing is done manually by agents by selecting the Zendesk instance from the select list beneath "Share ticket with" on the ticket summary screen.

After a ticket is shared, it’s not possible for you to find the ticket ID of tickets on both sides of the sharing agreement, and the simple reason for this is privacy. Since it’s impossible to know the relationship between your company and the other company with whom you are sharing your tickets, Zendesk does not provide any information about the ticket on the other company’s Zendesk instance, aside from the fact that the ticket is shared, and the standard ticket details such as fields, and the names of the people who have added comments.

TIP

If you’re using the Enterprise plan, it’s possible for you to automate the process of sharing tickets in your Triggers. This can be useful when you want to automatically send tickets to your partners and vendors. For example, on the Enterprise plan you might add a trigger that finds all tickets with the phrase "integration bug" in the subject line, and automatically shares those tickets with the Zendesk instance of your software development vendor. It saves a manual triage process on behalf of the agent who would share the ticket with the vendor manually anyway.

Chapter 6. Fields and Data Capture

When your customers submit a support ticket, they’ll use Fields to describe their problem. For example, the Subject field describes the problem briefly, and the Description field provides further details that are used to solve the request. When the agent receives the ticket, they’ll want to judge the severity, then forward it to the right people to solve it. This will involve use of the Priority, Group and Assignee fields. Sometimes, the standard fields in Zendesk aren’t sufficient to describe the issue succinctly, or there is a situation where a customer should be prompted to enter more specific details about their issue. If this is the case, Custom Fields can be used to capture new information. This section covers the various types of fields in Zendesk, including each of the fields mentioned here.

Data Capture Lifecycle

When a customer opens the ticket submission page on a default Zendesk instance, they will be prompted to enter a subject and description only. The screen that most end-users see is shown in Figure 6-1.

Figure 6-1. Default ticket submission form for end-users

As an administrator, you are able to add Custom Fields to the ticket submission page, which will prompt the user to enter additional information about their request. This process is often valuable because custom fields can remind the user about the information that agents might find useful to solve their request. Figure 6-2 shows an example of a ticket submission form with custom fields included.

Figure 6-2. Ticket submission form including custom fields for end-users

You’ll notice that this screen has some optional fields and required fields, and my recommended practices for using required fields appear in Required Fields.

Once the ticket has been created and its ID has been assigned, the ticket will appear on the Views of your agents. The exact process for an agent to find a new ticket will vary. Some organizations like to proactively use the default "Unassigned tickets" to find tickets to be processed, whereas others prefer to wait for an email notification to appear in the agent’s inbox before logging into Zendesk to start working on tickets. The choice between these options comes down mainly to the volume of tickets received by your organization. If your organization gets one new ticket per day it would be a waste of time for your agents to stay logged into Zendesk all day. Best to use effective Email Notifications in a situation where your volumes are low.

Ideally, the workflow for agents to find tickets and start working on them should be implemented on an organization-wide basis to create some consistency. In reality, every agent has a unique personality, so it’s also a good practice to allow your agents to subtly vary their personal ticket workflow from the standard organizational workflow. My advice is to set a standard workflow, educate agents on that workflow, then allow your agents to make the decision on how they work most effectively.

An example of the new ticket completed by the end-user, but viewed from the agent’s perspective, is demonstrated in Figure 6-3.

Figure 6-3. Fields on a new ticket from the agent’s perspective

When an agent reads a ticket for the first time, he should be looking at the fields on that ticket for red flags. For example, the words "outage" or "urgent" would suggest that the agent needs to raise the priority of the ticket to get it to the right people very quickly. Regardless of the severity of the incident though, it’s best for your agent to update all fields immediately. This process is also called triaging a ticket. Ideally, a properly triaged ticket should not appear in the view where the agent found it originally.

Once the ticket triage process is complete, it might look similar to Figure 6-4.

Figure 6-4. Fields on a ticket after being updated by an agent

Once all fields have been updated according to the agent’s perception of the issue, the agent should submit the ticket to save the updated fields. If the agent did not have the opportunity to complete the triage process, he should submit the ticket in the New status, which flags the ticket for triage by another member of the team. Otherwise if the agent has already triaged the ticket, he should submit the ticket in the Open status. If the agent assigned the ticket to himself, he might start working on the ticket. Otherwise, the agent to which it’s assigned might get an email notification or log into Zendesk directly to find tickets assigned to him for action. The new agent will read all the fields completed by the first agent, and start working on the ticket immediately.

End-User Fields

If you open the "Ticket fields" administration page and click the "edit" link for any of the system or custom fields, you’ll see a page similar to Figure 6-5. This page allows you to configure the options for the field.

Figure 6-5. Administration page for the Subject system field

When you select the "Visible" checkbox beside the "For end-users" option on the field administration page, a new section will be expanded, with an option that allows you to change the Title of the field for end-users. This Title will be visible on the end-user interface only, and is separate to the field Title that is set for agents and administrators at the very top of this page.

TIP

The option to make a field visible to an end-user is granted to administrators only, and it’s not possible for an agent to select which individual fields will be visible to the end-user. If you’ve configured a field to be visible or editable by end-users, the field will always be visible, regardless of the type or status of a ticket.

The Description text is configurable for every field, and the purpose of this text is to briefly explain to the end-user what information they should enter into the field. For example, if a field prompted the user to indicate the severity of their issue, the description text for that field might include some examples of other issues with the same level of severity. The description text is visible only to end-users on the ticket submission form, and is not visible to agents or administrators on the ticket page or submission form.

The other option on the field administration page is a checkbox to make the field Editable by end-users. By default, most of the ticket fields are not editable by end-users, and there is a very good reason for this. If end-users can change fields, you lose some control over your business process and reporting. As an example, if you’re capturing metrics on the number of incidents reported versus the number of questions and your customers have permission to edit this field, they might not select the correct field in every situation and your metrics will not be accurate. Agents have a much better ability to be trained on which fields to select, based on specific criteria for your organization.

On the other hand, making fields editable by end-users may help a lot with the triage process. It is possible, using Triggers, to configure an automatic business rule that checks the values entered by the end-user when they create a ticket, then assigns the ticket to a specific team based on those values. The other scenario is that you might want your customers to provide as much information as possible during the ticket creation to make it easier for your agents to diagnose the support request.

TIP

It’s not possible in Zendesk for a field to contain one value for agents and another value for end-users, even if the name of the field is different for agents and end-users.

Required Fields

In End-User Fields, I explained the value of asking for detailed information from customers, the end result of which is that the agent will be able to solve the support request more effectively. A common mistake by administrators is to make too many fields required. The problem with an extensive set of required fields is that it forces the customer to put a lot of effort into the process of submitting a support request, which is an unpleasant customer service experience from the very start. Customers may be frustrated and decline to complete the process, and may stop using your service altogether because they don’t feel like it’s easy to work with your organization. This idea is also contrary to Zendesk’s low barrier to entry philosophy, which is to make it as simple and easy as possible for everyone to achieve their tasks in the product.

If it’s necessary to make a field required, because the support ticket would not be complete without it, you can do this via the field administration page. Zendesk views fields as "required" in two different ways:

Required for end-users

This is the most conventional type of required field, where the ticket submission form cannot be submitted without entering a value in the text box. An asterisk appears next to the name of the field to indicate that the field is required. To make a field required for end-users, select the "Required" checkbox beside the "For end-users" option on the field administration page.

Required for agents

To make it as easy as possible for agents to do their jobs, in Zendesk you cannot force an agent to complete any field except the description field during the ticket creation process. Even if the field is marked as required for agents, it does not need a value when the ticket is created. The concept of a field being required for agents applies to solving the request only. In other words, if the Type field is required for agents, a ticket can be created without a value for Type, but when the agent solves the request, that agent must enter a value for this field. To make a field required for agents, select the "Required" checkbox beside the "For agents" option on the field administration page.

The Description field is required for all agents and all end-users, so none of these options are editable on the description field.

WARNING

In special circumstances in the product, it will be possible for a required field not to contain a value. Some examples are when the custom field was added to Zendesk after a ticket was already solved, or if the ticket was solved during the process of solving a Problem. For this reason, you should not rely heavily on a field always having a value when performing business processes.

System Fields

Out of the box, a standard Zendesk instance starts with a number of System Fields, each with a specific purpose. An administrator can configure most of these system fields in the "Ticket fields" administration page, and some other fields can be configured through various administrative sections of the product.

This section takes a high-level approach to your use of fields in Zendesk. The next section will explain each of the individual system fields in more detail and focus on the specific options for that field.

TIP

In general, I find that most of Zendesk’s system fields are worth enabling and should be used for their intended purpose. For one thing, parts of Zendesk make assumptions about how you are using them. I do occasionally see customers that use the system fields for non-conventional purposes, and I can tell you that it rarely works successfully.

Your ideal process would be to educate your agents on the meaning and interpretation of each of the system fields, based on the following summary:

ID

Numeric field that uniquely identifies every ticket.

Subject

Brief explanation of the support request, without going into specific details.

Description

More detailed description of the issue experienced by the customer, which should be enough information to solve the ticket.

Requester

The person who needs assistance.

CC

The other people who are interested in receiving email notifications when the ticket is updated.

Status

Stage in the lifecycle of a ticket, whether it has not yet been triaged (New), currently being answered (Open), waiting for customer feedback (Pending), answered (Solved), or completed and locked for further updates (Closed).

Type

Indicates the nature of the support request, whether it’s a request for information (Question), a request to make a change or a request between customer service team members (Task), an occurrence of something that is not working (Incident), or a systemic issue that is causing many related Incidents to occur (Problem).

Priority

Level of urgency that should be applied to the ticket, based on a small list of options. Helps to determine which tickets should be answered first or need the most attention.

Group

The team members at your organization that are assigned to work on this ticket.

Assignee

Individual person at your organization working on the ticket, who will belong to the group selected on the ticket.

Tags

Individual words that can be used to categorize a ticket, or to improve our ability to search for the ticket in Zendesk. Visible to agents and administrators but not visible to end-users.

Comments

A textual conversation between the viewers of a ticket—requester, assignee and other agents—that will assist the process of solving the support request.

Attachments

Files that can be included on the ticket when adding a comment.

System Field Configuration

The degree to which you can customize the Zendesk system fields is limited, because these fields play a big part in how Zendesk fundamentally functions. Some of the fields, such as Priority, have a bit more flexibility, and organizations occasionally elect not to use this field in their Zendesk implementation. The following section explains the options for all of the system fields, and the decision processes for implementation of them.

Ticket ID

Every ticket in your Zendesk instance will have a Ticket ID, which is a unique and incrementing number assigned to the ticket when it is created. The format of the ticket ID cannot be customized to include any characters other than this number. The only control that an administrator has over the ticket ID field is the number at which it should start. In the Tickets administration page, the "Ticket IDs" option can be increased to any number you like. Some customers elect to set the number higher than 2 (which is the default on a new Zendesk instance), to ensure that more digits are used in ticket IDs from the very start.

Ticket IDs are never recycled, which means that if you create ticket number 17 and ticket number 18 then delete ticket number 17, the next ticket will still be ticket number 19. Ticket number 17 no longer exists in your Zendesk instance, and will never exist again.

TIP

The ticket ID is the only unique identifier of a ticket, and is used in the ticket URL and in email notifications. In database terms, it can be considered the primary key of a ticket.

Subject

The value in the Subject field of a ticket should be brief, and it will be truncated if someone enters more than 150 characters. That is, any characters past the 150th character will be removed from the subject entirely. This field is used in the subject line of email notifications and search results, which is another reason for it to be brief. Specific details about the issue should not be described in the subject field, because this is the purpose of the description field. The subject field in the support ticket is very similar in concept to the subject line in an email, which is an analogy that makes sense to most people.

From an administrator’s perspective, it’s interesting to note that, by default, the subject field is not required for agents, either when creating a ticket or solving it. It’s also possible to deactivate this field, though I strongly recommend against doing this. When a ticket is created without a value in the subject field, Zendesk will use the first few words from the description in place of the subject line in some situations, or it will refer to the ticket by its ID.

Just to keep things consistent, I recommend that all administrators make the subject field required for agents and end-users. This still won’t guarantee that your agents will enter a subject during the ticket submission process (because, as described earlier, that’s not possible), but it will ensure that they enter a value during the solving process, and when you check a historical list of solved tickets, all of those tickets will have a subject included.

Description

The purpose of the Description field is to capture the details of the support request, which help the agent to solve it. In many ways the description field is simply the first comment on the ticket, and after the ticket is created, the description appears as the first comment and will scroll away from the top of the page like all of the other comments. A description is special, however, in that it cannot be made private, and the end-user will always be able to read the description field. The text entered in the description field will be truncated and removed after 64,000 characters.

TIP

Sometimes I speak to organizations that use a standard phone line (i.e., not Zendesk Voice) to provide support to customers, and they find it frustrating that the description of a ticket, which is also the first comment, must be visible to the customer. The problem, from their perspective, is that the agent is on the phone to the customer and would like to enter private information into the ticket, but cannot easily do so. One possible solution for this problem is to instruct the agent to enter the text "Customer phone call" in the description field and create the ticket immediately, then enter more private information as a subsequent comment and mark that comment as private. The result is that the end-user will see a generic description, but not the private notes in the comment field.

As mentioned previously, the description field is required for all users, so the options to configure this field on the field administration page are limited.

Carbon Copy (CC)

The CC field is one that is very useful, but disabled by default. I encourage all administrators to immediately enable the CC field in their Zendesk instance by opening the Tickets administration page and selecting the "Enable CCs on tickets" checkbox. The concept is very similar to the CC field in email: anyone CC’ed on a ticket will automatically receive an email update when a new comment is added to the ticket. The similarities are not exact, but it’s a relevant analogy.

The CC field is also a way of allowing end-users other than the requester to view a ticket in the web portal. If a ticket is relevant to multiple people and there are no privacy or security concerns, it’s possible to add multiple end-user accounts (up to 20) to the list of CC’ed users, and those end-users will all be able to view the ticket when visiting the Zendesk web portal. It’s possible to add an unlimited number of agent accounts as CC’ed users on a ticket.

After enabling the CC feature on the Tickets administration page, you will see some other options on this page that can be configured. One of the options is labeled "Only agents can add CCs". This option helps to ensure that your customers do not give access to tickets to other people unknowingly, by restricting the privilege of CC’ing another user to agents only.

WARNING

When an end-user wants to CC other end-users, they can do this only by CC’ing that person on an email sent to your Zendesk instance. The Zendesk web interface does not currently allow end-users to CC other people from their web browser.

Requester

From an administrator’s perspective, there are very few options to be configured for the Requester field. This field identifies the profile of the person who needs assistance. Sometimes an agent will submit a ticket on behalf of the customer, in which case the customer is the requester, and the agent is the Submitter. This relationship is indicated using the word "via", for example "Erin Enduser via Stafford Vaughan" indicates that I submitted the ticket on behalf of Erin, either through the web portal or one of the other channels. It’s also possible for an agent to create the requester’s user profile at the same time as they create the ticket.

Ticket Status

The five Status fields are built into the product and cannot be changed or extended by an administrator. The general principle behind this decision is that "less is more", and as the author of the Atlassian JIRA Workflows training course, I can tell you that whenever a workflow is customizable, the complexity of the software rises significantly.

Each of the statuses can be summarized as follows:

New

The ticket has not yet been evaluated or assigned to be answered by a support agent, and there is a good chance—though not a guarantee—that the ticket was created recently. Tickets in this status are some of the most important, because the nature of the request is generally unknown, and could be as severe as an outage that needs immediate attention. All tickets created by end-users in Zendesk will be placed into the New status, but after they move out of the New status, it’s no longer possible to put them back into this status.

Open

The ticket and its fields have been evaluated by a support agent, and someone is probably working on the ticket. If a ticket in the New status is assigned to an agent, its status will automatically be changed to Open. A ticket could also be in the Open status without an assignee, which means that it still needs to be assigned to someone for completion.

Pending

The support agent assigned to this ticket cannot solve the ticket without additional information from the customer, and is waiting for the customer to provide that information. This status should not be used when the agent is waiting for more information from another agent or another department at the organization. This status should be used only when you’re waiting for more information from the requester. Any emails or comments added by an end-user to a ticket in this status will automatically move the ticket back into the Open status.

Solved

Either the end-user or the agent believes that the issue described in the support request no longer exists, or the work has been completed. While the ticket is in the Solved status, it can be moved back into the Open or Pending statuses. Any emails or comments added to the ticket by an end-user while it is in this status will also automatically move the ticket back into the Open status, unless the end-user is on the web portal and has clicked the checkbox labeled "Consider this issue resolved".

Closed

The inquiry has been answered, a sufficient amount of time (the default is four days) has passed, and there is no more work to be done for the support request. When a ticket is moved into the Closed status, it is not possible to edit the ticket in any way. It’s not possible to change the assignee, update tags, add comments, or move it back into any of the other statuses. The only task that can be performed on a Closed ticket is to create a Follow-up ticket, which is a completely new ticket with a link back to an existing Closed ticket for reference. Any incoming emails related to a Closed ticket will also create a follow-up ticket. It’s important to note that users cannot manually move a ticket into the Closed status, and the only way to close a ticket is by using Triggers and Automations. The only exception to this rule is when an agent merges tickets, which will have the side-effect that the source ticket will be closed.

Typically, the workflow of a ticket will follow the order in which the statuses appear in this list.

The Status field—in the form described above—is not visible to end-users, so it’s also not possible to make it editable by end-users. Instead of showing the statuses listed above end-users, a brief sentence is shown. The list of the sentences provided to end-users is shown below:

New

This request is awaiting assignment to a help desk operator.

Open

This request is currently being processed by our staff.

Pending

This request is awaiting your response.

Solved/Closed

This request has been deemed solved.

When you are configuring the Status field you may notice that the "Visible" checkbox is disabled, suggesting that it’s not visible to the end-users. This is not quite true, it’s just that you can’t control the visibility.

WARNING

One of the most common mistakes that I see customers make with Zendesk is to use the Pending status in the wrong way. Zendesk has some default automations that will automatically send email reminders to the requester of the ticket after 24 hours and again after 5 days of the ticket being in the Pending state. These automations are described in Default Automations. If you use the Pending status while the ticket is waiting for further information from someone else on the support team, the customer will be very confused when they start receiving emails asking them to respond to the request. For this reason, it’s important that your agents always limit their use of the Pending status to when they are waiting for further information from the customer.

Ticket Types

Just like the status, Zendesk has a standard set of options for the Type field, which are not configurable by the administrator. Since the Type field is one that can be deactivated, I’ve seen situations in which some administrators decided that this field would not be used at all in their Zendesk instance. After reading this section and understanding the Type field, you should make the decision about whether it’s relevant for your usage of the product.

There are four possible options for the Type field, which can be summarized as follows:

Question

I generally reserve this Type for tickets where the steps required to answer the support request did not require any changes to be made by the agent or the support team. This interpretation will allow you to produce reports on the volume of questions in your Zendesk instance, then proactively record the answers to those questions in the self-service support portal of Zendesk, also called Forums (see Chapter 9).

Incident

An incident is something that has gone wrong, and needs to be fixed. An example of an incident is when a customer submits a ticket saying "I cannot log in to your website". From the customer’s perspective, they understand the symptoms of the issue, and they will describe those symptoms in the ticket. The Incident is usually the description of the symptoms.

Problem

When a customer submits the Incident just described, an agent will start to investigate the issue. She might discover that the customer cannot log in the website because the authentication server is down. This is known as the "root cause" of the Incident, and it is considered to be the Problem. A Problem will typically be the root cause of many similar Incidents.

Task

Tasks will represent a request for a change, or an internal activity carried out by agents. An easy way to think about the difference between a Task and an Incident is that if an Incident is reported, something has gone wrong. Often, nothing has gone wrong when a Task is submitted. Maybe some sort of activity just needs to take place, or a change is necessary. This is very commonly used in IT or internal customer service centers. The task type also features a "Due Date" field, that allows agents to indicate when the task is due for completion, and business rules can be connected to this date to provide reminders if necessary.

Zendesk has a useful feature that allows agents to link several Incidents to the same Problem. When the problem is solved, all of the connected incidents will automatically be solved at the same time. This feature saves a great deal of time for agents, and ensures that the message provided during the resolution of the problem will consistently be distributed to all of the end-users who are experiencing the same type of incident. I find that most people consider this to be the primary benefit of using the Type field in Zendesk (although I personally like the idea of tracking questions and turning them into forum topics).

TIP

The general rule is that only agents should create Problems in Zendesk, though I see some companies that don’t follow this rule. I recommend this practice because if a customer submits a ticket that is marked as a Problem and it is the primary ticket on which agents add comments, there is a strong possibility that one of those agents will make the mistake of publishing a sensitive comment and not marking it as private. This situation is far more likely to occur on a problem, which will be actively used by agents to solve the root cause, versus the incident, which is just a specific example of the impact of the problem. To avoid the risk of end-users being sent information that is potentially sensitive, the Problem ticket should always be created by an agent and end-users should never see it.

It’s possible for administrators to make the Type field visible and editable by end-users, though I don’t recommend it because there is a strong likelihood that end-users will mark requests as the wrong type, and the metrics that I described earlier will not be accurate.

Priority

The options allowed in the Priority field are Low, Medium, High, and Urgent. If you prefer to use only two priorities, you can change these options on the Priority field administration page to include just Normal and High. It’s not possible to create a custom set of priorities, though it is possible to deactivate the Priority field altogether, and add Custom Fields to include a custom set of priorities selected by your organization.

By default, the Priority field is visible to end-users, but not editable. Administrators often make the mistake of thinking that since the Priority field is not visible when end-users create a ticket, they will not see the Priority field after the agent triages the ticket. This causes negative feelings with customers when the agent selects "Low" priority for their ticket, and the end-user sees this classification on the ticket summary page. To prevent this issue, I suggest that you immediately set the Priority field to be not visible to end-users. The reality is that customers will often misinterpret your perception of the various priorities anyway, so it doesn’t add a lot of value for them to be able to see the Priority that the agent has selected.

If you would like to set up Zendesk to have separate "internal priority" and "customer priority" fields, it’s possible to do this by adding a new custom field. I’ve seen companies use this approach successfully, and it’s a good way for customers to feel like their voice is heard, without dictating the actions of your support agents. If you take this approach, it’s very important that you ensure that the internal priority field is not visible to end-users. If a customer selects "high" in the customer priority field and the agent has selected "low" in the internal priority field, that disconnect could make your customer very angry.

Group and Assignee

The reason that I’ve included both the Group and Assignee fields together in this section is that, when it comes to the ticket page, they are tightly connected. The purpose of the Group field on the ticket page is to funnel the ticket into the relevant set of agents. For example, if an agent was escalating a ticket, he might select "Level 2 Support" as the group. The result of this change would be that the list of agents in the Assignee field would include only the agents who are in the Level 2 Support group. This makes it easier for the agent to ensure that the ticket goes to the most suitable agent or agents to solve the request.

As an alternative to selecting the Group and Assignee, it’s a valid practice to select just the Group. For example, if your company had several people responsible for the billing process but the agent wasn’t sure which specific person should handle an inquiry, he can change the group to "Billing" (after it had been created by an administrator), then leave the Assignee field blank. The default Triggers in Zendesk will automatically send an email to all members of the Billing group with a message that a ticket has been assigned to the entire group. The same technique could be used for the Level 2 Support group described above, or any other group in the system. In fact, this is probably more common and a better practice than to assign tickets to a specific member of the group, just because it provides more flexibility on which members of the support team will address a specific inquiry.

It’s possible for an administrator to make the Group and Assignee fields visible to end-users, but it is not possible for you to make either field editable by end-users. The reason that end-users should not select the group is that you’ll end up with a situation where end-users always select the "Level 2 Support" or "Managers" group, and the reason that end-users should not select an Assignee is that only the support agents know whether or not that agent is able to handle the specific request. Customers should not be able to dictate which members of your support team should handle their inquiry.

TIP

The assignee field only lists the agents in your Zendesk instance, and will never include end-users. Even though an end-user may be the person whose responsibility it is to provide the next response, this situation can be expressed by an appropriately set Pending status, which implicitly suggests that the ticket requester is now working on the ticket.

Tags

I think of Tags as the "glue" that holds all business rules in Zendesk together. Tags are used extensively in business rules, as described in the Triggers and Automations sections later in this book. Tags also allow administrators to provide more detailed reports to their support managers, and at a very basic level, they help agents search for tickets. The contents of the tag field are visible to administrators and agents, but are never visible to end-users.

The tag field is not listed on the "Ticket fields" administration page, because it isn’t configured in the same way as many of the other system fields. This field can be enabled and disabled by administrators using the "Enable tags on tickets" checkbox on the Tickets administration page. If you are on the Enterprise plan, it’s also possible to grant or deny agents the ability to tag tickets at the agent role level, giving only some agents the permission to use tags, and hiding the tags field from other agents.

If you have enabled tags in your instance, you’ll notice another option labeled "Enable automatic ticket tagging" on the Tickets administration page. This is enabled by default, but there are certain situations in which I strongly discourage administrators from enabling this option. This feature will check all new tickets created by end-users, match those tickets against existing tickets, and tag the new ticket with exactly three tags, based on the set of tags added to similar tickets. This is usually a good thing because it makes searching and categorization of tickets easier, but it can also cause problems if your business processes and rules are closely tied to the use of tags. A simple example is if an agent tags a ticket with "vip_customer" according to a specific business process, and then the automatic tagging function automatically added this tag to a random ticket because it had properties similar to the first ticket, this would be a problem. The outcome of this situation would be that the new ticket was identified erroneously as being from a VIP customer, and the business process would break.

As an administrator, you will have access to the list of 100 most frequently used tags in the past two months on your Zendesk instance. The tags are presented in a Tag Cloud, which is a list of tags ordered by the frequency of use. An administrator can open this tag cloud from the Tags administration page, and remove a specific tag from all tickets—except those that are closed—by clicking on the tag, then selecting the appropriate link to delete all tags. A typical use for this feature would be if you find a meaningless tag such as "the" used frequently in your instance. The Tags administration page also allows you to see all tickets that are tagged with a specific tag, though it’s possible to use search syntax to achieve the same purpose.

Comments

I think of Comments as the "pulse" of a ticket. Comments help to keep a ticket active, they help maintain momentum during the support process, and they are vital to agent’s ability to solve a ticket.

Comments typically contain information relevant to the support request (though I’ve seen some humorous examples where they are not related at all). Comments can be added by the agent solving the request, or by the customer who submitted the request. They can be questions, answers, or just private notes for your support team. Like the tags field, the comments field is not configured via the "Ticket fields" administration page. The settings for the comments field are listed on the Tickets administration page.

The first option on the Tickets administration page allows administrators to reverse the order of comments. By default, comments will be listed on the ticket summary page from oldest to newest. You can change this order globally on your Zendesk instance by selecting the "Reserve" checkbox beside the Comments option on the Tickets administration page. A feature does not currently exist that allows individual users to select their preferred ordering.

The other settings on the Tickets administration page control the default visibility of the comment field when agents add comments via the web portal or email. By default, all new comments will be public and visible to the end-users that have access to the ticket. If you’d prefer to make all new comments private—and I’ve worked with plenty of companies that have selected this option—it’s possible to do this by deselecting the checkboxes on this page.

TIP

I recommend that you start by making all new comments public, then either adjust these settings if you find that your agents are making mistakes with public comments, or work with your agents to ensure that they understand that comments not specifically marked as private will be visible to end-users.

Attachments

Just like when you add attachments to an email, Zendesk allows end-users and agents to include Attachments on a ticket. Attachments in Zendesk are typically files that assist the process of solving the support request, and augment the information in comments. Attachments are always added to comments (i.e., they cannot be added independently) and will be displayed in context of the comment, which may require scrolling down the ticket page to find a specific attachment.

There is no limit on the type of files that can be attached to tickets, but the maximum size of each attachment is determined by the plan of your Zendesk instance. Starter plan customers can include attachments up to 1 MB each, Regular plan customers can include attachments up to 7 MB each, and Plus and Enterprise customers can attach files up to 20 MB each.

Administrators can configure the attachment settings on the Tickets administration page. The first option, "Customers can attach files", is intuitive and determines whether end-users are able to attach files to the ticket. The other option on this page, "Private attachments", is a slightly bigger decision. The private attachments option will determine the level of security that is added to the attachments in your Zendesk instance. Since attachments are not attached to email notifications sent from Zendesk, the recipient of the email must click a link if they’d like to open the attachment. This link contains a randomized URL generated by Zendesk, and this randomization process provides a level of security. The option to make attachments directly accessible via the email link is the default setting in Zendesk, and is the easiest option for the user because they just have to click a single link to access the attachment.

On the other hand, if you have serious concerns about security and would like an added layer of protection, you can require the user to log in with their username and password before they can access attachments, even if they are used the randomly generated URL for the attachment. To enable this option, select the "Private attachments" checkbox on the Tickets administration page.

Screencasts

Zendesk has partnered with a company named Screenr to allow users to record screen capture videos inside Zendesk. The feature is known as Screencasting and is available to organizations on the Plus and Enterprise plans. Screencasting is totally free if you’d like to only add videos to your tickets, but if you’d like to add videos to forum topics, you’ll need to pay an additional fee for the service.

Screencasting is useful for two different profiles of users:

Your customers submitting tickets

Sometimes, in order to explain their issue, customers will need to write a long list of detailed steps to reproduce it. I’ve done this myself on many occasions, and it can be frustrating. With the screencasts feature enabled, customers will have a link labeled "Record screencast" when submitting a ticket, which allows them to record their actions as a video instead of explaining their actions in words. It works just like the attachments feature, except there are a few more prompts for the user. Once the process of recording the video is complete, the user can preview it, then the video is added to the ticket for the agent to view. The customer will have the option whether to include audio or not (for the less vocally inclined). I should also note that it’s possible for agents to record screencasts on tickets in the same way as end-users. This can be useful if it’s the agent that is trying to articulate a long list of steps, and would prefer to do that in video form.

Your team members publishing content on the forums

The other side of the screencasts feature is the ability for agents to record videos to be added to the forums. The benefit here is that the seamless integration between Screenr and Zendesk saves the agent the effort of finding an external recording tool, saving the video, encoding the video, publishing on an external website, and then referencing the video from the Zendesk forums. With the screencasts feature, most of these steps are consolidated into just a few button clicks. Once enabled, this feature will allow your agents to immediately start recording videos from the same page they use to publish forum topics.

WARNING

In order for customers to use this feature, they will need to have the Java Runtime Environment installed on their computer. This is usually not an issue, because Java is installed on most modern computers by default.

Screencasts are disabled by default, and there are a few steps to enable this feature. If you visit the Tickets administration page, you’ll notice the "Screencasts" option. If you select the "Enable screencasts for tickets" checkbox, you’ll be immediately prompted to confirm that you’d like to link your Zendesk instance with Screenr. When you confirm this request, Zendesk creates a Screenr account for you in the background without requiring any further information from you. Once this process is complete, you’ll receive a confirmation message, and the screencast feature will be enabled. Be sure to save the tab after the checkbox is checked. Once the feature is enabled, customers can immediately start recording screencasts on their tickets.

TIP

If you’d like to use this service to post videos to your forums, you’ll need to pay an additional fee. On the first attempt by any agent or administrator to post a video, the user will be prompted to agree to the Screenr terms and conditions, and will have the option of entering credit card details. If you’d like to use screencasting in the forums, as an administrator you should visit the forums and start the process of creating a video, then submit your payment information.

Custom Fields

There are two common use cases for Custom Fields, which can be described as follows:

Agents requesting specific information from customers

At some stage in the life of every customer service team, it’s likely that administrators or the support team will identify a piece of information so important to the process of answering support requests that it’s worth asking every customer the same question. An example would be an "Outage occurring?" checkbox that allows the requester of the ticket to indicate whether their system is currently non-functional. This custom field would then feed into your support process, which may notify certain users of the outage.

Agents categorizing a ticket

The second use case for custom fields is when agents and administrators would like to categorize tickets for reporting, or execute a certain business process based on the agent’s selection in a custom field. For example you may add an "About" custom field, which has several options such as "Database", "User Interface" or "User Management". When an agent is triaging the ticket, they should select one of these options. As an administrator you may define a process that would automatically send an email notification to certain people based on the selection in this field. Afterwards, you may also like to run a report to identify the number of tickets with a certain category selected, which helps to make predictions or identify trends.

Custom fields are useful because they collect all of the important pieces of information about a ticket at the top of the ticket summary screen, which makes it easier for agents to quickly find relevant pieces of information. The alternative to using custom fields is to hope that the end-user provides the specific information in the comments, but even if they do, it can be difficult for an agent to find that information if it’s scattered through the comment history.

To add a custom field, you should visit the "Ticket fields" administration page and click the "add custom field" link at the top-right corner of this page. The list of custom fields will be presented along with examples of each field. This screen is shown in Figure 6-6.

Figure 6-6. List of custom field options, along with examples of each

Each of the custom field options can be summarized as follows:

Drop-Down List

Also known as a "select list" in some circles, this field allows an administrator to specify the valid options from which the user may choose. It’s a way of restricting the user response, usually for the purpose of categorizing the ticket. This type of field can be very useful when defining business rules, which might mandate that some action (such as "assign to a group" or "send an email notification") should occur based on a specific choice made by the user in this custom field.

Text and Multi-Line Text

These options simply ask the user to enter a text value in an input box. The difference between the two is that the Text field appears on a single line only, whereas the Multi-Line Text field spans multiple lines.

Numeric and Decimal

Both of these field types will present a text box to the user, but validate that the user has entered a number before allowing the user to submit the ticket form. The difference between these two fields is that the Decimal field supports the use of decimal points in the number, and the Numeric field requires the user to enter a whole number.

Checkbox

This is my favorite type of custom field, because it’s so simple but so powerful. When you start to define the tags that will be used by your Triggers and Automations in Zendesk, you’ll start to appreciate the importance of getting those tags exactly right. Misspellings or misplaced dashes could be the difference between a successful or failed business process. The Checkbox custom field concept is simple: the administrator can define a tag that is associated with the checked state of the checkbox. When a user checks the box, that tag is added to the ticket. Simple. Less risk for your business processes, as well.

Regular Expression

The last type of custom field is definitely the most complex, and probably the least frequently used. This type of field supports a Regular Expression, which is basically a special pattern that defines the valid format of the input from the user. Examples of this feature would be a social security number, a phone number, or the serial number of your product. To define a regular expression custom field, the administrator must also define what the regular expression pattern must be, and the result is that any time a user enters a value in the field, their entry must match the correct format before the ticket can be submitted.

Once you’ve selected the type of custom field, you’ll be taken to the same field administration page as all of the system fields, except that the options will vary depending on the exact type of field that you’ve selected. Once you’ve selected the options for your new custom field, click "Add field" and the field will be added to your Zendesk instance immediately.

CASCADING MENUS IN DROP-DOWN LISTS

If your select list has a very large number of options and you would like those options to be categorized into cascading menus, you can use a special syntax in Zendesk to do this. When you define your field options for the drop-down list field, you should use :: to indicate that a menu should be inserted. The :: needs to only appear in the Title of the option, and should not appear in the Tag for the option. An example of how to use this syntax is shown in Figure 6-7, which creates a menu labeled "Software" in the drop-down list, with three items inside that menu.

FIGURE 6-7. OPTIONS IN THE DROP-DOWN LIST TO CONFIGURE A MENU

When you’re defining menus, the rule is that whenever :: appears and the text before two options are the same, everything before the :: will become a menu and everything after the :: is shown as the second level of the menu. For the "Software" menu described earlier, Figure 6-8 shows the result displayed to the user. In this screenshot the first level of the menu is shown on the left, and the second level is shown on the right.

FIGURE 6-8. RESULT OF CONFIGURING A MENU OF OPTIONS (TWO SCREENSHOTS SHOWN SIDE-BY-SIDE FOR CONVENIENCE)

WARNING

If you’re using this option and enabling custom fields on your feedback tab as described in Creating a New Feedback Tab, you should be aware that this select list menu will be flattened when displayed to the user, but only when displayed on the feedback tab.

Ordering Fields

The order in which the fields are listed to users will depend on the person viewing the page. As an administrator, you will have complete control over the order in which fields are presented to end-users. You’ll have less control over the order in which fields are presented to agents, since the system fields have a predefined order.

The process to define the field order is simple: click the Reorder link on the "Ticket fields" administration page. This link will add boxes around each of the fields (see example in Figure 6-9), and you will be able to drag-and-drop each of the fields to the desired position. When you’re finished, click the Done button.

When an agent views the ticket creation or edit page, the rules for the ordering fields are simple:

- List all of the system fields in their standard order

- List all custom fields using the order defined for them by the administrator

When an end-user views the ticket creation page, the order of all fields will exactly match the order defined by the administrator, even if the custom fields have been positioned before any of the system fields.

Figure 6-9. Drag-and-drop interface for reordering ticket fields

Reading the List of Ticket Fields

The configuration of each field, including the settings described in End-User Fields, are summarized beside each field on the "Ticket field" administration page. Figure 6-10 shows a sample set of fields in the leftmost "Active fields" column. The administrator’s configuration choices are reflected as follows:

Field category

The third column shows whether the field is a System or Custom field.

Visibility

Fields that are shown to end-users (Subject, Description, Assignee, and "Nature of request") have a gray box labeled "visible" next to them. Fields without this box (Priority, Status, Type, and Group) are visible to agents and administrators only. The "Outage?" field is visible to end-users because it is editable by them, as will be described shortly.

Required for agents

An example of a field in the list that is required for agents is Assignee, which has an asterisk (*) beside the name of the field. Technically, the description field is required for agents as well, but since it’s implicit and not configurable, it is not noted on this screen.

Editable by agents and end-users

If a field has a gray box labeled "editable" next to it, both agents and end-users can change its contents.

Required for end-users

The Subject, Description, and "Nature of request" fields in the screenshot meet this criterion, because they have both the word "editable" in the gray box beside the field name, and an asterisk to indicate that the field is required.

The rightmost "edit" column allows you to change the configuration of the field.

Figure 6-10. Configured set of ticket fields

Chapter 7. Agent Support Process

Zendesk is the kind of tool that allows you to create a new instance (without requiring any installation, since it’s SaaS), and immediately start providing support to your customers. Out of the box, there are some nifty default settings that will assist with the process.

This is fine to start with, but as your business and support processes mature, it’s a good idea to ensure that your Zendesk instance matures with them. Some of these processes are less tangible and will require user education only, but for the other tasks, you can use macros and views for business process automation. This chapter describes these tools, and some of the other techniques that your agents will use to support your customers.

Restricting Agent Access to Tickets

On the agent creation page, administrators have an option to restrict what the agent "Has access to". Most customers elect to give all agents access to "All tickets", which is the least restrictive of the options. I also encourage you to select this option. The simple reason is that it allows agents to proactively find tickets that are new in your Zendesk instance, triage them, and possibly work on them. All of the other options would require an automatic triage policy to be set up in the Triggers, or a dedicated person to assign new tickets to agents manually. Assigning a team member to function as a triage manager is a potential roadblock, particularly if the person happens to be out of the office when an important ticket comes in, which adds potential risk to providing great customer service.

The option to restrict access to "Tickets within this agent’s group(s)" means that the agent must wait for someone else to assign the ticket to their group before reading it (or even knowing it exists). Be aware that agents restricted in this way cannot view tickets that are waiting to be assigned to a group. The option "Tickets assigned to this agent only" takes this one step further, and says that an agent can only view tickets that have been specifically assigned to him. This is the most restrictive access, and completely prevents agents from proactively finding new tickets and solving them.

The final option of "Tickets requested by users in this agent’s organization" helps to preserve customer privacy. If you elect to use this option, it’s important that you assign the agent to a customer organization in the "Organization" select list on the agent creation page (see Adding an Agent Account for further details). Agents restricted in this way cannot view tickets outside the organization to which they are assigned, and if you use this option for all agents, customers have the security of knowing that only a fixed, limited group of agents can ever see their tickets.

Presumptive Solve Approach

Many support processes should be defined up front in order to run a successful customer service program. Many of these process definitions will require user education, and cannot be automated in Zendesk.

One process that I strongly encourage customers to adopt is what I’ve named the Presumptive Solve Approach. Consider a scenario where a customer submits a ticket asking for a certain piece of information, and the agent replies to the ticket with the information that she believes answers the question. At this stage, the agent has the option of solving the ticket or leaving it in the Open status. The options can be analyzed as follows:

Leave the ticket open

So as not to potentially offend the requester of the ticket, the agent might set the status of the ticket as Open. She does this because she’s concerned that it’s presumptuous of her to assume that she’s already answered the customer’s inquiry. If she did answer the question successfully, the customer might come back and say "Thanks", but it’s also very possible (more likely, in fact), that the customer won’t reply at all. The agent won’t know whether she has solved the request, and the ticket will be sitting in her queue every day until she hears back. At this stage the agent can follow up with the customer, to which the customer may or may not respond, or she can simply solve the ticket. Adopting this approach for your customer service workflow assumes that the customer is going to respond eventually to confirm that the ticket has been answered. In my experience, this rarely occurs, and the agent is left with a situation where she needs to presumptively solve the ticket anyway.

Presumptively solve the ticket

The alternative to the approach above is that when the agent provides the answer to the question in the ticket, she sets the status of the ticket to be Solved immediately. This might seem presumptuous, but as I described earlier when discussing the Ticket Status, Zendesk will automatically reopen requests that were solved when a customer replies, so the customer still has a means of continuing the conversation with the agent. In other words, the customer could simply reply to request a better explanation from the agent, and the ticket will be immediately reopened. Adopting this support workflow will produce a cleaner database of tickets, and requires less effort on behalf of agents. The risk is that customers will be offended by the agent’s presumption that she has answered the inquiry, but I’ve found that the benefit of adopting this policy outweighs this risk.

Another benefit of the presumptive solve approach is that the Resolution Time metric in Zendesk will accurately reflect the amount of time that the agent took to provide what she believed was the answer to the ticket. If your agents keep tickets open indefinitely until the customer responds, this metric won’t accurately measure when tickets were solved. It will more accurately reflect the amount of time it took before the agent got frustrated with the lack of response and solved the ticket.

TIP

If you or your support manager are concerned that agents are using the Presumptive Solve Approach and typically not answering customer inquiries properly in their first response, Zendesk has some metrics that can help you to measure this. If you are on the Plus or Enterprise plans and have linked Zendesk with GoodData, you can analyze the Reopens and Replies metrics. Using this data allows you to balance the workflow above, and ensure that your agents are adopting just the right amount of "presumption".

Views

When a support agent opens Zendesk every morning, she somehow needs to find the tickets that she should be answering that day. The feature that allows her to do this is called Views. Views can simply be described as "saved searches". When you create a view, you’re defining the conditions for the search. The view does not save the search results themselves. Often, agents will create their own views (and are able to do so, if you are on the Regular, Plus and Enterprise plans). I encourage Zendesk customers to let their agents create their own views, but I also strongly encourage administrators to work with support managers to find out which views should be created as a standard baseline for agents. Standardizing a set of views for all agents will provide a a consistent and reliable process for your agents to follow. Past that, minor changes by agents are fine.

I generally find that the default views in Zendesk are useful for organizations just getting started. As your setup matures, you can modify these views to reflect your customized use of the product. For example, if you are getting 100 tickets every hour and would like to use the "Recently updated tickets" more effectively, you might change one criterion in this view to show tickets from the past two hours, instead of the past 24 hours.

Aside from creating new views, administrators really only have one setting in Zendesk to configure for views. On the Tickets administration page, there is an option labeled "Views" with a checkbox labeled "List empty views". By default, when an agent clicks the toolbar icon to display their views, Zendesk will include every view in the list, even if the view is empty. In this case, empty views will appear in a lighter gray color. If your Zendesk instance has a large number of views, this can be a poor use of screen real estate. If this is the case, you can deselect the "List empty views" checkbox on the Tickets administration page, which will cause empty views never to be listed for agents.

To get started with the creation of views, you’ll need to open the Views management page and click the "add view" link. The following sections show you how to handle each part of the dialog presented to you.

DEFINITION OF CURRENT USER

As you’re defining your process process in views, macros, and triggers, you’ll probably notice the phrase current user scattered throughout the options. To summarize what this means, the current user is the user who is executing the action.

In the context of a macro, the current user will be the agent that clicked the link to apply the macro. In the context of a view, the current user is the person who is reading the list of tickets in the view. In the context of a trigger, the current user is the person who made the change on the ticket, which resulted in the trigger being fired.

TIP

Automations do not refer to the current user in their configuration, because automations are fired by Zendesk itself, not as a result of an action by any individual person.

Understanding View Conditions

Every view has two types of conditions:

All conditions

Every condition in this set must be met by the list of tickets in the results. For instance, if this section contains one condition that the Status must be Open and another condition that the Priority must be High, the only results shown by this view will be the open tickets with a high priority.

Any conditions

One or more of the conditions in this section must be met, but it is not necessary for all of the conditions to be met. For instance, if one condition in this section says that the Group must be "Sales" and another condition says that the Group must be "Finance", the results will include all tickets that are assigned to the Sales group, in addition to all tickets assigned to the Finance group. Since every ticket can only be assigned to one group at a time, it would be impossible for a ticket to be assigned to both of these groups anyway. So having this particular condition in the Any conditions section is necessary to be able to achieve this set of search results.

An example of these conditions is shown in Figure 7-1, which uses two All conditions to find unsolved tickets assigned to the current user, and also uses two Any conditions to find all tickets from Zendesk Voice.

Figure 7-1. Example conditions for a view

Once you’ve selected your relevant set of conditions, you can test the view by clicking the "Preview match for the conditions above" button.

TIP

When you create a condition, you’ll often have the option to select three drop-down lists: the field, the qualifier, and the value. The qualifiers of "is" and "is not" are simple, but in the case of the qualifiers of "Less than" or "Greater than", it’s not necessarily obvious what is considered less or more. The rule is this: Less than refers to everything above the selected item in the select list. For example in the Status field, everything above the Solved status includes New, Open and Pending. Greater than refers to everything below the selected item in the select list, for example in the Priority field, everything below Normal includes the options High and Urgent.

Required Fields for Views

When you’re creating views, you might occasionally get an error message that says:

Status less than solved has been added as a hidden rule because at least one of the following ticket properties are required in the ALL conditions section: Status, Type, Group, Assignee, or Requester

Basically, this message is telling you that every view must contain at least one condition that checks one of these five fields. The reason for this is purely technical - the way that databases work is that they index data before searching. In order for this indexing process to work very quickly, only certain types of fields—usually numerical fields—can be indexed. The set of five fields mentioned in the error message are the ones that Zendesk uses to index the data, so it’s necessary that at least one of the fields appears in every view. Otherwise, your views would take a considerable amount of time to execute and it would produce a considerable strain on the Zendesk servers, and no one wins.

To satisfy this requirement, I almost always add a condition to check that the status of a ticket is less than solved. If you’d like to include solved and/or closed tickets, then you could also use a condition that checks for all tickets of a certain type. Most of the time it’s not really an inconvenience, unless you see the error message and you don’t understand what it means because you haven’t read this section in this book.

TIP

This message will also be displayed to agents who are creating their own views, so be prepared to explain this section to your agents when it happens.

VIEW FORMATTING OPTIONS

If you’re on the Zendesk classic interface, there are two ways to display the view search results. These options were recently removed from the default interface, and at some point in the future may not appear in the product. The options are:

List format

Tickets in the results are listed down the page similar to the results of a Google search. The fields included in the results are the ticket ID, subject, status, type, request date, requester name, and latest comment. The status/type/ID section is color coded to indicate the status of the ticket. New and open tickets are red, pending tickets are yellow, and solved tickets are white. The fields included in these results are not configurable, but the order in which the tickets are displayed can be selected by the creator of the view. The options for this format are shown in Figure 7-2.

Table format

Instead of listing the tickets down the page, the tickets are formatted in a table, where each row represents one ticket, and the columns represent one of the fields on the ticket. Unlike the List format, the selection of fields included in the Table format can be fully customized by the creator of the view (using drag-and-drop). This format also has an option to group the tickets together, in addition to ordering the tickets. I often use this feature to group all tickets by priority, then order them by request date. The result is that all Urgent priority tickets will appear first, then the High priority tickets, and so on. When the settings in this example are applied, even if a ticket was requested 12 months ago, if it has an Urgent priority it will appear above a High priority ticket requested last week. The options for this format are shown in Figure 7-3.

FIGURE 7-2. CONFIGURATION OPTIONS FOR THE LIST FORMAT FOR VIEWS

FIGURE 7-3. CONFIGURATION OPTIONS FOR THE TABLE FORMAT FOR VIEWS

Regardless of which option you choose, you’ll be able to restrict the number of tickets per page in the search results to either 15 or 30.

TIP

The List format is useful when you expect a small number of results, and the Table format is useful when you have a larger number of results, or you’d like to compare many tickets side-by-side.

Shared Views

Agents on the Regular, Plus and Enterprise plans can create views for personal use. Administrators on all plans can configure the standard set of views available for all agents, and administrators on the Plus and Enterprise plans can create views that are shared with a specific group of agents. Administrators on the Enterprise plan can also grant the privilege of creating shared views to agents, which is explained in Configuration Options for Agent Roles, and I mention specifically that the ability to grant the privilege of sharing views to agents is one of my favorite features of the Zendesk Enterprise plan.

After following the instructions in Understanding View Conditions to set the conditions for your view and defining the format of the results, you’ll see a section at the bottom of the view creation page labeled "Available for". This section allows you to create a Shared View, as opposed to a Personal View. The sharing options allow you to share the view with all users or to share it with a single group. If you’d like to share the same view with two groups, such as "Level 2 Support" and "Level 3 Support", a workaround would be to create a new group named "Higher Level Support", add all of the agents from both groups, then share the view with that one group.

Once you’ve created some shared views, you’ll be able to filter the list of views on the Views management page by clicking the select list marked "All shared views" and selecting a specific group instead. Once updated, this page will only show the views that have been shared with the selected group, allowing you to audit the shared views more easily.

WARNING

As an administrator, the option to share the view with "All agents" will be selected automatically when you create a new view. If you opened this page to create a new view for personal use only, it’s important that you change the sharing option to be "Me only". Otherwise, everyone will see the new view in their list.

Macros

Every customer service team, regardless of how they support their customers, will find that there are a few questions that just keep being asked by customers over and over again. Every time this question is added, the agents must write the same or similar answer for the customer. To make this process more efficient, Zendesk has a feature named Macros that allows agents to define actions that can be repeated by simply clicking a couple of links, or using keyboard shortcuts.

Just like views, macros will often be defined by the agents that use them. After all, your agents are the people who understand their process best. But just like views, it’s also possible for an administrator to define a standard baseline set of macros. Unfortunately, it’s very difficult to predict the types of questions that you’ll get from your customers, or the tasks that your agents will be performing over and over again. As an administrator, I recommend that you start with very few macros, and then you should iteratively speak to your agents about the personal macros that they find most useful, then create shared versions of these macros that are available to all other agents.

Unlike views, the default Zendesk macros are not particularly useful and are mostly for demonstration purposes. That’s OK, though, because if you educate your users on the process of creating macros, hopefully you’ll start to see some really useful macros appearing quickly. If you’re on the Enterprise plan, you will also be able to give your agents the permissions to share macros with other agents directly.

Adding a Shared Macro

Just like views, all administrators can create macros that are shared with all agents, but if you’re on the Plus and Enterprise plans, you can also add new macros that are shared with only specific groups. Macros are added from the Macros management page in Zendesk. The first tab on this page lists the Shared Macros and the second tab lists your Personal Macros. As an administrator, you’re not likely to have your own personal macros, because most of the time, administrators don’t solve support requests (although I’ve seen situations where this does happen). To get started with macro creation, click the "add macro" in the top-right corner of this page.

Every macro must have a title, and at least one action. Among the available actions is the ability to update the values of all fields, including system and custom fields. I won’t explain all of the fields here since most of them are intuitive, but there are a few options in the list of actions that sometimes confuse people:

"Set subject"

This option will erase the existing subject of a ticket and replace it with the value set in the macro. There is currently no way to suffix or prefix the subject with a piece of text.

Difference between "set tags" and "add tags"

The difference is quite simple: "set tags" will remove the existing tags and replace them with the tags defined in the macro, whereas "add tags" keeps the current tags and adds new tags as defined in the macro. To be honest, I’ve never seen a valid use for the "set tags" option. Since it comes first, I hear from customers that they select this option accidentally, and then they are frustrated to find that the existing tags on the ticket are erased when the macro is executed. So it’s important that you don’t make the same mistake, and remember to choose "add tags" unless, for whatever reason, you need to erase all of the current tags on the ticket.

Separate options for "Comment/description" and "Comment mode"

When an agent adds a comment to a ticket from the ticket screen, they’ll have the option to mark the comment as private. The process of adding a comment and setting its visibility probably seems like a single step to the agent, but technically, the agent has changed two fields - the comment text and the comment mode. On macros when you add an action to publish a comment, these fields are both presented separately, and are named Comment/description and Comment mode. Sometimes you’ll want your macro to add a comment to the ticket without explicitly setting the visibility mode, in which case the comment will use the existing visibility setting on the ticket. In other cases you might want to change the comment visibility without adding a comment at all. For example, if your macro was assigning a ticket internally, the comment mode should be set to private, without necessarily adding the comment text in the macro. This is the reason that these fields are separate in the macro configuration screen.

After you’ve defined the set of actions for your macro, you can share the macro in the same way that you share a view, which is described in Shared Views. Similar to views, macros can be shared with all agents, or just a specific group.

TIP

With the exception of macros that provide a set of instructions in the form of a comment, my general rule is that the ideal number of actions in a macro is three. Any less than this, and the macro doesn’t do much (with a few exceptions, such as tagging with difficult words). Any more than three actions, and the macro is so specific that it’s hard to find a relevant situation in which you would use it.

Macro Menus

As the number of macros increases in your Zendesk instance, it can be difficult for your agents to navigate a long list of macros to find the ones that are most important. The feature to create macro menus assists with this, by allowing you to define multiple cascading levels in your macros. The syntax for this function is exactly the same as the syntax described in Cascading Menus in Drop-Down Lists.

It’s surprisingly simple to use this feature. Just add two colons (::) in the macro at the point where the menu break should occur. Everything that appears before the :: in the macro name will be used as the menu name, and everything after the :: is considered the second level. It’s possible to use this technique several times in the same macro to create multiple menus. In Figure 7-4 I defined two macros that have a primary menu of "Take it", then a secondary set of options to assign a priority. I could have extended the first option to create a third level by naming the macro Take it::with normal priority::and make incident, which is a macro with three different cascading levels.

Figure 7-4. Definition of a macro menu on the Macro management page

The macros from this example will be presented to the agent in the menu format shown in Figure 7-5 (the first level of the menu is shown on the left, and the second level is shown on the right).

Figure 7-5. Macro menu shown to the agent (screenshot modified and shown side-by-side for convenience)

There are many different scenarios in which you might want to use this feature:

Defining next steps

You might use a macro similar to the default "Take it!" macro, which immediately assigns a ticket to the agent who executes the macro. It’s possible to set the first level of the menu to the text "Take it!", then have the second level define the next steps, such as assigning a priority to the ticket. This is the example just shown.

Categorizing for agent convenience

To illustrate this idea, suppose you have a dedicated group of agents who have the responsibility of managing social media tickets in your Zendesk instance. You’ll probably define a convenient set of macros for them to use. Rather than asking the social media team to navigate through the same long list of macros as every other agent, you might use a macro menu to create a "Social media" first level menu, then all of the social media macros would be included on the second level.

Funneling into the correct action

If you have several business processes defined to escalate tickets under various circumstances, it’s possible to create menus to make the process simpler. Your first level menu could be the word "Escalate", and your second level menus might be "Supervisors", "Level 2 Support", or another group at your organization. In other words, the sentence is being completed by the combination of the selected levels in the macro macro. This also saves space compared to the alternative option of listing all of the different escalation groups in the first level of the macro menu.

Referring Macros to the Forums

If you’re planning to use macros to provide detailed step-by-step instructions to customers (and most organizations do), I encourage you to take advantage of the forums feature in Zendesk (see Chapter 9). As an example, let’s assume that you’re providing a set of instructions to change a user’s password. Instead of including the instructions in the macro itself, the best practice is for the macro to refer to instructions in a forum article. There are a few reasons for this:

Maintenance

Since it’s impossible to update the fields of a closed ticket, it would be impossible to update the instructions if the process to change a password changed. The steps might be valid at the time that they were given to the customer, but if the steps change afterwards and the customer revisits the ticket, the instructions will be out of date.

Encouraging self-service

By linking the ticket to a forum article, you’re effectively making the customer aware of the existence of your Zendesk forums, and the extensive set of FAQs that you’ve (hopefully) published there. Next time the customer needs a simple question answered, they might go check the FAQs before submitting a new ticket to your support team.

Search Engine Optimization

By having the instructions listed on your forums, it makes it possible for Google and other search engines to include the instructions in search results. Before your customers even have the chance to submit a ticket, they might use their search engine to find the answer, and your forum article might provide the answer to them immediately.

TIP

If you’re linking to a forum topic in a macro or a comment, you might notice that the URL looks like https://support.zendesk.com/entries/510058-new-password-security-settings-for-zendesk (which is an example URL from the Zendesk forums). The section of the URL that says "new-password-security-settings-for-zendesk" is technically redundant, and you can link to https://support.zendesk.com/entries/510058 (or the equivalent in your Zendesk instance) instead, which is the same URL without the full title of the forum topic. The benefit is that if the title of the forum topic changes, the latter URL will still work, but the former URL will become invalid. If your agent has committed to redirecting the customer to a specific URL for all eternity on a closed ticket, it’s best to use the most future-proofed option possible.

Chapter 8. Automated Business Rules

Every organization has a slightly different set of ideas for how they’d like to support their customers. When I implement Zendesk solutions for organizations, support managers sometimes tell me that they have a "standard customer service setup", but over the years I’ve learned that there is no such thing. When we really dig into it, often the support manager understands that their requirements are quite specific, since their organization is unique from every other organization using Zendesk.

In order to accommodate this diverse range of customer requirements, Zendesk offers a very flexible set of tools to capture the your organization’s business process. Earlier I explained Views and Macros, which are the first pieces of your business process, but dealt with them from the agent’s perspective.

From an administrator’s perspective, you can define a number of automated business rules using Triggers and Automations. This chapter will describe each of these in detail, along with some other business rules that may be configured by administrators in Zendesk.

User and Organization Tagging

The User and Organization Tagging feature is one of my personal favorites in Zendesk, because it’s so simple, but makes it so much easier for you to provide varying levels of support to each of your customers. Using this feature, administrators can add tags to users or organizations in the same way that an agent might add a tag to a ticket. Then when an end-user submits a ticket, that ticket inherits the tags from the end-user’s profile, or the organization to which they are linked. An example use of this feature would be to tag a user as a "vip" or their organization as having the "premier_support" package. In the Tags section earlier I described tags as the glue that connects business rules, and this is a good example. You might use the "vip" user tag to define an automated rule that raises the priority of tickets from all VIP customers if their ticket has not been solved within 48 hours.

This feature is disabled by default, but you can enable it by clicking the "Tags on users and organizations" checkbox on the Customers administration page.

Once this feature is enabled, you’ll notice that every time you edit a user’s profile, it will include a Tags field. You might also notice that whenever you create or edit an organization, the Tags field also appears. This field works in the same way as the tag field on tickets—when you enter some text and press the space bar, the tag is added in its own box. Once you’re finished adding tags, you must submit the user profile or organization update form for the tags to be saved.

To find a list of users or organizations with a specific tag, you can click the "tags" link on the People management page, which will show a report of all tags added, and the list of users and organizations associated with each tag.

TIP

It’s possible to add tags to agent and administrator user profiles, but this is less useful than adding tags to end-users because agents and administrators generally don’t submit tickets. It can be very useful in the context of configuring the visibility of forums, though, which is covered in Forum Access Restrictions.

Immediately after you add the tags to a user or organization, those tags will be inherited by new tickets created by that user. The tags are not applied retroactively to tickets, but if you need to do this, you can perform a search for all tickets submitted by a specific requester and perform a bulk update. The bulk update operation inside views will add the specified tags as new tags on the tickets, without removing the existing tags.

The user and organization tagging feature is really just the first step in a mature business process. In the upcoming sections on Triggers and Automations, I’m going to explain some of the uses for tags on tickets, which will highlight the value for you.

Triggers

Triggers are configurable actions that will be fired when an event occurs. As an administrator, you can use triggers to turn your business process into business rules in Zendesk. I find that the best way to explain triggers is to provide examples on how to use them, which will be the approach in this section of the book.

Default Triggers

Triggers can be added and customized by administrators from the Triggers administration page. Eight triggers are activated by default in Zendesk, each of which provides some value to most organizations. These default triggers can be grouped into three categories:

Email notifications to the requester

Whenever a ticket is updated with an important piece of information, the requester of the ticket—who is usually an end-user—will receive an email notification with details of the update. There are three triggers in this category: one to notify the requester when the ticket is created, another one for when a ticket is updated with a comment, and one when the ticket is solved. These are the three big events in the life of the ticket, so deserve a notification to the requester. It’s important to note that the requester will not be notified when a field is changed without the addition of a comment, or when the added comment is marked as private. In other words, when your agents change the ticket status from New to Open, the customer will not be notified unless the agent adds a comment at the same time. It may be possible for the end-user to log in to the web portal to find out the new status, though.

Email notifications to the assignee

When an update is made to a ticket, the agent working on that ticket should receive an email notification about the change. This might encourage the agent to log in to your Zendesk instance and add another update to the ticket. By default, the three events that are important to an assignee are when a comment is added to the ticket, when a ticket is assigned to them, and when the ticket is reopened. There is a default trigger that will send an email notification to the ticket assignee in each one of these situations.

Email notifications to all agents

There are two default triggers in this category, the purpose of which are to notify a broad range of agents about new tickets. One of the triggers will notify all agents when a ticket is created without being assigned to a group, and the other trigger will notify just a specific group when the ticket is assigned to that group.

I occasionally hear from customers that the third category of triggers generates too many email notifications to agents, so they deactivate them. I’ve also worked with customers who disable the second category of default triggers, because they would prefer their agents to work inside Zendesk full-time, instead of working in email and waiting for email notifications to be sent to them. I rarely see situations in which the first category of default triggers are removed, because sending emails to your customers when a comment is added to their ticket is your best method of keeping them updated. Ultimately, each of these decisions should be made according to what is best for your organization, and the culture of email within your team.

WARNING

Although the effect of all the default triggers is to send email notifications to someone, it’s important to note that triggers can be used for many other purposes. The upcoming section on Trigger Examples has a number of triggers that do not send email notifications at all.

There’s one more default trigger in Zendesk that is hard to notice, because it’s deactivated by default. This trigger is named "Auto-assign to first email responding agent". The simple idea behind this trigger is that when a new ticket is created and an agent replies to the email notification saying something like "Got it!", the ticket will be automatically assigned to that agent. One potential issue with this process is that the agent’s reply would be sent to the end-user, unless the agent has used the correct email syntax to mark an email response as private. In general, it’s also not a good practice to let agents pick tickets by email, because there might be someone better equipped at that time to take the ticket, who is logged into Zendesk directly. Those are the reasons that the trigger is deactivated by default.

Trigger Conditions and Actions

To start creating your own triggers, click the "add trigger" link in the top-right of the Triggers administration page.

If you’ve already read the section on Views, you’ll be familiar with the format of trigger conditions. Just like views, trigger conditions have an All and an Any section. The conditions in the first section must all be met by all tickets in order for the trigger to be executed, and one or more of the conditions in the second section must be met by tickets. The difference between the trigger and view conditions is that there are more options in the list of conditions that can be configured for triggers.

The first step when configuring any trigger is to identify if you would like the trigger to be executed on tickets that are created, or tickets that are updated. The latter does not include tickets that are created. To add the condition, select "Ticket is…" from the list of conditions, and select either "created" or "updated" from the list of options. If you would like the trigger to be executed on tickets are created and updated, you can exclude this condition from the trigger entirely.

Once you’ve defined the complete set of conditions for your trigger, the next step is to define the actions that will occur on the tickets that meet the specified conditions. This part is similar to Macros, with some special actions such as "Requester language" added. Just like macros, you can add as many actions as necessary to the trigger.

Trigger Examples

There are literally thousands of possible triggers that you could define in your Zendesk instance. Of those possible triggers, I see many consistent themes, but rarely are the business processes of two organizations exactly the same. The beauty of Zendesk’s flexible triggering system is that you can customize your triggers to match however you want to achieve your customer support objectives. This section provides some example triggers, which you can either use verbatim in your instance, or customize for your specific use of the product.

Assign email ticket to the sales team

In the Incoming Email section, I explained that it’s possible to create several incoming email addresses for your organization, such as support@blueskies.com and sales@blueskies.com, and have all of these addresses forward emails into your Zendesk instance. Once the ticket is created, it’s also possible to use triggers to automatically assign it to a specific team, based on the email address used by the customer. To configure this trigger, the conditions should be set as shown in Figure 8-1, and the actions as shown in Figure 8-2.

Figure 8-1. Conditions for the "Assign email ticket to sales team" trigger

Figure 8-2. Actions for the "Assign email ticket to sales team" trigger

Assign twickets to social media team

In the topics on the Twitter channel, I explained that tickets created from Twitter are sensitive by nature, because the conversation can be easily broadcast to the world. For this reason, it might be worth immediately assigning all new twickets to your social media team to provide a response. To configure this trigger, the conditions should be set as shown in Figure 8-3, and the actions as shown in Figure 8-4.

Figure 8-3. Conditions for the "Assign twickets to social media team" trigger

Figure 8-4. Actions for the "Assign twickets to social media team" trigger

Notify managers of urgent tickets

Whenever a ticket is given a priority of Urgent, it’s obvious that a serious issue needs to be addressed. It’s possible to write a trigger that would send an email alert to the people managing your team whenever a ticket is updated with this priority. Note that this trigger should be executed regardless of whether the ticket was created or updated, so there is no "Ticket is…" condition included in the trigger. Note also that the qualifier for the condition is "Changed to", which is necessary to ensure that the actions are only executed once, and not every time that the urgent ticket is updated. To configure this trigger, the conditions should be set as shown in Figure 8-5 and the actions as shown in Figure 8-6.

Figure 8-5. Conditions for the "Notify managers of urgent tickets" trigger

Figure 8-6. Actions for the "Notify managers of urgent tickets" trigger

Increase priority of tickets with the word "outage"

There is a slight trick to this trigger, because you might notice that there are no conditions to check the subject or description of a ticket. There is a condition to check the "Comment text" though. What this condition really means is that it checks the comment text, but if the trigger was fired when a new ticket was added, technically the description is the comment text, so the condition will check the text in the description field. Regardless, the text in the subject will also be checked every time this condition is run. This is very useful when you want to find a specific word such as "outage" in incoming emails or tickets. The other condition in this trigger, which checks that the action was executed by an end-user, is useful to ensure that the trigger is not fired if the agent makes a casual comment such as "can you confirm if there is an outage" to the requester. The conditions specified in this trigger will ensure that it is fired only when a customer makes a comment about the outage. To configure this trigger, the conditions should be set as shown in Figure 8-7 and the actions as shown in Figure 8-8.

Figure 8-7. Conditions for the "Increase priority of tickets with the word outage" trigger

Figure 8-8. Actions for the "Increase priority of tickets with the word outage" trigger

Ordering Triggers

The order of triggers is important, because whenever a ticket is updated, the triggers will be executed in the order in which they are listed on the Triggers administration page. Many administrators make the mistake of ordering triggers for convenience or priority, but if you don’t order your triggers appropriately, your processes may not work as you intended.

A good example concerns the default trigger "Notify all agents of received request" and the trigger "Assign email ticket to sales team" from the Trigger Examples in this book. The default trigger "Notify all agents of received request" checks to see whether the ticket is assigned to a group, and if it’s not assigned to a group, an email notification will be sent to all agents in your Zendesk instance. If this trigger appears at the top of the list, it will be one of the first triggers to be executed, and all agents will receive an email. If the "Assign email ticket to sales team" trigger was further down the list, it would assign tickets to the sales team when the conditions are met. This, in turn, would fire the email notification defined in the trigger "Notify group of assignment", the end-result of which would send two email notifications to the sales team—one for the creation of the ticket, and another one for the assignment of a ticket. You’ll also end up with a number of agents who receive an email about a ticket that was immediately assigned to a team for completion, meaning that the email notification was just unnecessary noise.

WARNING

Sending multiple emails to the same person for a single event is bad practice, because users will start to feel like they are being spammed with redundant notifications and will tune out the emails coming from Zendesk.

Fortunately, avoiding this situation is quite simple. On the Triggers administration page, you can select the link labeled "Reorder". This will immediately add boxes around each of the triggers in the list, and using drag-and-drop, you can change the order of these triggers. In the example just discussed, you would move the trigger "Assign email ticket to sales team" to the top of the list, then the triggers "Notify all agents of received request" and "Notify group of assignment" further down the list. When a new ticket is created, it will be assigned to the sales team by the first trigger first (assuming that the conditions are met), then an email will be sent directly to the sales team via the "Notify group of assignment" trigger, and the "Notify all agents of received request" trigger will not be executed since the conditions will not be met.

TIP

Automations will also be executed in the order in which they are listed on the Automations management page, so the same ordering principles apply to your automations.

Mutually Exclusive Triggers

Aside from ordering triggers appropriately to prevent multiple email notifications from being sent to users, you can also use mutual exclusivity to ensure that multiple emails are not sent for the same event, regardless of the trigger order. Triggers defined as mutually exclusive cannot possibly both be executed as a result of the same event.

Out of the box, Zendesk has a good example of mutually exclusive triggers. To see it, start by opening the "Notify requester of comment update" trigger. When you look at the conditions of this trigger, you’ll notice that one of the conditions prevents the trigger from being fired when the status of the ticket is set to solved. In other words, if someone adds a comment and solves the ticket, the customer would not be notified. That might seem unusual, because this is the exact situation in which it’s very important to notify the customer.

The reason for this particular condition is that it prevents the trigger from overlapping with another trigger, named "Notify requester of solved request". The dedicated purpose of the latter trigger is to send an email notification to the customer when the ticket is solved, and this trigger contains a custom email template that notifies the customer explicitly that their request has been solved.

If the first trigger did not have the condition that prevents it from overlapping with the latter trigger, the customer would receive one email saying that a comment had been added to their ticket, and another email saying that their ticket has been solved. These duplicate emails are what mutually exclusive triggers help you to avoid.

Automations

Automations are very similar to triggers, but instead of being executed when an event occurs, an automation will be fired after a certain amount of time passes. Automations are also configured with a set of All conditions and a set of Any conditions, so many of the concepts to configure automations will already be familiar to you. For the same reasons as the triggers section, I’m going to explain automations by example.

WARNING

Automations are checked exactly once per hour (within a window of a few minutes), which means that the actions defined in an automation may not be applied until nearly an hour after the conditions in the automation are met. The automations are not necessarily run at the top of the hour, and it may not be exactly one hour between executions of an automation. In most situations, such as email reminders, this is not a serious issue, but in the case of Service Level Agreements (SLAs) with fine-grained definitions over the amount of time before a ticket is escalated, it can be more serious. You’ll need to consider this limitation before writing your automations.

Default Automations

All automations in Zendesk are listed on the Automations administration page. On a completely fresh instance of Zendesk, only one automation is enabled by default. As you start to enable other features such as the Twitter channel, Facebook channel, and Customer Satisfaction, some other automations will be automatically created. There are also two default automations that are deactivated by default, but I encourage most administrators to activate them. They are named "Pending notification 24 hours" and "Pending notification 5 days", and are explained with the other default automations below.

Close ticket 4 days after status is set to solved

In the Ticket Status field section earlier in this book, I explained that it’s impossible for a person to manually change the status of a ticket to closed by selecting the option in the ticket field. The only way to move a ticket into the closed status is to use either this automation, or one like it. It’s possible to change this automation to allow a greater period of time than four days to reopen a ticket, although I usually find that four days is an appropriate length of time, because the momentum of a ticket is usually lost after four days anyway. If you get a lot of complaints from customers that their tickets are closed too quickly and they’d like to be able to have a week or more to reopen them, you can update the conditions of this automation. Note that even if this automation is deleted or deactivated, Zendesk will wait a maximum of 28 days before automatically closing all tickets in the solved status. This is built into the product and impossible to change.

Request customer satisfaction rating

If you’ve enabled the Customer Satisfaction feature on your Zendesk instance, this automation will be added for you automatically. The purpose of this automation is to send an email to the requester of a ticket exactly 24 hours after the ticket is solved, to ask them for their feedback. The format and contents of that email are defined in this automation, so most of the text can be customized, with the exception of the customer satisfaction question itself. If you feel that 24 hours is too soon to ask the customer for their feedback, you can change the timeframe in this automation. Just be aware that end-users cannot submit customer satisfaction feedback on a closed ticket, so if the email is sent after one day, the customer has another three days to provide feedback before the ticket is closed by the automation above. If you extend the delay for the customer satisfaction email, you should change the closure automation as well. I also don’t recommend sending the customer satisfaction email immediately after solving a ticket, because if you’ve read the Presumptive Solve Approach section, you’ll know that in some cases the agent will solve a ticket but the customer will have more questions. If an email was sent to the customer every time the ticket was solved to ask for their satisfaction feedback, it could very easily get annoying.

Close Twitter ticket/Facebook Message one day after status is set to Solved

These are two separate automations, and will be enabled only if the relevant channel (Twitter or Facebook) is also enabled in your instance. The purpose of these automations is to close tickets that are created through these channels more quickly than tickets from other channels. The way that the Twitter and Facebook integrations work is that any incoming correspondence from a customer, regardless of the context, will be added to their latest open ticket in Zendesk. Since it’s possible that the customer might like to start a new conversation and have the details recorded in a new ticket, this automation proactively assumes that if there is no additional feedback after one day, the ticket should be closed for further updates. Then any future messages from this person on Twitter and Facebook will be created as a new ticket in your Zendesk instance.

Pending notification 24 hours/5 days

These automations are deactivated by default, but I encourage you to enable them. The purpose of these automations is to send customers a reminder email when their tickets are marked as Pending (i.e., the agent is waiting for feedback from the requester). Without these reminders, there’s a much smaller chance that the customer will add an update to their ticket. If you enable these automations, it’s very important that you review the description of the Pending status in the Ticket Status field topic, and understand that the Pending status should only be used to indicate that the ticket is waiting on feedback from the customer, not feedback from someone else at your organization.

Automation Examples

The default Zendesk automations already provide some good examples of processes that can be automated, but here are some more examples that might give you ideas for additional business rules:

Remind agents about unsolved tickets after 48 hours

I use this automation in my own Zendesk instances, and it’s an example of what I call a fortification automation. It prevents tickets from slipping through the cracks, especially if the ticket has been open for a long time. To configure this automation, set the conditions as shown in Figure 8-9 and the actions as shown in Figure 8-10.

Figure 8-9. Conditions for the "Remind agents about unsolved tickets after 48 hours" automation

Figure 8-10. Actions for the "Remind agents about unsolved tickets after 48 hours" automation

Escalate unsolved VIP tickets after 72 hours

This automation ties nicely into my example usage of the user and organization tagging feature. If you tag some special users with the "vip" tag, all of the tickets created by those users will be automatically tagged with "vip". Then you can write an automation that checks all tickets with this specific tag, and sets the priority of the ticket to Urgent if it has not been solved within 72 hours. When the automation updates the ticket with the new priority, as a side-effect it will also fire the "Notify managers of urgent tickets" trigger from Trigger Examples, which in turn would email the support manager. You can see how these different features start to connect, and hopefully understand the reasons that I call tags the glue that holds the business rules together. To configure this automation, the conditions should be set as shown in Figure 8-11 and the actions as shown in Figure 8-12.

Figure 8-11. Conditions for the "Escalate unsolved VIP tickets after 72 hours" automation

Figure 8-12. Actions for the "Escalate unsolved VIP tickets after 72 hours" automation

Reassign tickets to level 2 support team after one week

After a ticket has been assigned to a support agent for a certain amount of time, it’s fairly obvious that the ticket is not being effectively answered by that agent. Often, the agent is the last person to admit it. So you can define an automation that will automatically reassign a ticket to another team if the ticket has not received a response from the current team in an appropriate amount of time. To configure this automation, the conditions should be set as shown in Figure 8-13 and the actions as shown in Figure 8-14.

Figure 8-13. Conditions for the "Reassign tickets to level 2 support team after one week" automation

Figure 8-14. Actions for the "Reassign tickets to level 2 support team after one week" automation

Nullification of Automations

At some point, every Zendesk administrator will see the following message:

Automation could not be created as: Automation must contain an action that nullifies a condition. For example, if you have a condition testing for "Priority Is High", you could have an action setting "Priority Is Urgent".

This section is going to explain how to prevent this message from appearing.

First, I’ll start by explaining what this message really means. As I mentioned earlier, Zendesk will run your automations once every hour. If you’ve defined an automation that finds all tickets that have been open for 72 hours or more and changes the status to Urgent, the automation will run as soon as those conditions are met. Let’s look at this in more detail:

- 71 hours after the ticket was opened, the conditions will not be met, so the automation will not run

- 72 hours after the ticket was opened, the conditions will be met, so the automation will run and the ticket priority will be changed to Urgent

- 73 hours after the ticket was opened, the conditions will be met, so the automation will run and the ticket priority will be changed to Urgent

- 74 hours after the ticket was opened, the conditions will be met, so the automation will run and the ticket priority will be changed to Urgent

This pattern demonstrates that Zendesk is going to execute a potentially redundant operation on this ticket every hour. The ticket priority was already set to be Urgent at 72 hours, so it’s unnecessary to set it again every hour afterwards. Zendesk uses a Multitenant server architecture, meaning that every Zendesk customer shares the same processing power. Processes that waste power for one customer will also waste the server processing power for every other customer. To avoid this, Zendesk like to keep things fair and impose a rule that says that redundant automations should not be repeated on the same ticket.

Fortunately, it’s quite easy to add a nullification condition that prevents the automation from running a second time on the same ticket. In the example just shown, this condition would be "Priority is not equal to Urgent". In other words, at 72 hours Zendesk will change the ticket priority, and by having a condition in the automation that checks that the priority has not been changed, at 73 hours the conditions will no longer be met and Zendesk is spared the effort of repeating the automation.

TIP

The general rule to nullifying an automation is that you should write a condition that is the opposite of one of the actions of the automation. If your actions send an email only, the workaround is to add another action that adds a tag to the ticket (for example, "notification_sent"), then add a condition to the automation to check that the ticket does not have this tag before running the automation again.

Auditing Business Rule Use

If you’re on the Plus or Enterprise plans, you can easily identify the triggers and automations that you’re actively using, versus the ones that are perhaps no longer needed. To do this, you should open either the triggers or automations administration pages and change the sort order of the rules.

The default sort order for triggers and automations is "Sorted by position", which lists the rules in the order in which they will be executed (see Ordering Triggers for an explanation of why this is important). The other options for this select list are:

- Sorted by position

- Sorted by creation date, latest first

- Sorted by updated date, latest first

- Sorted by usage over the last hour

- Sorted by usage over the last 24 hours

- Sorted by usage over the last 7 days

If you select one of the options that starts with "Sorted by usage", the most frequently used rules will appear at the top, and you’ll get a sense of the value of each of the triggers and automations, based on their usage. If you consistently find that one of the rules is listed as having 0 uses in the past 7 days, it might be that the rule is either improperly configured, or not needed in your Zendesk instance.

TIP

Deactivating these unused rules, while not strictly necessary, will help to reduce the complexity of your Zendesk configuration in the long run, and make it easier to manage Zendesk for other administrators on your team. As a standard practice I recommend deactivation instead of deletion of business rules, just to maintain the historical context of your Zendesk configuration.

Email Notifications

There is no central page in Zendesk that will allow you to customize the contents of all email notifications that are sent from Zendesk. There is, however, a short list of pages that you can visit to customize the contents, which are listed below. Zendesk gives you a surprising amount of flexibility when it comes to defining the sender address and appearance of your email notifications, which will be explained further in this section.

Bi-Directional Email Communication

In Outgoing Email, I explained how to customize the sender email address of your email notifications. In certain situations it might be relevant to enable Personalized Email Replies, or it might be useful for the sender address to match the incoming address with the email pass through feature, as described in Email Notification Sender Address. The combination of options selected in your Zendesk instance will have an impact on the way that email notifications are sent to users, and the specific sender address selected for every outgoing email.

TIP

When sending email notifications, Zendesk will always use the primary email address of the user as the recipient address. Every Zendesk user can have several email addresses on their profile, but only one primary email address. If a user lists only one email address, it will automatically be selected as the primary address. If the user lists multiple addresses on their profile, the primary address must have been previously verified on the user’s account.

The sender address of all email notifications will be determined by the options selected on the Email channel administration page. Zendesk uses the reply-to address system in emails, which basically means that when a customer clicks "Reply", their email can go to an address that’s different from the sender of the email. Zendesk automatically generates extra information in the Reply-to email address to help your organization manage information.

For instance, assume that email notification about a ticket comes from support@blueskies.zendesk.com (or notifications-support@blueskies.zendesk.com if personalized email replies are enabled). The Reply-to address on that email notification would be support+id123@blueskies.zendesk.com. Although the sender of the email is support@blueskies.zendesk.com, when the user clicks the "Reply" button in their email tool, the email is automatically sent to support+id123@blueskies.zendesk.com. When Zendesk receives this email from the end-user, it will add the email contents as a new comment on the ticket with ID 123. You may have noticed that the ticket ID of 123 was subtly included in the Reply-to address in this example.

Similarly, when an email notification is sent to an agent from Zendesk, the sender address uses a unique code instead of the ticket ID, an example being support+idP6WQ-X8B9@blueskies.zendesk.com. When an agent replies with an email to this address, the contents of the email will be added as a new comment to the same ticket, although it’s impossible to determine the ticket ID from the email address alone. The reason that a unique code is added for agents but the plain ticket ID is used for end-users is to add a layer of security to agent emails. Since it’s possible to spoof an email address (meaning that you could send an email and pretend to be sending it from an address that is not yours), it’s theoretically possible for an end-user to maliciously pretend to be an agent by sending an email into Zendesk from a spoofed agent’s address. This will add their email as an agent comment to the ticket. To prevent this from happening, Zendesk generates a unique code (in my example, "P6WQ-X8B9") for each agent/ticket combination. Even if the malicious user was able to spoof the sender address, it’s probabilistically impossible for them to guess the correct code, which adds a layer of security to the process and ensures that only agents are able to add private notes to restricted tickets via email.

To ensure that replies to email notifications go to the correct place, it’s important that your agents and end-users don’t change the recipient email address when replying to email notifications from Zendesk. Regardless of the contents of the email, if a response is sent to the standard support@blueskies.zendesk.com email address in the situation above, it would be created as a new ticket instead of being added as a comment on the existing ticket.

TIP

In certain circumstances it’s not possible for Zendesk to add "+id" to the Reply-to address, which is usually for technical reasons. In this situation the ID of the ticket (in the case of end-users) and the generated code (in the case of agents) will be included in the subject line of the email instead.

Email Notification Template

The source code for the outgoing email template—in HTML format—can be found in the Email section of the Channels administration page, and is also listed below. The default template is set up to be clean and simple and to contain the most relevant information. The template deliberately does not use any branding or colors, meaning that you don’t have to be concerned that the colors will conflict with your corporate color scheme. There are also no logos or custom fonts used in the email template. If you want to do all of these things and you have a basic understanding of HTML, you can modify the template yourself by finding the text area labeled "HTML template" on the Email administration page.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<style type="text/css">

table td {

border-collapse: collapse;

}

</style>

</head>

<body style="width: 100%!important; margin: 0; padding: 0;">

<div style="padding: 10px ; line-height: 18px;

font-family: 'Lucida Grande',Verdana,Arial,sans-serif;

font-size: 12px; color:#444444;">

<div style="color: #b5b5b5;">{{delimiter}}</div>

{{content}}

<div style="color: #aaaaaa; margin: 10px 0 14px 0; padding-top: 10px;

border-top: 1px solid #eeeeee;">

{{footer}}.  Delivered by <a href="http://www.zendesk.com"

style="color:black" target="_new">Zendesk</a>.

</div>

</div>

</body>

</html>

I generally don’t recommend that administrators change the email template in Zendesk. Email notifications from Zendesk aren’t a marketing opportunity, or a branding exercise. They are a simple piece of communication that is sent to customers. It’s generally unnecessary to incorporate a flashy look-and-feel into something that is as simple as an email notification.

Once you’ve settled on the template of your email notifications, the contents of your emails can be found on any of the following pages:

End-users

New users to Zendesk will receive emails with text that is defined on this administration page.

Tickets

The message offered to CC’ed users can be customized on this administration page.

Triggers

Described in more details in Triggers, these are the email notifications sent to users when a ticket is updated. You’ll need to open each of the triggers and read the actions to customize the contents of the emails.

Automations

Described in Automations, these email notifications will be sent to users based on the time criteria determined by administrators. Just like triggers, you’ll need to open up each of the automations to adjust the contents.

Mail Delimiter

Below the email template on the Email channel administration page, you’ll find an option named "Mail delimiter". The default value for this field is {{txt.email.delimiter}}, which is a system placeholder that references the following message, translated if necessary into the language you use:

## Please do not write below this line ##

In the email notifications sent from Zendesk, the mail delimiter text will be placed above the part of the email generated by Zendesk, but below the section where the recipient would enter their comment when replying to the email. When Zendesk receives the email response from the user, it will exclude everything below the line since it believes it to have been generated from Zendesk itself, and keeps only the content above. There’s a slight risk that the sender of the email will have used inline editing, which means that they added their specific comments further down the email response. To avoid this, the mail delimiter message tries to be very specific about the importance of not writing below the line.

I’ve never really found a compelling reason to change the value of the mail delimiter. Zendesk does a good job of stating a simple message to the user, and translates the message into all available languages in the product. It’s possible that you’d want to write your own message because the default one does not suit your purposes, but that’s very rare.

Placeholders

When your agents define the text of macros or when you define the text in email notifications as an administrator, this text must be dynamic to be useful in a broad range of circumstances. For example, your email notifications may contain some instructions that refer specifically to the status or priority of a ticket. Placeholders will allow you to dynamically include specific field values in your comments.

There are several options to find the complete list of Zendesk placeholders:

1. When you select the "Comment/description" option in a macro, beneath the text area there is a link labeled "View available placeholders". Clicking this link will expand the page to list the set of available placeholders.

2. If you select the option to "Email user" or "Email group" from a trigger or automation, the same link will appear beneath the text area on this page.

3. Zendesk has documented the complete set of placeholders in their forums.

Before building shared macros for your team or writing your trigger and automation emails, it’s worth investing some time understanding placeholders and their role in the product.

Customer Satisfaction

For most support managers, the metric that is most important for customer service is the current size of the ticket backlog. The backlog is the major factor that will influence response times, and potentially the quality of the responses from your support team. While the response times and number of tickets answered are useful metrics, the fact is that they do not accurately reflect the level of satisfaction experience by customers seeking support from your organization. Fortunately, Zendesk has a feature named Customer Satisfaction that serves this purpose, and it is available to customers on the Regular, Plus, and Enterprise plans.

Zendesk’s customer satisfaction feature is unique because, like most of the product, Zendesk has deliberately made the feature simple. The question asked to customers is:

How would you rate the support you received?

The options for the response are either "Good, I’m satisfied", or "Bad, I’m unsatisfied". It’s not possible to change the question, and it’s not possible to change the options for the response. By deliberately keeping this question simple and avoiding a scale from 1-10 like many other systems, Zendesk has successfully increased the response rate in their customer satisfaction surveys to well above the industry standard. As a comparison, the industry average response rate for customer satisfaction surveys is below 10%, and the response rates on Zendesk’s survey range from 18-25% (depending on the geographic region).

To enable this feature, you’ll need to open the Satisfaction tab on the Customers administration page and select the checkbox labeled "Allow customers to rate tickets". As described in the Automations topics, this will immediately create a new automation that emails customers 24 hours after their ticket is solved to ask for feedback on their support experience.

TIP

If you’ve enabled this feature, it might also be worth revisiting the Shared Views that you’ve defined and adding the Satisfaction column to any views that include solve or closed tickets. This is an easy way to view the customer satisfaction of many tickets at the same time.

Chapter 9. Forums

In a way, Zendesk is really two products in one. The first product is the ticketing system, which includes most of the features that I’ve described up until this point in the book. The other product is the Forums feature, which is a self-service portal where your customers can find answers to their questions without engaging with your support team directly.

In his book High-Tech, High-Touch Customer Service, Micah Solomon describes the growth of self-service portals (similar to Zendesk’s forums) with the observation, "self-service[…] is a powerful trend in customer service, and companies that ignore it, pursue it reluctantly, or violate the basic laws of its implementation will be left in the dust". To companies who are not observing this trend, "customer service" is delivered through a person-to-person interaction, and anything else seems impersonal or robotic. But really, customers are becoming more satisfied when companies are able to anticipate their needs, and provide the answers to their question immediately, without human intervention.

Before explaining the forums feature, I want to clarify that its name is misleading for most people. When thinking of a forum on the Internet, most people think of those bulletin board style systems where people post new threads, perhaps asking a question, and other people respond and engage in a conversation on the forum. The primary purpose of these types of forums is to allow user-to-user interaction.

Forums in Zendesk provide some of this functionality, but it’s much more appropriate to think of Zendesk’s forums as a Knowledge Base. Zendesk’s forums are often used to make announcements to customers, to provide public access to Frequently Asked Questions (FAQs), or to publish documentation. In fact, the most extensive and diverse Zendesk forum available is provided by Zendesk itself, at http://support.zendesk.com/forums. These forums demonstrate many of the different uses of the forums feature, and can serve as a reference point for your own forums.

Terms and Definitions

Before getting started with the forums, I’ll provide a quick introduction to the terms that are specific to Zendesk’s forums:

Category

As your forums grow and you start to add more information, a logical structure becomes important. Categories are useful for this purpose, and provide visual order to the forum home page on your Zendesk instance. Otherwise, your forums may seem disorganized. A sample category from the Zendesk forums site is "Product news and updates", which is also visible in Figure 9-1. Forum categories are available only for customers on the Regular, Plus, and Enterprise plans.

Forum

This is the most confusing of the forum terms, since the term is used to mean two different things in Zendesk. In one context, the term refers to the entire Zendesk forum feature, i.e., the topic of this chapter. In another context—which is the one that I’m describing here—it is used to refer to a collection of topics on a specific subject area. Just like categories, forums help to collect your information together in a logical way. Otherwise your topics would be unstructured and hard for your readers to find. An example forum from the Zendesk forums site is "Announcements". To avoid the confusion associated with this term, I usually refer to the entire Zendesk forums feature as the "knowledge base", but for the purposes of this book I’ll continue to refer to the entire feature as "forums".

Topic

A topic contains information on one subject only. For example, a sample topic from the Zendesk forums site is "Introducing an all new email notification template". Each topic can be associated with one forum. Each topic will also be classified as either an Article, Question or Idea, so you’ll rarely see the word "topic" appear in the product. The different types of topics are covered in Types of Forums.

The use of these concepts is demonstrated in Figure 9-1, which shows a category of "Product news and updates", a forum of "Announcements", and a topic of "Introducing an all new email notification template".

Figure 9-1. Examples of the forum hierarchy

Forum Users

There are several different types of users with varying permissions in the forums. These include:

Administrators

Forum administrators are the same as Zendesk administrators, unless you are on the Enterprise plan, in which case you are able to assign forum administrative privileges to agents. Forum administrators are able to create new categories, add forums, and have unrestricted access to all of the topics in the forums.

Forum Moderators

A forum moderator is a special type of agent. Forum moderators are granted access to edit all existing topics in the forums, and can perform some additional functions such as closing all topics for new comments. Forum moderators cannot add new categories or forums.

Agents

On the Starter, Regular, and Plus plan, all Zendesk agents can create new topics in the forums. On the Enterprise plan, administrators can grant more granular permissions to agents based on the agent’s role. Under all plans, agents can edit their own topics. But unless they’ve been granted the permission on the Enterprise plan, agents cannot add categories or new forums, and they cannot edit topics that they did not create themselves.

End-Users

End-users in Zendesk can access forums, but can only create new topics if they are granted the appropriate permission as described in Forum Access Restrictions. Unless a forum moderator has closed a specific topic for comments, end-users can also add comments to forum topics, and engage in a public conversation with other end-users. This feature creates a bidirectional dialog between your customer service team and customers in a public space, the result of which might be beneficial for other visitors to the forums.

Anonymous visitors

Zendesk doesn’t use this term, but I use it to describe someone who is viewing your forums without logging into Zendesk first. These users can read topics that are open for public access, but cannot add comments to forum topics until they log in. Zendesk does not allow anonymous user contributions to forums.

Configuring Forums

Not every organization uses the Zendesk forums in the same way, because not every feature appeals to every organization. For example, some organizations prefer to rename the forums feature altogether. If this sounds like your organization, you should open the "Web Portal" section in the Channels administration page and find the "Forums name" option. The default value is "Forums", but many customers—for reasons I described earlier—like to rename this to "Knowledge Base". It’s also possible to internationalize this piece of text to appear in different languages depending on the viewer. To achieve this, you’ll need to be familiar with the steps described in Multi-Language Support for End-Users and Dynamic Content for Text Translation. Dynamic content placeholders are fully supported in this field.

On the same Forum administration page, it’s also possible to enable and disable many of the forum features. The options on this page are:

Forums on home page

This is enabled by default, and as the label suggests, it determines whether your forums appear on the home page of your web portal. As long as you’re using the forums feature, it makes sense to keep this option enabled. Without the forums on the home page, your Zendesk web portal will typically appear very empty.

Forum search on Web portal home page

This option is disabled by default, but I recommend that you enable it immediately. Basically, this option adds a search box to the home page of your web portal, which encourages visitors to search for answers to their question they first visit your Zendesk web portal. Encouraging customers towards self-service almost always seems like a good idea to me.

Pinned topics on Web portal home page

A Pinned Topic is one that has been highlighted by a forum moderator to appear on the home page of the site. Typically this feature will be used for important announcements that are designed to grab the attention of visitors immediately. This option will determine whether pinned topics are allowed on your web portal. I generally recommend that you keep this feature enabled, but try to limit the number of pinned topics by speaking to your forum moderators. It’s important that your moderators don’t pin too many topics on the home page, because this will distract your visitors from the most important topics. Once enabled, the default setting for this feature is to list the full contents of pinned topics, but I recommend that you change this option to just list the titles instead. Otherwise, the topics tend to take up too much screen real estate. If you elect to keep the full contents of forums pinned to your home page, you have to make an additional decision around the length of pinned topics, etc.

Forum comments

This option determines whether forum comments should be listed oldest-to-newest or vice versa, and is entirely up to the subjective opinion of the administrator. The default is to show the most recent comments at the bottom of the page.

Social Sharing

This feature is disabled by default, but if you’re running a public forum and you hope that your customers will leverage social media to share the topics in your forum, it’s worth enabling this feature. Currently Zendesk supports social sharing on Twitter, Facebook and LinkedIn, an example of which is shown in Figure 9-2.

Figure 9-2. An example of the header of a forum article with social sharing enabled

Once you’ve finished updating the settings on this page, click the Save button and the forum features will be immediately updated.

Figure 9-3 shows the support portal for Box, which is an example of a Zendesk environment that I helped implement, with most of the forums features enabled on the home page.

Figure 9-3. The Box support portal, which leverages most of the forum features on the home page

Types of Forums

Before you add forums, it’s important to understand that for users on the Regular, Plus, and Enterprise plans, there are three different types of forums, which can be summarized as follows:

Articles

This is the simplest type of forum, and is typically used to publish information to your customers. Although articles are typically published by your organization, there’s no reason that they cannot be a bi-directional communication tool to also elicit feedback from your customers by way of comments.

Questions

These forums have a special feature that allows comments to be marked as an Answer, which changes the status of the entire topic to be Answered. This type of forum is most useful when you allow your customers to add their own questions (see Forum Access Restrictions for further information on enabling customer access to forums), but can also be used by your organization to publish common questions to the community.

Ideas

This purpose of this type of forum is typically to allow your customers to add change requests, ideas for improvement, or suggestions for new features in your product or service. The unique feature of each topic in this forum is that the topic can have a status of Planned, Not Planned, or Done.

In the latter two types of forums, it is the responsibility of the forum moderators to mark questions as answered, or ideas as being planned, not planned, or done.

Digressing for a moment, you might remember that when someone adds a new ticket to your support portal, the agent will select the type of that ticket on a ticket-by-ticket basis. Forums topics work slightly differently, because the type of a forum topic—from the list just shown—will be determined by the forum in which it’s added. The type of a forum topic cannot be determined on a topic-by-topic basis.

Adding Categories and Forums

As an administrator, you have complete control over the forums. If you’d like to delegate this responsibility to another member of your team without giving them full administrative privileges, it’s possible to use the Roles function on the Enterprise plan, but not possible on the other plans. See Enterprise Agent Roles and Light Agents for details on how to do this.

To add a new forum category, you’ll need to click the button labeled "add category" in the top-right corner of the forums page. When you add a category, there are really no parameters for you to specify except the name of the category and a description. Once you’ve entered these values, submit the form and your category will be created.

After adding categories, the next step is to start adding forums to the category. This can be achieved by clicking the "Actions" pull-down menu near the top-right of the category, then selecting the option "Add a forum to this category". The form to add a forum contains many more options than the form to add a category, and I’ve explained some of those options in Reordering Categories, Forums, and Topics and Forum Access Restrictions. Otherwise the most important option is the type of forum, and to set this, you’ll need to use the option labeled "Content". The types of forums were described in the Types of Forums section earlier, and this option will only appear for organizations on the Regular, Plus, and Enterprise plans.

Reordering Categories, Forums, and Topics

If you’ve added several categories to your forums, it is possible to reorder those categories by clicking the "Reorder categories" button near the bottom of the forum home page. This button will appear only after you’ve created two or more categories in the forums, and the result is similar to reordering views: each of the categories will appear as a list item that you can drag and drop. Once you’ve finished reordering your categories, click the Done link.

If you’re adding a forum and have selected the type as an article forum, you’ll also see a select list labeled "Order by" on the page to create the forum. The options in this select list allow you to change the ordering of the list of topics in this forum. Question and idea forums do not allow the administrator to change the ordering, but will use the number of votes—in descending order—as the primary criterion for sorting topics, then the number of comments as the secondary criterion.

Once you’ve added several forums, you will be able to change the order in which the forums are listed by clicking the "Reorder forums" option in the Action pull down menu to the right of the category name. Unlike the function to reorder categories—which switches to a list view—this feature will place some arrows and dashed boxes over the top of each of your forums, enabling you to drag and drop the entire box. An example of this interface is shown in Figure 9-4. Once you’ve finished reordering your forums, click the Done button and your new forum order will be saved.

Figure 9-4. The drag-and-drop interface to reorder forums

It’s also possible for you to order the pinned topics on the home page of your Zendesk web portal. Pinned topics are the most important topics, and take prime real estate at the top of the home page. Given that some pinned topics might be even more important than others, it’s possible for you as an administrator to reorder them. To perform this task, you’ll need to visit your Zendesk web portal home page, which is different to the forum home page. If you have some pinned topics already, find them at the top of the page and click the "reorder" link. Once clicked, this option will convert all of the pinned topics to titles only, with gray boxes that allow reordering and a drag-and-drop interface just like the feature to reorder your list of categories.

There are two levels of pinned topics: those that are firmly displayed in the order in which they appear in this configuration, and those that are pinned but will be sorted in the order in which they were created. Figure 9-5, shows two items in the first list and none in the second list. After you’ve finished reordering your pinned topics, click the Save button and the topic order will be updated for visitors to your Zendesk portal home page.

Figure 9-5. The drag-and-drop interface to reorder pinned topics

WARNING

A common mistake by administrators is to visit the web portal home page when looking for the options to reorder categories and forums. Remember to visit the forums home page in order to change the ordering, because the links to reorder these items are not visible on the web portal home page. Pinned topics, on the other hand, can be reordered only from the web portal home page, because they’re not visible on the forum home page.

Forum Access Restrictions

Even though forums are meant for public access, you might want to restrict some of your forums to be visible only to certain people. One example would be an agent forum, which has answers to common questions as a reference point for your support agents. Another example might be a special forum dedicated to customers on your platinum support package, or customers who are running a beta of your software product. Using the tools described in this section, you are able to restrict forum access based on criteria such as these. All of the following options can be found on the page to create or edit a forum:

Who can view topics in this forum?

It’s possible to restrict the topics in this forum to be visible only to users who are logged in to Zendesk, or restrict access to your support agents only. If you elect to leave the forum visible to "Everybody", the topics will also be indexed by search engines such as Google, and will be returned in search results that contain the keywords in the forum topics. Most customers like this feature, and I refer to it in Referring Macros to the Forums as a specific benefit of using the forums to publish answers to common questions.

Who can create topics in this forum?

At the start of this chapter, I described a situation in which your customers might visit your forums and publish their own questions and ideas. This is a big part of Zendesk’s forums feature, and the Zendesk company also does it on their public forums. It’s an easy way to elicit customer feedback about your product or service. In order to allow customers to create their own topics, this option must be set to "Logged-in users", which is the default. On the Starter, Regular, and Plus plans, the alternative is "Unrestricted agents and moderators only". On the Enterprise plan, the alternative is "Moderators only".

Restrict access to organization

I consider this option to be a slightly less flexible version of the "Restrict access to end-users and organizations with all of the following tags" option. Having said that, it can still be useful for organizations that have not enabled user and organization tagging in their Zendesk instance, or simply as a shortcut to restrict visibility to certain customers.

Restrict access to end-users and organizations with all of the following tags

In the section on User and Organization Tagging, I described the ability to tag users and organizations. I said that the concept was simple, because when a user is assigned a tag, tickets created by that user will automatically have that tag added as well. I also mentioned that there was a secondary use of this feature, and this is it. By tagging a user—or the organization to which they are connected—with a certain tag, you can give them access to forums that are restricted to only a specific set of users. The beta example is a good one. If you release a beta of your product and have documentation for exclusive access to the beta, you can tag users on the beta with "beta_user", then restrict your forum to users with that tag. The forum will be totally hidden from users without that tag. In fact, this is how Zendesk itself provides documentation to beta users of its products. It’s also possible to use this feature to allow forum access for an entire organization: just add the tag to an organization instead of a user.

Multi-Language Forums

If you’re on the Plus or Enterprise plans, it’s possible to enable several languages in your Zendesk instance. You can take this one step further with forums by publishing information in a certain language, then restricting access to your forum to users who select that specific language only. This is not for security or privacy purposes; it’s just a courtesy and convenience for your foreign language users. The end result is that when a user opens your forums and selects a specific language, they will only see forum topics in that language.

TIP

In order to make this work effectively, you’ll also need to restrict all of your other forums—including the English forums—to be available only to users who have selected English as their language. Otherwise users who select a non-English language will end up seeing your English forums as well as the forums in their selected language.

The setting to configure this feature is named "Restrict access to end-users whose language is" on the forum creation page. The set of languages in the select list will be restricted to the set that you configured globally, so be sure to read Multi-Language Support for End-Users and select those options before visiting this page.

Ticket Deflection

If you’ve read this chapter and decided that you’re going to start using the Zendesk forums, the good news is that you’ll be able to leverage another feature in the product called Ticket Deflection. The idea of this feature is that when an end-user submits a ticket, Zendesk will match the keywords in the subject line of that ticket with keywords in existing forum topics. If there is a reasonable match, Zendesk will suggest a list of forum topics that might answer the user’s support request, before they even submit the form. As a customer service practice, this saves a lot of time for your agents because it prevents the need to provide an answer personally. From the customer’s perspective, the outcome is an immediate answer to their question. As long as the customer is satisfied with the answer, the benefits of this feature for both parties are win-win.

As I described in Referring Macros to the Forums, keeping your forum topics public also has the benefit that search engines will index the information in them, and it’s possible that your customers can get answers to their questions before they even start the process of submitting a ticket. However, you will need a high volume and a wide variety of topics in your forums before this feature is likely to find matches will be relevant to most users.

An example of the ticket deflection feature used on the Zendesk Support website is shown in Figure 9-6.

Figure 9-6. An example of forum topics suggested by Zendesk based on keywords

This feature is disabled by default, but you can be easily enable it by selecting the checkbox for "Topic suggestions" from the Web Portal section of the Channels administration page. Once the feature is enabled, end-users will immediately start to see related topic suggestions during the process of submitting new tickets. If you’d like to test this feature as an administrator, you’ll need to follow the instructions in the Assuming a User Profile section to assume the profile of an end-user in your instance.

Forum Search Analytics

As you’re populating your forums with useful topics, it’s important to measure the value that is being delivered to your customers, and the ways in which you can increase this value. Zendesk’s Search Analytics feature provides the sort of analysis that will help you to make these decisions.

To make it easier for your customers to search in the forums, your first step should be to follow the instructions in Configuring Forums to enable the forum search box on the home page of your web portal. You should also open the Web Portal section of the Channels administration page and enable the checkbox for "Forum & Search analytics", then save those settings.

Once these settings are enabled and your customers are using your forums for self-service support, every search that they perform will be logged, along with the results of the search, and the specific search terms used. To find this information, you can open the Search tab on the Reporting management page.

The search analytics page has a number of charts with basic information about search trends. This information is useful, but the more relevant and actionable information is at the bottom of the page, beneath the "Top 500 searches" heading. This table highlights the specific search terms used, the number of times that the search was executed, the average number of results, the Click Through Rate (CTR) as a percentage, the number of tickets created, and the link for the top result. Using this table alone, you can draw a number of conclusions and take action, some of which are listed here:

Ensure relevance of top results

For every set of search terms in the list, Zendesk specifies the top clicked result. If you click the search string in the left column, you’ll have access to the complete list of results displayed to customers. Sometimes you’ll find that the most popular result (marked "TOP" in a yellow box) isn’t at the top of the list. Having your most popular result at the top of the list is important, because it encourages visitors with only a cursory attention span to click the most relevant result. To improve the relevance of your results, one technique is to add more relevant terms to the tags on the forum topic, and decrease the uses of the specific terms in the other topics that are less relevant.

Check the accuracy of top results

Top results are the most important ones in your Zendesk forums, because they get the most visitors. It’s a good idea to regularly review the list of top results from the search analytics page, and update the contents of these topics if they are out of date. Not all of your forums topics will be 100% accurate all of the time, but using the search analytics helps to at least ensure that the most popular results are subject to an active review process.

Review searches with no results

The search analytics page contains a chart labeled "With no results". Clicking this chart will filter the table of search terms to only include the searches executed with no results. This is one of the most useful lists you can find in Zendesk, because it will tell you the specific topics for which users need information, but for which your forums don’t have a relevant topic. For every item in that list, it’s a very good idea to publish a new topic with those keywords as soon as possible.

Improve your Click Through Rate (CTR)

If the CTR metric for a particular search is very low, it’s reasonably likely that, although you have a number of topics that meet the search terms, none of those topics address the customer’s inquiry. On the search analytics page, click the "CTR percentage" table heading to sort the results by that field. Find the results with the lowest number of clicks, and then create a topic that is relevant to the search terms entered by the customer.

Reduce the number of tickets created

If you find that the number of tickets created after a customer searches for a particular topic is very high, there’s a strong chance that your topic did not answer that customer’s question. Try ordering the items in the search analytics table by the most number of tickets created, then work on improving the forum topics related those search terms. An ideal number of tickets created for every search is 0, suggesting that the customer’s question was answered every time.

By following the actions in this list, it will be possible for you to constantly improve the information in your public forums. As your number of tickets increase, you’ll also have more material to contribute back to your knowledge base, and after a little while, your Zendesk forums will be so populated with information that the process of providing support to your customers is so simple that it’s almost zen-like.

About the Author

Stafford Vaughan started computer programming at an early age. He grew up near Sydney, Australia, and found his first job at CustomWare, a software services company that specializes in the technology of fast growing software companies. In his time at CustomWare, Stafford has personally established the training departments of several companies, including Zendesk, Atlassian, and GoodData, and authored several of the official training programs for software products including Zendesk, JIRA, Confluence, GreenHopper, and GoodData.

As an educator, Stafford has delivered training sessions to more than a thousand organizations in 15 countries, including NASA, the Pentagon, the United Nations in Geneva, Harvard University, Stanford Graduate School of Business, Groupon, the US Department of Commerce, Sun Microsystems, and Wells Fargo Bank.

Stafford holds a Bachelor of Software Engineering degree from the University of Newcastle, he is a CompTIA Certified Technical Trainer (CTT+), a Sun Certified Programmer for the Java 2 Platform (Standard Edition 5.0), a Microsoft Certified Application Specialist (PowerPoint 2007), and an Adobe Certified Expert (Photoshop CS5).

Stafford currently lives in San Francisco and works in Silicon Valley. In his spare time he is a keen hiker and serves as a volunteer mentor at the San Francisco SPCA.

Practical Zendesk Administration

Stafford Vaughan

Editor

Mike Loukides

Revision History

2012-10-10

First release

Copyright © 2012 Stafford Vaughan

O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.

Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Practical Zendesk Administration, the image of the European nightjar, and related trade dress are trademarks of O’Reilly Media, Inc.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps.

While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

O’Reilly Media

1005 Gravenstein Highway North

Sebastopol, CA 95472

2012-10-12T08:30:21-07:00

Table of Contents

Practical Zendesk Administration

Dedication

Foreword

Preface

Chapter Overviews

Zendesk Version

Conventions Used in This Book

Safari® Books Online

How to Contact Us

Acknowledgments

1. Introduction to Zendesk

Explanation of the Zendesk Plans

Terms and Definitions

User Interface Experience

Steps to Administer Zendesk

Internal Versus External Customer Service

2. Initial Setup

Creating a Sandbox

Web Portal Branding

Customizing the Zendesk URL

Internationalization

Administrator Interface Language

Setting the Time Zone

Multi-Language Support for End-Users

Dynamic Content for Text Translation

Outgoing Email

Email Notification Sender Address

Personalized Email Replies

Sender Policy Framework (SPF) Settings

3. Security

Social Media Logins

Suspended Tickets

Public Creation of User Profiles

Blacklists and Whitelists

Password Strength Policy

Secure Sockets Layer (SSL)

Enterprise Security and Compliance

4. User Management

Administrators

Agents and Roles

Groups

Agent Signatures

Adding an Agent Account

Enterprise Agent Roles and Light Agents

Configuration Options for Agent Roles

Adding an Agent on the Enterprise Plan

End-User Access

Creating an End-User

Merging End-Users

Suspending End-Users

Organizations

Shared Organizations

5. Channels

Incoming Email

Adding Incoming Email Addresses

Agent Forwarding

Voice

Adding Phone Numbers

Call Center Configuration

Recording Greetings

Call Activity Dashboard

Feedback Tab

Creating a New Feedback Tab

Publishing a Feedback Tab

Managing Existing Feedback Tabs

Chatting

Setting Up Chat

Chatting from a Ticket vs a Feedback Tab

Twitter

Selecting a Twitter Handle for Zendesk

Authorizing a Twitter Handle

Linking in Tweets

Saved Searches

Facebook

Authorizing the App

Monitoring Posts and Messages

Ticket Sharing

6. Fields and Data Capture

Data Capture Lifecycle

End-User Fields

Required Fields

System Fields

System Field Configuration

Ticket ID

Subject

Description

Carbon Copy (CC)

Requester

Ticket Status

Ticket Types

Priority

Group and Assignee

Tags

Comments

Attachments

Screencasts

Custom Fields

Ordering Fields

Reading the List of Ticket Fields

7. Agent Support Process

Restricting Agent Access to Tickets

Presumptive Solve Approach

Views

Understanding View Conditions

Required Fields for Views

Shared Views

Macros

Adding a Shared Macro

Macro Menus

Referring Macros to the Forums

8. Automated Business Rules

User and Organization Tagging

Triggers

Default Triggers

Trigger Conditions and Actions

Trigger Examples

Ordering Triggers

Mutually Exclusive Triggers

Automations

Default Automations

Automation Examples

Nullification of Automations

Auditing Business Rule Use

Email Notifications

Bi-Directional Email Communication

Email Notification Template

Mail Delimiter

Placeholders

Customer Satisfaction

9. Forums

Terms and Definitions

Forum Users

Configuring Forums

Types of Forums

Adding Categories and Forums

Reordering Categories, Forums, and Topics

Forum Access Restrictions

Multi-Language Forums

Ticket Deflection

Forum Search Analytics

About the Author

Copyright