Announcing changes to views pagination and sorting user profile pages

Return to top


  • Ken Taylor

    It's not as clear cut as that - we have staff at many different levels of knowledge.  There are indeed classes of tickets that can and should be escalated, but it takes awhile even to reach the point of knowing that is so.  And, at any given time, even among those who are relatively new and in training, they would have different levels of knowledge.

    So, it is not uncommon for the pages to shake out like this:

    Last page - the newbies have glanced at them, bounced off, and left them there.  They may need escalation to T2 or higher, but nobody with the knowledge to evaluate that has looked at them yet.  More experienced T1 staff will be working through this page as they have time.

    Next-to-last page - there's some tickets on here that not-quite-so-newbies could handle, which they're looking at, and others that they can learn from, which they record so as to keep an eye on how they do end up handled.

    Previous page from that - the newest newbies are here, looking at tickets nobody has looked at at all, handling the very easiest.

  • Matthew W

    Your statement of "the newbies have glanced at them, bounced off, and left them there" right away tells me that they can't handle them and they could tag the ticket accordingly. 

    You could have a sliding scale for complexity 

    • Very low
    • Low
    • Moderate
    • High
    • Very high

    Each user which looks at the ticket which can not handle it moves the complexity up. 

    Maybe you have 3 view and new tickets and Very low sit in the first view for fresh users that just started they progress the tickets that they can't handle. 

    Tickets Low and Moderate are in the second 

    High and Very High in the 3rd

    You could use a numbering scale if you wanted to provide more options. And create more views if if needed. The triage of the tickets was happening in how you are having users use the first/last pages, this just adds more structure to the process. 

    Even through you have multiple views it doesn't mean that users can action tickets in each of them. If one view is empty then they can action the next up or down in the list.

    Just my thoughts.


  • Ken Taylor

    Yes, creating a half-dozen more views to keep track of, on top of the dozen or so we already have, would *work* in a technically-functional but inefficient way.  But why should we have to drag ourselves through knothole workarounds, when all we really need is to put the tool back the way it was that worked fine?

  • Shayan Moussawi

    Ken Taylor Technically, you wouldn't even need new views for it. 
    You could also use the new filter functionality to let support staff filter the Ticket "complexity" that is ideal for them. 

    I do agree with you, that removing features is always a bad course of action. 
    But to be entirely honest, I'd rather Zendesk focus on other areas of development/switch to a sufficient backend to improve their platform. And I believe cursor based pagination is a part of that.  

  • Laura Davis

    For us, due to the nature of some of our complex cases needing to be worked on, we don't always have an instant solution to each one and have cases on an On Hold status, whilst we solve the issue raised. As you know, the Play button doesn't work in instances such as these, as it will serve up the next ticket regardless of whether it's assigned already or not (as long as someone isn't actively viewing it). It's therefore sometimes easier to jump ahead a page or 2 (depending on the volume of colleagues we've got working on cases) and work through those manually, instead of using the Play button. 

    We also re-filter the view by Requester so that we can merge duplicates during Peak times and speed up responses that way, which is possible now for one person but was easier for multiple agents to do this together with the pagination view, hence speeding up the process rather than causing more work. 

    Essentially, we can make anything work but we shouldn't be having to change our entire workflow because Zendesk are removing features that were sold to us at implementation, some of which weren't even communicated with us before they were removed (eg automatic alphabetising). 

  • Ziah Goodrow

    Matthew W You're coming off as pretty needlessly condescending in this thread. Every team has their own workflows and use cases, and not every team dictates the same processes such as working all tickets in sort or SLA order. For example, one of the first things I do in the morning is run through our triage queue to clean out things like spam or irrelevant tickets, duplicates, or things that require escalation to our legal team. Due to the huge array of potential words and phrases used in these, it's not possible to use filters or build a view to capture them (much to my chagrin, as I've definitely tried). I also have ADHD and don't necessarily work in a linear fashion.

    Views are also a very substandard workaround for this issue, due to the default and unchangeable maximum of twelve shared views being accessible on the sidebar. We work around this with the Quickie extension, but teams shouldn't have to add third-party extensions - let alone paid ones - to improve baseline functionality as a workaround for regressive changes.

  • Matthew W

    Ziah Goodrow That is not my intent. I understand that each business has different workflows and leverage tools to meet their needs. I was just trying to provide suggestions to how views could be used to meet those requirements. The needs of a Tier 1 user verses a Supervisor are very different and cover a broad range of use cases. Views default filters, fields, and quick filters give the ability to isolate and order tickets. If these tools don't work then they don't. Understanding the reason is the first step. I would encourage people try these tools as they may find their workflow improved, but in the instance where it doesn't work to clearly state why as some have done and provided reasons. 

    I am sure Zendesk can provide better suggestions and best practice surrounding views and how to configure them that would mitigate some of the concerns in this thread. In the event they can't maybe with enough evidence they will rethink the change.

  • Phil

    Bring the page numbers back!  When working hundreds of tickets having the page number feature makes it much easier to jump from page to page.

  • Daniel Nagelhout

    This has been such a productivity waster. I really hope the backend has improved because the front end has been a slog ever since this change went through.


Please sign in to leave a comment.

Powered by Zendesk