Sort by Topics, Resources
Topics
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Salto for
Zendesk
Articles
SHARE
Best practice for Zendesk views
Jude Kriwald
February 16, 2023
9
min read
As a Zendesk administrator, one of your most crucial jobs is to provide views that your Customer Service or Operations teams can use so intuitively that they never have to stop and question their setup.
As any Zendesk admin knows, however, creating a views architecture that offers this user-facing simplicity whilst also dealing with complex ticket types that need accumulating or separating is no small task. On top of this, views need to be robust and fool-proof, meaning that an agent who misunderstands how to use them can never send a ticket down a so-called “ticket blackhole”, where it disappears from all views and ensures an unhappy customer.
Below, I’ll share my key insights into what makes a Zendesk views setup that your stakeholders will love whilst ensuring maintenance and setup is as pain-free for you as can be.
First Decision - View Organization
Your first (and most important) decision is how to split the views. Do you want one view for each ticket status? Or would your team prefer to have tickets separated out by ticket category? Perhaps your key stakeholder has asked for tickets to be split by channel.
If you’re administering an Enterprise account, it’s quite possible that you’ll be asked to do all of the above iterations (and more) simultaneously, depending on who is logged into Zendesk.
Let’s start by taking a look at the default views that Zendesk gives us.
Looking at the default views, it seems that Zendesk is trying to show Zendesk newbies some of the capabilities it has to offer. In reality, very few Zendesk admin will choose to keep their instance with these default views. As we discussed earlier, our aim is to create views that our stakeholders want to use and can do so without having to think.
In any categorization exercise, it’s useful to remember the “mutually exclusive, collectively exhaustive” principle (MECE).
In the context of Zendesk views, MECE dictates that between all of the views, every ticket should be displayed (this is the collectively exhaustive part), and that the contents of each view do not overlap (this is the mutually exclusive part), otherwise the same ticket will appear in multiple views at once.
With the MECE framework in mind, we can see that whilst the default Zendesk views are collectively exhaustive (we know this as one of the views is called “All unsolved tickets”). It is not, however, mutually exclusive, as a ticket could exist in multiple views at once, such as Your unsolved tickets, All unsolved tickets, Recently updated tickets, New tickets in your groups and Unsolved tickets in your groups.
Imagine logging in to Zendesk only to see that some tickets appear in multiple views at once - you wouldn’t know where to start. So, with the exception of the All unsolved tickets view, which we’ll come back to later, it’s smart to design these views to be mutually exclusive.
This is particularly useful in a customer service tool such as Zendesk, given that agents and team leaders are often targeted on “clearing” the ticket numbers down to 0. With mutually exclusive views, team leaders and agents know that if one view shows six tickets and another shows 10, they need to answer 16 tickets to clear their views and respond to all open queries. This practice also helps avoid the situation of two people working on the same ticket at the same time, having navigated to it from two separate views. In the budget-conscious world of customer-service teams, smooth-running teams like this make all the difference.
.png)
Start with Your Stakeholder(s)
As an administrator of any system, it can be easy to assume we know the best way of doing something. But we must remember that our job is to design a system for our users. That means putting them first, rather than any fancy ideas we may have of how we’d like to use it if we were the agent, as we’re not!
If you already work with your stakeholder (perhaps you’re an internal Zendesk administrator), then you may already have a good idea of how they like to segment their ticket workload. On the other hand, if, like me, you’re a freelance Zendesk consultant who may be new to the client’s specific needs, then it’s worth having a meeting to agree on the views setup.
Whilst it’s good to ask your client/stakeholder’s needs, don’t forget that your job is also to provide guidance, and many stakeholders won’t know where to start without your input first.
Below are some of the most common setups that might work for you, as well as my suggestion of further considerations you should bear in mind.
How to Categorize Zendesk Views
Split Views by Ticket Status
This ultra-simplistic approach splits all tickets by their status (note that the bottom two views, Suspended tickets and Deleted tickets, are system views that cannot be removed).
This approach works best for small companies that receive a low volume of tickets and don’t have multiple teams answering different types of requests. It encourages the proper use of Zendesk’s ticket statuses.
Pro-tip: if you have pending automations set up (to automatically solve tickets X days after they are moved to the Pending status, then you could remove the Pending view. This is because, by definition, Pending tickets need no action from agents and will either become Open or Solved soon. Any step to simplify what agents see (without losing useful information) is a worthwhile endeavour.
Split Views by Channel
This setup is quite common owing to its simple reasoning. Unlike the previous approach, this one allows for different teams to manage different channels, perfect for when your customer service team looks after emails but the marketing team needs to keep an eye on Facebook.
As in the above example, this approach is only really worthwhile when each channel requires a different kind of response. This may be due to each channel having different types of customer queries, or it could be that you have tighter SLAs for Whatsapp than you do for emails, owing to the 24-hour reply window with Whatsapp.
Split Views by Teams
Whilst the previous approach works well for businesses that aren’t always evolving (e.g. not startups), it’s worth considering what will happen as the company grows. If the marketing team is responsible for Whatsapp and the CS team looks after Email, what happens when the marketing team creates a campaign that requires customers to email in to a new email address? Would you change the Whatsapp view to “Whatsapp + Marketing Emails), or perhaps create a new email called “Email - Marketing”?
A simpler approach would be to separate Views by team from the start, so that as new channels are added into Zendesk, those channels can be plugged directly into the existing relevant team’s view. A business is far more likely to create a new comms channel than to create an entirely new team. Thus the team-based view is arguably the best one-size-fits-all approach as it allows the agents stability (the views never change) whilst allowing you to add new channels to pre-existing views.
Company-Specific Requirements
Whilst the above is a great place to start off your Zendesk view development, any Zendesk admin responsible for a large company’s instance will no doubt need to add subdivisions to the teams-based approach.
For example, you may require one view for Customer Service emails and another for Customer Service voicemails. Ultimately, the exact requirements will be informed by taking the time to understand how the agents and their managers approach solving tickets, both in terms of ticket priority and skill-based agent assignment.
Best practice dictates that we don’t create so many views that agents start to struggle to find what they’re looking for, so take time to consider which views can be combined and which ones really benefit from being standalone.
The Must-Have Failsafe View
The views we have considered above are all designed to ensure that agents can do their job as easily as possible. But what about helping out the managers, who are responsible for the agents?
We saw earlier why the MECE principle is an important consideration for any categorizing task. We just covered how to split the views, so you’ve hopefully now got some ideas on how you’d like to make yours mutually exclusive. But how do we ensure that they’re collectively exhaustive?
What if you’ve made one view that you think will display most tickets, and a second view that will display all others but, in fact, there’s a rarely-used channel you’ve missed out? Zendesk “blackholes” occur more than most Zendesk admins would care to admit. They happen when the views you set up have been so specific that, unintentionally, there are certain types of tickets that don’t show up in any of the views.
This will cause these tickets to never be found by agents, so we must mitigate this possibility. Of course, one option is to double and triple sense-check our view configurations. This works fine for very simple setups but, beyond this level, it’s worth admitting that we can all have oversights.
The solution is then, by necessity, a simple one. We create a view which is set up to display all unsolved tickets, with the oldest showing at the top. That way a manager or team leader can keep an eye out to ensure that the oldest unsolved ticket is never older than they’d expect.
Here are the parameters I normally use:
View name: All Unsolved Tickets
Condition: Status - Less Than - Solved
Group by: (No group)
Order by: ID (ascending)
This places your oldest unsolved ticket right at the top, making it easy to check that all tickets are being seen to properly.
For a bonus level of satisfaction, if all of your other views have followed the mutually exclusive, collectively exhaustive principle, you won’t even need to open this view to check that your views are working properly, as the sum of all your MECE views will equal the number of tickets in your All Unsolved Tickets view.
Summary
To summarise, you’ll need to balance out your stakeholder’s desires with what is both technically achievable and also practically functional. Ensure that you plan this stage before building commences, and consider using the MECE principle to keep your output simple and easy to understand.
If you’re a small business who intends to stay that way, views based on ticket status or channel work well, otherwise a team-based approach is the best-place to start as agents can easily identify the view they’re supposed to work from.
Setting up this gives you both a simple and quick method to set up, whilst also ensuring there is little to no technological debt when the request to add more channels or functionality to Zendesk inevitably arrives.
.jpg)
WRITTEN BY OUR EXPERT
Jude Kriwald
Zendesk Consultant
Jude Kriwald first learned to administer Zendesk in 2015 and has been helping businesses improve their customer operations as a freelance consultant since 2018. Offline, he can be found making maps, paragliding or exploring remote places.
What’s next?
Knuckles has suggestions
Business App Configuration. Re-Imagined.
© Copyright Salto 2024 | Various trademarks held by their respective owners
Sort by Topics, Resources
Topics
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Salto for
Zendesk
Zendesk
SHARE
Best practice for Zendesk views
Jude Kriwald
February 16, 2023
9
min read
As a Zendesk administrator, one of your most crucial jobs is to provide views that your Customer Service or Operations teams can use so intuitively that they never have to stop and question their setup.
As any Zendesk admin knows, however, creating a views architecture that offers this user-facing simplicity whilst also dealing with complex ticket types that need accumulating or separating is no small task. On top of this, views need to be robust and fool-proof, meaning that an agent who misunderstands how to use them can never send a ticket down a so-called “ticket blackhole”, where it disappears from all views and ensures an unhappy customer.
Below, I’ll share my key insights into what makes a Zendesk views setup that your stakeholders will love whilst ensuring maintenance and setup is as pain-free for you as can be.
First Decision - View Organization
Your first (and most important) decision is how to split the views. Do you want one view for each ticket status? Or would your team prefer to have tickets separated out by ticket category? Perhaps your key stakeholder has asked for tickets to be split by channel.
If you’re administering an Enterprise account, it’s quite possible that you’ll be asked to do all of the above iterations (and more) simultaneously, depending on who is logged into Zendesk.
Let’s start by taking a look at the default views that Zendesk gives us.
Looking at the default views, it seems that Zendesk is trying to show Zendesk newbies some of the capabilities it has to offer. In reality, very few Zendesk admin will choose to keep their instance with these default views. As we discussed earlier, our aim is to create views that our stakeholders want to use and can do so without having to think.
In any categorization exercise, it’s useful to remember the “mutually exclusive, collectively exhaustive” principle (MECE).
In the context of Zendesk views, MECE dictates that between all of the views, every ticket should be displayed (this is the collectively exhaustive part), and that the contents of each view do not overlap (this is the mutually exclusive part), otherwise the same ticket will appear in multiple views at once.
With the MECE framework in mind, we can see that whilst the default Zendesk views are collectively exhaustive (we know this as one of the views is called “All unsolved tickets”). It is not, however, mutually exclusive, as a ticket could exist in multiple views at once, such as Your unsolved tickets, All unsolved tickets, Recently updated tickets, New tickets in your groups and Unsolved tickets in your groups.
Imagine logging in to Zendesk only to see that some tickets appear in multiple views at once - you wouldn’t know where to start. So, with the exception of the All unsolved tickets view, which we’ll come back to later, it’s smart to design these views to be mutually exclusive.
This is particularly useful in a customer service tool such as Zendesk, given that agents and team leaders are often targeted on “clearing” the ticket numbers down to 0. With mutually exclusive views, team leaders and agents know that if one view shows six tickets and another shows 10, they need to answer 16 tickets to clear their views and respond to all open queries. This practice also helps avoid the situation of two people working on the same ticket at the same time, having navigated to it from two separate views. In the budget-conscious world of customer-service teams, smooth-running teams like this make all the difference.
Start with Your Stakeholder(s)
As an administrator of any system, it can be easy to assume we know the best way of doing something. But we must remember that our job is to design a system for our users. That means putting them first, rather than any fancy ideas we may have of how we’d like to use it if we were the agent, as we’re not!
If you already work with your stakeholder (perhaps you’re an internal Zendesk administrator), then you may already have a good idea of how they like to segment their ticket workload. On the other hand, if, like me, you’re a freelance Zendesk consultant who may be new to the client’s specific needs, then it’s worth having a meeting to agree on the views setup.
Whilst it’s good to ask your client/stakeholder’s needs, don’t forget that your job is also to provide guidance, and many stakeholders won’t know where to start without your input first.
Below are some of the most common setups that might work for you, as well as my suggestion of further considerations you should bear in mind.
How to Categorize Zendesk Views
Split Views by Ticket Status
This ultra-simplistic approach splits all tickets by their status (note that the bottom two views, Suspended tickets and Deleted tickets, are system views that cannot be removed).
This approach works best for small companies that receive a low volume of tickets and don’t have multiple teams answering different types of requests. It encourages the proper use of Zendesk’s ticket statuses.
Pro-tip: if you have pending automations set up (to automatically solve tickets X days after they are moved to the Pending status, then you could remove the Pending view. This is because, by definition, Pending tickets need no action from agents and will either become Open or Solved soon. Any step to simplify what agents see (without losing useful information) is a worthwhile endeavour.
Split Views by Channel
This setup is quite common owing to its simple reasoning. Unlike the previous approach, this one allows for different teams to manage different channels, perfect for when your customer service team looks after emails but the marketing team needs to keep an eye on Facebook.
As in the above example, this approach is only really worthwhile when each channel requires a different kind of response. This may be due to each channel having different types of customer queries, or it could be that you have tighter SLAs for Whatsapp than you do for emails, owing to the 24-hour reply window with Whatsapp.
Split Views by Teams
Whilst the previous approach works well for businesses that aren’t always evolving (e.g. not startups), it’s worth considering what will happen as the company grows. If the marketing team is responsible for Whatsapp and the CS team looks after Email, what happens when the marketing team creates a campaign that requires customers to email in to a new email address? Would you change the Whatsapp view to “Whatsapp + Marketing Emails), or perhaps create a new email called “Email - Marketing”?
A simpler approach would be to separate Views by team from the start, so that as new channels are added into Zendesk, those channels can be plugged directly into the existing relevant team’s view. A business is far more likely to create a new comms channel than to create an entirely new team. Thus the team-based view is arguably the best one-size-fits-all approach as it allows the agents stability (the views never change) whilst allowing you to add new channels to pre-existing views.
Company-Specific Requirements
Whilst the above is a great place to start off your Zendesk view development, any Zendesk admin responsible for a large company’s instance will no doubt need to add subdivisions to the teams-based approach.
For example, you may require one view for Customer Service emails and another for Customer Service voicemails. Ultimately, the exact requirements will be informed by taking the time to understand how the agents and their managers approach solving tickets, both in terms of ticket priority and skill-based agent assignment.
Best practice dictates that we don’t create so many views that agents start to struggle to find what they’re looking for, so take time to consider which views can be combined and which ones really benefit from being standalone.
The Must-Have Failsafe View
The views we have considered above are all designed to ensure that agents can do their job as easily as possible. But what about helping out the managers, who are responsible for the agents?
We saw earlier why the MECE principle is an important consideration for any categorizing task. We just covered how to split the views, so you’ve hopefully now got some ideas on how you’d like to make yours mutually exclusive. But how do we ensure that they’re collectively exhaustive?
What if you’ve made one view that you think will display most tickets, and a second view that will display all others but, in fact, there’s a rarely-used channel you’ve missed out? Zendesk “blackholes” occur more than most Zendesk admins would care to admit. They happen when the views you set up have been so specific that, unintentionally, there are certain types of tickets that don’t show up in any of the views.
This will cause these tickets to never be found by agents, so we must mitigate this possibility. Of course, one option is to double and triple sense-check our view configurations. This works fine for very simple setups but, beyond this level, it’s worth admitting that we can all have oversights.
The solution is then, by necessity, a simple one. We create a view which is set up to display all unsolved tickets, with the oldest showing at the top. That way a manager or team leader can keep an eye out to ensure that the oldest unsolved ticket is never older than they’d expect.
Here are the parameters I normally use:
View name: All Unsolved Tickets
Condition: Status - Less Than - Solved
Group by: (No group)
Order by: ID (ascending)
This places your oldest unsolved ticket right at the top, making it easy to check that all tickets are being seen to properly.
For a bonus level of satisfaction, if all of your other views have followed the mutually exclusive, collectively exhaustive principle, you won’t even need to open this view to check that your views are working properly, as the sum of all your MECE views will equal the number of tickets in your All Unsolved Tickets view.
Summary
To summarise, you’ll need to balance out your stakeholder’s desires with what is both technically achievable and also practically functional. Ensure that you plan this stage before building commences, and consider using the MECE principle to keep your output simple and easy to understand.
If you’re a small business who intends to stay that way, views based on ticket status or channel work well, otherwise a team-based approach is the best-place to start as agents can easily identify the view they’re supposed to work from.
Setting up this gives you both a simple and quick method to set up, whilst also ensuring there is little to no technological debt when the request to add more channels or functionality to Zendesk inevitably arrives.
Business App Configuration. Re-Imagined.
© Copyright Salto 2024 | Various trademarks held by their respective owners