Insightful Delight's founder listed in "50 Customer Service Experts You Should Be Following"

We are excited to share that Insightful Delight's founder, Heidi Craun, was listed in NiceReply's 50 Customer Service Experts You Should Be Following (even if you're not on Twitter). NiceReply's mission is to help companies provide outstanding customer service, and they do this by helping companies gather real-time customer insights about the quality of their experience.

To stay on top of customer experience trends, hop on Twitter and follow NiceReply (@nice_reply), Heidi (@HeidiCraun), and all of the other amazing folks on the list.

Onboarding a Community: A Support Driven Service Design Project

Shout out to the lighting design store near the office for hanging this awesome piece outside.

Shout out to the lighting design store near the office for hanging this awesome piece outside.

Note: This is cross-posted from a guest piece I wrote for the Support Driven blog. Support Driven exists to nurture and grow a community of professionals who work in and inspire customer-driven organizations.

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. This means that 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 up the customer 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. But without companies 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 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 Slack channels that a successful customer belongs to?
  • How do we want new customers to feel when they’re added to the Slack community?
  • 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 from 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's results worth the time that you invest in taking it.

Looking forward to learning together with you all,


Focus on Solving Support Problems, Not Tickets

NOTE: This is cross-posted from a blog I maintained while I was the VP of Customer Experience at a previous company.

In my conversations with support leaders over the years, I've often heard people ask each other questions like "How many tickets do you expect your team members to solve each day?" or "What are your employee ticket KPIs?"

And while I'm mentally responding with "We don't have ticket KPIs," that thought is shocked out of my system when I hear others reply with answers like "Between 80 and 100." I find this to be absolutely B-A-N-A-N-A-S. So in this blog post, I bring you my thoughts on why we should focus on solving support problems instead of on support tickets.

Reason 1: The goal in support should be to eliminate tickets, not find more tickets to solve

People do what you incentivize them to do. I'm still taken aback when I recall that while I was (briefly) at a company, the support managers would actually create more support tickets so that they could meet their daily ticket KPIs. Their support signatures said things like "1 problem = 1 ticket" and instructed customers to create individual tickets for each question or problem they had. Not only did this artificially inflate support volume; it put the burden on customers to ask for help multiple times when they reached out to the company that had, in some way, already failed them.

With the exception of when a customer emails just to tell you how badass you are (which does happen but isn't likely a large portion of any support team's ticket volume), every support ticket represents a company failure:

  • you didn't have a feature that the customer wanted
  • the customer didn't understand how to use the app
  • the customer encountered a bug
  • the customer didn't discover that it was already possible to do something

The customer had to take time out of their day to contact the company. Nearly everyone hates doing this. It is the worst. Products and services should just work. And when they don't, for the love of all things holy, don't make your customers list their concerns across multiple emails in a single sitting.

No one wins when there are a lot of support tickets: customers don't receive the experience that they want with a product or service, and the company doesn't earn loyal and successful customers. Our goal as support managers should be to eliminate support tickets, not make our team members wish the company failed the customer more just so they can meet their daily ticket KPIs.

Reason 2: If team members are solving 80-100 tickets in a normal work day, they're likely solving a lot of easily-answered questions

The only way a person can answer 80-100 tickets in a day is if those tickets are, by and large, easy to solve. I argue that if most of your tickets are easy to solve (i.e., they don't require expert troubleshooting), you're probably either not doing enough to help your customers help themselves or not doing enough to advocate for product changes–or, more likely, you could be better at both.

My team members don't even solve 50 tickets a day. That's because the bulk of the support requests that we receive require expert troubleshooting. Is this because we have incredibly tech savvy customers? Nope! We work with farmers who are more comfortable operating $300,000 tractors than they are a $300 smartphone.

Rather, it's because we make it really easy for customers to self service and get nearly-instant answers, if they want to, from our support site. Of course, we welcome them to contact us and will always dedicate time to them one-on-one if they prefer that. But the simple truth is that people don't want to wait for answers to questions that they shouldn't have had to ask in the first place.

In fact, the 2016 Consumer Experience Index Study showed that 71% of consumers prefer to self service and value a brand more when they're able to do so.

The bulk of the messages that make it to your support team should be the kinds of messages that require expert intervention: unusual bugs that strike in rare circumstances that your team didn't foresee, major issues with billing, feature requests that go beyond what most customers have considered, etc. The more that your support team is focused on solving the root of support problems, the more that your team will:

  • eliminate tickets
  • work on really interesting stuff
  • collaborate with engineering and product management
  • add long-term value to the company

Essentially, the more that you try to eliminate support tickets, the more valuable your team becomes. This means that you shouldn't have to worry about job security. The truth of the matter is that the company will likely be more interested in investing in your team. And if it isn't, it might just be time to get the hell outta there, because investing in a value-adding support team is a customer investment that gives high returns.

Reason 3: Focusing on quantity compromises quality

This one is pretty simple, folks: if you measure your team members' success by the number of support tickets they solve each day, then you incentivize them to solve tickets quickly and at the expense of thoughtfulness, thoroughness, and care. Granted, part of what makes up good service is fast responses to customer concerns. However, fast answers that aren't the correct answer, don't illustrate that you heard the customer, or don't foster a healthy relationship by showing that you're willing to invest time and care in serving the customer will all backfire on building customer loyalty and satisfaction.

Recently on my team, two Customer Advocates and a customer exchanged seven carefully-crafted emails that involved methodical troubleshooting and friendly language to reach a resolution for the customer's issue. In the end, the customer wasn't at all upset that it took just over a day to fully resolve his concern. In fact, when evaluating his support, he said, "It was awesome. I felt like your only customer. Very attentive." Of course, he wasn't our only customer; rather, we simply took the time to actually help him, asked him the right questions at the right times, didn't ask him to repeat things that he already told us, and showed him that it's important to us that he have long-term success with our product.

We take this approach with all of our support tickets. Although we don't always nail it, we try our best to ensure that we have time to give our customers a high-quality experience with our support. After all, it's one of the personal experiences they have with our company. The result? Year over year, the result is 97% satisfaction with our support, as evaluated by more than 39% of the customers who requested support. Not too shabby. It's also worth noting that our resolution times are quite fast, although they're not always single-touch.

In fact, although we measure ticket resolution times and analyze efficiency in our emails, we don't measure ticket touches. After all, that would incentivize us to not reply to customer emails, which would also just be B-A-N-A-N-A-S.