SOURCE-BASED ANALYSIS · NO HANDS-ON RATING
Start with a queue decision
Zendesk views are filtered ticket lists that can guide daily workflow. Define each view from the action an agent should take. “Unassigned urgent tickets” gives an operator a decision; “All open tickets” may be useful for oversight but is too broad to establish a working order on its own.
Write the inclusion contract
Record every condition in plain language before configuring it. Include group, assignee, status, priority and any custom field that changes eligibility. Then write at least one ticket that should appear and one near-match that should not. This exposes ambiguous AND/OR logic before a live queue depends on it.
A four-view example
A fictional support team might use New unassigned, My active work, Waiting on customer and Waiting on third party. The names alone are not enough: define the exact statuses and ownership fields behind each. Zendesk documentation describes on-hold as a state for waiting on a third party; adapt the queue to the statuses actually enabled in the account.
| View | Required action | Exit event |
|---|---|---|
| New unassigned | Claim or route | Assignee or group is set |
| My active work | Respond or progress | Status leaves active set |
| Waiting on customer | Review due follow-up | Customer reply or resolution |
| Waiting on third party | Check dependency | Dependency clears |
This is a proposed operating model, not Zendesk's universal default.
Choose columns that support the decision
Show the minimum fields needed to decide what comes next: age, requester, assignee, priority, status or a relevant custom field. Extra columns can obscure the signal. Set the sort order to match the operating policy, then check whether agents can understand ties and exceptional priorities.
Diagnose a missing ticket systematically
Zendesk advises comparing a missing ticket with each view condition. Open the ticket, record its current field values and work through the conditions one by one. Also consider group or department access. Do not weaken a condition globally just to make one unexplained ticket appear.
Test overlap and abandonment
- Create synthetic tickets for every positive and negative fixture.
- Confirm each appears in the intended view and exits after the documented action.
- List tickets appearing in more than one working queue and decide whether overlap is intentional.
- Identify active tickets in no working view and assign an owner for that exception.
- Repeat after changing statuses, groups, forms or triage rules.
Pair views with routing rules
A view shows work; it does not by itself establish that incoming tickets receive the correct fields. Keep view conditions aligned with triggers, automations or routing configuration. When a rule changes a field used by a view, treat both as one release and test the complete path.
Sources and verification
Official documentation checked on 2026-10-29. Worked examples are hypothetical planning exercises, not measured product benchmarks.