For most people, there’s the job you’re hired for, and then there’s the messy reality. Customer experience (CX) people know this all too well—they’re always going beyond their job title to help the customer, and their best tool is data, says Craig Stoss, Director of CX Transformation at PartnerHero.

Craig has been supporting customers for more than two decades, and during that time, has mastered using Zendesk to solve CX issues. I asked if he’d share one specific story about a time he veered outside his job description to do this—ideally, something counterintuitive.

Today, he shares how he encountered an unfixable user experience issue—something that led hundreds of customers to a dead end—and how he reduced that error by 98% with no help from the then-swamped product team. 

I’ve edited this interview for brevity, but only lightly.

Yoni Argaman: What’s a time you went outside the bounds of your role to help the customer?

Craig Stoss: At a previous company, there was this gap—a known product configuration where if you set up a certain widget in our software, you couldn’t then turn it off later. You were stuck with it. And if you then tried to use that widget in production in a certain way, you’d reach an unavoidable error. There was usually a long lag between when people would activate the widget and when they’d experience the issue, so they had no way of knowing what caused it.

I know it sounds wild, but there was actually a valid reason for this widget to exist, and for customers to not be able to disable it. A certain cohort of customers needed it. Thus, the product team didn’t want to change it. But it meant some customers would do all the work to set up their account, get stuck, and call support. They’d ask, “How can we change this?” and we’d have to reply, “Unfortunately you can’t. You have to start over.”

Obviously, this was a bad experience. 

‍

How did you and the team find out about it?

The issue bubbled up because it was showing up in a report I’d run on our top 10 issue categories. It was high on the list. So the first question I asked was, is this flow actually valid? Should the people arriving here be here at all? For some, the answer was yes. But I also knew from calls that just as many people were clicking this button without knowing why. And we said, “Okay, we need to figure out how to tell them.”

‍

But you couldn't change the product? 

Exactly. We couldn’t change the software. We sold to many verticals and some needed the widget to function like it did. And because there were valid reasons to use it, the product team didn’t want to add warning labels and accidentally discourage those people. 

In a perfect world, it would have been a product change. But the CX team and I said, “Okay, if we’re going to be proactive, how do we find out who’s using it and let them know the implications?” 

‍

So what did you do?

I worked with a technical person on my team and a DevOps person to design and build a tiny script mechanism for us. All it would do was run a query every night at midnight to find anyone who had enabled the widget based on the data in our database. The mechanism would then automatically generate a Zendesk ticket and tag it as one of these issues. Using the API, it’d then email the user and say, “Hey we recognize you created this configuration today. Here’s a link to the widget, and here’s why we’re emailing you. If this is what you expected, ignore this email. If it’s not, here are the implications of what you’ve done and an article with more detail. If you have questions, just reply.”

This served two purposes: 1) The user could help themselves at their convenience and resolve the issue if they understood our documentation and 2) If they needed help, they could reply. Because we had all the details in Zendesk, our team could have a high-context conversation immediately without all the triage, which massively reduced the handling time.

Within one quarter, we reduced that problem by 98%. It basically no longer existed. That one little mechanism was powerful. If you think about the time it saved our support time, and how much it reduced customer frustration, that’s a meaningful amount of dollars. 

That’s pretty impressive. What do you take away from that? 

That you can repeat this experiment anywhere. Imagine doing that for your top 20 issues. I ask that of my teams now, and you see lights going off in people’s heads. It’s so simple. You can start it as a grassroots project without asking for budget, permission, etc. If it works, you now have validation to get executive buy-in on building something real. It’s really as simple as doing three things: 

1. Look for issues in data you wouldn’t normally review.

Do you have a tool like Gong that aggregates and labels the contents of your calls? A tool that can track user paths in a product like Pendo? I think data is massively underused in customer success and support. If you’re in software, where data collection is inherent to the business model, there’s so much opportunity. Pull a report of your top 10 issues or most frequently voiced complaints or combine data from multiple tools to extract trends and patterns that can change the way you provide support.

2. Ask, “What can we do to address those using Zendesk and its integrated apps?”

Starting with those problems is really important. If you start with the technology—say an AI chatbot—you’ll be forever chasing an application for solutions. Whereas if you start with the problem, then consider tools, and ask how you can fix it as cheaply as possible, you’re halfway to having an impact.

3. Once you can show that it’s having an impact, seek buy-in to build a real fix.

If you have data that shows how your grassroots fix improved the customer experience, you’re speaking your executives’ language.

‍

Final thoughts? 

There’s no science to this. Get creative. Think from the customer’s perspective, and go look at new sources of data.