Features, Bugs, Insights and the Art of Solving Customer Problems

It’s been 10 years since I wrote an article on this blog about the importance of never saying “No” to customers. I also shared about how the company I worked for at the time went even further and banned the word “unfortunately” from our ticketing system. Company leadership felt like there was almost always an opportunity to solve a problem for a customer and it just required the right amount of creativity.

As I continue to mull over this idea, or perhaps the fantasy of never saying no to a customer, I’ll openly admit that I don’t think preventing contact center agents from saying particular words or phrases stops them from telling a customer we can’t do something for them. Ask your agents how they say no to customers and you’re bound to get an entire thesaurus worth of options. 

Here’s the thing about contact center agents and the word “No”

I firmly believe that contact center agents don’t actually like to tell customers they can’t do something. Think about it. Customer service professionals are hired and wired to find solutions for customers. Furthermore, who wants to be put into a position where they have to disappoint a customer? It’s not until they are slowly beaten down by product limitations, silly policies, and unapproachable leaders that they resort to the dreaded “no.” 

Take for example my recent trip to the bank. They have this machine where we can insert our coins and turn them into cash. I had this one silver dollar that the machine kept returning when on the final attempt, the machine kept the dollar seemingly without compensating us. I went to the teller to report this and he was prepared to credit us a dollar before his supervisor reminded him that the machine was managed by a third party. There was nothing that could be done. I watched that teller die inside just a bit in that moment. 

This is why it’s so important to work tirelessly to find ways to say yes to customers. Some solutions may require more creativity than others but oftentimes there’s an option out there.

Let’s talk about software limitations

I work at a software company where customers contact us every day asking for our software to do things it cannot immediately do. As much as I’d love to wave my hand to implement new features on the spot, it’s not always possible. In a world of infinite possibilities, we have a finite amount of time and resources. We have to be smart about what gets implemented next and resist the urge to sound the alarm any time a customer makes a request.

As I think about things our software can’t do and the quest to find solutions for customers, there are a few categories where it’s particularly valuable to understand our limitations. By knowing how often these requests arise, we can improve our product, service and training to be able to say “Yes” to more customers in the future. The three types of requests are as follows: 

• Bugs – When our product isn’t doing what it was designed to do.

• Feature Requests – When customers want our product to do something it wasn’t designed to do.
• Upsell/Cross-sell opportunities – When the product the customer is currently using doesn’t do what the customer wants but another product in our line does.

Note that all of these items require significant brand and product knowledge for contact center agents to understand what can and can’t be done.

Who cares about these limitations?

One of the most interesting things about issues that fit into these buckets is that there are various groups within our organization that want to know when they occur and how often. In fact, they crave this knowledge and the contact center is critical to identifying and sharing it with them. Let’s look at who tends to care about each issue type.

• Engineers and programmers care about bugs – Our engineering team works hard to make their code as bug-free as possible. Taking great pride in their work, they are likely to address these as quickly as possible to minimize the impact on customers. We also work to prevent bugs by involving key stakeholders like the customer support team in the testing process. I’ve come to realize that in a complex set of code, bugs are inevitable — but they can also be incredibly aggravating to customers and those supporting them so we must work together to squash them quickly.

• Product managers care about feature requests – Product managers deeply care about the possible features to add to our existing line of products. There are a number of factors they look at when reviewing requests like the overall practicality of the request, the frequency of the request, the revenue-generating potential, the size of the customer(s) making the request, and possible companies we’re losing business to because they already offer this feature. Rather than dropping everything because a big customer asks us to or because our competition just added a feature, we seek to create our product roadmap by weighing a variety of factors.
• Marketing cares about upselling and cross-selling – Marketing wants to know if their efforts to promote new products and services are successfully generating leads and the frequency at which those leads are turning into sales. For example, we had a product that we were upselling often and we significantly improved our conversion rate when the marketing team reduced the price a bit.

This is by no means a comprehensive list but it does represent the folks at our company that we’re most likely to communicate certain insights and issues to.

How we gather and communicate insights to these groups

Now that we know who in our organizations wants these insights, I’ll share just a bit about our process for gathering, reviewing and sharing them.

• Assign a tag to each issue – In our ticketing system we can add tags to tickets. I’m not sure if it’s an infinite amount of tags but it’s a lot. For the sake of this article, our tags include names like featurerequest, bug, and then unique tag names for the various products in our line that we upsell. It’s easy to tag, especially when it’s tied to an applicable macro for the situation. Macros are like canned responses but allow you to automate many more actions than just the response.

• Review the tags on a regular basis – If you’re going to have a system of tagging, you had better circle back and review those tickets and macros make it easy to find them. I aim to review the feature request tickets at least once a month to understand what customers are asking for. We have a massive spreadsheet with every customer feature request — some are one-offs while others are consistent requests that we work to prioritize.

• Handle each issue with the appropriate level of urgency – Our contact center agents are trained to prioritize the critical issues right there in the moment. For example, bugs that affect multiple customers are escalated to our engineering team immediately. Feature requests, especially if a customer says “It would sure be nice if you could…” can be tagged and left for someone to review at a later date. But in the event that the customer says something along the lines of “Add this feature or I’m going elsewhere,” we might evaluate the opportunity sooner — especially for a big customer.

• Share the insights – At some point, other groups in the organization need to know about these issues and requests. While bugs get reported fairly quickly, insights from upselling efforts, marketing campaigns and feature requests can be communicated through a variety of ways including meetings with various groups and leaders or quick emails or Slack messages. This shows our company that the contact center is paying attention to insights that are important to them.

Final considerations

With some issues, you’ll inevitably have to kick the can down the road until the opportunity is right. And let’s face it — certain customer requests will likely never come to fruition at our company. In these cases, make it OK and encourage your contact center agents to browse the internet and find solutions offered by other companies that can solve the customer’s issue. I know it feels a little weird to send customers elsewhere, but I’ve seen this sort of goodwill work in our favor more times than I can count.

Finally, I guess you should know that I absolutely hate burning bridges. I hate it in my personal life and I hate it with customers. If there’s a solution out there, whether now or in the future and whether with our company or another let’s aim to find it. Customers will love you for it — and by identifying key insights and sharing them beyond the walls of our contact centers, we’ll be able to provide more and better solutions in the future.

This article was created as part of the Vistio Knowledge Collective.