How the CX Community Helped Me Through Some Dark Days

Disclaimer, friends: This post involves a lot of RealTalk™. Some of you already know me as a chronic RealTalker, one who struggles with extreme transparency and to not drop F bombs during presentations. (For the record, my creative writing professors are the ones who taught me to embrace that sometimes "fuck" is the most descriptive word for a situation.) That said, this post is personal. But I think it's relevant, and I think we'll get through it.

Today is the third anniversary of the day I didn't get married. It's also the 32nd anniversary of a day when I didn't get married, which is everyday until I turn 33, after which everyday will be the 33rd anniversary of another day when I didn't get married, and so on. No big deal, right? It literally happens everyday. But today—May 25th—is the third anniversary of a day when I was supposed to get married. There was a wedding planned for that day, and two weeks prior, it was canceled. As you might imagine, it was a pretty rotten and tumultuous time. But what you might not imagine, CX community, is that you helped me navigate my way through it.

On May 2nd, 2013, my User Happiness team and I had plans to fly to New York for our first UserConf (which is now known as Elevate Summit). Up until this point, I had no connections whatsoever to the broader Customer Experience (CX) / Customer Support (CS) community. My team and I had been trying to no avail to find "our people" for a couple of years. So we were delighted to discover that this conference existed; it seemed like a diamond in the rough.

I remember telling my fiancé about our discovery, and he was excited about it, too. He sent his startup's new CS team to the conference as well. We were all super eager to hear what other folks had to say about these best-in-class customer experiences that we were building in our respective companies.

But the night before I was supposed to leave for UserConf, my fiancé and I sat in the living room of our beautiful forever home that we'd just built and moved into, and we had a brutal conversation about the fact that maybe we shouldn't get married. It was heart-wrenching and ugly, triggering yelling, crying, vomiting. I left the house that night (as I'm ashamed to say I often did) and drove around, looking for somewhere, something to give me an answer, peace, relief, anything.

But it wasn't going to come, and I knew that there was probably no turning back from this verbal declaration of what I'd known for a long time and what my fiancé later said he hadn't allowed himself to acknowledge. The situation was dire, and we decided that a couple days away from each other might be healthy and help us to clear our thoughts. So after a sleepless night and with an enormous secret within me, I boarded an NYC-bound plane the next day, immediately ordered a cocktail, and hoped that this UserConf thing was worth being away from my support system.

The next morning, I sat in the Scholastic Theater with so many empathic, driven, and wildly-smart CX people. Folks were using phrases like "Turn your haters into brand evangelists"—articulating the same philosophies that my team and I had employed in our support for years. It resonated and felt so familiar. After years of searching, it was like a breath of fresh air to find that there was indeed a home for people like me, people who are passionate about building companies on a foundation of mutually-beneficial relationships with customers.

The CX fire within me grew that day, and I discovered positive feelings: of community, of validation, of inspiration. I couldn't wait for the next conference; I told my boss about it, and he encouraged me to speak at a future one. I established new professional goals. A whole new world full of opportunity to learn and share opened up in front of me. I had something to appreciate and be optimistic about, despite the fact that my personal life was a raging dumpster fire. (Side note: If you're interested in a funny podcast about dating, you should check out my friend Andrew's podcast, Dumpster Fire.)

      The User Happiness team at UserConf 2013

    The User Happiness team at UserConf 2013

I returned home from the conference, and within a week, it was determined that our impending marriage was a no-go. And with less than two weeks' notice, we sent heavy-hearted messages to our friends, families, and colleagues all over the country, telling them that we were "postponing" our wedding and would reimburse their travel expenses. Neither of us could find the courage to admit total defeat yet, although I think we both knew deep down that our wedding was being canceled. Our relationship was being canceled. Our new home in which we'd toiled over every tiny detail was going to have to be sold.

Everything was falling apart. To two high-achieving perfectionists, this felt like failure—very humiliating and very public failure. Our loved ones, who were supposed to celebrate us in just a matter of days, were now wrapped up in our mess. We had unintentionally situated them smack dab in the middle of our pain.

But I had an escape. I had something positive to cling to in knowing about this CX community. It was something that I was proud to deeply identify with, a part of me that wasn't being lost and that was in no way tarnished by my personal drama. I say I knew "about" the community, because I didn't really know anyone in it yet. In fact, I don't think I talked to anyone while I was at UserConf that year; I was in another world—one in which I hadn't really slept for days and couldn't keep food down.

But it didn't matter that we weren't friends (yet). I didn't need your friendship; I simply needed you to exist and be passionate about CX.

I had lots of friends, amazing coworkers, and more family than you can possibly imagine (seriously, I have 6 families). And as much as I love them and am still so grateful for all of their support, I sometimes found myself needing to get away. They were always incredibly well-intentioned but would sometimes say things like "I'm so mad! Why aren't you upset?!" and, my favorite, "You know...you should grieve."

As someone who's lost several loved ones unexpectedly, if there's anything I'm well-versed at, it's grieving. I didn't need to be told this. I didn't need people to be mad on my behalf, especially given the fact that I wasn't mad. I didn't need people to solve this problem for me.

To be clear, I'm not saying that I didn't need loved ones; I absolutely, 100% did. I needed them there as I moved out of the house and into a corporate apartment and, in the process of doing so, had to separate our cats from each other.

I needed them to take me on their vacation and then act like nothing was happening when I sobbed uncontrollably at the resort pool, because songs as romantic as "Thrift Shop" were playing and made me sad. I needed loved ones to give me a reason to get out of bed everyday and eat anything other than chips and queso, the only food that sounded even remotely appetizing for at least a month (#yolo?).

But I also needed a place where I could go and just be, where I felt like a part of the tribe without having the tribe all up in my business. I needed a community where no one was worried about or feeling sorry for me, where I didn't feel embarrassed by how much I'd inconvenienced people. I needed something beyond my immediate world, a horizon to aim for.

And aim for it, I did. I've spent the time since then trying to immerse myself in this community and what it represents. I read your blog posts, Skype with you, chat with you in various Slack groups. You've connected me to your coworkers when I've had questions about how to continually be better and do better. And because of how valuable the greater community has been to me, I along with a few others started an Ann Arbor CX meetup, so that we can reinforce and foster this community locally. And out of that meetup, a group of us started a conference that will take place later this summer for people who live and thrive at the intersection of technology and creativity. (And some of you will be there!)

Friends, so many amazing things have happened as I look over the last three years. I can't help but be overwhelmed by gratitude for you all and for the community that we've built from our various corners of the world. I've heard people describe the beauty of it with comments like "It's where I found my new job!" and "It's where I met my girlfriend!" Ladies and gentlemen, this community is where I found myself. Even in the solitude of it, I found a place in which I could just be.

Like the Anonymous Lemur creepin' on your Google Doc, you trusted that I had business being here and demanded nothing more of me. You let me learn from and grow with you without explanation or expectation. And when I was ready, you let me share with you what I was learning, too. You helped me to more fully nurture and celebrate this professional identity that I'd been forming. And I continually see you doing the same in those around us. In the short time that I've been in this community, I've watched it explode. It's amazing what finding one's tribe can do.

So, friends, this is my very longwinded way of saying thank you. Thank you for existing. Thank you for being so passionate about what you do. Thank you for being so good at what you do. Thank you for striving to continually learn and grow and be a community of better human beings who are doing things that matter—even if that's just by brightening your customer's day with a kitten GIF. Thank you for creating a gravitational force that folks like me can't help but want to be a part of. And, dare I say it, thank you for giving me a seat at your table.

Focus on Solving Support Problems Instead of Tickets

In my conversations with support managers 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 often shocked out of my system when I hear others reply with statements like "Between 80 and 100." I find this to be absolutely B-A-N-A-N-A-S. So in this long-overdue blog update, 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 am 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 also 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, or the customer didn't discover that it was already possible to do something. The customer had to take time out of his or her 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 God's sake, don't make your customers list out 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 were failing the customer more just so they can meet their daily ticket goals.

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 be answering 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 in 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 help 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.

The bulk of the messages that make it to your support team should be the kinds of messages that require expert intervention, like weird 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; and most importantly, 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. Obviously, 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 customer 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? In 2015, 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.

What the Duck?!

If you have spent time with me in a professional capacity, have seen or heard a talk of mine, or follow me on Twitter, you might have noticed that ducks are kind of my schtick. Yep, I'm a "grown" (almost 5 feet tall) woman who keeps a children's bath toy sitting on her desk. I also give rubber ducks as gifts and recently ordered a giant rubber duck vinyl "mural" for my team's office wall. It seems ridiculous, I know, but hear me out, peeps.

A few years ago, I was just a year or so into my experience managing a customer support team. It was a lonely world of trying to figure out what it means to provide concierge-quality customer service for, and in, mobile apps. No one else was really doing this, let alone doing it well. Or if they were, they weren't vocal about it. Moreover, customer support tools weren't yet optimized for mobile experiences. For me, it was a time of creativity and observing; I looked for people who provided amazing customer service and tried to find ways to transfer and mold their best practices to our small, mobile app world.

As someone who had spent the previous several years as a technical writer, I opted to draw on that experience and determine what I could leverage from my fellow user assistance professionals. So, I took my teammate, Kristina, with me to attend the WritersUA conference. The conference that year was held at the Peabody hotel in Memphis. I had never stayed at a Peabody hotel before, so Kristina and I were delighted to discover that the hotel is known for the ducks who reside and perform there. Every morning, the ducks come down the elevator from their luxurious home on the hotel rooftop, perform a march along a red carpet, and then play in the lobby fountain all day. In the evening, they perform a march again and then ride the elevator up to their rooftop suite to retire for the night.

After a long second day at the conference, Kristina and I snuck out a bit early to go see the ducks march the red carpet. We stood by the fountain, waiting for the march to start, discussing the fact that we didn't quite "fit in" with the other conference attendees and that it required a lot of energy to "translate" the conference talks' content into ideas that we could use in our roles on a mobile app support team. As we discussed this and whether attending the conference was useful at all for us, we watched the ducks swimming laps around their fountain. We noticed how regal and graceful they looked, like quickly gliding around on top of the water was nearly effortless for them. Upon closer inspection, though, we noticed their feet paddling rapidly in the water; it turned out that this beautiful, poised behavior was actually quite intense, fierce, and nearly messy. It was in this moment that we discovered solidarity at the conference—with the ducks. We realized that supporting users is often like being a duck: We try to display a calm confidence as we troubleshoot, despite the fact that, beneath the surface, we often feel like we're scrambling.

After nearly a year of trying to figure out where my team fit in the tech, user assistance, and customer support worlds, this analogy was surprisingly comforting. So while the ducks walked their red carpet back to the elevator, Kristina and I walked to the hotel gift shop, bought ourselves some Peabody-branded rubber ducks, and went home with a team mascot. Fast forward a few years, the ducks have become a symbol of customer care and solidarity. New teammates start their tenure with a rubber duck on their desks. We refer to each other as ducks and say things like, "It'll be okay, ducky." We even created a company-wide award that we give to those outside of our team who go above and beyond for customers.

The duck award has become a successful program that we use to recognize our coworkers and show everyone the value and reward that come from helping customers to succeed with our products. Other companies have followed suit by creating their own version of this award, and Scott Tran from SupportDriven created a graphic about the duck award that might just be cooler than the duck award itself.

So now, I ask you this: What about you? How do you unite your team? Do you have a team mascot; if so, what is it and why? How have you gotten through trying times with your team? How do you embrace the chaos that can be customer support? Do you have ideas about how we can encourage others to invest in customer care? If so, please comment and share the love!

It's Not What You Say; It's How You Say It

The other day, I was catching up at Panera with one of my dearest friends, Shannon. We met in graduate school, where we spent many hours together taking classes, teaching classes, tutoring in the Writing Center, studying, and meeting with students in a shared office that was adorned with self-made construction paper awards and a bobble-head Jesus whose head only bobbled "no." It was an intense, vibrant, and fun environment, the perfect circumstances under which to make a lifelong friend.

Shannon is brilliant. She epitomizes my favorite kind of person to be around: someone who challenges and inspires me. After we completed our Master's degrees, she went on to earn her PhD (and several awards and recognitions to boot) at Michigan State University. She's hella amazing, and I want to be like her when I grow up.

Shannon and I have many things in common that have nurtured our friendship over the years, and one of our latest is homeownership. She and her husband closed on their new home on the same day that I closed on mine. As such, we have enjoyed sharing stories about the adventures that we're encountering as new homeowners. Shannon's husband is a very talented carpenter, and they've beautifully renovated their house. As part of their renovation, they installed a new gas stove (hubba hubba). As Shannon began baking in her new oven, however, she noticed that the thermometer inside of it didn't maintain the temperature that she set the oven to. Given that they just bought this oven and it's still under warranty, she called the store to have the oven serviced.

Before long, the oven repair person paid Shannon a visit. As she tells it, the visit did not go very well. He didn't listen to her concerns. Instead, he talked over her and condescended to her his mansplanation of "how stoves work." She, of course, is a highly intelligent and educated person with a general understanding of how stoves work. He told her that stoves don't maintain a constant temperature and there was nothing wrong with her stove. After he left, unsurprisingly, she was not satisfied. Her oven thermometer fluctuated greatly when she used it. She felt that, because he hadn't listened to her, there was no basis of understanding from which he could begin to solve the problem, let alone solve it satisfactorily. So, not interested in running the risk of having a broken stove, Shannon called the store again and, this time, asked for a different repair person. The store obliged and sent a different employee.

This appointment, Shannon says, went much better. This repair person was understanding. He listened to her and examined her stove. He then also explained to Shannon the inner-workings of the stove but in a way that was instructional and constructive rather than demeaning. More importantly, he explained that no gas oven maintains a consistent temperature at all times, because the flame increases and decreases, similar to a furnace kicking on and off according to its thermostat setting. However, he also recognized that she was seeing such intensely-changing readings on her oven thermometer due to its close proximity to the flame, which wasn't clearly visible. As a solution, he suggested that she move the thermometer to the center of the oven for more accurate readings of the oven's overall temperature. Additionally, he explained that fluctuations in temperature are very normal for gas ovens and, therefore, any recipes she might use were all written with the understanding that this is how gas ovens work in the U.S. He assuaged her concerns, taught her something new, and gave her a solution to improve her daily experience with the oven.

Although this conversation came about as Shannon and I were catching up on adulthood, homeownership, and the unexpected repairs that we've encountered, her experience resonated with me from a customer care perspective. We say and hear this all the time: Customers just want to feel heard. But what really stood out to me in this situation was that it was the way in which the first repair person spoke to Shannon that made her feel unheard. It wasn't that he didn't listen to her problem, because in essence, the end result was very similar to what the second person did. However, listening to her was not the same as hearing her, and perhaps most notably, telling her was not the same as teaching her. As the old adage goes, it's not what the second repair person said; it's how he said it that made her feel heard and assured. Teaching is a participatory experience, and if anyone knows that, it's Shannon, who is a phenomenal teacher. Because the first repair person didn't engage her in the teaching process, she didn't learn what she needed to learn from him.

"It was the way in which the first repair person spoke to Shannon that made her feel unheard."

I've been pondering Shannon's experience for a bit. What can we, as customer experience professionals, do to engage our customers as we teach them—particularly when the media that we use to communicate often limit our ability to have natural conversation? How do we make it clear that we heard our customers when we reply to them with information about our products?

One of the ways I try to do this is to ensure that, as I give users instructions about how to do something, I make those instructions specific to their personal circumstances. For example, if a user told me that she needed to track her son's flight in the flight-tracking app that I supported, I would tailor my "how to track a flight" instructions to reference her son's flight specifically. I would also tell her that I know how important it is to know the status of our loved ones' travels and whether they've landed safely at their destinations. This is, of course, empathy, but it also shows that I heard her—not only the fact that she didn't understand how to add a flight in our app but that being able to track her son's travel is hugely important to her sense of security. That's ultimately the problem that I have to solve in this situation: How do I help my customer rest assured, knowing her son's whereabouts as he soars through the sky at 32,000 feet? How do I communicate with her in a way that shows that I know our conversation is about much more than a four-step procedure on how to add a flight to a flight-tracking app? 

So now I look to you for your expertise. What have you learned in your customer care experiences? What other methods should we be employing? How else can we, in (sometimes asynchronous) communication with our customers, engage them in the teaching process (rather than just talk at them) and ensure that they feel heard? How do we say the things that our customers need to hear in order for them to feel heard?