Zendesk on Zendesk is a day-long discussion about a specific topic and how Zendesk Support uses Zendesk. Each session is hosted by a member of our Support team.

This session is about how we decide which apps to install in our Zendesk instance and strategies for maximizing app usefulness. 

This session is hosted by Jim Nestell, a Support Operations Manager in our Madison office. See all of our Zendesk on Zendesk series discussions.

Introduction

Here at Zendesk, we use a variety of public and private apps to optimize our support workflows. For a long time, anyone with admin access could add any app to our Zendesk instance. As we continue to grow, though, there are more and more ideas and requests for apps in our own Zendesk instance, and we have to take a wider perspective before installing an app. Departments across the company, from Finance to Documentation, work out of our Zendesk instance, and it can be tricky to meet every different request without interfering with any other workflows. Here are some of the factors we take into account for managing apps and strategies to address them.

Maximizing visual real estate and placement

While there’s no official limit on how many apps you can install in terms of performance issues, there is a limited amount of space available in the UI to display them. The Apps that appear “above the fold”, or without having to scroll down, are easier to access than those that are “below the fold.” Since support advocates do the majority of work on tickets, apps that they use frequently get priority placement at the top of the Apps panel. 

Where it goes is also a consideration. When determining where an app lives, we consider what goal of the app is and who the intended the users are. Administrator-focused apps make more sense in the left sidebar next to other admin options. Apps in the left navigation bar will also have the most screen real estate available, which makes it an ideal spot for admin-focused apps that contain lots of configuration options. 

Apps that help with part of the ticket workflow go in the ticket Apps panel so they’re easy to access while working on a ticket. For example, the Pathfinder app, which displays the requester’s Help Center searches and article views, lives in the ticket Apps panel:

For more details about app order and placement, see Managing your installed apps. 

Consolidating app functions

With so many departments and roles using our Zendesk for a variety of workflows, there are a lot of requests that apply only to one very specific area. These requests are often "singletons", meaning a single use case is packaged in its own app.

 When this is the case, we compare it with existing apps and make a deliberate choice between it being a singleton, or if it could be included with features of another (possibly already existing) app. If the features are logically consistent with another app that is trying to achieve similar goals, it probably makes sense to include it with that app rather than rolling a new one. 

Clarifying app goals early in the process

To maximize how UI space is used and prevent overlapping or contradictory apps as described above, we have a set of guidelines for thinking through specifics of what needs an app is meeting before adding it to our Zendesk.

The first step is to think through how the app will fit into our existing set of apps. This includes questions such as:

• Who are the stakeholders? Who will be using the application?
• What impacts could your app (or changes to an app) have on Z1 or other Zendesk processes?  If you don't know, who might be champions that we can rely on to help us find out?
• Does the app interface with 3rd party tools? If so, it may need to go through security review, which support ops can help facilitate
• What other risks could be associated with your application? Examples:
• Security
• Legal
• Compliance
• How do we control access to the application?  (groups, roles, etc.)
• What location in Zendesk does the application live? (eg. ticket, top bar, side bar, etc)
• For private apps:
• • What is the name of the app? Does it appropriately reflect its purpose?
  • Who owns the project?
  • Who are the contributors to the project?
  • Where will it live in Github?
  • Who’s maintaining the app? Someone needs to fix the bugs and plan new releases!

The next step is to catalog who the users are going to be for the app.  Most likely, the idea for an app came from some past work of various staff that someone notices could potentially be made easier. We list of all the users who could benefit from this improvement. For example, even if an app came from an idea when talking to someone from IT, it might still also be useful for support advocates. Talking with representatives from the different user groups about the idea to helps get a complete picture of what they would like and how they want to use the app. It can also help determine whether the need can be met by using an existing app or if a new private app is required. As mentioned above, our goal is to tweak or add to existing apps whenever possible.

If it's determined that a private app is necessary, the next step is to write a user story. A user story is a way to index what users want out of an app. They help manage the sometimes overwhelming number of functionality requests that are received by users of the app, and they can be used to help plan releases based on how long a story will take versus the amount of time there is to develop the release. User stories have a specific format that is designed to remove as much ambiguity as possible, and to help developers better understand for whom, what, and why they're developing features:

As a <type of user> I want to <description of features requested> so that I can <benefits of requested features>.

Before even thinking about how an app should work, we ask private app requesters to take the time to create stories that reflect the purpose of the app. All the users from the list made earlier need to be represented in these stories. Even if the description of features is the same or similar, the benefits might be different for each type of user.  Stories should also account for error conditions. How does the user want the app to respond to errors?

Once the user story is complete, it's easier to make some important decisions regarding how the app works, who it is geared towards, and where the story's features should ultimately live. Using the described list of features, we make deliberate decisions about how your application should behave to achieve the goals of all the stories. The story provides a complete picture for the features, so it can serve as the "source of truth" when designing the functionality of the application. If someone requests changes to any features later, the private app owner can decide whether to alter a story (before design/development, ideally) or to create a new story to be considered in a future release.

 ----------------------

What do you consider when deciding whether to install an app? How do you determine the placement and order in your Zendesk? What strategies do you have to maximize efficiency and avoid redundant apps? Share your own experience and ask questions in the comments section below!