My approach to Zendesk Views

In this article I explain my approach to Zendesk Views, and how you only need 8 views to make an efficient setup.

My approach to Zendesk Views

For a long time now Zendesk had this strict limitation of 12 Shared Views, and 8 personal views. And even though they announced an expansion of this with a supported 30 shared, and 10 personal views later this month, I'm of the opinion that you don't need more than 12.

Announcing improvements to the views experience in Support
Announced on Rollout starts Rollout ends September 11, 2023 September 29, 2023 October 6, 2023 In response to customer feedback, Zendesk will be improving the views experience on September 29,…

How to use Views

There are a couple of approaches to how people setup views:

  1. Views show work to be done by an agent
  2. Views show work that is already done
  3. Views give insights in a subset of tickets
  4. Views split up tickets to create different queues.

For me, Views serve a very specific purpose: they are there to inform agents on the status of their work, and should offer the most urgent ticket first.

Any other feature or setup is secondary to this.

So if you use views to get insights in specific subsets of tickets, to get an overview of your entire inbox, or to filter to a very specific subset of tickets, well, in my opinion those views aren't views, but should be setup as dashboards and reports in Explore.

How I approach views

When I setup a Zendesk instance for customers, I'm a big proponent of the idea of moving tickets through statuses and have agents only touch active tickets that require their attention.

In a good Zendesk setup your agent live in specific groups that define what they are working on.

Examples are: first line/second line or support/sales/finance or any other grouping. An agent belongs to one or more groups, and their job is responding to the tickets in their group and get the queue empty.

This is the way I imagine an ideal Zendesk flow:

  1. A ticket is created by a customer.
  2. Triggers assign the ticket to a specific group and set urgency to the ticket, this could be based on custom fields, Zendesk AI intents, brand, form or any other ticket metadata,
  3. SLA policies set a first-reply and next-reply time for each ticket based on ticket group and priority.
  4. The ticket appears in an "Open Tickets" view for agents that contains all new and open sorted by SLA, so the first SLA to breach is top.
  5. Agents can do four things, and each one of them removed the ticket from their "Open Tickets" view:
    1. Reply to a ticket and solve it – the issue is resolved and they don't expect feedback
    2. Reply to the ticket and put it on pending – meaning they need customer input
    3. Reply to a ticket and put it on hold, often combined with a side conversation or internal comment – meaning it needs internal action
    4. Reassign to a different department
  6. Whenever a ticket gets a reply, being it from a customer or colleague will re-open the ticket and resurface it in the "Open Tickets" view. As long as we're waiting, the ticket is out of side and out of mind. Once they re-appear we go back to step (5) until we reach a solved status.
You can automate moving tickets from on hold or pending to open by making use of automations. This way agents can be sure that no tickets gets stuck in those statuses, and tickets are kept moving towards a solved status. Check out this article for more info on how to do this!

The views I use

Whenever I deploy a Zendesk setup, it contain these eight shared views. And I rarely add any more then these:

➡️ My Tickets

Tickets where the current agent is the assignee, sorted by SLA. Depending on if the customer uses Omnichannel Routing or not this view is either on top (if routing is on agents solely work with assigned tickets), or lower in the view order (if agents pick their own tickets)

📥 Open Tickets

This view contains all tickets in a NEW or OPEN status. The view is sorted by an Ascending SLA (first to breach on top).

This views is available for all agents, but is filtered to only show tickets to the groups the agent belongs to.

It also removes all Problem tickets from the view.

This is the default view that agents should work from, except when using OmniChannel routing.

⏸️ Pending Tickets

This view shows all PENDING tickets, sorted by oldest agent reply on top.

Since I have two custom statuses "Pending - waiting for information" and "Pending - Waiting for confirmation", I group them by Status Category.

This views is available for all agents, but is filtered to only show tickets to the groups the agent belongs to.

⏭️ On Hold Tickets

This group shows all ON HOLD tickets, sorted by oldest agent reply on top.

This views is available for all agents, but is filtered to only show tickets to the groups the agent belongs to.

⚠️ Active Problem Tickets

All open problem tickets. Useful to assign a few agents to handling the current crisis, while others focus on the rest of the tickets.

🕣 Recently Updated Tickets

This tickets shows all tickets which were updated in the last two days by either an agent or end-user. This is useful for team leads to get an overview of what's happening. I sort these by most recent on top. And as always, they are filtered by the group the current user belongs too

✅ Recently Solved Tickets

This tickets shows all tickets which were solved in the last three days, sorted by creation date, and once again filtered by the group the agent belongs too.

Useful to quickly detect recurring issues over the span of a few days

👍 Recent Feedback

Tickets of the last week that got a recent CSAT score, sorted by ID and grouped per Feedback Type, in a descending order, so the bad ones appear on top. Handy for reaching out to angry customers.

A word on groups

As you see, all views are scoped on the group an agent belongs too.

So in a setup where there are 10 open tickets, 6 for first line, 4 for second line, an agent in the First Line group would see 6 in their Open tickets view, and a Second Line Agent would see 4. A team lead who works in both teams would see 10.

For every agent the closest SLA breach-ticket would be the top most, so you can be sure every ticket gets handled in relationship to your SLAs, which would, normally, make sure all customers get a reply in time.

Since the job of an agent is to reply to customers with a correct answer within an SLA, there's no reason any agent should see tickets in their views they shouldn't work on. And by scoping views to a specific agents' group, you only need one view that can be shared across all agents, instead of creating a view per department with almost identical parameters. So instead of creating a "First Line open tickets" "Second Line open tickets" view, you only need one.

A word on reporting

But... but what if I need to see how many tickets are created about "Refunds"? How do I know the workload of the Finance team which I'm not a part of? How can I see all tickets assigned to John?

That's where Zendesk Explore comes in. Any insight you need with regard to current workload, backlog, tickets per intent or any other filter should be done in Explore. It gives a more nuanced view, has better filters, and, frankly, reduces the frustration with having only 12 views available.

Additional Views

My above view approach still leaves room for four more shared views, and doesn't touch the personal views.

So if you really need to have a specific view for legitimate reasons you can still create them within that available space.

For example, a finance team in Zendesk might want a separate view for "Refunds" because sometimes its easier to just handle all refund tickets in one queue instead of mixing refunds with payment inquiries and invoice changes. So for that use case you can use one of the four slots for a "Refunds View" that contains all open refund tickets, shared with only the Finance team.

Similarly, you could create a few personal views to get insights in data instead of going to Explore each time.

But whenever you see yourself building a bespoke complex view with a lot of parameters, take a step back and think: since these tickets are also available in one of the 8 basic views, does this view help agent resolve tickets faster? Or is this a view I need for reporting?

And if that view helps those tickets be solved faster, try fixing it by changing the priority of these tickets, so they appear in the right place in your "Open Tickets" queue

Agent Home

The new limits for views are not a bad thing. There are realistic use cases where you might need just that one additional view, and resorting to third party apps like Viewer (Built by me), Better Views or Lovely Views always felt a bit like hack.

But in a Zendesk world where OmniChannel routing, skill based assignment and the new Agent Home are becoming the de-facto standard, you should reconsider your approach to views and start thinking from the idea of a ticket queue where Zendesk surfaces work to agent based on priority and sla, instead of a micro-managed view based approach with dozen if separate inboxes.

And once Agent Home, currently in EAP, becomes widely available, the focus of your agents will shift from Views to the new Home, where the Your Work tab will provide them an SLA sorted list of assigned work, very similar to the "My Tickets" and "Open Tickets" view I proposed above anyhow.

So here's your homework:

  1. Make sure every ticket gets a priority, group and ticket type assigned
  2. Create those 8 views, put them as the top most views and make them available for your 3 best and 3 worst agents.
  3. Test, validate, and deploy for all agents.