Improve capability to define which tickets to work on next (from a View) in Support

When trying to handle requests in a orderly fashion, we are struggling to set up our Views in Zendesk Support, due to contraints in the View definitions. 

Use case

We have a process where we have multiple forms and channels submitting tickets into a single View. We want to handle the requests by SLA first, but we also need to consider tickets that has no SLA set. In Zendesk SLAs are often based on comments, and some tickets have a SLA met but are still Open or new, and should be handled. 

We want to have better logic in place to e.g. weight on SLA first, but also consider the tickets that are new/open and based on for example their request date or custom date field, rank them higher. Today we'd have to use akward automations to update the data of these tickets. I wish we could have a better view defintion such as multiple sorting criteria or a sort expression, weighing different parameters to build the final View order. 

Use case

We have process like two-party signing processes, where tickets are created in Zendesk early, but they don't need action from support until both parties has signed an agreement. We have these tickets in a View sorted on the Signed date. However, the same business functions also gets follow up requests and direct requests that are not part of the signing process. We have a hard time to build a view that properly balance the request order between these two different processes, because the View only supports a single sort order. Again, dealing with Automations or Triggers to try to build some data based on customer actions and build a view based off on that, makes things quite complicated. 

Make it simpler 

We'd like improved capabilites in Zendesk Support to better determine the order in which our agents process tickets. The current capabilities are that we have two options:

• Group by (e.g. priority)
• Sort by (an attribute)

These are not enough for us. Due to how SLAs, agent reassignments, customer updates, custom dates from custom processes work, etc, we find ourselves limited in arranging an effective request order pipeline. 

This becomes even more important if we were to start working with a push model. 

The situation that we typically find ourselves in is that we find a sort order that works for 80-95% of the tickets, and then we have situations where the simple sort order rules we can have in Views are not enough, and the requests risk a bad customer experience because they are at the end of a view, or somewhere in the middle, when they should be next in line.