Você não pode recusar: o que fazer com as solicitações do cliente
Os clientes podem ligar para o suporte e pedir para adicionar uma ou mais teclas ou um campo adicional. Esta situação lhe soa familiar? Você pode responder às solicitações dos seus clientes de diferentes maneiras. Por exemplo, eles respondem "vamos considerar sua solicitação" e se esquecem isso. Isso está bem, você não tem que executar todos as fantasias dos clientes. Mas há uma outra visão, que lhe ajuda a fazer o seu serviço ainda mais atraente para os clientes. O principal é definir a maneira certa de trabalhar com esses desejos. Nós vamos dizer a você como funciona.
Entenda o que o cliente realmente precisa
Se o operador de suporte no início não entende qual é o problema que o cliente quer resolver, ele pode imediatamente prometer que vai cumprir esse desejo, mas isso nunca vai acontecer. Portanto, o problema não é resolvido; o cliente fica insatisfeito e compartilha seu descontentamento nas redes sociais. E então, no curso da investigação, acontece que o problema do cliente poderia ter sido solucionado com a ajuda de ferramentas que já estão disponíveis.
Por exemplo, tivemos um caso em que um cliente ligou e pediu para fazermos pra ele um outro método de API. Nos pediram para carregar os tempos de criação e de modificação de ticket no nosso sistema. Nós não tínhamos essa função, então criamos a solicitação, discutimos e a fechamos porque não estávamos prontos para implementá-la. Após a rejeição, o cliente começou a discutir e ficou ofendido.
Quando a situação se tornou crítica, a gerência da empresa começou a se envolver. Começaram a perguntar para o cliente: "Por quê? Após uma série de perguntas, ele só precisou monitorar o SLA dos funcionários da segunda linha. Mas não havia nenhuma necessidade de usar o API; não tinha nada a ver com aquilo. Ficou claro que nós já tínhamos no sistema o que ele queria; ele não sabia disso.
Em vez resolver a tarefa imediatamente, o operador a enviou para fila para revisão. Em consequência, perdemos tempo e tivemos um conflito, que teve que ser solucionado pela gerência da empresa. Se o funcionário compreendesse o problema da maneira certa, ele teria sido solucionado sem um escândalo.
Por exemplo, tivemos um caso em que um cliente ligou e pediu para fazermos pra ele um outro método de API. Nos pediram para carregar os tempos de criação e de modificação de ticket no nosso sistema. Nós não tínhamos essa função, então criamos a solicitação, discutimos e a fechamos porque não estávamos prontos para implementá-la. Após a rejeição, o cliente começou a discutir e ficou ofendido.
Quando a situação se tornou crítica, a gerência da empresa começou a se envolver. Começaram a perguntar para o cliente: "Por quê? Após uma série de perguntas, ele só precisou monitorar o SLA dos funcionários da segunda linha. Mas não havia nenhuma necessidade de usar o API; não tinha nada a ver com aquilo. Ficou claro que nós já tínhamos no sistema o que ele queria; ele não sabia disso.
Em vez resolver a tarefa imediatamente, o operador a enviou para fila para revisão. Em consequência, perdemos tempo e tivemos um conflito, que teve que ser solucionado pela gerência da empresa. Se o funcionário compreendesse o problema da maneira certa, ele teria sido solucionado sem um escândalo.
Katerina Vinokhodova
cofundadora da Usedesk
Nossa dica: Como entender o que o cliente precisa
Quando um cliente entra com uma solicitação, nós partimos de três pontos chaves:
QUANDO: descrevemos a situação na qual o usuário precisa de uma nova funcionalidade.
EU QUERO: descreve o trabalho que o usuário precisa fazer, sem ser limitado ao nosso serviço
QUE: um objetivo, por que esse trabalho deve ser feito. O objetivo não tem nada a ver com o serviço. É para nos ajudar a entender o que o usuário quer finalmente, não para fazer uma funcionalidade para uma funcionalidade.
Por exemplo:
QUANDO: depois de hora quando um usuário VIP solicita alguma coisa.
EU QUERO: um gerente para receber notificações no Telegram.
QUE: para responder rapidamente - ver imediatamente a solicitação do usuário e para reagir a ela.
Geralmente, demora um bom tempo para compreender a tarefa em profundidade. Às vezes você tem que falar com o cliente por 20 minutos até entender essas três coisas: Por quê? E isso? Isso resolveria o problema? O suporte técnico tem muito tempo. Se acontecer com você um problema que não pode ser resolvido rapidamente, o operador passa esse problema para o nosso especialista de Sucesso do Cliente. Ele entra em contato com o cliente separadamente e descobre que tarefas ele quer solucionar.
Quando um cliente entra com uma solicitação, nós partimos de três pontos chaves:
QUANDO: descrevemos a situação na qual o usuário precisa de uma nova funcionalidade.
EU QUERO: descreve o trabalho que o usuário precisa fazer, sem ser limitado ao nosso serviço
QUE: um objetivo, por que esse trabalho deve ser feito. O objetivo não tem nada a ver com o serviço. É para nos ajudar a entender o que o usuário quer finalmente, não para fazer uma funcionalidade para uma funcionalidade.
Por exemplo:
QUANDO: depois de hora quando um usuário VIP solicita alguma coisa.
EU QUERO: um gerente para receber notificações no Telegram.
QUE: para responder rapidamente - ver imediatamente a solicitação do usuário e para reagir a ela.
Geralmente, demora um bom tempo para compreender a tarefa em profundidade. Às vezes você tem que falar com o cliente por 20 minutos até entender essas três coisas: Por quê? E isso? Isso resolveria o problema? O suporte técnico tem muito tempo. Se acontecer com você um problema que não pode ser resolvido rapidamente, o operador passa esse problema para o nosso especialista de Sucesso do Cliente. Ele entra em contato com o cliente separadamente e descobre que tarefas ele quer solucionar.
Registra a magnitude e a adequação da solicitação
Rastreamos desejos recorrentes de diferentes clientes no serviço Jira - nosso gerente de produto faz isso por nós. Para nós, a mesma solicitação de três clientes é já uma solicitação. Mas uma solicitação de magnitude nem sempre é adequada. Por exemplo, cada cliente novo pede para nós mudarmos a cor do status dos seus tickets. E cada vez que respondemos, faremos isso se ainda for relevante para o cliente após dois meses de uso do sistema. Até o momento, ninguém voltou com essa pergunta. Quando um vendedor descobre uma solicitação de magnitude no sistema, ele a envia para revisão.
Dois clientes querem a mesma funcionalidade. Assim que houver um terceiro, o produto vai enviar uma solicitação para revisão
Estabeleça um processo de tomada de decisão para desejos de clientes
Nossa equipe de produto revê todos os desejos dos nossos clientes. Nós nos encontramos toda terça-feira e discutimos as solicitações dos clientes de novas funcionalidades: é um pedido razoável ou não, vale a pena implementá-lo, ele terá demanda de outros usuários, quão difícil seria implementá-lo e é economicamente praticável. Como resultado da discussão, decidimos se vamos ou não fazer e determinamos o tempo dispensado e o modelo de recursos. Incorporamos os resultados dessa discussão nos comentários das tarefas e damos ok para avançar ou não.
Nossos operadores de suporte técnico sabem que às terças-feiras, revemos todos os desejos que foram acumulados durante a semana. Quando um cliente liga para pedir uma nova funcionalidade, o operador diz na hora para o cliente quando a decisão será feita. Após a reunião de terça-feira, o operador liga para o cliente de volta e a/o informa sobre a decisão: ou a funcionalidade nunca será implementada, ou você poderá implementá-la, mas vai ter que ser pago um acréscimo, ou a implementação terá que ser paga dentro de um determinado período de tempo.
Você pode configurar sua própria programação e mecanismo para considerar os desejos, o principal é tê-lo e fazê-lo funcionar.
Nossos operadores de suporte técnico sabem que às terças-feiras, revemos todos os desejos que foram acumulados durante a semana. Quando um cliente liga para pedir uma nova funcionalidade, o operador diz na hora para o cliente quando a decisão será feita. Após a reunião de terça-feira, o operador liga para o cliente de volta e a/o informa sobre a decisão: ou a funcionalidade nunca será implementada, ou você poderá implementá-la, mas vai ter que ser pago um acréscimo, ou a implementação terá que ser paga dentro de um determinado período de tempo.
Você pode configurar sua própria programação e mecanismo para considerar os desejos, o principal é tê-lo e fazê-lo funcionar.
No cartão de tarefas, você pode monitorar seu status. Todos as etapas de trabalho nas tarefas são gravadas aqui, o problema é descrito da maneira mais sucinta possível e o que é preciso ser feito exatamente
Recusar clientes corretamente
Você pode e deve dizer não aos clientes se for impossível implementar o seu desejo, se ele não faz nenhum sentido, ou se não é benéfico para a empresa. Se não for crítico, se o cliente não ficar ofendido, mas se for crítico e não pudermos implementá-lo, significa que o nosso produto não serve para ele. Ele precisa de um produto que já tenha essa funcionalidade. É como o cliente que precisa de maçãs verdes e nós vendemos as vermelhas. Não há nenhuma opção aqui. Estamos à vontade com isso, o que significa que ele não é nosso cliente.
Por favor, avalie nosso artigo
Sabemos muito sobre atendimento ao cliente
Uma vez a cada duas semanas, enviaremos materiais interessantes e valiosos sobre atendimento ao cliente – artigos, casos e atualizações do sistema. O que você acha da oferta?
Sabemos muito sobre atendimento ao cliente
Uma vez a cada duas semanas, enviaremos materiais interessantes e valiosos sobre atendimento ao cliente – artigos, casos e atualizações do sistema. O que você acha da oferta?
Seu suporte realmente funciona?
Descubra com o nosso diagnóstico gratuito! Nossos especialistas vão auditar todos os seus canais de atendimento e oferecer um relatório completo e exclusivo para a sua empresa.
©2023 Helpdesk&Bots LTDA
Informações Úteis
Para quem
Oportunidades
INSTITUCIONAL
Para perguntas aos fundadores
;