For many CX organizations, the aspects of your support structure serving as the front line are not unique thoughts. Oftentimes, agents might be answering questions regarding new promotions, product updates, policy changes, or other aspects of a number of other external communications your external teams may send out from time to time. However, there are times where your agents might be serving in a response capacity; where they need to react more to something occurring in the moment.
Within the SaaS space, this often occurs when a service goes down for a number of reasons and becomes inaccessible to those who use it. Agents may find themselves tasked with forming a response as other internal teams work to rectify the issue. Like cooking a complex meal in your kitchen, much of how well it may turn out relies just as much on the preparation as well as the execution. Below are some aspects of incident response that could be worth considering if you are looking to overhaul your organization's own response process!
Defining your process
Whether a vendor integral to your business is having issues, your own product suffers some unexpected interruption, or another outside force causes a huge influx of volume to your support team, it's best to be prepared with a broader response process your team can leverage in those types of high-stress situations. While it might be a little different depending on your area of business, below are the general stages of an incident response:
- Response Identification - This begins once your CX organization starts seeing a pattern of incoming volume. Maybe your portal became inaccessible, a bug on your app is causing an odd user experience, or your business is receiving an influx due to recent PR. Once you have identified a common issue, it's time to investigate.
- Investigation - Investigation is the stage of an incident when internal teams are engaged to find the source of the issue and begin drafting plans to remediate it. This could be a code review by internal developers, sourcing more information from customers on their experience, or engaging third-party providers for updates if you have reason to believe the issue lies outside of your own organization.
- Resolution - Once the issue has been identified, it is time to begin implementing a solution. During this time, teams internally might be implementing a fix for an issue. Once complete, it could be worth checking in with customers to see if they believe the issue is persisting from their side if it's something they are able to observe.
- Conclusion - Once a fix has been deployed and it is confirmed that the issue is resolved, the incident can be concluded and your CX team can begin winding down from the event and returning to normal operations.
These stages speak generally to what many responses may look like from an organizational level, but yours may feel different based on your needs. Understanding your response at a high level is important as this can help inform you on how your support team can fit into this process!
The CX Response
Understanding the common stages of an incident, it's now worth understanding how your organization’s support team can fit into this response. There are a few key philosophies to keep in mind as you build out your incident response process:
-
Your process should automate
Instead of being set up to work fast, many teams can fall prey to the analysis paralysis of an unexpected response. What do I say to our customers? What aspect of our product might be broken (and what aspects are not)? Are we doing everything we should be doing right now? These questions can be difficult to answer in the middle of a response, but your process can help streamline your team towards quicker answers. For instance, having a process built in to speak with developers during a technical outage can provide a support team with the information needed to answer questions your customers may have faster than they would otherwise. Additionally, having checklists of tasks to accomplish during a response can help with a quicker mobilization of your team.
-
Your process should be trainable
A process is no good if it can’t be understood by your support team. Enablement training to introduce them to the process as well as reference documentation they can leverage in the moment are key to kicking off their understanding of what would need to be done. To keep the process fresh, it would also be a good idea to schedule drills at a regular cadence, such as quarterly, to ensure that the practical aspects of your process remain fresh in the heads of your support team for when they need it. It should be designed to be simple, actionable, and remove complexity so you can be efficient in your response.
-
Your process should be iterative
In the same way that our products and services evolve overtime, our response processes should as well! We will get into common roles for a response team soon, but one role will consist of someone on the support team logging information and debriefing with the team after a response has concluded. The debriefs are centered around the questions of what when well, what can be improved, did we ever stray from our process, and what could we do differently next time. These questions are open-ended, and encourages participation from your entire team on informing what your response process should look like first-hand.
-
Your process should be customer-centric
At the end of the day, your response process should be designed to provide our customers with all of the actionable information they need so they can make informed decisions should this issue impact them. Ensuring you have guidelines for messaging so your support team knows what to include in their responses is key in ensuring you provide them with all of the relevant information they need.
Roles & Responsibilities
We spoke to leveraging checklists to help automate your team’s response previously. These types of lists can help eliminate the questions of what needs to be accomplished, and can instead usher your team towards doing what is needed quicker. As a part of helping to streamline your support team’s response during an incident, it can help to break up expected tasks into different roles so your teams can hit the ground running when an unexpected issue arises.
Below are some sample roles your team can adopt in some way based on how you want your process to look. You might consider shifting some roles around, expanding the reach of a role, adding in your own tasks based on your business needs, or outright eliminating a role entirely. All of these are fine; and are encouraged as a part of the iterative nature of your response process!
- Primary Owner - This person is the person who first reported the issue internally. They will be the POC on your team that will be engaging other teams internally should they be needed in the investigation and resolution of the issue. They will serve as an ultimate source of truth and will serve as an internal liaison to the rest of their support team.
- Deputy - This person helps to coordinate the support team’s response directly. They will lead the coordination of the team and will serve as a liaison between the Primary Owner and the rest of the support team. They will also help ensure all roles are assigned and will periodically check to ensure everyone on the team has everything they need as they continue reacting to the issue.
- Scribe - This person will document all aspects of the issue and response for review. They will take notes throughout the issue, keep a timeline of events, and will both create and lead a meeting to go over the team’s incident response and discuss how to iterate it based on the team’ s feedback. All of this information would likely be documented internally for posterity.
- Customer Liaison - This person works to construct customer responses during an issue. They will manage external communications the team will leverage for repeated questions, and update a central status page as needed to ensure communications are distributed as widely as they can be. This person may also decide what information should or should not be shared at that particular time.
- All Other Support Staff - Everyone else will work through incoming volume while assisting anyone in the roles above with anything they need!
The roles described above can be the preliminary ones you adopt for your response, or function as guidelines as you work through creating what would be needed for your specific response. Over time as you continue to respond to real issues and drill your teams, you may find these responsibilities morphing and changing overtime. This is a completely natural aspect of the iterative process and the more you and your team embrace it, the better your process will work for you!
Creating an incident response process can feel like a large initiative, but once created, it can help streamline and eliminate much of the stress during an incident response so your team can respond in a more certain and coordinated way. This will help provide your customers or clients with the information they will want or need during an incident.
At the end of the day, this process and your response is in place for them; and the more prepared your team is to serve them in these types of situations, the more they will appreciate it!
For more information, you can always reach us by emailing: support@kustomer.com