Community discussion: How do you assign tickets?

33 Kommentare

  • Offizieller Kommentar
    Jennifer Rowe
    Aktionen für Kommentare Permalink

    Thanks for all the amazing contributions to our community discussion! It's so interesting to see the different approaches to assigning tickets to agents.

    Congrats to the five participants who were randomly selected to receive a Zendesk t-shirt!

    And if you haven't commented yet, you still can! We've completed the swag giveaway, but we'd still love to hear from anyone who wants to share and keep the discussion going.

  • Fernando Duarte
    Aktionen für Kommentare Permalink

    I have account SME who get High priority tickets assigned to them automatically by the system. Normal and Low priorities go to a pool of level 1 agents, and Urgent priority tickets got to the escalation team.  Level 1 agents are assigned to a group of account SME agents

    2
  • Antonio King
    Aktionen für Kommentare Permalink

    Equally interested to learn how others are assigning tickets, manually or via automation.

    0
  • Andrea Saez
    Aktionen für Kommentare Permalink

    I do it via an automation, but then again we're only three so it's a bit easier. All support goes to me, all marketing goes to one agent, and all sales goes to another. We have categories so our clients can let us know what their issue is about, and based on that it'll go to a specific view that those agents manage.

    1
  • Jacob J Christensen
    Aktionen für Kommentare Permalink

    We use triggers to automagically assign tickets to groups, groups are based on a combination of brand and country. Agents are members of the groups that correspond to the languages they speak (usually they only speak one language) and they are instructed to pick from views that are sorted by priority.

    During Christmas season we need to scale up on agents manyfold, we basically do the same as above, but we devide agents into teams that specialize on certain types of tickets (based on channel and ticket category).

    1
  • Marshall White
    Aktionen für Kommentare Permalink

    Our primary sorting mechanism is brand. This property is usually set based on the support email address, but we also use triggers for cases where someone messaged the wrong email address. After that initial sorting, a second sort happens that is different for each brand. One brand is sorted based on a custom ticket type field. A trigger attempts to set the correct value at ticket creation, but agents will also triage as a backup. Another brand is sorted based on organization. We create views that only show tickets from certain organizations and limit those views to groups of agents. An unknown organization view is also set up for all agents, so they can triage tickets where the organization isn't known yet.

    We never assign tickets directly to agents, only to groups, as we've found that it can result in tickets getting missed in scenarios like vacations or sick days.

    1
  • Jeremy Flanagan
    Aktionen für Kommentare Permalink

    We use a combination of tagging from our internal base through API and triggers to route to the appropriate groups. The trigger order goes from most specific to most general to ensure that sensitive tickets are caught in time. 

    1
  • Bonnie Schofield
    Aktionen für Kommentare Permalink

    Very similar to Jacob, we have agents assigned to Groups based on language and job skill. We then have Triggers that determine the Group assignment based on Forms and Categories selected by our customers when they create a ticket. Their language also is used in these triggers. 

    Once a group is determined, the Triggers assign the appropriate schedule and SLA to the ticket.

    Agents work tickets from Views (play only) based on their Groups with tickets served up by oldest SLA first.

    1
  • Reagan Helms
    Aktionen für Kommentare Permalink

    We like to work from an open inbox, so that customers get a quicker response if someone is away at lunch or their day is over. Any ticket that has a response on it has a reopened tag that allows everyone currently on to see it in the queue. But we use SLAs to order our queue.

    With that said, I have an SLA set up that makes the ticket run out faster for the assigned agent. Meaning that tickets assigned to me that have been followed up with have a 45 minute timer that I see, and they have a 1:30 timer for everyone else. My tickets float to the top of my list faster than they do for others who are viewing the same queue.

    1
  • Daniel Duan
    Aktionen für Kommentare Permalink

    In our practice, we don't actually have many technical barriers when handling tickets, and therefore don't require different technical or analysing skills for a particular agent.

    We have different BUs and tickets are handled by agents from each BU at first. Thus we set up organisations for all users in each BU (synced from AD). Afterwards, we set up different supporting groups, the ticket raised by the user will be routed to BU support group based on his/her org. setting.

    We also have an escalation team. All agents in different groups can escalate to the L2 support team. We set up a macro, which sets ticket group to L2 with public comments and others, to complete this escalation process.

    2
  • Anton Maslov
    Aktionen für Kommentare Permalink

    Our Team Leaders assign tickets. For regular tickets, they do it based on agent's skill. E.g. Mark has strong knowledge with Active Directory, so he is the best person to handle such tickets. 

    Urgent tickets are processed by SMEs.

    There is a methodology name "intelligent swarming" by KCS which describes how to do it effectively.

     

    1
  • Fredrik Vessberg
    Aktionen für Kommentare Permalink

    We use triggers to place the ticket in the right group and to be assigned to the correct agent. The triggers looks at the organization of the end user. We also add tags depending on who the requester is to be able to pick the ticket up in different views.

    Really interesting to read how others are using Zendesk.

    1
  • Steve Morrell
    Aktionen für Kommentare Permalink

    We use triggers on ticket creation to assign tickets to certain groups. Some agents are only in certain groups, so they only see the tickets that they can take.

    After that, it's a case of grabbing whatever is in your queue. We do pass tickets around the team depending on skillset or experience with a certain customer, but we're a small team, so we do it informally.

    1
  • Amy Waugh
    Aktionen für Kommentare Permalink

    We receive tickets from multiple sources. We have shared email inboxes that are linked to Zendesk and route to the relevant team that own the inbox.

    We use Formstack to receive instructions from our customers and have a unique code on each form that Zendesk looks at an diverts the ticket to the relevant team.

    We also use the API to receive tickets from our internal systems and if they raise tasks it goes to one team and if they raise a query it goes to another.

    We have 8 teams, 3 Zendesks and 70 agents. All teams use Zendesk in a different way.

    We use triggers to assign to the groups and agents assign tickets within their teams to ensure that tickets aren't assigned to agents who are not in the office.

    1
  • Molly Katolas
    Aktionen für Kommentare Permalink

    We use Zendesk both for external communication with our customers and vendors, as well as internal communication from our customer operations teams to our development/engineering teams. Most of our tickets are for external communication and come in through many sources - via the help center, emails, and agents opening tickets on behalf of customers. We route tickets to groups and then the group managers are responsible for assigning them out respectively.

    Since we're working with so many different teams (>10), we handle some notifications and assignments differently. For tickets routed to our technical support groups, they're assigned a priority and organized based on the severity of their technical issue. For tickets routed to our general customer support, they're assigned based on customer category with special attention given to "key" accounts. 

    We also have a catch-trigger that assigns any ticket that isn't caught by another trigger to our general support queue. This makes sure that we are receiving all tickets and none of them are falling into what we call the Zendesk Black Hole. 

    1
  • Viorica Pop
    Aktionen für Kommentare Permalink

    In our case we have different support centers across the globe. The ticket assignment is done based on the country/region of the customer (for each customer we set the default group). This happens for majority of our requests, but there are some requests that are handled globally, so in that case we use triggers to route those requests to a specific group.

    Each group/tier has a mix of agents, agents that are specialized and have deep knowledge of a certain product out of the # of products we have. So when the ticket comes in, the agents will assign the tickets to themselves depending on the product the customer has. If a ticket was left unassigned then the lead of the group will assign the ticket to the right agent.

    If the issue cannot be solved by the support group(s) then will be escalated to Development tier.

    1
  • Chandler Bainter
    Aktionen für Kommentare Permalink

    All three Agents in our organization are notified when a ticket is created.  The one who is best qualified to take the ticket will start working it.  

    0
  • Karen Stephen
    Aktionen für Kommentare Permalink

    We use a few things: Roles, Brands, Forms and Channels to show various tickets to different Groups and/or activate various triggers to get tickets to the the right people.  

    Certain people only work certain brands, and possibly only certain forms within those brands.  We've created groups to match their skillset and the product they manage.  We've set up views so that these agents (within groups) only see the tickets that they need to.  We also manually cc Light agents (who are often SME's) so that we get the information as quickly as possible.

    We also have integrations that we use to deliver ticket content to the light agents, via Slack channels, for general awareness of all the feedback we receive.

    We are thinking of adding some automations to escalate tickets, as required so that resolution is as quick as possible.

    1
  • Rakesh Bhonagiri
    Aktionen für Kommentare Permalink

    We have an elaborate list of issues listed in a field. On selection of any issue a trigger fires to route the ticket to the concerned/specialized group with SME's aligned to the group. That way we get the right issue to the right people the fastest way. How we measure is that the tickets are not reassigned and end up in first time fix.

    we do have integration with our vendor systems so that the there is a seamless two way communication to responsive the issue. this is done using the Zendesk APIs

    2
  • David Verhoff
    Aktionen für Kommentare Permalink

    Our organization is a tax collector's office.  The way we have our Zendesk set up is that our counter associates serving the public are our end-users filing tickets (e.g. transaction based questions).  We process motor vehicle transactions, driver license transactions, property tax transactions, and hunting & fishing license/permit transactions.

    We use our Help Center as a hub for procedures, forms, etc. that end-users can utilize to find the answers to their questions and assist with processing their transactions.  If they are unable to find their answer or need clarification, they file a ticket.

    The management staff at each of our 6 offices are the Agents fielding the tickets.  We created groups for each office's management staff.

    Each office has its own ticket form.  Within each ticket form, we have a ticket field which is a drop-down that contains 80+ categories.  Based on the category selection, the ticket will be either a 'normal' priority or 'high' priority.

    When the end-user selects the appropriate ticket form (the office at which they are working that day), we have triggers that auto-assign the tickets to the group (management team) of that office.

    1
  • James Hollister
    Aktionen für Kommentare Permalink

    We've just started using zendesk so are keeping it fairly simple at the moment with an open inbox, the first agent to get to a ticket will handle it and escalate it to second line support if needed. 

    I think we'll start to look into triggers as our company and support requests grow. 

    0
  • David M Cardoso
    Aktionen für Kommentare Permalink

    All inbound tickets are first delivered in a pre-inbox view and due the amount of cases received on a daily basis, we have one agent per shift classifying them in different views (Priorities, Generals or Specifics Topics). This agent also has autonomy to decide if a case may or not to be replied with a automated response configured in macros.

    Based on skill, experience and roles, agents will act in different views in order to solve them. Once the view where they are in charge to, runs out, they migrate to another one and keep resolving tickets.

    Sometime ago we had only one view for all inbound tickets and we also had plenty of automated responses set up on triggers. These responses would be sent based on Keywords among the customers inquiries. Unfortunately the satisfaction success rate of those responses were not reaching the minimum level established by our organization and that's the reason we simply changed the way of handling them.

    8
  • Adam Feren
    Aktionen für Kommentare Permalink

    I have tickets automatically filter to one of a few different groups based on user selections in certain ticket fields. My agents have equal access to each of these groups; the split is largely for sorting. From there, I usually go through and manually "triage" the tickets, scanning for any that need to be escalated to certain other groups that only a few light agents have access to.

    1
  • Elisa Reggiardo
    Aktionen für Kommentare Permalink

    Hey!

    it goes more or less like this:

    1. Triggers (based on tags, support addresses, description, subject, etc) ---> assign tickets to specific groups, our Zendesk groups are the mirror of our Teams, each team has specific tasks, within those groups clients are divided by the 5 languages we support therefore tickets end up being distributed across 5 different views (1 for each language).

    2. Round Robin ----> serves itself from the previously arranged views and assigns tickets to agents based on pre-established rules (priorities, frequency, limits etc).

     

    Side note: we have one agent in charge of verifying our suspended tickets as well as checking all the tickets received via email (opposite of tickets received via web form or API these ones can hardly be automatized and they are almost 40% of our ticket volume), this agent assigns those tickets to the different Zendesk groups and fills in the necessary ticket fields so that Round Robin can take it from there on. We are looking forward decreasing the percentage of tickets submitted via Email by improving our Contact Form, activating Web Widget across our Website and increasing our Help Centre visibility in order. Once the percentage of Tickets via email decreases consistently we will be able to have one common view where Team Managers will be able to pick tickets for their teams so that Round Robin can then assign them to their agents instead of having one agent doing this task full time.

    Hope that helps!

    4
  • Jennifer Grill
    Aktionen für Kommentare Permalink

    We use triggers based on the organization as well as the category the client selects when submitting a ticket.

    0
  • Galen Foster
    Aktionen für Kommentare Permalink

    We've created triggers based on incoming channels and specific email addresses. The triggers may also take into account the customers organization or any tags that were added by automations. Our triggers are based off of submitter, the form, the brand, selected fields (tags), or any other data points specific to the routing need.  

    We rely on agents picking up new general tickets once they've been assigned to groups. This works for us because each department (brand) uses Zendesk differently. They each follow their own SLAs and availability procedures. 

    In IT we have a automation that bumps any requests that hit 61 business minutes to tier 2. 

    1
  • Antonio King
    Aktionen für Kommentare Permalink

    Our channel distribution at the conclusion of 2016 was 32% email, 32% web form. We triage tickets by category into tiers (Red, Yellow, Green), with relevance to urgency to handle. Since we're an online retailer, tickets that come in with categories like "Change/Cancel Order" and "Where's My Order?" are collected together in the "Red Tier" to stress urgency in handling by the team. 

    With that, the team works on the red tier first to knock out those issues, then proceed down the other tiers until the inbox is clear. 

    Sadly, there's still no solution to efficiently distribute tickets evenly amongst agents available unless you pay extra to utilize guided mode. 

    1
  • Zach
    Aktionen für Kommentare Permalink

    We use a few combinations of methods.

    1. Support Email Addresses

    We have people who scan items in on a MFP that need to be updated, like a customer's address for example. A piece of mail may come back to us because the address is wrong. So the mail gets scanned in a forwarded to the Support staff. 

    I added a "scan" email address to the MFP and to Zendesk. So if it comes in to the address, it gets assigned to a Group and priority is set to Low

     

    2. Help Center

    Based on the category, we have rules that assign to certain groups or individual users

     

    3. Organization

    If a request comes in from specific Organizations we set priority and assignee. Depending on the Org it comes from, we will assign to a group or a  specific user.

     

    We tried to assign based on key words, but that never took off. In one case the rule was updated because the key word was misspelled. After 3 different misspellings, we abandoned the method.

    1
  • Peter Hochstrasser
    Aktionen für Kommentare Permalink

    We're just starting, however, we do have 4 different brands with different support requirements:

    1. Standard Software Product Support: Licensed users pay maintenance which includes support and error corrections. Product change requests (enhancements, extensions etc.) are also entered in this channel.
      No SLA.

    2. Premium Support: Support for individual solutions implemented using above product. Require a paid SLA, and receive their own support mail address, since several of our customers use 3rd parties to run their IT systems.
      Mostly, those third parties are the ones opening tickets with us - the number of 3rd parties is less than the number of customers.

    3. Product Support for a Web Application which targets the bookkeeping and HR tasks of SMEs up to 20 employees.
      The service is free to use, the support is done mostly via Chat. We have a few agents who specialize on this product.
      No SLA.

    4. General and Internal Support: Everything that does not fall into the categories above ;-) - lots of IT support, including coping with DMARC reports, backup reports etc.
      No SLA.

    We use a strict organization - group matching, so for each client organization, there is a corresponding support group. This is a n:1 match; several client org's may be assigned to the same group.

    We're heading towards a "First Level checks all" policy, i.e. first level support gets all customer interactions first, do the obvious things like check for completeness, request missing information etc., then involve various second and third level organisations. All output of those organizations is again screened by first level to avoid unclear statements, unfriendliness, ..., and then sent out to the clients.

    We achieve this by assigning the 2nd and 3rd level agents as Light Agents. This holds for all four brands.

    Where feasible, we assign the tickets to the correct groups automatically using triggers. This is easy in premium support, because the client sends the tickets to "his" support mail address, or registered users create tickets on their Guide/Help Center.

    In general support, we automatically process backup reports - successful ones are closed immediately, while unsuccessful ones are assigned to IT support. The same holds for DMARC reports which we get from all over the world.

    Since at this time, only one brand uses chat, its tickets are also automatically assigned.

    For all other cases, we have to assign the tickets manually.

    1
  • Graham Foster
    Aktionen für Kommentare Permalink

    We have 2 helpdesk systems - 1 EU and 1 "Global" (aka USA). I wrote our assignment system which uses the Zendesk API via Google Sheets and their automation tools to allocate tickets based on

    • Group that the ticket is assigned to (specific market segments)
    • Skills required for the ticket (something we call Call Type) and is broadbrush breakdown of the technology / product that the issue is about
    • Agent availability - i.e. are they working, (or on vacation or public holiday for their site)
    • Agents can  have "primary" responsibilities and "other" responsibilities allowing them to pickup tickets from other queues if not fully busy.

    An agent has an allocated "maximum ticket load" and all helpdesk environments are read and consolidated such that we know how many open tickets every agent has.

    We then determine who gets the ticket by assigning it to the least busy person who is available for work.(People on vacation or public holiday are unavailable for work). All this is calculated using the timezone the resolver lives in (from USA to Japan). We also try to ensure that Agents don't get assigned tickets immediately before holidays, i.e. we allow them time to respond / resolve or redirect the ticket before the end of their day.

    The great thing about this is that all this is addition to the power of triggers and automations available within Zendesk, and doesn't require the deployment of any additional hardware  systems. You do Google sheets automations simply by scheduling your function to run at specific intervals. Really cool!

    0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.

Powered by Zendesk