Admin Pro Tip: Views - Your Hidden Super-Map – Available ApS

In many organisations the same challenge crops up: a chaotic and unmanageable list of views that are only used sporadically and that make agents' work harder rather than easier. The best-functioning teams typically do not have hundreds of views, but a handful that are sharp, precise and so effective that they act as a GPS map for the agents, guiding them straight to the next task.
A view is not just a list of tickets. A well-functioning view supports a workflow. It acts as a prioritised to-do list, a tool for identifying bottlenecks and a "super-map" for navigating the daily flow of customer enquiries. This article gathers knowledge on how views can be built, maintained and exploited to make a Zendesk instance more manageable and efficient.

Why Views are one of the most important tools

Before going through the specific tips, it is essential to establish why views are fundamental. Views are often perceived as a simple search function, but their real strength lies in their ability to shape behaviour and create focus.

When an agent logs in, views are typically the first thing displayed. Views therefore define the working day. An unstructured list of hundreds of tickets can create a loss of overview and inefficiency. Conversely, three or four clearly defined and prioritised lists provide a clear focus.

Views are a primary tool for:

Automating prioritisation: Instead of manually assessing which ticket is most important, a view can prioritise based on data.
Ensuring consistency: A good view supports agents in following the same workflow and prioritising in the same way.
Reducing cognitive load: The agent's energy is spent solving the customer's problem rather than finding the next task.
Creating transparency: Views provide insight into the flow of work, including where bottlenecks arise and which enquiries take a long time.

Mastering views means mastering the workflow in Zendesk and is a direct way to influence agents' efficiency and wellbeing.

The 5 Views every agent should have

There are many view configurations, from very few views to set-ups with more than 50. Experience points to a "golden middle ground". For most teams, the following five views form a solid starting point that covers the majority of daily needs.

1. My Open Tickets (The Personal Inbox)

This view is the core of the agent's personal area of responsibility and provides a quick overview of tickets that the agent is working on or is responsible for.

Purpose: To show all assigned, unsolved tickets for the current user.
Build instructions:

Ticket | Status | Less than | Open
Ticket | Assignee | Is | Current user
Sorting: Updated (ascending)

Pro Tip: An extra condition can be used to filter out spam or test tickets, e.g.: Ticket | Tags | Does not contain at least one of | spam, internal_test. The Updated (ascending) sorting is key, as it ensures that tickets that have waited longest for an update sit at the top, which reduces the risk of forgotten tickets.

2. New Unassigned Tickets (The Triage Queue)

This view acts as the team's inbox, where new enquiries land before they are assigned to an agent. The purpose is a shared overview and quick assignment based on availability or expertise.

Purpose: To show all new, open tickets that have not yet been assigned.
Build instructions:

Ticket | Status | Less than | Open
Ticket | Assignee | Is | - (None)
Sorting: Created (ascending)

Pro Tip: In larger teams the view can be split further, e.g. by channel ("New Emails" and "New Chats"). A more advanced move is to use macros to automatically add a tag on assignment (e.g. assigned_email_team) and then create a view with Assignee: - AND Tags: Does not contain at least one of: assigned_email_team, assigned_chat_team to catch tickets that would otherwise fall through the cracks.

3. Tickets Waiting on Me (The Follow-up List)

This view supports proactive service by showing tickets where a reply from the customer is awaited. Without such a view it is easy to lose track of follow-ups.

Purpose: To show all assigned tickets that are waiting for a reply from the customer.
Build instructions:

Ticket | Status | Is | Pending
Ticket | Assignee | Is | Current user
Sorting: Next follow-up (ascending)

Pro Tip: The Next follow-up field depends on "Solve" macros. It is recommended that all "Solve" or "Set to Pending" macros add a follow-up date. The follow-up interval can vary by ticket type, e.g. 3 days for a simple technical query and 24 hours for a complex complaint. The view helps avoid leaving customers without follow-up.

4. The Queue (The Dynamic Work Distribution)

This is a more advanced version of "New Unassigned Tickets". The purpose is to show tickets that are ready to be handled by any available agent, and it suits a "take the next one in line" model.

Purpose: To show a prioritised list of tickets that are ready to be handled, whether they are new or returned from another agent.
Build instructions:

Ticket | Status | Less than | Open
Ticket | Group | Is | [Your group name]
Ticket | Assignee | Is | - (None)
OR
Ticket | Status | Is | Open
Ticket | Group | Is | [Your group name]
Ticket | Assignee | Is | Current user
Sorting: Priority (descending), then Created (ascending)

Pro Tip: The view uses "Any" (ANY) logic to combine two scenarios: new tickets and tickets that are already assigned to the current user. Sorting by priority (if prioritisation is used) and then by creation date ensures that the most important and oldest tickets are handled first. The view assumes a strong practice of "locking" tickets while working on them, so that two agents do not start on the same task.

5. Solved Today (Today's Work)

This view supports motivation and quality assurance by providing an overview of the day's solved tickets and a basis for review.

Purpose: To show all tickets that have been solved today.
Build instructions:

Ticket | Status | Is | Solved
Ticket | Updated | Is | Today
Ticket | Assignee | Is | Current user
Sorting: Solved (descending)

Pro Tip: The view can be used in daily stand-ups for a quick review and recognition, as well as for spot checks of the quality of the solutions (choice of macros, tone, etc.).

How to build views that actually get used

Having the right views is one thing; ensuring adoption is another. Views that are not created with the users in mind risk being ignored. The following process can increase the likelihood that views are actually used.

Start with the goal, not the filters

A typical mistake is to start with filters, e.g. "show all tickets with the tag 'invoice'". Instead, the starting point should be: What problem does the view solve?

Poor goal: "Show all invoice tickets."
Good goal: "Ensure that all invoice-related enquiries are answered within 2 hours."

Once the goal is clear, it can be translated into filters. For the goal above, a view might, for example, show:
Status < Open, Tags > Contains at least one of > invoice, payment, invoice query, Group > Is > Billing, Updated > Less than | 2 hours ago.

The view thus acts as an alarm panel for tickets that are approaching an SLA breach.

Think like an agent, not like an admin

Administrators see Zendesk from an overview perspective, while agents work on specific tasks. A view must make sense in the agent's everyday work. Relevant questions for agents can be:

"What is the first thing you look for when you log in?"
"What is the most time-consuming part of the working day?"
"Which type of ticket is most at risk of being forgotten?"

The answers can be turned into views. One example is a view such as "Escalated to me", which automatically shows tickets where a tier 1 agent has used a specific "Escalate to Tier 2" macro, thereby reducing manual searches.

Naming is a central part of the work

An unclear name can render an otherwise good view useless. Names should be unambiguous, action-oriented and short.

Poor names: "View 12", "New stuff", "Urgent", "Support"
Good names: "My open tickets", "Waiting on the customer", "New chats - unassigned", "Following up today"

A naming convention could be:

Owner: "My..." (personal), "Team..." (shared)
Action/Status: "...open", "...waiting", "...new", "...solved"
Context (optional): "...today", "...high priority"

This makes it easier to scan the view list and find the relevant view without guesswork.

Use grouping and sorting strategically

The order in a view is just as important as the filtering. Incorrect sorting can make a view ineffective.

Updated (ascending): Standard for many work views; the oldest activity sits at the top.
Created (ascending): Well suited to triage queues (FIFO).
Priority (descending): Relevant when using prioritisation; supplement with a secondary sort (e.g. Created) as a tie-breaker.
Grouping: Can be powerful, but should be used with care. Grouping "My open tickets" by "Status" can make sense, while grouping by "User" in a large queue often creates noise. Grouping can be useful for reporting, e.g. "Solved today" grouped by "Assignee".

Iterate and gather feedback

A view is rarely "finished". Processes change and needs evolve. A practical approach can be:

Create a draft version: Build the view based on a hypothesis.
Present it to 1-2 agents: "A draft view has been created to help with [problem]."
Gather feedback: Is it too complex, are tickets missing, or is the sorting wrong?
Adjust and launch: Roll it out to the team with an explanation of its purpose and use.
Evaluate after 2 weeks: Use "View activity" to see whether the view is being used. If not, the reason should be clarified (adjustment or reassessment of the need).

Refresh rate and performance: How to optimise?

Slow views reduce productivity and cause agents to avoid them. Performance is a prerequisite.

What is refresh rate, and why does it make a difference?

Refresh rate is the time Zendesk takes to execute the query and display the results. It is affected by filter complexity. Some filters are typically "expensive" (slow), because they require searching through large amounts of non-indexed data:

Commenter: In particular "Is not Current user" can be very slow, as comments must be reviewed.
Organization: Filters that cross organisation data can be slow in large instances.
Custom fields: Can be slow depending on type, especially dropdowns with many options or text fields.
"Does not contain": Often slower than "Contains".

Faster filters are typically based on simple, indexed fields:

Status
Assignee
Group
Ticket ID
Tags (generally fast, but can become slower with very large numbers of unique tags)

The golden rule: Less is more

Each condition makes the view slightly slower. Each OR (ANY) can increase complexity significantly. A practical rule is: Start as simply as possible, and add only the conditions that are necessary for the view's goal.

A view for "My open tickets" can manage with just Status < Open and Assignee > Is > Current user. Extra conditions such as Ticket | Type | Is | Question can make the view slower and less flexible. If needed, the agent can instead sort or filter within the view.

Concrete optimisation tips

Avoid the Commenter filter: Instead, use Status > Is > Pending combined with Updated > Less than | [number of hours] ago to find tickets without a customer reply.
Use tags as a "proxy": Instead of filtering on a complex custom field, a macro can add a tag (e.g. high_priority) that you filter on via Tags.
Be careful with ALL/ANY: A chain of ALL conditions is typically faster than a chain of ANY conditions. Keep ANY chains short.
Limit the time frame: Report views should always have a time limit (e.g. Solved > Is > Last week) to avoid searching through the entire history.
Test performance: Build and test the view in a private incognito tab, as caching can otherwise hide the real load time.

When should a view be deleted?

View hygiene is important. Over time, views accumulate as projects end and processes change. A large view list creates confusion and hides the most important views.

Signs of a "dead" view

A view is typically redundant if one or more of the following applies:

No use in 30+ days: "View activity" is a key indicator.
Constantly shows 0 results: Can indicate changed processes or overly restrictive filters.
Duplicate work: Two views effectively show the same thing (e.g. "New emails" and "Unassigned emails").
Too specific: Views such as "Tickets from customer X about product Y assigned to agent Z" quickly become outdated and should often be replaced with temporary searches.

Process for "view clean-up"

A quarterly clean-up can be carried out like this:

Run the "View activity" report: Export data for the last 90 days.
Identify candidates: Sort by number of views; 0-5 views are candidates.
Analyse "empty" views: Assess views with 0 results over time.
Communicate: Inform the team of the planned deletion and allow for objections.
Carry it out: Delete views without objections and finish with a more manageable view list.

Archiving vs. deletion

If a view contains complex logic that may be needed again, it can be archived:

Rename the view to ARCHIVE: [Original name].
Move it to a specific view group called "Archive".

After a year in the archive, the view can be deleted permanently.

Common view mistakes and how to avoid them

Even experienced administrators can fall into classic traps. Below are the most common mistakes and their solutions.

Mistake #1: Too many conditions

Symptom: 10+ conditions with a combination of Status, Type, Priority, Tags, Group, Custom fields, etc.
Problem: Slow, fragile and hard to understand why tickets are or are not shown.
Solution: Start with 2-3 core conditions and define the minimum requirement for the list. If needed, complexity can be split into two smaller views.

Mistake #2: Conflicting conditions

Symptom: The view is constantly empty, even though tickets are expected.
Problem: Logically impossible combinations, e.g. Status = Solved AND Status = Open, or Assignee = - (None) AND Assignee = Current user.
Solution: Read the conditions aloud as a sentence and be particularly careful when mixing ALL and ANY.

Mistake #3: Ignoring "All" vs. "Any"

Symptom: The view shows too many or too few tickets.
Problem: "All" (ALL) requires that all conditions are met; "Any" (ANY) requires that at least one is met. The wrong combination gives incorrect results.
Example: The goal is to see all new tickets AND all tickets waiting on the current user.

Incorrect: Status < Open (All) Assignee = Current user (All) Assignee = - (All) → always empty.
Correct: (Status < Open AND Assignee = Current user) OR (Status < Open AND Assignee = -)

In Zendesk this is built by creating two condition blocks and selecting "Meet ANY of these".
Solution: Think in sentences and use mental brackets: "(A and B) OR (C and D)".

Mistake #4: Poor sorting

Symptom: Agents sort manually or consistently work on the wrong tickets.
Problem: The default sorting does not match the view's purpose.
Solution: Match the sorting to the purpose:

Triage queue: Created (ascending)
Personal work queue: Updated (ascending)
Prioritised queue: Priority (descending), then Updated (ascending)
Follow-up queue: Next follow-up (ascending)

Mistake #5: Forgetting the "Updated" filter

Symptom: The view shows old tickets or tickets with no activity for a long time.
Problem: Filtering only on Status and Assignee without a time limit can make the view historically heavy.
Solution: Add a time limit, unless the purpose is to see all tickets. For daily views, Updated > Less than | 30 days ago can be a relevant supplement for both relevance and performance.

Red flags: Hundreds of views, no one uses them

A list of 50, 100 or 200+ views typically indicates chaos rather than an advanced set-up.

Symptoms of "view inflation"

"Let's make a view for that" at every minor problem.
Personal test views that are never deleted.
Naming chaos such as "View 1", "Copy of My open", "Test", "NEW VIEW - READ!!!".
Agents spend more time finding the right view than answering customers.

Consequences of clutter

Poor performance: Many complex, unused views can put a strain on the system.
Confusion and errors: The wrong views are selected, critical tickets are overlooked, or several agents work on the same ticket.
Demotivation: An unmanageable workspace signals a lack of structure.
Administrative burden: Maintenance and troubleshooting become unmanageable, especially when changes affect many views.

Measures against "view inflation"

A key move is discipline, e.g. a rule that for every new view created, another must be archived or deleted. In addition, the approval of new views can be formalised (e.g. by a small admin team), focusing on whether the need can be met by existing views, and why a new list is necessary.

Green flags: Few, well-designed views that everyone uses

The goal is a healthy, efficient and scalable Zendesk set-up.

Characteristics of a healthy view culture

Short list: Typically 5-8 active views per agent without the need for scrolling.
Intuitive names: Short, precise and action-oriented.
High adoption: "View activity" shows daily use among most agents.
Clear purposes: Each view has a unique purpose without overlap.
Fast performance: Views typically load in under 2-3 seconds.

Measures of success

Number of views per agent: Aim for under 10.
Average load time: Measured manually or via agent feedback; the goal is "instant".
Agent feedback: Questions such as "Are the views helpful?" and "Are there views that are missing or never used?"
Fewer forgotten tickets: Track metrics such as "First Reply Time" and the number of reopened tickets; effective views should improve these.

Example: A "lean" view structure

A core structure that is often implemented:

For all agents:

My Open: Personal work list.
Waiting on the Customer: Personal follow-up list.
Team Queue: Shared triage queue for unassigned tickets.
Solved Today: Quality assurance and motivation.

For team leads/selected agents:
5. Unassigned (Keep an eye on): Triage queue showing tickets that have been unassigned for more than, say, 1 hour (early warning).
6. Escalated: Tickets that have been escalated to the team.
7. SLA breaching: Tickets that are about to exceed SLA targets.

With this structure, a team can handle large ticket volumes with transparency and control, while other needs are covered by temporary searches or reports as required.

Conclusion: From chaos to clarity

Views are a foundation in Zendesk and a central part of an efficient customer service experience. Correct design creates flow, focus and efficiency; incorrect design creates chaos, frustration and wasted time.

Experience indicates that the key is not complexity, but clarity and discipline: a focus on the agent's needs, clear goals for each view, simple and performant set-ups, and ongoing maintenance and clean-up.

Mastering views is a valuable investment for Zendesk administration, with a clear effect on both the team's wellbeing and customer satisfaction. Tidying up the view list and establishing a tight, usable structure is a concrete step from chaos to clarity.