Vor Kurzem aufgerufene Suchen
Keine vor kurzem aufgerufene Suchen

Ryan Mumby
Beigetreten 15. Apr. 2021
·
Letzte Aktivität 17. Mai 2022
Folge ich
0
Follower
0
Gesamtaktivitäten
39
Stimmen
8
Abonnements
16
AKTIVITÄTSÜBERSICHT
BADGES
BEITRÄGE
POSTS
COMMUNITY-KOMMENTARE
BEITRAGSKOMMENTARE
AKTIVITÄTSÜBERSICHT
Neueste Aktivität von Ryan Mumby
Ryan Mumby hat einen Kommentar hinterlassen
I'm noticing upon partial copy sandbox creation, it completely unorganizes our entire trigger list. We have them organized very meticulously and in multiple categories. It dumped them all into a single category from what I can tell. As I'm sure you're aware, the order in which triggers are processed is critical. Reorganizing 150+ triggers is not exactly pleasant.
It also launched most of the brands as "deactivated" - I'm fine with the brands being named different/having different URLs, that makes sense, but this also affects and breaks tons of triggers referencing them.
Is this expected behaviour?
Kommentar anzeigen · Bearbeitet 17. Dez. 2021 · Ryan Mumby
0
Follower
3
Stimmen
0
Kommentare
Ryan Mumby hat einen Kommentar hinterlassen
Also just went through a nightmare of trying to use a whole mess of different standard and custom attributes to come up with my own "first assignment to resolution time" metric that would only show business hours only to ultimately end up not being able to calculate date diff in business hours in every avenue I went down. Can't believe this isn't available, feels like it would be pretty simple to code as there are a bunch of other standard metrics that make that calculation behind the scenes, its just not available in the GUI for us to grab and use on our own.
Kommentar anzeigen · Gepostet 07. Mai 2021 · Ryan Mumby
0
Follower
2
Stimmen
0
Kommentare
Ryan Mumby hat einen Kommentar hinterlassen
@... There's been no update for a year and 6 months past the time you advised we would likely have this.
Considering this ask is 3+ years old, this feature already existed with insights before its deprecation, and that the information already exists in the Zendesk data model.... what the h-e-double hockey sticks is going on?
I can't imagine this is technically challenging. Having to create a new field on every ticket form we use and an automation for it to be populated is not really an acceptable workaround as it ignores the entirety of past history. Plus... the data already exists as I'm sure you're aware. Throw us a bone here man!
Kommentar anzeigen · Gepostet 06. Jan. 2021 · Ryan Mumby
0
Follower
1
Stimme
0
Kommentare
Ryan Mumby hat einen Post erstellt
Our ability to let our team leads/agents use explore is extremely limited since we can't trust that they will not be able to intentionally or unintentionally modify important queries used in dashboards that get sent to executives, clients, etc on a large scale basis. As the datasets in Zendesk can get quite complex in how they interact it would be very easy for someone to modify something that caused incorrect filtering for some important reporting that goes out to our executives and our clients.
Being able to limit users to only be able to create/edit their own reports is essential for us being able to allow more wide adoption of self serve reporting.
Gepostet 30. Okt. 2020 · Ryan Mumby
7
Follower
7
Stimmen
2
Kommentare
Ryan Mumby hat einen Kommentar hinterlassen
Hey Maddi - I'm able to save the above just fine in my instance. I would say double check your syntax or repost a screenshot of the actual formula here for us to have a look and verify there are no errors in the formula, and if that's not working then you might have to contact support and report a bug.
Kommentar anzeigen · Gepostet 29. Juli 2019 · Ryan Mumby
0
Follower
0
Stimmen
0
Kommentare
Ryan Mumby hat einen Kommentar hinterlassen
Hey Maddi,
From the query you're building select Calculations (calculator on the right), then choose Standard Calculated Metric.
Try this formula
IF([tag]="canada" AND [tag]="processed")
THEN [Ticket ID]
ENDIF
Drill into your data and do some spot checking by looking up a few randomly selected Ticket ID's to make sure it's grabbing tickets with the data you expect, but this should do the trick.
Zendesk recently changed how they call out the the "Tags" attribute in their formulas though so I'm not 100% certain. They've moved from a model that called out Ticket, Org, User etc tags separately to 1 single "Tag" attribute, which is why I'm suggesting the checking to make sure its operating correctly.
Kommentar anzeigen · Gepostet 26. Juli 2019 · Ryan Mumby
0
Follower
0
Stimmen
0
Kommentare
Ryan Mumby hat einen Post erstellt
It's seems that in explore (same as in insights) we still don't have the ability to filter based on a users group. I know we can filter based on ticket group, but I'm looking more at a group of users rather than what type of ticket they are looking at. Currently all we can do is add each user 1 by 1 to a filter of a report, multiply that by however many reports you have and by however many groups you have, thats in INCREDIBLY time consuming process.
We need to be able to filter by user group in examples like...
- Updater is a member of "XYZ" Group.
- Assignee is a member of "XYZ" Group.
- Requester is not a member of "XYZ" group.
Doing this based on a ticket group is not sufficient because we have many groups that respond and work in multiple areas, so if I want to report on our "Vetting" team - they may be interacting with other groups on tickets, and I can't make a report where I look at the # of updates from users on the vetting team for the last week, organized by user. At least not without singling out each user, but this creates a huge strain creating and updating the reporting based on team changes/turnover/etc.
Also, if we were able to do this we could cut down on the total number of reports by adding a dropdown filter to a dashboard to select which user group someone wants to report on. So the same "Ticket Updates" report from my example above could be used to serve multiple teams.
Unless I'm missing something and you can show me how to do this, I haven't been able to figure out a way myself, or in the community or KBS articles.
Gepostet 16. Juli 2019 · Ryan Mumby
19
Follower
14
Stimmen
6
Kommentare
Ryan Mumby hat einen Kommentar hinterlassen
I don't actually set a time of day, but I know that if we're open 7am - 6 pm actioning request, they are going to be solved in that time frame. If I delay it by 10 hours after that it's going to fall either in the evening or late at night/early morning. for the majority of our users which are in North America. You'll have to come up with a plan for your own business as your operating hours and time zones of your clients might vary.
Kommentar anzeigen · Gepostet 14. Nov. 2018 · Ryan Mumby
0
Follower
1
Stimme
0
Kommentare
Ryan Mumby hat einen Kommentar hinterlassen
Steve, it's also important to note that sending that automation right away always might not be wise. If you get a fair amount of reopens, for example, and you might get a customer with an unresolved issue answering that survey that's not very happy.
I can't seem to find it but there was an article from zendesk based on data they'd gathered that suggested more people are likely to respond when they are not as busy (in the evening or first thing in the morning) and delaying your satisfaction surveys to get sent in the evening or middle of the night would produce a higher response rate.
Basically, you should adjust it how you see fit but put some thought into when you are sending them based on whats right for you.
Kommentar anzeigen · Gepostet 12. Nov. 2018 · Ryan Mumby
0
Follower
0
Stimmen
0
Kommentare
Ryan Mumby hat einen Kommentar hinterlassen
Yeah I was thinking the same thing as.. err... "Shipping Manager"?. 1 off customers will never get asked about their experience. Only people who submit lots of tickets.
Kommentar anzeigen · Gepostet 29. Juni 2018 · Ryan Mumby
0
Follower
0
Stimmen
0
Kommentare