Community discussion: How do you manage incoming tickets?

22 Comments

  • Fernando Duarte

    We like to give our customers the ability to select the Priority of the issue they are submitting, and since customers do not like it when you change (lower) the Priority of their issue I set up the following:

    When tickets are created

    A custom field name "Severity" with the following values

    • P0
    • P1
    • P2
    • P3

    A set of Triggers that set the Severity based on the Priority given by the customer when the ticket is created

    • If Priority is Low, set Severity to P3
    • If Priority is Medium or is not set (like when it is an email), set Severity to P2
    • If Priority is High, set Severity to P1
    • If Priority is Urgent, set Severity to P0 and send email to Management and Team leaders

    We organized the "New Tickets" view to 

    • Group by Severity Ascending (P0 on top, P3 at bottom)
    • Ordered by Request date Ascending

    This makes sure that those tickets marked as Urgent by the customer are displayed at the very top of the New Tickets view.  We have a policy that tickets must be grabbed out of the queue starting on the top of the list.

     

    Managing the Queue based on Severity

    We set up 3 automations to Auto Escalate unassigned tickets like

    • For Severity P1 

      • Meet all of the following conditions: 
      • Tickets: Hours since created (business)   |   Greater than |   1
    • Ticket: Severity   |   Is   |   P1

    • Ticket: Assignee   |   Is   |   -

      • Perform these actions:
      • Ticket: Severity   |   P0
    • Ticket: Add tags   |   autoescalate  p1->p0

    • Notifications: Email group   |   Management

      • Email subject   |   {{ticket.id}} has been Auto Escalated from P1 to P0  for {{ticket.organization.name}}
    • Email body:   |   

    Ticket {{ticket.id}} has been escalated from a P1 Severity to a P0 since it was opened over 1 hour ago and it has yet to be assigned.

    Title: {{ticket.title}}
    Requester: {{ticket.requester.name}}
    Organizattion: {{ticket.organization.name}}

    {{ticket.url}}

    • For Severity P2 we change the condition to 4 hours
    • For Severity P3 we change the condition to 8 hours

    It is important that they are in the correct order, otherwise a P3 will become a P0 as soon as it has been sitting on a "New" status for more than 8 hours.

    This system allows our staff to evaluate those tickets opened with an Urgent Priority and simply set the Severity appropriately to manage our queue according to our prioritization and without having to change the Priority on the eyes of the customer.  This is particularly helpful with those customers that open everything as Urgent.

    0
  • Andrea Saez

    We have several groups and multiple languages, so our process may be slightly more complicated.

    First of all, we  have several groups of agents, so we set up multiple incoming addresses. (I've written about this before here: https://support.zendesk.com/entries/27753053-Managing-work-flow-for-multiple-email-addresses-with-views)

    Right now we only have one sales bucket, one billing bucket, and one info bucket, as demand for multiple languages there hasn't grown just yet.

    For support@ however, we have separated it into languages.

    As soon as the request comes in, it is automatically separated into a Support [X] view - where X is a language (let's say, English).

    We have pre-defined tags for premium clients, so if it's a premium client, it is automatically set to priority: high. 

    Everyone else by default is set to priority: Normal.

    This way agents is a bit more aware of how to best prioritize tickets.

    For bugs, our support process is already outlined here: https://support.zendesk.com/entries/24123472-Zendesk-JIRA-use-Amilia-Support-Process-included-

     

     

    0
  • Diane Albert

    Ours is pretty simplistic since there are two of us, but it sure beats pure email hands down!

    INCOMING NEW

    We pass our incoming support email directly to our Zendesk, automatically creating a ticket using our generic Customer Support Ticket Form.  These prefill to go into our Support group.

    We also receive notices from our Hightail dropbox (formerly YouSendIt) for media files we receive.  These are also redirected, but we capture specific text from those notices, so they open a ticket using our internal Media Ticket Form instead of the standard customer facing ticket.

    Those tickets prefill for our Media group, set a Priority, and then start the ticker on our SLAs.  We only use the SLA for media as a tickler.

    We have views set up for these new media tickets so we know they need to be checked.

    ROUTING

    As far as routing, we are sharing tickets with our production department who is on a starter version.  Our media goes through a logging process with us where we determine who sent it, what Org it goes to, what it is, and is it useable.  If it passes through all those various stages, it's shared with production.

    We needed to use Custom Field IDs in the description when passing since OUR ticket number is not THEIR ticket number.  And since we don't know what their ticket number will be, we decided to pass ours and have them search by that.  (we haven't overlapped yet, but we have a plan for when that occurs.)

    Although tickets aren’t truly “new” at this point, they still haven’t really been worked until they get to this shared point.

    CUSTOMER CONTACT

    We’ve created various macros based upon the type of media.  This allows us to customize the outbound customer emails so they know we received stuff, so they can remember what they sent us, and so they know when we’ve uploaded things.   Depending upon the media, it can take more time to process, so we don’t want them to be hanging wondering what happened to it.

    We also created a “reopen” view because we get a lot of “thank yous” back our customers and we wanted to make sure we addressed that the ticket was still sitting.  We haven’t separated out the Thank Yous from the “this isn’t solved” ones, but they are very manageable as is.

    LONG TIME TO CLOSE

    One of the best things we’ve done is set our Solved to Close time to be a LARGE number – like a month.  I don’t remember what Zendesk’s max is, but we have it.

    We found we had too many already closed tickets that needed to be updated for additional pieces of reportable data.  This gives me the opportunity to revisit these in a bulk view and do a “blink test” to see what’s not filled in.

    We have our Satisfaction set for 8 calendar hours after Solved and Unoffered.  We’ve received more Satisfaction feedback this year than ever and I think that’s because it is almost immediate for the customer.

    MY ADVICE

    We purchased Zendesk and jumped right in without much planning.  Although that got support out of pure email, when we backed up and looked at all the benefits we had in the system, it was time to map out what we wanted to do.

    I have learned a lot about what data points I missed the first time around and what more I can track and trend with custom fields as the tickets roll in.

    While our individual ticket form may seem to contain a lot of “stuff”, we made as many fill-in macros as we could to cover those points automagically so those new tickets get touched quickly.

    We’ve also begun to log our new internal support requests and place our new Tasks in the system.  Many times it looks like Support isn’t very busy, since ours is mostly electronic and not phone-based.  No one hears us talking!  This allows me to pull up reports and give a ‘good enough’ view of productivity or what kind of time we can free up for special projects.

    We aren’t a help desk - my metrics are very loose.  But they exist and we can tell we are making progress with the system by the comments in our Community Forums and the Satisfaction Comments we see.

    I know I can’t go back to email only!

    Diane

     

    0
  • Ian Melton

    There are only two of us also in the IT area to support 5 of our Company sites - around 200 users (all internal staff) and get an average of 250 - 300 tickets per month.

     

    We set up company associations to when a ticket is logged it gets put into the company the staff member belongs to right away which is good for viewing and tracking.

    We also created around 15 Ticket Fields to identify the type of support that is being requested - could be iPad support to Database support or just a password reset.

    As mentioned we have two of us as Agents - we pretty much ask all staff to email their support request and around 85% of them do - the ones who are old school and hate email call us and we generally log it on their behalf. Once the email comes in one of us looks at it within 30 minutes and many are resolved within 1 hour (all internal makes this easier) The ones my employee cannot fix will get escalated to me and put in my Queue. (I am the I.T Manager)

    We also use Zendesk for our Maintenance Manager and share Zendesk accounts - this way if I get a ticket to set up a new PC at a location missing a desk chair etc I can share the ticket so he can be aware of the need to supply the desk etc - then close his part of the ticket which alerts me its done and I can complete the job. Pretty handy feature.

    Each year I run up a report of all the ticket requests and break them down to show total tickets, number of tickets the two of us solved, the company who logged the ticket, the department of the user who logged the ticket. This way we can identify weakness in training or equipments if a trend develops - i.e Company 01 - Accounts Dept logged 50% of that company's tickets we can work with the managers to identify why so many from that one dept - each company has 6 departments.

    We then give key managers in each company access to see the tickets logged by their own companies and get an overview of the quantity and type of tickets logged so they can work out how to train / manage to minimise support.

    Last of all we do assign photo's to the users so when accessing from the ipad / iphone and ticket system we see the image - sometimes helps to remind us there is a person on the end of the ticket no matter how crazy the issue is thats being logged. Very easy for techy folk to class users in the ID-10-T user section.

    As we are totally internal it makes many thing much easier :-)

    I couldn't go back to a "phone me" system now or I would lose any sanity I had remaining.

     

    0
  • Spike

    Our support is all provided based on ORGANIZATION, as we have multiple users of our system at any given organization.

    We also assign each organizational client to a specific client services rep, for personal first-name basis support.  

    So we use the ZD Groups function to set up which clients are assigned to which CS rep.  (IE Groups such as "Jim's clients", "Greg's clients", etc). 

    We build in each client Organization when we on-board the client. So that exists in ZD already, and is assigned to a group.

    Our end users log into the help desk via the automatic login protocol, so when they click on "HELP" in our system, it takes them over to the ZD web portal already logged in.  During that login we pass their name, login, and organization, which either logs them in as an existing user, or creates a user acct for them.  

    We then use triggers to automatically assign tickets based on the organization.  So if an org is part of "Jim's clients" group, that ticket automatically gets assigned to him.  We do have some exceptions, such as invoice/billing questions get assigned to one of our admin staff for all clients, that's based on the choice of Component, which overrides the standard assignment using a different trigger.  

    0
  • Rob Deutsche

    Typically tickets are one of four categories: A Problem, a billing query, a design request (for new systems) or new client/ training.

    I have a "Section" Field with a bunch of subcategories (For example, Accounts: Billing inquiry), and have built triggers so that when certain sections are defined, it auto assigns it to either Account Management, Design, Support or Customer Success (our department who handles on boarding and adoption) with the appropriate info and ready for follow up.  We are in the 400 ticket per month range, so we are on the lower end of the typical Saas company, but this has worked well so far and we typically close things out in < 8 hours and respond in <2 hours.

     

    0
  • Amanda Birch

    We have one member of the team who deals with the incoming tickets and assigns them to an individual. Upon assignment the end user gets notification that it has been assigned and who to. This only happens if no tick is in a box marked Do Not Send e-mail. This means that common requests such as password resets which get done immediately and do not warrant an e-mail to the end user we can choose not to send the e-mail. This is very useful to save spamming end users with e-mails they do not need and we used tags to do this.

     

    We have a number of various views based on additional ticket fields we have added together with views based on who tickets are assigned to and groups they are assigned to and this is dependent on what role you play in the IT Team.

    0
  • Wes Drury

    I finally got around to posting on this topic so here is an overview of our setup.  We give our end users the ability to select their issue category using Ticket Forms.  Our end users log in via our SSO authentication where they are able to select their issue category.  Our help center is internal only.  We have the following ticket forms setup:

    • Hardware Support
    • Application Support
    • Network Support
    • Printer\Copier Support
    • Password Support
    • Telephone Support
    • Other

    We have custom fields that are conditional that appear when certain categories are picked.  I’m bringing this up as this is how we determine our routing to our different departments.  For example, under Application Support we have a drop down so the end user can select what application they are having an issue with and the incoming ticket will route to the appropriate group.  We have 5 main groups that tickets get routed into based on the above selections.  We also have a few back-end groups like our Web Development group that only get routed tickets from one other group, they never get tickets routed directly to them.  We offer the end user to be able to select “Other” under every single category in case they can’t find what they are looking for.  All of our “Other” tickets route straight to our help center where they get triage from there.

    Besides our Routing triggers we have several triggers that do our integration with our third party vendors.  For Hardware Issues we require a serial number which will only take a certain custom format.  Zendesk built us a Warranty Calculator App that reads the serial number and determines if the computer is “In Warranty” or “Out of Warranty”.  If Out of Warranty then it routes to our Hardware group to take care of but if its “In Warranty” it sends the ticket into our third party vendor’s work order system.  When our vendor closes a ticket on their end then it then updates our Zendesk ticket and another trigger runs that closes out the ticket.

    Other than that we have the regular Zendesk built in triggers and also a few Bad Satisfaction triggers that alerts management when a bad satisfaction ratings are received.  Well that is how we handle incoming tickets and the triggers that we have setup.

    0
  • Adam Ramjane

    1.       Client emails generic email IE Clientsupport@xxxx.com
    2.       Support create departmental tickets based on client email as undoubtedly one email could contain multiple issues.  Going forwards this ticket is used to correspond with the client. All sub tickets are referenced in the clients ‘Master’ ticket.  Once the ticket is closed, the hyperlink to the ticket will appear as crossed through.
    3.       Internal communication is done via the sub ticket and any priority or specific information will be contained here.  This will also avoid any security/priveledged information issues. Also allows priority to be set.
    4.       As tickets close, the master (client facing ticket) is updated until point of completion.

    0
  • Matt Zaglin

    (Just an FYI - The notification I receive from Wes's comment came in looking like the attached screen-shot.  The rest, including Adam's, were just fine).

    0
  • Matt Zaglin

    Whoops - I meant Adam's!

    0
  • Jennifer Rowe

    Hey Matt, thanks for letting us know. Yea, it's weird. I got the same notification, but when I went to the forum to delete that garbage, it wasn't there. Maybe Adam realized it and fixed it.

    0
  • Justin Koehler

    Very cool, great to get an idea on how other organizations handle their workflows for incoming tickets!

     

    0
  • Allen Lai

    Note: We deal strictly with consumers, not businesses. Once we start to sell to businesses we will have a whole new set of  processes/rules.

    IMO, integrating our billing system with Zendesk was critical. Every customer that signs up, upgrades, downgrades, or cancels, we perform an API callback to Zendesk and create or edit the user. We also add them to specific Orgs depending on the aforementioned actions.

    • Consumer - Free
    • Consumer - Premium
    • Consumer - Pro

    This ensures we always have the most accurate information about our customers. Also, if someone is not a customer and sends an email to us, we setup a trigger to send them an automated reply and auto-close the ticket. 

    We then created triggers when a customer sends an email or submits a request via the portal. Depending on their Org and which email they send to (billing@bitcasa.com, support@bitcasa.com, etc.), we automatically assign to the appropriate Group and Category. I then create views based on Category. For example:

    • New Tickets - Billing
    • New Tickets - Premium/Pro
    • New Tickets - Free
    • Open Tickets - Billing
    • Open Tickets - Premium/Pro
    • Open Tickets - Free

    I also have  views for management purposes, such as tickets that are unsolved within X days, pending more than X days, etc.

    0
  • Andrea Saez

    We have added tags for premium clients, which automatically updates the priority. Hopefully when we integrate with salesforce/evergage this can be done automatically instead of me having to do it manually :P

    0
  • Colin Piper

    One of things we have tried to do is to standardise the subject of tickets. We wanted customers to select from a list of symptoms so that we can route the ticket to the correct team with the correct severity. Yes, we replaced priority with severity so better reflect the impact of the issue. All customers say their tickets are top priority so this option is removed from their control. This does not work for email although I did look at trying to spot phrases in emails but soon went off that idea. For emails we just route by who the email was sent to

    0
  • Kristof Van Kriekingen

    Hey all!

    Lots of idea, I like it!

    This is how we will/do it.
    First we create our own software for HR management.

    So if we get a report it can either be for a feature request or an Import file. Yet maybe a bug or a question or a small improvement.
    So we have a custom field for this. ' Type of Issue '

    If the type of issue is Feature Request or Improvement
    Tickets will get assigned to a Group that we call ' Ticket Masters '. These agents will review the ticket.
    If it is already planned we'll give the feedback to the customer that it's planned and etc.. The ticket in zendesk will be closed and a new ticket will be created internal on our Jira Bug Tracker. Just so we don't keep ' open ' tickets in Zendesk . Sometimes a feature request as we all know can take up some time to be created. ( I find this very helpful, and a awesome idea, (got it from zendesk webinars!))

    If it's an import issue. or a import request, it will also be reviewed by our ticket masters and they will also make an internal ticket to discuss this at our next meeting.
    If a ticket comes in with the type ' bug ', it will be assigned to our test team, so they can take a look at it.
    If it's not a bug, we will give feedback to the customer and maybe even an extra link of our manual how it should be done etc..
    If it is a bug we will create a Jira ticket ( through Integration ) and it will be assigned internally to our programmers.
    And we give feedback to our customers.

    When the issue is resolved and we have released a bugfix or a newer version of our software. We will give feedback to our customers.

    At the moment we are slowly getting our customers from our old helpdesk to zendesk, we'll also make an extra custom field Language(with people) but only for our agents to see. So if the customer is french, it will be assigned to one of our french support agents!

    We have a closed zendesk so not everyone can make a ticket either. So it's only a few people from an organization.
    We haven't set a field ' priority'. Are all tickets of high priority? Maybe who am I to tell.
    Mostly a customer will write in the ticket itself ' this is urgent, I need this by tomorrow for my presentation or ... '
    I think then it's of high priority. Or when a user is not able to continue in our software and is blocked.
    If there is a work-around ( not always preferred ) then it can just be reported and it will come with one of the next bugfixes. If it's super urgent and blocking, then we'll hotfix it.

    To set a priority to a ticket, we don't do that in zendesk itself. Only in Jira we'll give it a priority blocking or critical if it has to be done asap. Otherwise we'll keep it normal/major.

    This is how we eventually want it to roll!
    We just started Zendesk and looking forward to it!Feel free to even give suggestions or how we can improve!
    It ofcourse will be tweaked here and there until we come up with the ' most perfect alike system ' to handle our tickets and customers.

    Kind regards
    Kristof

    0
  • Justin Graves

    It's been great to read how everyone uses Zendesk differently and is suiting it to their needs.  I've been thinking about how to explain this here and to our new employees so this has some extra parts that explain more than just how we route incoming tickets but it's really a holistic system so it helps to understand incoming tickets as well as incoming replies, etc.  Here goes...

     

    OUR USE CASE

    We use Zendesk to support our 15,000+ internal employees only. We solve about 4,500 tickets each month. Half come in via email and the other half via phone calls. We have 24 agents total but only 11 of us do 100 or more tickets per month... which means some of them should probably be made Light Agents. Anyway, here's how we do it.

     

    GENERAL SETUP

    Step 1. Tag Users and Organizations with VIP or any other designation that sets them apart from the rest.

    Step 2. Use triggers to search incoming tickets for keywords in order to add tags and/or set ticket fields, forms, groups, agents, etc.

    Step 3. Utilize tags and/or ticket fields to sort tickets into actionable groupings (views). We have views for VIP, Emergency, Password Reset, and then Everything Else.

    Step 4. Prioritize the views and tickets within them. Most important views go at the top. Most important tickets should be at the top of their respective view.

    Step 4. Let the agents loose. Let them know to attack the tickets top to bottom. Topmost view, topmost ticket first. When that view is empty move on to the next. It's like a game to get each view to zero every day!

     

    AGENT FOLLOW-UP

    We create some views for each agent in their Personal Views. All of these views are set where the Assignee is (current user).

    * Re-Opened Tickets. For us, these are a top priority because it indicates that we messed up and need to fix it ASAP. Or else, it's a "thank you" which we can close instantly.

    * 2 Days Stale. This view shows the agent all tickets where they were the last updater more than 48 hours ago. If it's been that long, we want our agents to follow-up with a call to the requester.

    * Open Tickets. This view shows all the tickets where the agent is responsible to take the next step.

    * Pending or On-Hold Tickets. The agent is not expected to take the next step on these but they might want to proactively follow-up at some point.

    * Other views based on keywords. If the agent is responsible for a certain system or set of users, they can create a view that surfaces those tickets as well.

     

    AUTOMATED FOLLOW-UP

    If an agent adds a reply, checks the box in the ticket for "Waiting on Requester" and then submits the ticket as Pending, an automation will email a reminder to the requester every following business day at the same time as the original reply asking them to get back with us. After 2 reminders, a 3rd email goes out to the requester and the agent saying that the ticket will be automatically closed (solved, really) if there is no reply by this time tomorrow. Then, if no reply by that time the next business day, the ticket will get solved via an automation. If at any time after the original reply was sent the requester replies, a Trigger automatically un-checks the "Waiting on Requester" box and sets the status to Open.

     

    AUTOMATICALLY-CLOSED TICKETS

    * We have an education systems which emails our zendesk to a custom address (like education@mydomain.zendesk.com). We automatically close those tickets via a Trigger but want that info in ZD so we can reference it later as proof of completion. Pro tip: mark these types of tickets closed under an agent for which you don't care about their metrics or else these tickets will unfairly skew their productivity.

    * We also have some servers submitting reports to a custom address. We use a few Triggers which search for keywords to find the ones that indicate a problem and assign those to the appropriate agent. We auto-close the others.

     

    QUALITY ASSURANCE

    Certain group leaders want to be notified when there is an unassigned or unsolved ticket in their group that is older than X number of hours old. We set up those notifications as Automations.

     

    SUMMARY

    Zendesk ticket routing via Triggers, Automations, and Views work well for us. If I could ask for one more "tool" in this toolbelt it would be to allow us to configure Triggers and Automations to go active / deactive based on a date and time.

    Hope this was helpful and if you have any questions about the settings we use to create a certain view, trigger, or automation, please let me know. I'd be happy to share.

    0
  • Megan Bigelow

    Hi Everyone - 

    Great post! I'm wondering how you all handle the situation in which a ticket that was once considered "Urgent" is no longer "Urgent." As an example, we have an SLA to provide a follow-up to a ticket everyone 4 hours if it is considered "Urgent" or Sev 1. NOTE: We are only using Priority ratings for tickets at this time. In many cases, we will fix the problem but leave the ticket open to perform root cause. The concern is, the ticket is still labeled as "Urgent" and flags myself (the manager) that a follow-up is needed in 4 hours, when in fact, it isn't. The easy answer, of course, is to simply change the priority of the ticket. If we do that, we will lose our ability to accurately report on meeting SLAs.

    Any guidance? Do we simply introduce a Severity rating, run reports against that and allow support engineers to change priority ratings once the problem is no longer urgent?

    Megan

    0
  • Jessie Schutz

    Hi Megan!

    If it's important to keep the ticket in Urgent status for reporting purposes, even if the issue is resolved, I would suggest either adding a tag to these tickets once they get to that stage so you can filter them out of the reporting. You could also consider using the On Hold Status (instead of Open or Pending) to further differentiate them from active tickets.

    Hope that helps!

    0
  • saurabh

    Hi,

    great discussions. We are company which gives out loans to customers and it often creates a lot of anxiety to customers. That leads few of them to contact us multiple times as there needs may be more urgent.

    I have been thinking is there a way to create a queue or view in which we say prioritize customers who have contacted us more than 3 times in say last 12 hours

    Regards,

    Saurabh

     

     

     

    0

Please sign in to leave a comment.

Powered by Zendesk