Support vs Customer Success
Battle of the century!
In my current role, I’ve been tasked with building a dedicated Support function. At the same time, another newly hired leader is building and formalizing Customer Success (CS). As we work side by side, the same questions keep popping up, both in our conversations and from elsewhere in the organization:
So who handles what?
How can you decide who’s going to field questions that come in?
When is it time to hand off issues from one team to the other?
How do you keep information flowing and ensure your teams are aligned?
So I’ve been spending a lot of time thinking about this stuff lately, which means that you get to hear about it too. This week we’re going to talk about Support versus CS.
The distinction can be fuzzy
There’s a lot of overlap between Support and CS functions. They both interact directly with customers, they both build relationships with individuals on the customer side in order to more effectively do their jobs, and they’re both highly invested in the success of the customer. But that’s where the similarities end. The critical distinction between the teams is this:
Support owns all customer issues and inquiries that are directly related to the technology, while CS handles issues around the business relationship and nontechnical product inquiries.
This isn’t a hard and fast boundary, but it’s a good way to conceptualize the two domains. If an issue comes in related to the customer experiencing a bug? Support gets it. If a question comes in about renewals? That’s Customer Success. Where things get more interesting, however, is in the borderline cases. Who handles questions about product functionality, for instance? What about feature requests? This is where Support and CS leadership have to spend time in discussion, carefully delineating the boundaries and providing guidelines for their teams to make sure customer inquiries are handled as effectively as possible.
Setting boundaries
Especially in early-stage startups, you’ll often find a single person handling both Support and CS tasks. Either they’re more a technical resource and do their best with business-related customer interactions, or they’re more experienced with the relationship side of the business and are doing their best to field and escalate technical issues. So this can make it even more difficult to figure out where the boundaries lie, when it comes time to hire more dedicated support and CS folks. But even when you’re starting both teams at the same time, the ambiguity of ‘who handles what’ is going take quite a while to sort out. In the meantime, you’ll have false starts, you’ll have Support fielding issues that should have gone to CS, you’ll have CS fumbling through technical issues that they should have passed along to Support sooner. And all this is okay. The critical thing, as a Support or CS leader, is how you discover these misfires and prevent them from happening again.
So how do you figure out those boundaries, then? “By crossing them, repeatedly,” is the glib response. But there’s a lot of truth to it. As I’ve mentioned before, in a previous role I stayed in close contact with my counterpart in Customer Success. We built the boundaries and connection points between our team week by week, looking at points of friction (and of success) from the previous week. Case by case we improved our internal processes, and built a library of examples for both our teams to refer to on future occasions. Every Support and CS org is different, so the exact demarcations between them will change from company to company. Don’t expect to get it right the first time, but make adjustments regularly and soon you’ll find the proper balance.
… And crossing them
I’ve just spent the last few minutes telling you that boundaries are important, and to make sure the right team is handling the right issues. Now I’m about to tell you something that may seem contradictory, but bear with me for a moment. Sometimes it’s more productive for Support to handle CS issues, and vice versa. Imagine this situation: a Support engineer has been working for some time with a customer technical contact, and has had great success over a number of months or even years in solving their issues and building a relationship with this contact. Now the engineering team has discovered a long-standing security issue in the product, and company leadership has decreed that all customers must be notified. Normally this would be a CS task—sharing a difficult product-related announcement—but with the warm relationship your Support engineer has built up with the customer, why not let them handle it? They can share the news more effectively and empathetically than CS in this situation, and as an added bonus can handle any technical follow-up questions as well.
Similarly, you may run into issues where CS is in communication with the customer when they run into a technical glitch that this Customer Success manager (CSM) has seen before. If they can solve the issue themselves, let them. It will help build more trust between the CSM and the customer, and fortify the CSM’s own technical chops.
The key aspect of these situations is straightforward to discover: the Support engineer or CSM is already in contact with the customer, has the skills necessary to handle the problem at hand, even if it’s outside their specific duties, and is comfortable taking on that additional responsibility. In cases like that, it makes sense to empower your Support engineers and CSMs to branch out a bit to more efficiently solve the customer issues in front of them. But even in less clear-cut circumstances, there’s a lot of value in cross-training and pushing the boundaries of Support’s, and CS’, capabilities. If CS can train Support engineers how to have more customer empathy, and how to handle difficult customer conversations, this can only improve the support process, not to mention providing an early warning system back to CS when customer frustration is increasing. And the more technical aspects of the product that Support can convey back to CS, the more issues CS can handle themselves without having to involve Support. Like the above example, this builds customer confidence in the CSM, and can go a long way towards improving the customer relationship.
There’s one major topic I haven’t covered today, but we’ll get to it next week: effectively handing off issues between support and other teams, particularly CS. Join me back here next week!
Thanks for reading Andy's Support Notes 💻💥📝!