Vor Kurzem aufgerufene Suchen
Keine vor kurzem aufgerufene Suchen

Carmelo Rigatuso
Beigetreten 22. Okt. 2021
·
Letzte Aktivität 12. Feb. 2025
Folge ich
0
Follower
1
Gesamtaktivitäten
162
Stimmen
69
Abonnements
36
AKTIVITÄTSÜBERSICHT
BADGES
BEITRÄGE
POSTS
COMMUNITY-KOMMENTARE
BEITRAGSKOMMENTARE
AKTIVITÄTSÜBERSICHT
Neueste Aktivität von Carmelo Rigatuso
Carmelo Rigatuso hat einen Kommentar hinterlassen
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.
Kommentar anzeigen · Gepostet 12. Feb. 2025 · Carmelo Rigatuso
0
Follower
0
Stimmen
0
Kommentare
Carmelo Rigatuso hat einen Kommentar hinterlassen
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.
Kommentar anzeigen · Gepostet 12. Feb. 2025 · Carmelo Rigatuso
0
Follower
1
Stimme
0
Kommentare
Carmelo Rigatuso hat einen Kommentar hinterlassen
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
Kommentar anzeigen · Gepostet 13. Jan. 2025 · Carmelo Rigatuso
0
Follower
0
Stimmen
0
Kommentare
Carmelo Rigatuso hat einen Post erstellt
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,
Gepostet 13. Jan. 2025 · Carmelo Rigatuso
3
Follower
3
Stimmen
3
Kommentare
Carmelo Rigatuso hat einen Kommentar hinterlassen
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:

Kommentar anzeigen · Gepostet 23. Okt. 2024 · Carmelo Rigatuso
0
Follower
0
Stimmen
0
Kommentare
Carmelo Rigatuso hat einen Kommentar hinterlassen
Same issue, I can't order the macros because I can't see them all.
Kommentar anzeigen · Gepostet 29. Aug. 2024 · Carmelo Rigatuso
0
Follower
1
Stimme
0
Kommentare
Carmelo Rigatuso hat einen Kommentar hinterlassen
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
Kommentar anzeigen · Gepostet 20. Aug. 2024 · Carmelo Rigatuso
0
Follower
0
Stimmen
0
Kommentare
Carmelo Rigatuso hat einen Kommentar hinterlassen
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
Kommentar anzeigen · Gepostet 14. Aug. 2024 · Carmelo Rigatuso
0
Follower
1
Stimme
0
Kommentare
Carmelo Rigatuso hat einen Kommentar hinterlassen
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?
Kommentar anzeigen · Gepostet 09. Juli 2024 · Carmelo Rigatuso
0
Follower
1
Stimme
0
Kommentare
Carmelo Rigatuso hat einen Post erstellt
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
Bearbeitet 09. Juli 2024 · Carmelo Rigatuso
0
Follower
1
Stimme
0
Kommentare