The Importance of Ticket Deflection

Any given support team will collect a large amount of tickets. These can range in complexity from simple to complex, and require a wide range of skill sets to manage, track and resolve.

The first step in handling those tickets is to gather them all in one spot with a tool like Zendesk, Jira, Asana or something else. This allows groups to track their status, report on them and manage the workload. Generally a small group (sometimes just one person!) handles all the tickets.

Eventually, however, the number of tickets and the types of tickets that come  in begins to grow. That small team will find itself buried under a landslide of requests, and will be rapidly shifting from one type of ticket to another. This constant pressure, and need to context switch takes its toll.

Tiered Approach

To help address the wide range of tickets that come in, companies tend to evolve a multi-tiered approach for their support teams to handle the influx:

• Tier 1 - This is the front line and is equipped with stock responses to as many tickets as possible. They’re typically trained how to triage any given ticket, and if they have a response to provide it. Examples of tickets this group can handle are things like password resets, simple Q&A and general feedback.

• Tier 2 - This is a more specialized group that takes over any ticket that Tier 1 isn’t equipped to handle. They may have some stock responses, but generally this tier has either access or training that the Tier 1 group lacks. There are, however, some things Tier 2 can’t handle.

• Tier 3 - These are your super-experts and they handle the most complex or challenging topics. Ideally only a small percentage of tickets end up in this group as there tend to not be many of them, and the requests can take a while to respond.

This structure allows the team to specialize. Some agents tackle the large numbers of “simple” tickets, while a smaller number focus on the “complex” ones. This increases response times, as well as satisfaction, as the simple ones are knocked out more quickly, while a more knowledgeable agent handles the harder ones.

This approach, however, requires humans - someone who is trained in how to respond to, and resolve, issues. In many cases a human is required to help out, however, employing someone to answer tickets can be expensive, and it can result in it taking longer to get an answer.

The 0-eth Tier

This is where ticket deflection, or Tier 0, comes in. This tier is everything the customer can do BEFORE asking for help. It could involve reading a wiki page, asking a chatbot something, or trying it themselves. There’s a wide range of things this COULD be, but they all result in the customer getting an answer/help without having to interact with someone on a support team. 

Examples include:

1. A knowledge base - Having robust, customer-facing documentation is a great way to empower customers to answer their own questions. These do take time to setup and maintain, however, directing customers to them is significantly cheaper than having a human answer at ticket. Many customers also want the ability to lookup information on their own, so having a knowledge base available also helps fill that need.

1. In addition to questions and answers, knowledge bases can also contain step-by-step guides customers can try on their own to resolve their issues. This subset of information gives customers one more thing they can do before having to interact with your support team. This allows customers to get help 24/7, and further reduces the demands on your support desk.

2. Chat bots - Chat bots are getting a LOT smarter and a lot more helpful. While there are certainly some gaps and features that aren’t quite there yet, these interactive tools make accessing information and guiding customers to responses a bit quicker than search. Some of the newer tools are even able to take action on behalf of a customer - for example resetting their password. This reduces the number of things your TIer 1 team is responsible for, both simplifying their workload but also reducing it.

3. Automated Tools - This one can be a bit trickier to setup, but having a tool the customer can use, without having to access a support team, is another way to deflect tickets. Resetting a password is a common example - customers click a button and go to their email to get back in. This shortens the distance between the customer having an issue and getting it solved.

Typically Tier 0 starts out as a small help-center, however, it should be constantly evaluated, expanded and updated as time goes on. Not only will older content need to be refreshed, but new pages, tools and guides can be added. 

Tier 0 Improvements

Agents should be constantly on the lookout for opportunities to improve Tier 0. Not only do they see all the incoming requests, but they have solutions for them. There’s several ways this can be done:

1. Writing (or rewriting) articles - Agents are typically closest to the problems, and solutions, so they should either have the ability to directly edit or update articles, or have a process to suggest changes. 

2. Product improvements - Agents should have a pathway to suggest product changes to avoid the need for a ticket. These suggestions should be reviewed by product, marketing, or other teams, to see what can be incorporated to help alleviate the need for a ticket.

3. Training materials - Agents should suggest ways to train customers or users on how to use systems. This can directly reduce the number of “how do I do X” tickets.

Deflection can be a bit tricky to quantify, after all you’re stopping them from having to do something (put in a ticket), so you may never know how much it’s REALLY impacting. There are a few ways to keep an eye on it.

1. Knowledge base utilization - Tracking which pages are used can give you insight into how much pressure it’s taking off your ticketing system. For example if you add a new article on password resets and that ticket type drops, you can infer the article had some impact.

2. Automated actions - The number of times your chatbot (or other tool) takes actions is another way to see how effective it is. Each password reset done automatically is essentially a ticket that wasn’t submitted.

Ticket deflection is incredibly important to a successful ticketing system. Not only does it reduce pressure on your support teams by both reducing volume and the number of things they have to handle, it empowers customers to take action… and is faster than putting in a ticket. There is a bit of legwork needed to determine what can be done, but it’s more than worth it.

Expectations with transitioning to a ticketing system

The move to a ticketing system is a necessary step in a company's growth.  It can be an exciting shift (especially for the support teams using it!), but it can also be cause for some heartache, especially for the end users expected to use it.  The root cause tends to be change… those individuals are going from simply emailing or talking to someone to now having to use a System.  

Generally it doesn’t matter what system is used, there’s now a process to follow.  That process could be as simple as using a new email or more complex like having to go to a website and fill out specific fields in a form.  This change results in friction, especially when expectations for what those users should do aren't clearly set.

Exactly what is expected can differ, but regardless of specifics, what an end user is expected to do should be considered during the deployment process.  Taking time to think through what they’ll need to do, speaking with some directly, and adjusting your system to help make things easier does take time, but it will pay off in the end.  

Failing to think this aspect through can lead to a lot of friction as your new process and system is rolled out. Customers, after all, are the ones who are coming to you asking for assistance. They’re the ones who may not be able to get their own work done, and now knowing how to reach out for help, or not knowing when help will be provided, can make their lives a lot more miserable.

Below are a few questions I ask myself to help figure out what those expectations are.  By no means a complete list, but a good starting point that will help you get into the head of the folks expected to use your shiny new system:

1. Who will be putting in tickets?  I prefer that the person experiencing the issue report it, but will it be OK for someone else to submit it?  What about agents submitting on behalf of a user?

2. What is the expected response time?  Knowing how long to wait for a reply or resolution is critical, but to protect your team and also to keep users comfortable with timelines.  Having this clearly set and shared is important.

3. Where/how should tickets be entered? Ensuring everyone knows where, and how, to enter tickets reduces frustration, especially if it changes. You should also consider what happens if someone puts in a ticket the 'wrong' way.

Basic Ticketing Systems Data Points

Ticketing systems are great... or at least they're necessary to provide some semblance of order to the chaos..  Having one is a big step in helping better understand what your users need, where errors originate, and how to improve your process.  Just collecting a ticket, however, isn't enough, it also needs to collect useful data points.

Exactly what those data points are will differ based on your needs.  A library, for example, will likely need different data than a startup or a big company.  Regardless of size.or industry, however, there are se basics that everyone should be collecting.  Many of these are done automatically, but others may require setup or configuration depending on your system. The fields you choose to collect may also change over time… this is fine! As organizations change and grow their needs for data collecting will also change and grow. At the start though, it’s very useful to collect the following:

Reporter - this is the person who enters the ticket.  This is needed to get more information, share updates and understand where tickets come from.  This can also generally be used to gather more info, such as location, department and other data points related to the reporter that are useful in analysis.

Assignee - this is the person working on the ticket.  This is necessary both to ensure one individual is actually doing the work, buy also useful in tracking utilization and bandwidth with your team. 

Time entered - the time the ticket was created is useful for several reasons, including tracking response times and SLAs and routing tickets.

Time completed - similar to time entered this is useful in tracking your SLAs and how quickly your team can close specific ticket types.
Type of ticket - this can go by different names such as issue type, case type, etc. Regardless of its name this field tracks what 'bucket' your ticket falls into. Exact values vary depending on need, but examples include things like 'access request' 'training' and 'bug report'. This data is very useful identifying trends in your tickets.

Ticketing for the Small Things

Ticketing systems are incredibly important to ensuring users are supported.  Not only do they allow us to track any given issue, they give us the ability to look for trends and changes in what’s happening by digging into data.  Ideally, every single contact gets a ticket.  This includes the simple requests, like reset my password, and the complex ones, like install a new system.

I find it easier to sell the idea that tickets are needed for the bigger asks.  After all, they tend to have more moving pieces, require more documentation and are generally more complex.  Getting buy-in for those simple requests, however, can be challenging.  After all, sometimes it takes less time to just do the Thing that it does to put in the ticket.  Ticketing always increases friction since someone needs to fill out a form, but it’s completely understandable that it shouldn’t take more effort to do that than fix the Thing.

What to do then?...

My personal approach is to setup my system so specific types of tickets just auto-close when they’re created.  I’ll still have to enter the reporter’s name, but otherwise it’s a one-click process.  The total number I have depends on the types of requests I’ve identified, but there’s really no limit.  The biggest challenge is ensuring only items that don’t require additional information don’t end up here. I’ve dropped some examples below, but I’d encourage you to think through how your help desk can be sped up using these one-click submissions.

Some Ideas (all should collect the reporter’s name, and assuming no approvals/etc are required)

• Password resets - ensure you capture the system

• Basic hardware - e.g. getting a keyboard, power cable, etc

• How do I? - referring someone to documentation

• Is X system down? - refer them to a down detector / status site

On Logging Tickets

On logging tickets

Technical support is an interesting place.  It’s where everyone goes when a thing breaks, or they need help, or they’re stuck.  In smaller companies (under, say, 500 folks) technical support can be fairly straight forward - just walk over to so-and-so’s desk and ask for help.  In larger environments, however, this breaks down… dozens, or hundreds of people needing help in multiple physical locations makes walking up to a desk MUCH less impactful.

This is where ticketing comes in.  Some type of ticket or case or contact or whatever you call it needs to be submitted to track the work and the request.  I’m amazing at how much pushback this can generate, especially in environments making the shift from smaller, walk-up-to-the-desk approaches to more mature enterprise levels.  

The biggest piece of pushback tends to be that tickets aren’t perceived as being “white glove” or “high touch” service.  By requiring a ticket, we’re divorcing the user from the process and making it a colder, more mechanical, transaction.  On the one hand, this is true - we are requiring the user to use a form or submission portal to enter information.  That said, having a “white glove” service for 1000’s of users isn’t possible without a massive number of technical support agents involved.

The tradeoff is the ticket - an artifact that allows for tracking of each request.  Not only does this allow any given technician to monitor how the request is going, tickets also give us data.  This can be used to look for trends and patterns.  Hard numbers also make it easier for a support organization to quantify what they do. Instead of “well it feels like we’re constantly busy answering tickets”, it becomes “last month we answered 1200 tickets”, or “we’ve got 120 open tickets, I need more agents”.  The minor loss in “white glove” service is more than made up for in understanding the patterns and underlying flows of support at the organization.

The Importance of Triage

Every process has a point of entry, the point or place at which new work is considered and brought onboard.  In the ticketing world, whether it’s for a benefits team, IT team or anyone else, this point of entry also represents a challenge; frequently requests come in that are missing information.  As these move through the process they start to gum up the works as downstream folks may be missing critical information and have to go find it.  At best this slows things down, at worst it results in a catastrophic failure.

This is where triage comes in.  I think of this as a sub-process that runs as soon as new work enters the queue.  Exactly what is performed here can vary, however, there are some standard questions that should be asked and actions that should be taken regardless of specifics.

Is the request clear?

Many times a request comes in and it’s hard to tell what it’s for.  Maybe the name is poor, something like “New report request”.  New report request for what?... for who?... when is it needed?  Or maybe they’re asking for something sensitive but don’t provide any reason why.  Regardless, we should always ask ourselves “Do I understand what this request is for?”.  If I cannot answer “yes”, I follow up with the customer and ask for more information.

Is any information missing?

Similar to understanding the request, we need to ask if there’s enough information to take action.  Asking for a change to report, for example, is useless without knowing what the change should be.  Asking for access to a system without providing what type of access is similarly useless.  Taking a moment to ask yourself if there is sufficient information to take action (or for the next person who gets the ticket to take action) is the next critical step.  If you think any is missing, just reach out to the customer and ask for clarification.

Who should work on this?

Once we’ve got enough info on the request, we need to then determine who should work on it.  Sometimes this is REALLY simple; there’s only one person to give the ticket to.  Other times, this can be very complex if there’s multiple available agents to help out.  In these circumstances figuring out who can/should work on the ticket can take a bit of thought since we have to take into mind things like workload and experience.  In these scenarios I find it most helpful to have a list of who is trained/experienced in specific areas, and have access to everyone’s workload.  These two pieces of info can make it easier to figure out who to assign the ticket to.

While triage does take time, it does streamline things quite a bit.  By ensuring the ticket has sufficient information and is assigned to the most appropriate resource we set ourselves up for success.  Even better, it helps build trust-based relationships with our customers by demonstrating we care about their needs.