Attack plans always provide a better CX, even if the customer doesn’t follow the steps provided, doesn’t see the next issue you described, or ends up escalating the case as you anticipated.
Customer frustration with your support can be caused by many things.
Do they need to contact you multiple times or through multiple channels? Do they have follow up questions, or feel like they are troubleshooting the issue for you? And do they need to re-explain their issue multiple times?
When a support agent does not know the answer or has not seen a specific issue before, there can be a sense that you are asking the customer many things with no clear direction or cohesive strategy, also known as “throwing spaghetti at the wall to see what sticks.”
A better approach is to look at the problem in its entirety and use only the tools and steps necessary based on the customer’s needs. This concept is similar to how online map software works.
You input your starting position and your destination and it will calculate a few different routes. They may differ by time, distance, or mode of transport, but it shows you the entire plan, which is then easy to follow. It does not just show you the next turn or direction, one step at a time, waiting for you to ask about what follows. Also, it often gives you choices for other routes.
One route could be blocked by construction, or include a highway which you might not be comfortable driving on. Therefore, it shows you different options and paths, but always with your destination in mind. The software helps you make self-service choices for the best way to solve your own problem.
Support tickets can be approached the same way: identify the end goal, anticipate the follow-up directions, and offer options or different paths based on previous outcomes. This methodology is called an attack plan.
Attack Plans can be used with any support ticket and will improve your customer experience, lower your customer effort, and increase your support representative efficiency.
When a customer contacts support, they ultimately want to work with someone who is knowledgeable and is capable of solving their issue. However, as studies show, they want to do so with the least effort possible on their end.
There are numerous techniques and process to accomplish this: a robust knowledge base, video tutorials, in-product guides, chatbots, etc. All of these are potentially excellent ways to reduce the effort your customer has to put into a resolution. However, these are just tools, and just like any other tool, there are times to use it and times to not.
How do you know when to use which tools and in what combination?
“The general who wins the battle makes many calculations in his temple before the battle is fought.” -Sun Tzu
Attack plans are a way of organizing your tools and deploying them at the right time. The idea is to take an anticipatory mindset that focuses on creative, efficient, and objective-driven solutions. When a ticket is opened, there are things that you do and do not know.
Look holistically at all of the things you can ascertain from the ticket details, and the associated metadata to which you have access. Too often support agents ask customers for details that can either be determined through a customer relationship management tool, a previous case or other available heuristics.
Once you have everything you need, consider which tools you require to solve the customer’s query. To figure that out, start with some questions about how you need to go about solving the problem.
Ask yourself:
- Is the client seeing something they do not expect, or not seeing something they do expect?
- Is this a known or documented issue?
- What options does the customer have?
- Are there any barriers or unknowns to solving this problem? (eg. language, timezone, technical ability, permissions, etc.)
- Is the customer’s goal or expected outcome clear?
These starting questions will help you to frame up how to attack the case and resolve it fast.
For example, if the client sees something they do not expect, can you re-create the issue yourself? If the issue is not known, is it something specific to this device, person or organization, a recent change/update, or is there a broader impact of which you are not aware? If there is a timezone barrier or a technical ability barrier, will you address that through a different channel or team member?
Often, these steps are probably already done intuitively. It is the amalgamation of all the information and the forethought on what tools to use that build an attack plan.
An essential element of an attack plan is to remove iterations with the customer from your approach. Instead of giving one piece of information or asking one question at a time, you present your entire thought process.
It is the difference between “Is the button you see greyed out?” and “If the button is greyed out, please select option XYZ…” The first question requires the customer to respond to you. You have given no direction, and they are unable to solve their problem on their own without waiting for another response from you. The later statement potentially helps the customer to solve their problem all at once, without any further contact.
There are three main frameworks you can train yourself to use to help you build a complete attack plan. They can be used in combination with each other, or separately, but always with the anticipated outcome in mind.
If this, then that
This type of attack is used when there are a limited number of options. It works exactly as the title suggests: If you observe this, then take this action. In practice, this allows a customer to achieve their goal, even if your initial guess as to the problem is incorrect. This approach can also be step-by-step if there are multiple paths a customer can take.
For example (bolding just for emphasis):
I see you are receiving a browser error. If you have another browser, then please try the same action through it, if you do not, then please clear your cache. If the problem persists after clearing your cache or is reproducible in another browser, then please copy the exact error code and send it back to me.
The customer sees a clear path of thought, can do this work asynchronously, and only requires to contact you again should all the debugging you have tried failed.
Next Issue Avoidance
Next issue avoidance is the concept of predicting where a customer may hit a further problem, based on their original problem, and solving it before they need to contact support again.
In the example above, there are obvious places where there could be other issues that the customer will need to ask you further questions.
For example, if they are non-technical, they may not know what a browser is, or how to clear the cache, or how to capture a screenshot. In your attack plan, remove the need for the customer to write back to you by linking informative articles or videos explaining all of these concepts.
Another example is when you know through predictive analytics of your cases that customers who take one action, often take a predictable action right afterward. To reduce further effort, you could say something like: “If you wish to do action B after you are done with action A, here is a great article that can help you through that.”
There’s always a balance – you can’t predict four or five actions into the future (and it would be crazy for a customer to read through that many suggestions!) Stick to offering help for the next one or two potential requests, and then continue the conversation from there if needed.
Anticipate the Output
Anticipating the output is a type of next issue avoidance, but more focused on the things you learn about a case.
For example, if the sentiment analysis of the ticket, whether automatically derived or just intuited, is indicating that the customer is either under a deadline, frustrated, or ready to escalate quickly, you can anticipate that and involve a tier 2 agent or a manager.
If the product is under warranty, you might anticipate the customer will want to know if the problem is covered under that warranty, and therefore the agent could research that as part of the attack plan.
Zendesk offers an AI driven “satisfaction prediction” engine that automatically sense if each issue tends to result in an unsatisfied customer. This allows teams to prioritize or escalate incoming tickets based on how sticky the situation might become – potentially heading off a frustrated customer.
Anticipating the customers’ needs or their expected response will help you frame your solution to be better suited for them in their current situation.
A common reaction to this methodology is that it takes too much time, or often results in wasted effort since customers may not take all the actions sent. We follow comparable processes all the time.
For example, seat belts always provide safety, but only actually save a life when the vehicle is in an accident. We all wear seatbelts because it is demonstrably better, even though it is unlikely we will be in an accident every time we are in a vehicle.
Similarly, attack plans always provide a better customer experience, even if the customer doesn’t follow the steps provided, does not see the next issue you described, or ends up escalating the case as you anticipated.
The number one benefit of attack plans is that there are fewer iterations between a customer and the support agent. This advantage leads to lower customer effort, and less time per case for your agents. With higher iterations, there is always wasted time re-reading the ticket to remember the context and then thinking about next steps and typing another response. Attack plans save that effort.
Handoffs also become easier. If there is a well laid out attack plan and the customer responds at a time the case owner is out of the office, another agent can immediately understand the course of action the original owner intended.
The customer does not have to repeat themselves, and agents spend less time trying to read and catch up on a ticket, which also provides a better customer experience and less customer frustration.
Finally, attack plans will make your customers more successful when communication is asynchronous.
If your customer is in a different timezone, or can only work on the issue outside of your business hours, having more steps and providing more details to remove further roadblocks to success will allow your customers to self-serve as much as possible. A customer should rarely be forced to respond to you.
Between fewer interactions between customer and agent, faster resolution times, and not forcing the customer to contact you back, your customers will have a more satisfying experience when there are problems that arise.