Giving customer support a seat at the product table

At Intercom, we’re ferociously focused on two things: our product and our customers. Keeping a strong bond between these two parts of our business is paramount to our success.

But keeping the bonds between product and support is hard at a growing startup. The bigger your customer support team gets the more conversations you have to handle. The bigger your product gets, the harder it is to keep all this information in one person’s head. The more bugs and feature requests you get, the harder it is to get it all triaged and prioritised with the product team.

Thankfully, in recent months, we’ve discovered a new way for support and product to always stay in sync. We’re now embedding customer support into product teams.

Hold up – customer support reps sit with engineering?! If your first reaction is “That will never work”, bear with us. It might sound far-fetched, especially if you’re a fast growing startup drowning in support requests and the last thing you can afford is to lose a rep. But this method is based on some strong assertions any customer-first company can agree on.

• Priorities: Customer support is a top priority for your company and always will be.
• Feedback loops: great products are a result of direct access to customer feedback.
• Perspective: engineers, designers and product managers should have a clear customer perspective for all decisions.

If you’re reading any of the above and nodding your head in agreement, read on to see how this unique approach can be implemented in your organisation.

Journey to an embedded role

Working on customer support is a thrilling experience. You’re pulled in loads of directions (in the best possible way). As you’re tasked with answering so many different types of problems, you’re a generalist. But over time you pick up areas of expertise and you almost accidentally end up becoming the go-to person for certain types of problems on your team. For me, it was messaging. I became the authority on fighting spam and ensuring our customers’ messages were delivered.

It started out as a passing interest with some small responsibilities. I began to answer more and more delivery related questions in the support inbox and owning problems that customers had in that area, such as messages going to spam or messages not sending as expected.

This worked well in the short term, but after a serious deliverability incident, for which I led the post-mortem, it was clear that customer support was required on the product teams full-time. For the customer support and product relationship to be fully effective, I had to be involved in every meeting, every standup and every emergency.

Naturally, spending my days with an engineering team was a daunting prospect (talk about imposter syndrome ?) but it got easier over time. I still report to the customer support team – it’s important to keep your finger on the customer pulse – but I sit with, and attend all meetings of, the engineering team too.

The best of both worlds

Having a former support rep on the product team gives you a unique insight into both sides.

Championing the customer

Most teams should (hopefully) have some form of customer input into their roadmap, but having customer support in the room during product ideation is extremely powerful. You have direct access to the voice of the customer, so it’s impossible to ignore. There have been many projects that I have pushed onto our team roadmap by pleading the customer’s case in planning sessions.

For example, I’ve fought for many small improvements to our product, like allowing customers to filter their main user list for users with invalid email addresses.

We had a technical limitation which only allowed for tagging 10,000 users at one time from the message statistics page. This became especially limiting for large senders who could have bounced messages in the tens of thousands. ? Moving this to the main user list means large senders can manage their list hygiene more easily.

This is unglamorous work that would not have been prioritised without having someone championing the customer’s cause and explaining the direct customer impact of such a limitation. Had customer support not been in the room, these frustrations might well have gone unanswered.

Embedded support can filter customer requests like these and better advocate for impactful changes that are frustrating your customers. The feedback loop between customer support and our product and engineering teams is tighter than ever before!

Championing the product

If embedded support improves the product team, it also can help improve the support team too. Our ‎Product Support Engineers (that’s what we call ourselves ? ) triage and prioritise bug reports and act as a filter for the engineering team, closing issues resulting from customer confusion or lack of investigation. In this way, issue counts are lower and they get resolved faster. In the event of an outage, it’s bad for customer support to find out from customer feedback. With embedded support, we can tell customer support to brace for impact when we’re having operational difficulties.

I often have enough context and knowledge about our infrastructure and code to offer help to customer support when they need it, without them having to wait for a product engineer to be available.

Not content with just giving you my perspective, I asked Aidan Lynch, engineering manager for the team which builds our messenger, and Raph Estrada, a product engineer on Team Delivery, what they felt the benefits were:

• A customer champion in all meetings, bringing a customer’s perspective to all discussions.
• Maintenance of good “social capital” between customer support and product
• Better quality bug reports.
• Better product knowledge on the engineering team.
• Better engineering knowledge on the support team.
• Issues solved faster.
• More impactful work on the roadmap.
• More career progression options for your support team.

We’re still experimenting and developing this approach at Intercom, but so far we’re really happy with the results. In fact, not to toot my own horn, but one of our engineering managers was even heard asking for their own “Penny” on their team ?. If you’d consider implementing something like this for your own team or want to know more about how we did it, we’d love to hear from you.