While connecting the team to our customers has always been a priority for us at Buffer, how the team has connected with customers has changed quite a bit over the years.

When I first joined Buffer in 2015, the team would have a dedicated time when everyone would spend an hour answering customer support emails at our annual company retreat. During these sessions, our Customer Advocates would provide support for the entire Buffer team as they answered customer emails. It was an awesome bonding experience and a great way to bring everyone across the company–from the People Team, to Engineers, Designers, and Finance–closer to customers. Plus, with our fully-remote team having gathered in one location for the retreat, we weren’t able to provide our usual around-the-clock customer support, so having extra hands to reply to customers was a huge help!

After some reflection, it dawned on us that we shouldn’t limit full-team connection to annual company retreats! We thought through how it might look in a remote setting, and we came up with our first remote iteration in 2019: Advocacy Day.

Iteration #1: A full day for replying to customers

Our annual Advocacy Day was an entire day blocked out for the team to engage with our customers by replying to customer support emails. With our team being fully remote and spread across multiple time zones, we wanted to make sure a solid structure was in place to support all team members, especially those who were new or had never replied to a customer email before.

For the duration of Advocacy Day, our Customer Advocates were “on call” in Slack and on Zoom to support our Engineers, Product Managers, and other team members as they navigated conversations with our customers. We took shifts in an open Zoom call where anyone could pop in to ask questions, get support for tricky conversations, or just have company as they worked.

To support new team members during their first Advocacy Day, we also held celebrations in Slack when someone shipped their first reply to a customer and shared meaningful learnings and interactions throughout the day.

From the customer perspective, Advocacy Days also resulted in many quick wins. If an Engineer learned about a bug or a Designer learned of a small user experience issue from a customer conversation, they might jump right in to address the issue and follow up the same day with the customer to let them know it was resolved.

While there were many great benefits to connecting the entire team with our customers, there were some challenges and drawbacks. Some team members in roles further from the product experience found it challenging to troubleshoot an issue or know if certain behaviors were expected or were bugs.

We also received feedback that replying to customers was a bit intimidating for some team members, because they didn’t feel as though they were experts at our brand’s voice and tone. Adding to this challenge, some of our teammates speak English as a second language.

Taking all of this into account, we moved to a new model.

Iteration #2: Dedicated customer support sessions

In 2020, Customer Quality Time became our second iteration of remote, full-team customer support days.

Different from Advocacy Days, in this model, we removed the full-team aspect, and instead, we paired each non-support team member with a Customer Advocate buddy to work through a predetermined customer-facing topic or challenge. Each team member had at least one Customer Quality Time session scheduled during the year, but our Design, Engineering, and Product Teams had three to four.

Unlike previous iterations, Customer Quality Time did not require the non-Advocate team member to reply directly to customers. Instead, the pairs could read through customer conversations and feedback to understand how customers were using our products, note any challenges or UX confusion, and identify which jobs to be done are being noted by our customers. This removed the intimidation factor and allowed the team to focus on understanding the customer experience. Because our product-facing teams met more frequently with Advocates, they had the opportunity to enjoy a concierge service –courtesy of our Customer Advocates – each time they went to research a new part of the product.

While this chapter had its benefits, it also had its challenges. It was led primarily by the Advocacy Team and there were challenges with aligning schedules, especially around the Product team’s existing timelines and sprints, as well as ensuring enough coverage for our customers. We also were not tracking any learnings or outcomes from each Customer Quality Time, so it felt difficult to see the impact these days had for our customers or measure their success.

After taking a hiatus in 2021, we went back to the drawing board.

Iteration #3: Pairing Engineers with our customers

In 2022, we introduced Customer Engineering Days. Drawing on past feedback, we wanted to be especially intentional with how these days were designed. Instead of pairing Advocates with individuals across the entire team, we focused on pairings with Engineers, and we had the Engineers reach out to the Advocate they were paired with to schedule a date based on their team’s work schedule. This way, they could utilize their day to gather customer insights based on their current engineering work.

We’re a year and a half into Customer Engineering Days and have had phenomenal success so far. We’ve had 13 Customer Engineering Days so far across eight time zones with six more scheduled. Engineers have identified and fixed dozens of bugs, identified several UX improvements, and gained deeper understanding about how customers are using our products.

Pairs have also shared feedback along the way so we can continue to make adjustments to the Customer Engineering Days process. After each pair finishes their Customer Engineering Day, engineers also share learnings and insights with their teams to help inform the work that they do.

What’s up next?

So far, Customer Engineering Days have hit the mark, allowing Engineers to learn about areas of the product they want to dive deeper into, and allowing our Customer Advocates to understand more about which insights our engineers are most interested in.

We’re going to stick with this iteration for a bit, and we look forward to experiencing more Engineer <> Advocate connection, enjoying improvements to our product as a result!

We’d love to know what you think and if you’d adjust these at all. Let us know on Twitter or by joining the Buffer community.