최근 검색
최근 검색 없음

Carmelo Rigatuso
가입한 날짜: 2021년 10월 22일
·
마지막 활동: 2025년 2월 12일
팔로잉
0
팔로워
1
총 활동 수
162
투표 수
69
플랜 수
36
활동 개요
배지
문서
게시물
커뮤니티 댓글
문서 댓글
활동 개요
님의 최근 활동 Carmelo Rigatuso
Carmelo Rigatuso님이 에 댓글을 입력함
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.
댓글 보기 · 2025년 2월 12일에 게시됨 · Carmelo Rigatuso
0
팔로워
0
투표 수
0
댓글
Carmelo Rigatuso님이 에 댓글을 입력함
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.
댓글 보기 · 2025년 2월 12일에 게시됨 · Carmelo Rigatuso
0
팔로워
1
투표
0
댓글
Carmelo Rigatuso님이 에 댓글을 입력함
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
댓글 보기 · 2025년 1월 13일에 게시됨 · Carmelo Rigatuso
0
팔로워
0
투표 수
0
댓글
Carmelo Rigatuso님이 에 게시물을 만듦
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,
2025년 1월 13일에 게시됨 · Carmelo Rigatuso
3
팔로워
3
투표 수
3
댓글
Carmelo Rigatuso님이 에 댓글을 입력함
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:

댓글 보기 · 2024년 10월 23일에 게시됨 · Carmelo Rigatuso
0
팔로워
0
투표 수
0
댓글
Carmelo Rigatuso님이 에 댓글을 입력함
Same issue, I can't order the macros because I can't see them all.
댓글 보기 · 2024년 8월 29일에 게시됨 · Carmelo Rigatuso
0
팔로워
1
투표
0
댓글
Carmelo Rigatuso님이 에 댓글을 입력함
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
댓글 보기 · 2024년 8월 20일에 게시됨 · Carmelo Rigatuso
0
팔로워
0
투표 수
0
댓글
Carmelo Rigatuso님이 에 댓글을 입력함
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
댓글 보기 · 2024년 8월 14일에 게시됨 · Carmelo Rigatuso
0
팔로워
1
투표
0
댓글
Carmelo Rigatuso님이 에 댓글을 입력함
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?
댓글 보기 · 2024년 7월 09일에 게시됨 · Carmelo Rigatuso
0
팔로워
1
투표
0
댓글
Carmelo Rigatuso님이 에 게시물을 만듦
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
2024년 7월 09일에 편집됨 · Carmelo Rigatuso
0
팔로워
1
투표
0
댓글