Recent searches
No recent searches

Justin Graves
Joined Apr 15, 2021
·
Last activity Mar 08, 2022
Following
0
Followers
0
Total activity
71
Votes
20
Subscriptions
43
ACTIVITY OVERVIEW
BADGES
ARTICLES
POSTS
COMMUNITY COMMENTS
ARTICLE COMMENTS
ACTIVITY OVERVIEW
Latest activity by Justin Graves
Justin Graves commented,
@Robin - Thanks for the feedback. I think I'm going to use an 'About' field after all since Forms are not searchable. I'm glad you brought that up because it would definitely get cumbersome.
What I've decided to do is create Forms for each area of knowledge like IT, Medical Records, Accounts Receivable, etc. Then I set up a Trigger to change the Group to match and change the About field to navigate that area.
For example, if the IT form is selected and then the ticket is submitted (our triage person does this), the trigger will assign it to the IT Group and also set the About field to:
IT:: IT (select option below) <-- note the space before the second 'IT'. That will sort this to the top of this level in the list of About option as long as you sort that list alphabetically.
Then the options below are something like:
IT::Password Reset
IT::New User Account
IT::Troubleshooting::Hardware
IT::Troubleshooting::Software
We might, at some point in the future, also disallow our agents from solving a ticket set to the generic About option like 'IT:: IT (select option below)' if we see too many tickets left like this.
View comment · Posted Jul 06, 2016 · Justin Graves
0
Followers
0
Votes
0
Comments
Justin Graves commented,
Has anyone considered using the Ticket Form field instead of an About field. Since we use the Form field to display the custom ticket fields relevant to the ticket already, it seems like we should be able to set up a Form for each category we might otherwise put into an About field -- and thereby save our agents time selecting the About drop-down field. Has anyone tried this yet? I'm mostly wondering if the Form field has the same reporting options as the About field. That might be the deal-breaker for us.
The other option is to do both I guess -- create the About field and the Forms and then set a trigger for each form to set the About field. Then hide the About field with something like Field Marshall. http://www.lovestockleaf.com/zendesk/zendesk-apps/field-marshal.html
Thoughts?
View comment · Posted Jul 06, 2016 · Justin Graves
0
Followers
0
Votes
0
Comments
Justin Graves commented,
Yes. The new system worked much better. We went down to 1 helpdesk group and that provided some much-appreciated sanity.
I'll also say that my statement about needing a triage person when we got larger was also true. We have, in fact doubled in size as a department and as a company since 2013 when I wrote this post. As such, we now have 3 groups with 4 to 15 members each now. That setups seems to work pretty well for us.
Best of luck to you, Samantha!
View comment · Posted Jul 01, 2015 · Justin Graves
0
Followers
0
Votes
0
Comments
Justin Graves commented,
Annastashia- I know this doesn't solve your root problem but I thought I'd chime in with a method for speeding up and standardizing the ticket subject lines.
You would create a custom drop-down field with a list of the products your users log tickets about. Then create a Macro which uses that field's Placeholder (along with other fields if you like) to set a new Subject.
Then, when your agents first touch a ticket, they select the proper drop-downs and run the Macro in order to set the standardized Subject line.
View comment · Posted Mar 10, 2015 · Justin Graves
0
Followers
4
Votes
0
Comments
Justin Graves commented,
We would also like to see this implemented. Our use case is that we have certain agents who specialize in something, say cell phone ordering, and get CCd by our end users when those end users email in a request to replace a cell phone. That works fine until the agent moves on to specialize in something else. When that happens, we would like to be able to automatically remove that agent from the cc field on tickets. We would trigger this action when the topic (one of our custom fields) gets set to that specialty.
View comment · Posted May 07, 2014 · Justin Graves
0
Followers
0
Votes
0
Comments
Justin Graves commented,
This would be helpful for us as well.
View comment · Posted Apr 03, 2014 · Justin Graves
0
Followers
0
Votes
0
Comments
Justin Graves commented,
This would be helpful for us as well.
What about this as a solution: Lets say we have a "bad" org that was created on accident with junk data in it and a "good" on with all of the proper data. We want to see the tickets in the "bad" org in the "good" org when we look it up. Could ZD possibly make a way to automatically create "follow-up" tickets for all of the closed tickets from the bad org in the good org and mark all of those as closed (while circumventing triggers and automations). Then we would have a reference to all tickets in the good org. And I know I'm asking for a lot, but it would also be great if there could be a way to archive "bad" orgs and only have them show up in search results if we tick a box that says "include archived".
Pragmatically, since I have this issue right now, what I'm doing is just re-naming my bad orgs. I keep the Org name but tack on something like "DO NOT USE" in the name so our agents know which one is the accurate org for current use.
View comment · Posted Apr 03, 2014 · Justin Graves
0
Followers
4
Votes
0
Comments
Justin Graves created a post,
I'm going to share what NOT to do -- assuming you are a company like ours. I am in the IT department and we have about 15 techs, 10 of which are "front line" Help deskers as we call ourselves.
We answer the phones and field emails for our 5,000+ healthcare professionals (internal employees). Some of us have strengths in various areas but we all are trained to do almost everything.
I made two mistakes with groups:
-
I created too many groups. If you are like us, you probably don't need 7 groups for 15 people. It makes assigning tickets to agents more time-consuming than necessary.
This sounds like a small thing but since everyone was in about 5 groups, there was also a lot of overlap in the group membership and it was very confusing. I'd recommend having your agents in a maximum of two groups, and only in one if at all possible. That way, when you type their name to assign a ticket to them, they only show up once in the drop down list.
-
I created a group that became a bottleneck to expediency. We called it the Triage group and the idea was that all new tickets would automatically (via a trigger) get assigned to this group. And then two agents were supposed to monitor that group (via a view showing only those tickets). They were supposed to be the gatekeepers. They were to assign the tickets out to the other Helpdeskers and also email back to the requesters to get more info if they had forgotten to include something that was necessary for us to solve their issue.
The problem was that those two gatekeepers got busy and became a bottleneck so that I had to allow access to the Triage group to everyone and then it became meaningless. In fact, the problem got compounded because I had set up a trigger that would re-open any ticket that was solved in the Triage group because I thought I would be running reports on groups and Triage was not what I considered a "real" group.
I suppose if you have a larger organization and can devote 2 people to the task of triaging your tickets and passing them on to the other agents this might work but for us it was a major failure.
The interesting thing is that our agents got used to this inefficiency and have made our Zendesk work in spite of my ill-conceived plan. Anyway, I just spent 2 hours fixing all of this - triggers and groups and views and automations. What a nightmare. I hope my pain and experience will save you some of the same.
I'll let you know if our new system works better. Fingers and toes crossed.
Posted Mar 16, 2013 · Justin Graves
0
Followers
18
Votes
8
Comments