Recent searches


No recent searches

Justin Graves's Avatar

Justin Graves

Joined Apr 15, 2021

·

Last activity Mar 08, 2022

Following

0

Followers

0

Total activity

71

Votes

20

Subscriptions

43

ACTIVITY OVERVIEW

Latest activity by Justin Graves

Justin Graves commented,

Community commentDiscussion - Zendesk on Suite best practices

@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,

Community commentDiscussion - Zendesk on Suite best practices

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,

Community comment Discussion - Tips and best practices from the community

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,

Community comment Feedback - Help Center (Guide)

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,

Community comment Feedback - Ticketing system (Support)

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,

Community comment Feedback - Ticketing system (Support)

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,

Community comment Feedback - Ticketing system (Support)

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,

Post Discussion - Tips and best practices from the community

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