Where does support live?
This week we take a short look at where support teams live within an organization and what they might say about the metrics they care about. If you read all the way through and find it interesting, hit the thumbs up at the bottom.
On the first day of your next support conference (yes, these exist), ask other attendees where customer support lives within their organizations. You of course already have an idea of where support lives within your organization, but just for grins, ask others about where their teams live. Is it customer experience? Customer success? Product? Marketing? You might be surprised at what you hear.
When I began working in support at Fog Creek Software, I was hired as a support engineer, but I was full Member of Technical Staff, so I guess you could say we were part of engineering, though a team of our own. When Trello spun off from Fog Creek and I started building out the support team, we initially reported to the VP of Product and after a few years reported into the Chief Marketing Officer. At FullStory, support began as “all hands support"—so not part of any department—then became a small team as part of Hugging. At that time, Hugging reported to the Chief Operating Officer. Later, when Hugging got rebranded as Customer Experience, our VP started reporting directly to the CEO. Engineering, Product, Marketing, no department, Hugging, Customer Experience.
Why are there so many places for support to live? To answer that, let’s start by exploring where support teams come from.
Photo by John Schnobrich on Unsplash
Where do support teams come from?
Your brand new startup is in its second year. You and your cofounder have built out a small product team and are starting to get product/market fit. You’re creating customers and making money. It’s a good start! You’ve chosen the self-service software-as-a-service (SaaS) business model, so your website and free trial do most of your selling for you. You put a support@ email on the website in case anyone has questions before or after they purchase. At least at first, you’re thrilled with every new ticket that comes in (“someone is actually using my product, or at least they’re thinking about it!”). You’re able to squeeze in a few customer emails between meetings and get caught up at the end of the day. But pretty soon, the end of the day starts stretching well into the night and you can’t remember the last Saturday where you weren’t trying to answer emails “so things wouldn’t be so bad on Monday”. It’s time to make your first support hire.
After a few weeks of interviews, you find someone who’s been doing support for a year and a half at another startup across town. You’ve always heard great things about their customer support, so you’re thrilled for them to get started. The first several weeks are great. They quickly get up to speed and you plan a weekend trip camping because you know you won’t have to answer emails on a Saturday morning.
The Wednesday after your camping trip—it was a four-day weekend; you deserved it—you’re perusing through old support emails and you stumble across an email from a company whose logo you would love to have on your homepage.
Hey there, I’m wondering if you offer Single Sign-On (SSO) support for your app?
To your horror, your new support rep replied:
Thanks for reaching out! Right now, SSO isn’t available, but I’ve added a “plus one” to the existing feature request on your behalf. We’ll let you know when this becomes available.
Okay, it’s not that bad of a response. The voice and tone is on brand, you’re glad they’re tracking the feature request, and they did respond within 30 minutes. But ugh, what a missed opportunity to engage further with this future customer! If you had been the one that replied, you would have invited them to jump on a call so you could learn more about what has them interested in your product. And from a product research perspective, you want to know what identity provider they’re using. And you would have done anything to get that logo!
What’s going on here?
The founder hired someone to “take care of the inbox”, which meant providing on-brand responses to customers quickly. The support person who was hired came from a team that only ever dealt with current customers (they had had a separate team handling pre-sales emails). When an email from a prospect about a feature request came in, the support person treated them no differently than a current customer, providing an on-brand and responsive reply. The founder, who intimately knew who was and who was not a customer, always treated pre-sales emails differently, and as a product person, was always eager to dig deeper into feature requests to truly understand customer pain. But those things hadn’t been included in “take care of the inbox” training.
In a “take care of the inbox” approach, the founder isn’t thinking about where the support team will best align or what existing teams’ metrics will most closely be moved by support. Really they just want someone to answer the emails. But as we’ll see, there are many metrics which we can potentially use to measure customer support.
The many metrics of customer support
I suspect that many support teams begin as “take care of the inbox” teams, and as the business matures, the support team starts to align closely with existing (or newly formed) departments. Those teams are going to have metrics they care about, and support will mostly align with those teams, but as the inbox for the entire company, it’s never so cut and dry as being able to align perfectly with just one department.
One of my favorite metrics for customer support is “contact rate”, which is the number of people who do email you for support divided by the number of people who could email you for support. All things being equal, you want contact rate to go down over time, because it means your product is doing a better job supporting customers, precluding the need for customers to reach out. This would be a product metric.
You could also measure customer retention as a function of customer support. “Don’t provide support that is so bad that customers would rather pay a cancellation penalty then spend one more day doing business with us”, you might say. And then maybe you look at the customers who cancel and see which of them had a recent support ticket that went south and you make it a goal to reduce the number of bad interactions so you can retain more customers. This would be a customer success metric.
Or you could look at the number of new leads and expansion opportunities that are generated from the support inbox. You might even give a spot bonus for each new qualified opportunity generated or deal closed that originated from the support inbox (incentives matter, though I’m not sure I’m a fan of this approach for support). This would be a sales metric.
I could go on. The point is that as the business matures, the department that support ends up in is going to have metrics that its VP is responsible for, and support will mostly align with those metrics, but being the caretakers of the entire company’s inbox, there are going to be claims to other metrics that better align with other teams. This is why support teams can live in so many departments within the organization. But that’s also why support teams are going to have metrics that feel like a better for other departments. That’s okay. Customers don’t always fit neatly into your departments’ metrics, either, so it makes sense that support teams are aligned to metrics across the business.
Etc.
Things I’ve read:
The CNN/Sesame street town hall on racism I haven’t watched this yet, but I’m planning to watch it with my kids the first night I’m not writing a newsletter.
How to raise a black son in America 5 minute video. Highly recommend.
The Stand by Stephen King. I mean, it’s a whole entire novel and I’m not saying you should read it, but I just finished it so technically it’s a thing I’ve read. I enjoyed it. It’s long.