Community discussion: How do you assign tickets?

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

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

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.

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).

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.

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. 

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.

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.

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.

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.

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.

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.

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.

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. 

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.

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.  

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.

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

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.

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. 

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.

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.

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!

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

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.