Três maneiras infalíveis de estragar o relacionamento entre suporte e desenvolvimento

Frequentemente, um cliente relata um problema e acontece que não existe nenhum problema, ou ele está em um lugar completamente diferente. Se você enviar, imediatamente, esse pedido para suporte, você vai dar dezenas de voltas e vai voltar para a sua posição inicial, em vez de solucionar o problema do cliente com pouco esforço. Para não desperdiçar tempo e evitar que se cliente se estresse, encontre a essência do problema na costa. Para fazer isso, percorra as etapas com o cliente e identifique o problema.

Enviar, imediatamente, solicitações de cliente para desenvolvimento

Cliente: Boa tarde! Não consigo abrir o aplicativo de vocês

Suporte: Olá! Aceito. Passo para desenvolvimento. Assim que esclarecerem, ligo para você de volta.

Suporte: Chefe, temos um problema. O cliente não pode abrir o nosso aplicativo. O que pode ser?

Desenvolvimento ruim: Finalmente cheguei na sua pergunta. Acabei de abrir o app. Está tudo funcionando. Eu não sei o que o cliente não abre lá.

Suporte: Droga!

Cliente: Boa tarde! Não consigo abrir o aplicativo de vocês.

Suporte: Oi! Vamos tentar abrir junto com você. Qual é a sua primeira ação?

Cliente: Bem, eu vou no site e não consigo entrar no programa.

Suporte: Sei. Eu entendi corretamente que você quer entrar no sistema através do navegador do computador e não do aplicativo do celular?

Cliente: Bem, sim!

Suporte: Entendi. Verificando. Tudo funciona. Vamos tentar juntos outra vez. Insira a senha. Você pode ter inserido uma senha errada?

Cliente: A senha está certa; eu tenho tudo escrito. Está aqui, a senha… Ah…. Espere. Estou com as maiúsculas acionadas. Agora tudo funciona. Obrigado! Me desculpe.

Suporte: Bom ter ajudado. Mantenha contato.

Katerina Vinokhodova,

Cofundadora da Usedesk

Se você enviar uma tarefa para desenvolvimento no formulário de poucas frases, os desenvolvedores vão ter de procurar todos os detalhes por conta própria e acionar o suporte todas as vezes. Dessa maneira, você inicia um conflito do zero, e suporte e desenvolvimento vão desperdiçar tempo e células nervosas. Para impedir que isso aconteça, dê ao suporte um algoritmo de ações e crie um formulário padrão do aplicativo para os operadores.

Formule tarefas para o desenvolvimento em um formulário livre

Estão aqui três pontos que devem ser incluídos na declaração do problema para evitar conflitos:

1. Característica da amplitude do problema. Um dos maiores erros de um funcionário de suporte é enviar uma tarefa para desenvolvimento sem entender quão amplo é o problema. Depende de onde procurar a causa do problema. Por exemplo, um cliente reclama de que os hieróglifos estão no bate-papo, em vez de o alfabeto cirílico. Se esse for um caso isolado, o que é muito provável, tem um problema no navegador ou a codificação, simplesmente, desapareceu - esse problema pode ser resolvido, rapidamente, pelo lado do cliente. Se os sócios do cliente que usam seu serviço também virem hieróglifos em seus bate-papos, então o problema está no lado do serviço – e precisa ser encaminhado para desenvolvimento.

E a natureza da amplitude do problema aumenta, imediatamente, o nível de seu criticidade - mais sobre isso mais adiante.

2. A criticidade do problema. Se você enviar uma tarefa para desenvolvimento sem determinar sua criticidade no início, os desenvolvedores não vão entender imediatamente qual ordem deve ser seguida para a realização das tarefas. Um problema pode esperar uma semana, mas você precisa largar tudo e correr urgentemente para ajudar por conta de outra pessoa. Não se recomenda que os desenvolvedores assumam, imediatamente, tarefas não urgentes enquanto as emergências estão juntando pó na estante. Descubram logo a criticidade da tarefa e somente aí encaminhem para desenvolvimento.

Um cliente indignado reclamou do suporte, e nós começamos a pensar

O que aconteceu foi que o operador, em vez de um alto nível de criticidade - definiu o médio e a tarefa foi empurrada para uma prioridade mais alta. Eu tive que resolver a situação urgentemente - me desculpar com o cliente e oferecer uma compensação

A última etapa é a de resolver o problema rapidamente. Cliente satisfeito, conflito finalizado.

Usamos quatro níveis de criticidade de tarefas, mas você pode desenvolver o seu sistema.

Níveis de severidade

1 Não afeta o trabalho de jeito nenhum, só cria uma inconveniência

2 Afeta o trabalho, mas não criticamente

3 Afeta criticamente o trabalho, mas você pode resistir por uns dois dias

4 Detém completamente o usuário

Exemplos de

✓ O calendário parece horrível
✓ É inconveniente selecionar um período no calendário
✓ Ao salvar as configurações, um pop-up de erro aparece, ocasionalmente, embora as configurações estejam salvas
✓ Para dez casos de uso de modelo, o layout desaparece
✓ A seção de relatórios não funciona
✓ O sistema não abre
✓ O sistema não recebe letras
✓ A regra de automatização não funciona

3. Descrição do problema usando um modelo. Sem um modelo, o operador vai escrever um ensaio sobre um assunto qualquer, e desenvolvimento vai resolver esse enigma e suar muito. Mas suponhamos que você dê um modelo ao operador. Nesse caso, tudo que você tem a fazer é preencher todos os itens: especifique o ID da empresa, anote a severidade do problema, determine o nível de criticidade, descreva todas as etapas do cliente depois da ocorrência do erro, especifique a URL do problema, adicione capturas de tela. E o desenvolvedor pode rapidamente trabalhar na estrutura familiar, entender a situação e decidir o que fazer e quando fazer.

Por exemplo, identificando que o cliente vai alertar os desenvolvedores para dar prioridade à tarefa baseada na importância do cliente para a empresa. E especificar a parte do sistema onde o problema aconteceu vai, rapidamente, ajudar a designar um executor e encontrar os pontos fracos no sistema que precisam ser retrabalhados.

Suporte: Chefe, temos um problema. O app do cliente não funciona. Eu enviei informação pra você.

Desenvolvimento: Sim, estou vendo é o Ivan Ivanovich de novo.
Acho que podemos resolver rapidamente. Sim, estou vendo o erro, entendi. Vamos começar a trabalhar agora mesmo.


Suporte: Ótimo! Ele está esperando.

Suporte: Chefe, temos um problema. O app não funciona para o cliente. Eu enviei pra você algumas informações.

Desenvolvimento: Sim, Eu executei diagonalmente; em duas horas, posso verificar mais de perto.

Suporte: Mas ele é o Ivan Ivanovich; eu escrevi pra você postscript no final do documento. Ele ligou e garantiu. Se nós não corrigirmos – cabeças vão rodar.

Desenvolvimento: $ # * @%!!! Então eu diria, é pra já, eu não tinha terminado de ler… Estou prestando atenção…. E o que exatamente não funciona para ele?

Suporte: Hum… Vou mandar uma tela pra você agora… Aqui…

Desenvolvimento: Sim, eu estou vendo. E então onde aparece o problema?

Suporte: Eu escrevi.

Desenvolvimento: $ # * @%!!! Onde? Eu não estou vendo.

Suporte: No quarto parágrafo, a quinta frase.

Desenvolvimento: Sim, achei. Tem um erro de URL?

Suporte: $ # * @%!!!

Se você espalhar tarefas aleatoriamente, vai perder o controle sobre elas rapidamente, e os clientes insatisfeitos vão correr para os seus concorrentes e começar a escrever comentários negativos e arruinar o seu karma. Para manter todas as tarefas sob controle, gere solicitações em um sistema automatizado que permita a você configurar prazos finais para cada tarefa e a rastrear sua conclusão. Trabalhamos no serviço Jira, mas você pode usar qualquer um.

Para fazer esse sistema funcionar, você precisa:

1. Designar um administrador dentro de desenvolvimento. Um administrador de tarefa dentro de desenvolvimento aceita tarefas da equipe de suporte e as distribui. Se não tiver essa pessoa, os operadores vão incomodar os desenvolvedores, constantemente, e vão desconcentrá-los das suas tarefas, o que pode levar à geração de conflitos. A função do administrador pode ser assumida pelo líder do departamento de desenvolvimento, gerente de projeto, ou você pode contratar uma pessoa especialmente para cumprir essa tarefa. Ele vai controlar a carga de trabalho de cada funcionário e distribuir tarefas equitativamente, de acordo às suas complexidades e prazos finais.

2. Definição de prazos finais para diferentes tarefas. O desenvolvedor vai assumir tarefas, gradualmente, de acordo com o nível de sua criticidade. Por exemplo, tarefas com o quarto nível de criticidade são realizadas imediatamente, com o terceiro - na semana seguinte, com o segundo - em uma semana, com o primeiro - em duas semanas. Dessa maneira, os desenvolvedores vão ter uma carga de trabalha equitativa, e os operadores de assistência técnica vão ter a previsão de conclusão de todas as suas tarefas e vão poder avisar aos clientes, imediatamente, quando há um movimento no seu problema.

Envio de tarefas no bate-papo comum, PM, ou e-mail dos desenvolvedores

Para tornar mais fácil a condução de tarefas para o suporte, vinculamos as solicitações de suporte no Jira às tarefas executadas por desenvolvimento. Assim, o operador pode entrar, em qualquer momento, nas suas tarefas e ver as tarefas de desenvolvimento associadas a elas: em que etapa se encontram e quais são os prazos finais

3. Definição de pontos de controle. De acordo com a complexidade das tarefas e com outros fatores, as datas podem ser remanejadas. Para que isso não surpreenda os operadores que estão esperando a solução de suas tarefas, você precisa definir prazos finais para a reconciliação. Por exemplo, a equipe de suporte entra em contato com o administrador todas as terças-feiras e especifica os prazo finais para as suas tarefas. Dessa forma, eles vão saber o que está acontecendo com as suas tarefas e vão comunicar as mudanças para os clientes no tempo devido.

4. Estabelecimento de resposta a desenvolvimento → suporte. Acontece quando um desenvolvedor no processo de solução de um problema tem perguntas adicionais sobre o suporte. Sem uma resposta, ele não pode continuar a trabalhar. Tivemos um caso quando os desenvolvedores escreveram perguntas para tarefas no Jira. Os comentários foram enviados à equipe de suporte no e-mail corporativo, mas eles não leram. Em consequência, começamos a ter muitas tarefas paradas. Quando verificamos, configuramos o sistema para que as mensagens com referências aos operadores chegassem a eles na forma de tickets no Usedesk, como as dos clientes, e o problema foi resolvido. Para impedir a paralisação devido a problemas de comunicação, forneça ao desenvolvimento a oportunidade de receber a resposta do suporte.

5. Crie um bate-papo separado para tarefas críticas. Temos um bate-papo particular para as tarefas especialmente essenciais, onde os operadores as colocam, logo que definem uma tarefa no Jira. E às vezes, o problema é preciso, a solução também é, mas demora um tempo para se formular um problema de acordo com um modelo. Então o operador descreve a tarefa no bate-papo, e os desenvolvedores começam, imediatamente, a vê-lo, depois disso, ele é formulado no Jira. Desenvolvimento, primeiramente, retira as tarefas do bate-papo para trabalhar nelas.

Suporte: Eu configuro uma tarefa, está acionada, então vou duplicar no bate-papo.

Administrador: Entendi. Veja…. Eu vi que a tarefa está pegando fogo. Agora o Ivan tem uma janela. Eu dou a tarefa pra ele e configuro o prazo final para depois de amanhã.

Suporte: Ótimo! Obrigado.

Suporte: Chefe, passei um problema ontem pra você. E como está? Quando você pode ver?

Desenvolvedor: Vi ontem, mas me perdi completamente. Hoje, está tudo pegando fogo. Amanhã eu vou ver, com certeza.

….

Suporte: Bem, como está a minha tarefa? Eu queria que fosse rápido; se não, o cliente pode ligar de novo. E aí o que devo dizer pra ele?

Desenvolvimento: $ # * @%!!! Irmão, desculpe, não tenho tempo. Você pode pedir para o Ivan ver?

Suporte: $ # * @%!!!