How To Respong To A Customer That No Longer Needs Services

Do you lot find that you become many "bad" satisfaction tickets when customers are requesting product changes or new features?

Picture this scenario: A customer requests a feature. Support politely tells them that it can't exist done while even so providing top quality service. However, the satisfaction survey comes back as bad, with a annotate about the product, non the service.

Sound familiar?

Many of united states of america have experienced similar situations before. The "bad" satisfaction tickets might be considering nosotros're responding to feature requests in the wrong manner.

In some cases, nosotros might already exist building the characteristic. It might be easier to reply the client in this scenario, and let them know the feature is on its fashion.

However, in most cases we won't exist planning on building those features, or at to the lowest degree non whatsoever fourth dimension shortly. Replying to these requests are more tricky as we have to tell the client that they won't get what they want while trying not to disappoint them.

Regardless of the situation, how we communicate with customers who give feedback is very important.

Are you lot ready to deliver Friction-Free Customer Service? Capture your customer's entire journeying in a mode a support ticket or traditional help desk never could. Notice Kayako Single View

Why practise they give feedback?

Earlier we dive into how to communicate with these customers, permit's take a look at why they would spend their valuable time offer us their feedback.

According to a whitepaper by TFM&A Insights, nearly customers give feedback because they want to express their opinion (64%). More specifically, they do so to let companies know where they were doing poorly (57%) or well (49%).

company feedback graph

These customers feel that they are a function of the company and want to help it get meliorate and succeed. A research by InMoment'south market insights team found that when asked why they give feedback, four in five consumers stated that they enjoy offer feedback and making a difference.

How fabulous!

At that place are many benefits to listening to customers' feedback, specially gaining customer insight and learning how to improve your product. The feedback from our ain customer community forum has had a huge affect on how our product has adult. However, this has simply happened through responding, engaging and acting upon the great feedback we've received from our customers.

Importance of communicating with these customers

Past responding to customers' feedback and characteristic requests, we show that we are listening to them and that we value them every bit our customers. This helps strengthen customer loyalty.

Customers don't just want to be heard by companies. They want to know what difference they can make. The enquiry by InMoment found that consumers "desire brands to let them know how they programme to utilize their feedback, whether or non it was helpful, and what changes it inspired."

Customers expected companies to respond to them. And so how should we go most communicating with these customers?

Overarching principles for communicating with customers

First, let'southward look at some overarching principles for responding to feedback. In fact, these principles can exist applied to about all conversations with customers and not only with those who give feature requests.

ane. Be open up and honest

Before we decide how to respond, it's important that we have the right mindset. Instead of hiding the truth from your customers to wait good, customers volition appreciate transparency more.

ii. Exist grateful for their attempt

Regardless of the feedback, it makes sense to give thanks the client for the time they took to share their thoughts with you.

Co-ordinate to Dave Chapman of Buffer, "Our customer knows what will help them best, and a characteristic request helps u.s. stay in tune with what people want, demand and expect from Buffer." Hence, gratitude is the first thing they express when they receive feature requests.

iii. Be courteous, not scripted

The next principle is to pay attending to your tone and linguistic communication when replying to the customers. This matters a lot considering you don't want customers to feel like their suggestions have triggered an automated reply and that their suggestions will be going into the void.

Buffer uses a tone guide for communicating with their customers. MailChimp has a style guide for writing content such every bit their blog posts and knowledge base of operations articles:

mailchimp style guide

4. Don't make promises you can't keep

Interestingly, Automattic does not use a formal tone or fashion guide. Andrew Spittle of Automattic shared that instead of using a formal tone or style guide, they emphasize individual judgement and follow a few basic principles:

Promise updates, not timelines:

According to Andrew, "It's ameliorate to say that a characteristic is on the mode and that a customer should 'Stay tuned!' rather than say something with a date attached like, 'Nosotros program to launch this next month.'"

Stating a engagement creates an expectation and declining to see it might issue in disappointment or dissatisfaction.

Promise investigation, not fixes:

Andrew recommends maxim "Allow me check with the team and get dorsum to yous with more information." over "I've reported that bug to the team so nosotros can become information technology fixed upward."

Promising to fix a problems or implement what seems like a basic feature risks frustrating the customer. The "bug" may not be a bug. Or, the seemingly basic feature might turn out to exist not feasible to implement.

5. Testify understanding

In Back up Ops' podcast on Working with Characteristic Asking Emails, Jeff Vincent from Wistia mentioned that most importantly, customers want to exist heard. They desire us to understand what the problem is and why they are excited about this idea.

A contextualized reply shows that you have given a proper thought to the customer'southward feedback.

support ops email

The hypothetical email above, suggested by Chase Clemons from Support Ops, does this well. By explaining why he thinks the suggested feature would be useful for users, he is showing that he considered the suggestion from the customer's point-of-view.

At present, let'southward dive in deeper into the two main situations: feature requests that you are non working on and those that y'all have already planned to do.

In The Ultimate Guide to Communicating Product Feedback, we show you how to make a case for your customer'southward great feature requests. Download information technology now.

Feature requests that you lot are not working on

As much as nosotros honey our customers and their suggestions, we know that we do not accept the resource to work on all the requests. Even when we could, information technology might not be the wisest thing to practise.

"I know yous take a thousand ideas for all the absurd features iTunes *could* have. Then do we. But nosotros don't desire a thousand features. That would be ugly. Innovation is non about maxim yeah to everything. Information technology's virtually saying NO to all but the most crucial features. "

– Steve Jobs at a private presentation to contained record labels in 2003

Still, nobody likes to be told "No". Nobody likes to exist rejected. So how do we say "No" and without angering them?

6. Notice their real need

Before replying "No" immediately, pause for a moment and think from your customer'south perspective. Why do they want that characteristic?

Our co-founder Jamie wrote a great post about this where he explained how in the early years of Kayako nosotros struggled with high volumes of customer feature requests. In many cases, nosotros ended upward directly implementing what the customer asked for, only to realize it wasn't right for us, or even the customer!

In one instance, a substantial feature request was implemented only to turn out that the functionality the customer wanted could be accomplished by making a pocket-sized change to an existing feature in the platform.

So we started using the 5 Whys principle to dig deeper into customer feedback. The 5 Whys means that by request "why" v times, you're able to tease out the existent root cause of the problem and make the changes needed to resolve the underlying issue for good.

Soon, our team discovered that many feature requests were already in Kayako, just our customers just didn't know where to look; some characteristic requests were bugs or problems we could troubleshoot; and less than x% of feedback was really a valuable and viable feature request.

Hither'southward an instance of how we use the five Whys:

5 whys

Adii Pienaar, co-founder of WooThemes and now Receiptful, also wrote a great post on this topic. He suggested that startups should try and understand the terminate goal customers have when they request for a feature.

receiptful email

He said that this not only allows yous to learn from the customers just likewise engages the customers, lets them know that you are listening and communicates that you care about their wants and needs.

7. Offer workarounds

As we talked about in politely rejecting customer requests, there's some kind of "yes" most of the time.

Your customers may not know your product every bit well as you. And so they might not know the possible workarounds. When you lot sympathise the real demand that they have, yous volition be able to offering them alternative ways of using your product.

All the same, don't create imaginative workarounds only to win a customer.

8. Give an honest caption

Finally, if y'all really actually take to say "No", be transparent and provide an honest explanation for why you are non going to work on the feature. An honest explanation will help the customers understand your context and they might sympathize with your situation.

Andrew of Automattic agrees, "If information technology's non something we're working on nosotros tend to honestly thank the customer for the proposition and, when applicable, exist open about agreeing with them that it's an area we need to meliorate."

This might non be what the customer likes to hear, just putting in the try to requite a genuine explanation can help to build their trust in your company. It shows that you lot value them plenty to explain how you will human action on their feedback.

Feature requests that you have already planned for

What if yous are already working on the feature? Easy piece of work, correct? Tell them that the features are coming before long and they will exist satisfied! Loftier 5!

Non so fast!

Yes, they might be delighted that your team is already building the feature for them. Notwithstanding, they are however unable to use the feature now. The adjacent question volition popular upward in their caput – when tin I use the feature?

9. Communicate ETAs honestly

Like to dealing with feature requests that you lot are not working on, honesty is key.

At Buffer, they let customers know transparently where they are with the characteristic evolution – dreaming and discussing, customer research phase, edifice or testing. Through this, customers tin form a rough expectation.

At Kayako, we found that information technology is not piece of cake to communicate estimations for the date of completion of features and to manage customers' expectations for them. Giving exact dates of completion can exist an issue if we cannot deliver the characteristic on time. This can happen for a variety of reasons – a change in scope, focus or project timelines.

Nosotros taken this approach with our Product Feedback and Suggestions Forum: autonomously from a very small-scale amount of exceptions, nosotros practice not provide ETAs for features. Where possible, nosotros communicate the status of a particular characteristic proffer using tags.

We use Planned, Non Planned and Completed tags to provide an indication without being too precise. Suggestions that are untagged mean that we have not decided on a course of action, typically considering nosotros desire to hear feedback from other customers.

kayako tickets

We take also written cognition base articles to explain how the feedback system works and how nosotros handle feature requests. All these aid set appropriate expectations with our customers.

Certainly, this does not satisfy the expectations of all our customers who want more than information and more features. We are still figuring out ameliorate ways to do this.

Similarly, at Entrada Monitor, if the requested characteristic is certainly on the roadmap, they might be more forthcoming about the fact that information technology's coming in the future. Yet, they do not provide whatsoever sort of timeline as product development can be unpredictable.

If information technology'due south on the brink of being released, Davida from Campaign Monitor said that she might even say something along the lines of "You'll be happy to know that this characteristic will be in our next release, go on an heart on our blog for the announcement!"

Every bit we tin can come across, the mutual theme for communicating ETA seems to be similar what Andrew from Automattic said, "hope updates, non timelines". Product development tin be unpredictable so we would not desire to requite promises that we might not uphold.

ten. Provide updates on feature developments

When the characteristic is completed, it's squeamish to go back to these customers to allow them know that the feature they requested has been implemented. This makes sure they get a chance to use information technology.

For instance, Davida from Entrada Monitor said that if they add a feature that has been requested, they will become back to those customers even if it's years subsequently!

Fifty-fifty earlier that, perhaps you could get them to be beta users for the feature. At Buffer, if an unreleased characteristic is stable enough, the team would offer to enable it for the customer'due south account for them to check information technology out.

When a client requests the characteristic, the team tin reply, "Do you know what, we're working on that, fancy having a play? Nosotros'd dearest to know what y'all think!"

It's a two-way street

I like to think of this situation as a two-fashion street. When customers make the try to offer a characteristic request or suggestion, it is but right for us to reciprocate by taking the fourth dimension to understand their requests and respond to them honestly and politely.

By communicating with the appropriate mindset and language, nosotros can requite a response that the customers would, hopefully, exist satisfied with and prevent bad satisfaction survey. Happy customers and happy agents – a win-win situation for us!

There isn't a perfect way to reply to all feature requests as information technology depends a lot on the context. How do you normally handle feature requests and suggestions? We would love to hear nigh them! Share your expertise by leaving a comment below 🙂