Proactivity in a reactive team
It's like peanut butter and chocolate
I want to kick off the second half of 2023 by spending a little time thinking about one way that different business tasks can be bucketed: proactive and reactive actions. For a working definition, let’s say that proactive tasks are ones where you’re actively taking steps to help the business, and reactive ones are ones where you wait for something to happen, then react to it. Obviously this is oversimplifying, but for our present purposes it will suffice. Using these definitions, we can say that everything that a company does is either proactive or reactive, driving towards a goal or responding to external conditions.
Building on this, every organization is divided into functional teams, and each team is either inherently proactive or reactive. Proactive teams are sales, customer success, software engineering. They look for and undertake tasks to further the goals of the organization. But technical support is reactive—the job is, when you come down to it, waiting for customers to have problems, then solving those problems. We react to customer issues rather than proactively preventing issues.
But of course no team is 100% in one box or another. Proactive teams have tasks, or seasons, that are primarily reactive: think about when CS starts an urgent project trying to save a customer that is at risk of churn, or engineering teams pause regular work for a week of bugfixing. And support is no different. Though its bread and butter is reactive, there is still plenty of room for proactivity. Just a few examples:
Writing and updating documentation to address customer questions
Submitting, reproducing, and helping prioritize bugs
Writing up and proposing feature requests
In fact, I’d argue that it’s essential to save room for these proactive tasks because they’re what make the entire job manageable. If the support team is spending all of its time fielding and resolving customer problems, the overall support load will just get heavier and heavier.
No proactive work on documentation and customers can never get anything accomplished without asking for help.
No proactive work on submitting bugs and customer issues persist, and generate new tickets, forever.
No proactively advocacy of feature requests and customers get angry and repeatedly ask for the same thing because it never gets built.
Because customer support is one of the closest interfaces the business has to its own customers, support teams are uniquely positioned to act proactively in the customer’s interest. The trick is finding the trends and issues that need to be proactively addressed while down in the weeds of reactive work.
If you’ve been reading for a while, you probably already know what I’m going to suggest. Build proactive activities into your ticket response playbooks, and communicate regularly both within and outside the support team to make sure Support has the authority and institutional support it needs to take these proactive actions.
Proactive steps in reactive playbooks
Looking at the example proactive support activities I mentioned above, one thing they all have in common is that they all flow directly from the support tickets your customers submit to you. Therefore it makes a lot of sense to redirect that flow, so to speak, directly into procedures that lead to documentation, bug reports, and feature requests.
Documentation—our rule of thumb on one team was as soon as a question was asked twice, we would look at the relevant documentation for that feature or procedure to see what improvements we could make. We’d then work directly with the education team to address any shortcomings we identified, which could range from adding a more specific example to writing a new document altogether. One issue with this, of course, is tracking when there have been multiple requests if your team is more than just one person! One way to manage this, and integrate documentation updates even more tightly into ticket handling procedures, is to mandate an automatic documentation review every time a usage question comes in. This requires careful balancing between level of effort and the corresponding improvements to the documentation, of course!
Bug reports—when the support team is empowered to open bug reports, the pipeline to an engineering fix is significantly shortened. The only concern here is to avoid flooding the bug system with spurious customer reports that are attributable to misunderstanding or misconfiguration. Part of the ticket response process should be to verify all customer-reported issues, either by reproducing them in your own environment (ideal) or witnessing the issue live via screenshare (at a minimum).
Feature requests—similarly to bug reports, permitting the support team to open feature requests directly with the Product team allows for a faster flow of feedback from the customer to Product. The balance to be struck here is how much judgment Support brings to bear on these feature requests: do they submit any and all customer suggestions, or are they encouraged to gently push back on clearly impractical suggestions? This needs to be established by agreement between Support, Product, and CS, as every organization will have different needs.
Communication
As I alluded to above, most proactive support activities are going to involve interfacing with others: regular discussions with the rest of the support team to look at trends you’re seeing in where customers are having problems, and agreements with other teams like customer success, product, and engineering to make sure you’re all agreed as to the scope of what your team is empowered to address on its own. These aren’t discussions you’ll have only once!
For coordination within the support team, a good place to start is in your regular ticket crash meetings. You are having those, right? Once these meetings have been going for a little while, folks will become accustomed to thinking more strategically and holistically about the tickets they’re seeing. And you, as the support leader, are well positioned to point to trends that you’ve been seeing. Maybe the ensuing discussion will suggest a particular proactive course of action, perhaps not. Weekly team meetings and focused discussions are also good places to bring up larger trends and customer pain points that you’re seeing, but the tactically-focused ticket crash is the natural place for these discussions to begin.
A full discussion of the interfaces between Support and other teams in an organization will have to wait (stay tuned!) but in brief, it’s a matter of regular communication and coordination between leaders of these different teams, leavened by the regular involvement of everyone on both teams, not just the leaders. An example of this is one I will certainly be returning to in the future, the Support relationship with CS in one of my former roles. The director of Customer Success and I met regularly, one on one, to discuss any points of friction or larger projects that our teams would need to take on together, and came to broad agreement between the two of us. But then, critically, we would bring this discussion to the broader teams in joint semi-weekly meetings. This would allow us to present our thought process and conclusions to the larger group judgment, and any points of confusion or contention could be dealt with before it had a chance to fester and cause lasting harm. To bring it back to our current discussion, Support and CS leadership might agree on a specific escalation path for customer feature requests, then bring this proposed change to the larger group to ensure everyone understood and bought in.
While Support will always be inherently a reactive function in your organization, you can vastly increase your team’s productivity and overall support load by regularly carving out time and space to perform proactive tasks. Your customers will be happier not having to ask the same questions over and over, your engineers will be happier not responding to the hundredth ticket about the same GUI bug, and your coworkers will be happy to have your team helping them with their own functions. What’s not to like?
Thanks for reading Andy's Support Notes 💻💥📝!