You can't refuse: what to do with customer requests

Customers call support and ask to add one more button or additional field. Does this situation sound familiar? You can respond to your customers' requests in different ways. For example, they answer "we will consider your request" and forget about it. This is fine, you do not have to implement any fantasies of customers. But there is another approach, which will help you make your service even more attractive for clients. The main thing is to set up the right way to work with such wishes. We tell you how it works for us

Entenda o que o cliente realmente precisa

If the support operator at the start doesn't understand what problem the client wants to solve, he can immediately promise to fulfill his desire, but this will never happen. As a result, the problem is not solved; the client is dissatisfied and shares his resentment in social networks. And then, in the course of the investigation, it turns out that the client's problem could have been solved with the help of tools that are already available.

For example, we had a case where a client called and asked to make him another API method. They asked us to load the times of ticket creation and modification into our system. We did not have such a function, so we created the request, discussed it, and closed it because we were not ready to implement it. After the rejection, the customer started to argue and scandalize.

When the situation became critical, the company's management got involved. They started to ask the client: "Why? After a number of questions, it turned out that he just needed to monitor the SLA of the second-line employees. But there was no need to use API; it had nothing to do with that. It became clear that we already had what he needed in the system; he didn't know about it.

Instead of immediately figuring out the task, the operator sent it to the queue for review. As a result, we lost time and had a conflict, which had to be resolved by the company's management. If the employee had understood the problem right away, it would have been resolved without a scandal.

Katerina Vinokhodova

Usedesk co-founder

Our tip: How to understand what the client needs

When a customer comes in with a request, we figure out three key points:

WHEN: we describe the situation in which the user needs a new feature.

I WANT: describe the work which the user needs to do without being bound to our service

WHAT: a goal, why this work should be done. The goal has nothing to do with the service. It's to help us understand what the user wants in the end, not to do a feature for the sake of a feature.

For example:

WHEN: after-hours when a VIP user requests it.

I WANT: a manager to receive notifications on Telegram.

WHAT: to respond quickly - to see the user's request immediately and react to it.

It often takes a long time to understand a task in depth. Sometimes you have to talk to the customer for 20 minutes to figure out these three things: Why? How about this? Would this solve the problem? The helpdesk doesn't have that much time. If you come across a problem that cannot be solved quickly, the operator passes it on to our Customer Success specialist. He contacts the customer separately and finds out what tasks he wants to solve.

Record the mass and adequacy of the request

We track recurring wants from different clients in the Jira service - our product manager does this for us. For us, the same request from three clients is already a mass request. But a mass request is not always adequate. For example, every new client asks us to change the color of their ticket statuses. And each time we answer, we will do this if it is still relevant to the client after two months of using the system. So far, no one has come back with this question. When a vendor discovers a mass request in the system, they send it in for review.

How to fire a customer

Recommendations for breaking up with toxic customers |26.09

Two customers want the same feature. As soon as there is a third one, the product will send a request for review

Establish a decision-making process for customer wants

Our product team reviews all of our customers' desires. We meet every Tuesday and discuss client requests for new features: is it a reasonable request or not, is it worth implementing, will it be in demand by other users, how difficult it would be to implement and whether it would be economically feasible. As a result of the discussion, we decide whether or not we're going to do it and determine the timing and funding model. We enter the results of this discussion into the comments to the task and either give it a go or reject it.

Our helpdesk operators know that on Tuesdays, we review all the wishes that have accumulated over the week. When a client calls about a new feature, the operator tells the client right away when the decision will be made. After the meeting on Tuesday, the operator calls the client back and informs him/her about the decision: either the feature is never implemented, or you will be able to implement it, but you will pay extra, or you will have to pay for the implementation within a certain period of time.

You can set your own schedule and mechanism for considering your wishes - the main thing is to have it and make it work.

In the task card, you can monitor its status. All the stages of work on the task are recorded here, the problem is described in the most succinct way, and what exactly needs to be done

Refuse customers correctly

You can and should say no to customers if it's impossible to implement his desire, it makes no sense, or it's not beneficial for the company. If it's not critical, the client won't be offended, but if it is critical and we can't implement it, it means that our product doesn't suit him. He needs a product that already has this functionality. It's like the customer needs yellow apples, and we sell red ones. There are no options here. We are comfortable with this, which means it's not our client.