Carmelo Rigatuso

The Explore recipe: Filtering reports by business hours  article only filters by created within business hours. I need to know the time spent in a custom ticket status in business hours instead of calendar hours.

I created a Measure Duration of Status and Custom fields in Business hours feedback post, but I'm not really happy with the reply. I would encourage anyone who needs this to upvote this post and push for higher priority in Zendesk's roadmap.
 

Is there no “Offered To” option in explore? I need to see who the chat was offered to initially to be able to see who's missing their assignments. All I can see is the assignee, but that doesn't tell me who it was offered to initially. This ends up creating a report with agents who don't answer chats with chat metrics attached to them because they were ultimately assigned the ticket. I'm not even seeing any way to create a custom metric for this. I am surprised that this isn't a standard metric, especially since that data point is captured in the events of the ticket.

How do I get the name of the agent that the chat was offered to in an Explore report? All I can see is the assignee, but that doesn't tell me who is being offered chats and missing them.

Agreed with Heidi Ritzenthaler and Stacey Horowitz .

I created a feedback post here , please vote and comment on to get it up higher on the list!

thanks,

Carmelo

Hi, I would like to suggest three important features for Custom Ticket statuses to improve ease-of-use by agents, and ease-of-maintenance by admins.

1. Nested statuses, so that clicking on submit doesn't bring up a long list to scroll through. A user can simply click the parent status category to start, and then see the custom statuses for each. This will also help agents understand what the link between a custom status and its parent. A double nesting would be valuable as well. Ex: Open::Pre-Sales::Discovery, Open::Pre-Sales::Demo, Open::Sales::Negotiating, Open::Sales::Contracting
2. Re-ordering the statuses. We may add a new status in the future, and we would want to slot it in the process flow to make them more intuitive and therefore quicker to find.
3. Color-coding: Assign our own color scheme for ticket statuses, so that they are easier to identify. For example, 
   1. we may want to use RED statuses for more critical statuses (like On Hold - Escalated to 3rd party vendor)
   2. Use darker shading as the ticket goes through its workflow (so lighter share for Open::Pre-Sales::Discovery, and darker for Open::Sales::Contracting) so that we can see at a glance how far along the process a ticket is.
   3. match color scheme with other tools we use, so anything Open shows blue in all our support tools.

thanks,

D.Fitz I don't think so, we created a workaround for this. We created a custom drop-down field called “Email Received at” and then added all of our support emails as drop-down values. the we created a trigger to run when the channel is email and the ticket is created to set the custom field value to the same as the Ticket > Received at. Then you can use the custom field ID to reference it {{ticket.ticket_field_123}}. Example:

Same issue, I can't order the macros because I can't see them all.

Amar Taggar 
I would try using the ticket.ticket_field_123 format in the case, and use the tags associated with the value you want, and then if you need to display the value, use ticket.ticket_field_option_title. So something like:
Note that I'm not 100% sure on the syntax if you're evaluating tags instead of text. you may not need the quotes.

{% case ticket.ticket_field_123 %}
{% when "xyz_abc" %}
Print ticket.ticket_field_option_title_123

Cameron Eng A bit late, but if you haven't figured it out yet, it's ticket.ticket_field_option_title_12345 not ticket.requester_field_option_title

Why is it so hard to find the brand ID? Why can't it appear in the brand settings or in the URL of the brand page, like groups and forms?