Mood: Grateful
Music: "Transit" by Progger
Book: The Golem and the Djinni by Helene Weckler
Food: Sunday roast
Hey Support friend!
Let's ask some big questions...
What is the role of a Customer Support team? What is its purpose?
I've been thinking about this a lot lately and asking as many Support leaders as I can. I don't have any solid answers, but it's led to some great discussions. It's something we should all be thinking more about.
If you ask a group of Support leaders what the purpose of their team is, you'll likely hear some mix of:
To help customers
To solve problems
To plug gaps in the product
To represent the voice of the customer
To act as a stress ball
To reduce churn and increase customer adoption
It's not an exhaustive list, but it covers a lot of ground. They aren't the specific goals, though they're certainly related. The purpose of the team puts some boundaries on what the team's goals should be. For a team whose goal is to act as the voice of the customer, they'd probably set some goals oriented to doing things to promote customer needs internally. Conversely, a company who needs customer problems solved is going to give those tasks and goals to the team whose role is to solve customer problems.
Since Yetto is building a data analysis platform for Support teams, we're particularly interested in what teams are measuring. Looking at the list of Support purposes above, you'd expect the metrics to look something like:
Customer satisfaction scores
Solved issues per day/week/month
Ratio of solved to unsolved tickets per day/week/month
Workarounds and one-off fixes provided to customers per day/week/month
Feature requests and bug reports per day/week/month
Implemented vs unimplemented feature requests and bug reports per day/week/month
Churn/expansion per day/week/month as a ratio of customers who contacted support and those who didn't
Again, it's not an exhaustive list, but those metrics would do a decent job of answering the question of whether or not the Support team is meeting its goals, which are aligned with the team's purpose.
When you search for industry standard metrics, though, you'll find a list that looks more like this:
First response time
Resolution time
First contact resolution rate
Ticket handle time
Utilization rate (how much time each agent is spending working on tickets)
Why are we measuring these things? Why do we say that we care about the customer experience and the impact of the team's work on the business, but instead report almost exclusively on the individual performance of the team members?
There are some easy answers to those questions. For starters, our tools often give us that data out of the box and it's easier to use it than figure out how to measure something else. It sounds plausible, but it feels like a cop out. Those are often the out-of-the-box metrics because they're what most teams want to know. It's circular reasoning, but it had to start somewhere. And Support teams existed before most of our current cohort of tools did.
Maybe it's because our bosses - directors, VPs, the C-suite - are asking for that data? They don't have as much context, so they just need to know what's going on with the team. It's true, but another cop out. Can't we talk to our leadership and decide what metrics matter for our team, rather than deciding on the first thing that comes up in a Google search?
Ultimately, I think this is where we, as Support leaders, are failing. We need to talk about this with our teams and our colleagues on other teams, and with our leadership. I know I'm not the only one asking these questions and finding the discrepancy jarring. It's time we sit down and ask ourselves some hard questions.
Why do we even have a Support team? What should we be doing?
The goals we set, the data we collect, and the metrics we track should all come from our answers to those larger, more difficult questions.
I don't have the answers for you. When you're ready to think about your data and metrics differently, though, Dashbort is ready to help you.