The Importance of Ticket Deflection
Answering tickets is great - but preventing the need for them is even better.
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:
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.
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.
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.
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:
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.
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.
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.
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.
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.
Service Level Agreements
Expectations are a tricky thing. Everyone’s got one, and they don’t always align with what other people think. This is especially true working on a help desk or providing customer support. A customer calls in expecting an answer or a resolution in a specific timeframe… and many times the agent answering the call or ticket is stuck having to reset that expectation.
Folks get expectations from a LOT of place - but there’s one that can help make everyone’s life a bit easier and set those expectations out of the gate - the Service Level Agreement, or SLA). An SLA is basically an agreement between the service provider and the customer on how long something will take or how something will be done.
Essentially it’s a promise by the customer to have a specific expectation and in return the provider will meet that pre-set expectation.
Having worked on a help desk and helped agents working on them I find them to be both really great and a bit not so great.
Why they’re great!
SLA’s are great because they set a clear expectation that everyone can see. Generally they’re posted on a website and shared with customer groups so everyone has visibility into what they are. Customers go into a call knowing what to expect in terms of service. and agents know how long they have to complete any given request.
Why they’re not so great…
SLA’s aren’t so great for much the same reasons. Customer can now see how long something should take, meaning they can end up watching the clock and getting more anxious as it gets close to ticking down. They can also cause stress for agents since watching multiple tickets near their SLA is a bit stressful.
Some Terms
Breaching - When an SLA is exceeded. For example if you have 1 hour to do something and you take 2 hours, you’ve breached that SLA.
Paused - SLAs can be paused under certain conditions. This can be done when the agent is waiting for information from a customer or something is blocking the ticket. Generally this is utilized to ensure agents aren’t penalized for things they can’t control.
Active - SLA’s are active when their clock is ticket. Generally open tickets have an active SLA.
How to manage them
Folks who have SLAs setup should be on the lookout for the following:
Tickets nearing the SLA - Tickets within an hour or two of exceeding (breaching) their SLA should be closely monitored, and if needed additional resources should be added.
Tickets breaching SLA - These ticket should be examined to determine WHY the SLA was breached. This information is helpful to improve your processes and prevent it from happening again.
Tickets with a paused SLA - Tickets that have a paused SLA should be monitored to ensure they’re paused legitimately. It’s not uncommon for tickets to be paused and then forgotten about.
SLA’s in Jira Service Management
If you’re using Jira Service Management you can easily setup and track SLAs. Be default, you’ll have two
Time to first response (TTFR) - This begins ticking when a ticket is opened and stops once an agent responds. This helps ensure tickets get a quick response indicating they’ve been received.
Time to resolving (TTR) - Begins ticking when a ticket is opened and stops once a tickets is resolved. This is what most people think of when they think of SLA’s as it enforces a timeline to solve an issue.
You should consider when SLA’s are paused, commonly done when:
Tickets are waiting for customer - If a ticket is pending the customer to respond to take some action pausing the SLA lets the agent work on other issues.
Pending - If a ticket is stuck due to a third party it frequently pauses the SLA.
What's better than "Status" in JQL? statusCategory
Searching for issues in Jira by status can be tricky. Every installation has a different slate of statuses, and that list can even vary within projects. While there are some more “standard” ones, like “Waiting for customer” sometimes a status like “Declined” will show up and throw your searches for a loop.
My old workaround was to keep a running list of statuses, especially those in the “Done” state, that I would add to queries. This looked a bit funny since I had to add “status in (“status 1”, “status 2”, “status x….”), but it got the job done. Unfortunately it made it hard to onboard new folks to the project and really frustrated users.
There’s a better way
Fortunately the nice people at Jira have a solution! Recently I’ve almost entirely stopped using “Status” for my day-to-day quering. There are specific cases where I need to use it, but generally it’s been replaced by statusCategory.
When an Admin adds a status to a project they have to select a category for it:
To Do - This status signals the ticket is pending work. Common examples include “Review”, “To Do” and “New”.
In Progress - This status signals the ticket is being worked on. Common examples include “In Progress”, “In Development” and “Waiting for Customer”.
Done - This status indicates work on the ticket is complete, or no further work is necessary. Common examples include “Cancelled”, “Completed”, “Finished”
How to use it
StatusCategory is similar to any other field in Jira : statusCategory = (value) - where the possible values are “To Do”, “In Progress” and “Done” (note they are case sensitive!.
I typically replace “Status” with “statusCategory”, so instead of using status = Completed I would use statusCategory = Done. This does make the query broader, but ensures I capture EVERY ticket that no long requires owrk.
Examples
Find all tickets in project ABC that are in the To Do category
statusCategory = “To Do” and project = ABC
Find all tickets in the ABC project that are in an open sprint and in progress
Project = ABC and sprint in openSprints() and statusCategory = “In Progress”
Check it out live: