Recent searches
No recent searches

Carmelo Rigatuso
Joined Oct 22, 2021
·
Last activity Feb 12, 2025
Following
0
Follower
1
Total activity
162
Votes
69
Subscriptions
36
ACTIVITY OVERVIEW
BADGES
ARTICLES
POSTS
COMMUNITY COMMENTS
ARTICLE COMMENTS
ACTIVITY OVERVIEW
Latest activity by Carmelo Rigatuso
Carmelo Rigatuso commented,
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.
View comment · Posted Feb 12, 2025 · Carmelo Rigatuso
0
Followers
0
Votes
0
Comments
Carmelo Rigatuso commented,
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.
View comment · Posted Feb 12, 2025 · Carmelo Rigatuso
0
Followers
1
Vote
0
Comments
Carmelo Rigatuso commented,
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
View comment · Posted Jan 13, 2025 · Carmelo Rigatuso
0
Followers
0
Votes
0
Comments
Carmelo Rigatuso created a post,
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.
- 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
- 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.
- Color-coding: Assign our own color scheme for ticket statuses, so that they are easier to identify. For example,
- we may want to use RED statuses for more critical statuses (like On Hold - Escalated to 3rd party vendor)
- 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.
- match color scheme with other tools we use, so anything Open shows blue in all our support tools.
thanks,
Posted Jan 13, 2025 · Carmelo Rigatuso
3
Followers
3
Votes
3
Comments
Carmelo Rigatuso commented,
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:

View comment · Posted Oct 23, 2024 · Carmelo Rigatuso
0
Followers
0
Votes
0
Comments
Carmelo Rigatuso commented,
Same issue, I can't order the macros because I can't see them all.
View comment · Posted Aug 29, 2024 · Carmelo Rigatuso
0
Followers
1
Vote
0
Comments
Carmelo Rigatuso commented,
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
View comment · Posted Aug 20, 2024 · Carmelo Rigatuso
0
Followers
0
Votes
0
Comments
Carmelo Rigatuso commented,
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
View comment · Posted Aug 14, 2024 · Carmelo Rigatuso
0
Followers
1
Vote
0
Comments
Carmelo Rigatuso commented,
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?
View comment · Posted Jul 09, 2024 · Carmelo Rigatuso
0
Followers
1
Vote
0
Comments
Carmelo Rigatuso created a post,
Hi,
When we share tickets with another Zendesk, it is often to either transfer an issue to a relevant team, or to escalate an issue to a higher level team. In both cases, there are requirements that may differ from the originating Zendesk ticket. Triggers will allow me to tag, notify, and take some other actions on a ticket, but they won't prevent a ticket from being shared with missing requirements.
For example, I may need to prevent a ticket from being shared if the ‘App Name’, ‘Version number’, ‘Source’ and whatever other custom fields are not filled in. I can do that by displaying those fields specifically when a value is selected in the sharing field, and making them required Always (or even just Open).
With custom fields synced, I can also use this to ensure that if a ticket is set to something like “On Hold - Escalated to Vendor” the vendor's ticket number is required for that status.

Ticket sharing with everything synced solves a major headache for internal users who previously had to know where to submit and follow a ticket depending on the specific issue (we have two Zendesks, Engineering works in Jira, and then there are vendor escalations, like Microsoft and Google, for example).
This works best if we can ensure that all requirements are provided up front, and not react with a trigger after the ticket is already shared.
I also want to hide/prevent a ticket from being shared if the wrong form is applied. For example, our default form is very basic and is generally used by our frontline to triage and then assign an issue to a group with a more specific form applied. I shouldn't be able to share a ticket using our default form. I'd like to remove the sharing field from the default form (or other forms where sharing is not relevant).
Thanks,
Carmelo
Edited Jul 09, 2024 · Carmelo Rigatuso
0
Followers
1
Vote
0
Comments