Proactive support
Co-Founder, CEO
Hey, Support friends. This one is for the Product and Engineering folks. Send this to them if you like, and then go take a coffee break. You deserve a moment to yourself.
Customer Support teams exist to solve problems — specifically, the problems of people who use their company's products. If your product worked flawlessly and did exactly what every customer wanted and expected, you probably wouldn't have a Support team at all.
Your product isn't perfect, though (sorry to break it to you). Nobody's product is perfect, so everybody has Support people who talk to customers all day every day. All they do is answer questions that customers call or write in about, right? They react to customers, fix their problems, and then everyone goes home happy.
Wrong. That's a limiting belief and a huge missed opportunity for everyone. Open yourself to insights coming from your Support teams. Your product teams — and your customers — will thank you.
The value of Support
People in most of the Customer Support circles I travel in talk about "the value of Support." They talk about how to bring value to the company, how to show value to the C-suite, how to prove their value to other teams. For years, I've heard people plead their worth to those in charge. Wherever Support Professionals gather, this conversation happens.
It's great that we're talking about how important this work is; thousands of us do this work because we care about it and want it to be better. But we don't seem to be convincing anyone outside our smallish circles that the work is valuable.
The core sources of value Support Professionals tend to bring up are:
- Customer retention. We solve customer problems. Ideally, they're happier after talking to Support than they were before even encountering the problem. This makes them loyal, and that means they renew.
- Customer growth. We help customers find more ways to use our products and services with our insider knowledge. This means they stick around and upgrade or make additional purchases.
- Product feedback. We talk to people about products all day, amassing troves of untapped product feedback data just waiting for an eager product manager. It's becoming more common for Product and Support to dig through this data together.
- Product knowledge. Few people at a company (cough nobody cough) know its products better than the Support team. They know what it can do, what it can't do, what customers expect it to do, and happens when customers do something they shouldn't. We use that knowledge to write product documentation or make video tutorials and other educational materials that keep customers happy.
All of these improve the customer experience and, in most cases, improve the company's bottom line.
But.
All of the things we value from Support teams are reactive. Everything on that list adds value to the customer experience after a product is built and shipped and in a customer's hands.
We're missing out on something big here. And we're devaluing the work of Support by limiting it this way.
Vote early, vote often
Your Support team is sitting on a mountain of data regarding how customers use your products, and it's a big mountain. They know what customers want, expect, and need. They know how customers act (even though they would often like to forget everything they know about how customers act) and have insight into what they'll do with a new product or feature - how they'll react to it, how they'll try to use it, whether it will meet their needs and expectations. Product teams pay large sums of money to contractors and consultants for this kind of data.
If you're lucky, your company has a user researcher (or even a user research team) specifically tasked with getting this info. But your Support team already has it... though it's probably uncategorized and disorganized because nobody ever asks them about it. Support teams are asked for feedback about products that have shipped (sometimes; oftentimes, we aren't even asked about that). But I very rarely hear about Support teams being asked to weigh in on product conversations during the earliest stages of development.
There are two benefits to bringing the Support team into product conversations as early as possible:
- They'll be better prepared to support a product if they know how and why it was built.
- They can give valuable feedback from the customers' point of view before anyone spends time building anything.
That second point is huge... and is almost universally ignored. In my experience, bringing Support into Product and Engineering conversations at every stage of the product development cycle yields better products that are better received by customers. (My data is anecdotal, but I stand by it.)
When a Support person is "in the room" for product conversations — from first idea to first release — the product will likely have fewer edge-case bugs. The Support team doesn't just know what bugs customers run into: they know why the customers run into them. This insight can help predict what kinds of edge cases new features and products will need to handle.
The Support team can also give early feedback on product direction. What will customers think of this? Will it solve the problem that we want it to solve? Will it uncover new problems that the Product team might not know about? I'm not suggesting that Support should dictate what gets built; there are lots of inputs needed for those decisions, and Support often has a biased view since we primarily talk to customers who are having problems with the existing product. But it's a deeply insightful source of input if harnessed well, like by having Support vet new product ideas.
Talk to us!
Too often, Customer Support teams only talk to other orgs when there's a problem. When there's a bug that needs to be fixed, we talk to Engineering. When there's a sudden influx of negative feedback about a new feature, we talk to Product. But not seeking Support's input on new product developments throughout the product lifecycle is a missed opportunity for Product and Engineering. It means changing your MO slightly, to make space for another hand in the pot and another person in the meeting, but the potential payoff is significant.
You're smart people. You want to do what's best for your products and your customers. You want to do the right thing for everyone at your company. I'm sure you can find a way to include Support's input and insight earlier in the design and development process. I believe in you.
Want to see what cross-functional support operations look like in practice? You can sign up for Yetto for free during our beta period and start using a cross-team support help desk right now.