When Scott started the Support Driven Slack community in 2014, it was a handful of passionate support pros he had interviewed on his podcast. The community served as an active place for us to have support conversations, learn from each other, and grow our expertise. Community members generally already knew each other or, at least, knew of each other. We knew what to expect by joining the SD community, and keeping up with conversations was easy.
A few years and 2000+ members later, connecting within the community isn’t quite as easy or as simple as it used to be. For example, if you joined the community back in 2014, you might not know that channels about knitting, diversity & inclusion, beer, and eCommerce exist now. If you joined recently, you might have felt overwhelmed by the number of channels and people—not knowing where to go to start (1) building relationships or (2) getting value out of the community in the same seamless, low-effort way that early members did.
The ways in which the SD community experience has changed as it’s grown in volume and complexity are not unlike the changes our customers experience when our products and services grow. When customers encounter this friction with our products/services and must contact support, their purchase becomes more costly to them than it was before, and the return they get from their investment with us starts to diminish. If we don’t take the time to understand why customers encounter these issues and try to design the customer experience to prevent them, support simply serves as a band-aid for the product/service and, oftentimes, customers churn. This is when support is a cost center: when it’s not adding value to the company by truly supporting customers and helping to design an experience that sets them up for ongoing success.
What if we approached this SD Slack community problem using the same approach we could take for a product/service that we support? After all, SD is a business, the community is one of its products, and we members are that product’s customers. To help illustrate this idea, from now on in this post, I’ll refer to the SD community as “the product” and SD members as its “customers.” When we customers get value out of the product, we learn and share, we network with other customers, we become better at our jobs, we adopt more SD products (e.g., SupConf, SDX, the newsletter), we refer other customers to the product, those customers contribute to the product, we find our next jobs, the product delivers more value to us, etc. In other words, when a customer experience is designed to meet customer needs, the customer and product have a mutually-beneficial relationship in which everyone gets value. This is the goal of service design: to thoughtfully design systems that set the customer up for positive end-to-end experiences.
In my opinion, there’s no better team to help inform and design the customer experience than the humans who sit on the front lines, listening to the reasons why customers need help with the product/service that failed them. Customer experience teams house a treasure trove of customer information, and far too many companies fail customers and leave money on the table by:
- viewing support as a cost center
- not empowering CX teams to surface and share actionable data that could help customers get more value out of the company’s products/services
Not a lot of companies consider this, though, and it’s on CX teams to find ways to prove their value in service design. Unfortunately, without a company empowering CX teams to live beyond the ticket queue, how can CX teams learn how to contribute in this way? Enter the SD community service design project!
In the coming weeks, a group of us (including you, if you want!) will communicate with our SD customers, both new and “seasoned,” to explore ways to set you up for even more rewarding, valuable experiences with the community product. We’ll send everyone a survey to get your insights, and we’ll blog what we learn every step of the way. By taking this approach, we can research what customer success with the product looks like. For example, are successful customers simply “active” users by Slack’s definition? Do successful customers also attend SUPCONF/SDX events?
After we define what success with our product looks like, we can dig deeper and explore how to design our customer experience to ensure that customers are set up for success and continue to get value out of it. This might involve asking questions like the following:
- What’s the average number of channels that a successful customer belongs to?
- How do we want new customers to feel when they’re added to Slack?
- How do we set new customers’ expectations of what they will (and won’t!) get out of using the product?
- How do we equip new customers with the information they need to be successful with the product?
- How do we ensure that customers continue to get value out of the product over time?
If you’re interested in learning more about user research, service design, customer experience, or onboarding in general, we’d love to involve you with the project! Project participants will have opportunities to do the following:
- conduct user research in accordance with best practices
- be interviewed for more focused, in-depth research needs
- analyze customer experiences
- make service design recommendations to share with other teams for execution
If one or more of these opportunities sounds exciting to you, please fill out this form and let us know how you want to get involved. If you can’t or don’t want to participate in the execution of the project, please look for the research survey in future newsletters and blog posts; we’d still REALLY love your insights to help guide us in our next step toward making the SD community more valuable. And in the interest of mutually-beneficial customer experiences, we promise to do our best to be conscientious of your time and make the survey results worth the time that you invest in it ;)
Looking forward to learning together with you all,