10 regras para o sucesso de técnicos de suporte a campo

(*)Thomas S. Wolfe

Se você é um engenheiro, técnico ou consultor, se algum aspecto de seu trabalho envolve a interação com o usuário através de "suporte de campo", é importante reconhecer o poder e a responsabilidade do que você diz.

A partir do momento que você se apresenta a um “usuário final", como alguém qualificado para diagnosticar e resolver as suas preocupações, você está sendo percebido na mesma ótica de um médico ou advogado. Você é reconhecido por ser de uma área muito especializada de conhecimento.

Enquanto o ensino técnico e sua experiência podem ter aberto a porta para que você forneça soluções técnicas, quão eficaz você é como um "profissional de suporte" raramente depende do seu know-how técnico, mas sim do quão bem você se comunica e apresenta a sua solução - é responsável, politicamente correto e pode ser entendido por alguém sem o seu nível de especialização?

A apresentação é o quesito onde se pode ganhar o respeito de ser um profissional consumado por usuários finais e parceiros de trabalho. As dicas a seguir são oferecidas como orientações para ajudar a promover a interação eficaz e responsável que mencionei. São sugestões oferecidas para a construção de confiança entre você e os usuários servidos por você – o que incentiva eles a te consultarem por soluções.

# 10: Entenda o potencial impacto do que você diz:
Eu comprometi algumas estações de trabalho enquanto desempenhava ações que não deviam comprometê-las e “derrubei” servidores durante uma instalação de patches que não deveria ter impactado os servidores. Com isso, eu aprendi de uma maneira dura a necessidade de testar tais implementações "Sob o ambientes normais..." e comunicar ao cliente de uma forma diferente.

"Este patch não irá travar o seu servidor", embora bem-intencionada, talvez não seja tão eficaz como "Sob circunstâncias normais, este patch não deve travar o seu servidor". Explique que há sempre uma chance de algo "fora do normal" ocorrer, que pode impactar tais operações, e que "provavelmente não é uma má ideia que seus usuários loggem out e salvem todos os dados importantes - apenas por precaução".

Procure promover as atualizações em um ambiente de produção após o horário, de preferência em uma sexta-feira - o que irá permitir que a falha de backout seja finalizada no sábado e domingo.

# 9: Comunique-se tanto através de uma linguagem profissional como por metáforas
Ao explicar conceitos técnicos para um usuário que não tem uma formação técnica, procure usar analogias. Carros funcionam bem. Comparar a largura de banda de 56k de uma rua residencial e uma conexão T1 como uma auto-estrada de quatro pistas é um exemplo. Comparar um 486 com um compacto V4 e um processador Pentium II ao desempenho de um automóvel V8 pode ser usado como outro exemplo.

Durante o diálogo com o cliente, substituta palavras como "estação de trabalho", "usuário", "incidente" e "resolução" por substantivos mais comuns. Use palavras como "identificar", "diagnóstico" e "implementar". "Determine" estatísticas do ambiente e da “frequência" de um determinado problema ou ocorrência. "Correlacione" esses dados e tente "isolar" ou "identificar" as causas, como parte de seu “diagnóstico".

# 8: Não faça promessas irreais
Se você não tiver certeza de que um patch ou solução irá resolver um problema, não diga que isso irá acontecer. Se não se realizar, ele indica uma má capacidade sua de solucionar problemas. Só porque a Microsoft ou Novell diz que uma atualização específica é a resposta, nem sempre significa que irá funcionar - ou que não irá causar um outro problema que possa impedi-lo de usar o computador. Nesses casos, explique ao seu cliente que "A Microsoft afirma que isto vai resolver o problema". Se isso não acontecer, indicará uma falha da Microsoft e não incapacidade sua.

Se você está inseguro quanto à possibilidade ou não de um determinado patch ou correção ser a resposta, mas quer tentar mesmo assim, deixe isso claro. Tenha um raciocínio embasado por trás da sua crença nessa solução, ao invés de apenas ter um "pressentimento". Esteja preparado para explicar o seu raciocínio - que você pode ser solicitado a fazê-lo!

# 7: Se você não pode ajudar, foque na prevenção
Talvez você não tenha dados suficientes para identificar o problema, ou fez o seu melhor, mas simplesmente não há maneira de recuperar esse arquivo. Isso acontece! Se desculpe, demonstre empatia. Diga que você sente muito por não haver mais o que fazer para ajudar. Ela irá remover o desejo do cliente de colocar "culpa" em você, ou pelo menos desviar a culpa de você para o sistema de computador.

Se puder, tente fornecer ao usuário conselhos úteis para evitar o mesmo problema. No caso de perda de dados, humildemente sugira que "da próxima vez, talvez não seja uma má ideia salvar o seu trabalho com mais frequência".

No caso de não ser capaz de isolar um problema particular, forneça ao usuário informações ou instruções que possam ajudar a isolar o problema no futuro.

# 6: Trabalhe com o usuário e não contra eles
Quando encontrar um usuário pela primeira vez, leve alguns momentos para se apresentar. Descreva a abordagem que tinha planejado para diagnosticar e resolver o problema. Ao invés de simplesmente "resolver o problema", é importante demonstrar a sua capacidade de identificar o problema de forma racional eficaz. Com isso, o usuário irá tornar-se confiante na sua capacidade, que por sua vez, vai permitir uma maior liberdade em futuras interações.

Permita que o usuário controle o mouse e o teclado para salvar seu trabalho e fechar seus aplicativos antes de entregar o controle da máquina a você. Dessa forma, se algo der errado com os arquivos previamente abertos, ele irá remover o desejo de colocar a culpa em suas ações. Além disso, permitir que o usuário faça parte da solução demonstrará que você está "do lado deles" e "lá para ajudar" – e não vê-lo como um tecnólogo que está lá para fazê-lo se sentir inútil, porque eles precisam de assistência para usar o computador. NUNCA incite o confronto.

# 5: Seja honesto
Se você não sabe a resposta a uma pergunta, não finja. O cliente não tem a expectativa de que você saiba tudo sobre tudo. Diga com clareza "que o problema está fora da sua experiência particular, mas que irá buscar a solução". Isso poderia ser melhor recebido do que um simples "não sei" - o primeiro, pelo menos, demonstra um foco definido e direção.

# 4: Cuidado com as ramificações políticas da sua opinião
Como um profissional, saiba que sua opinião tem valor. Sua "opinião" informal pode facilmente tornar-se combustível para discussões políticas dentro da empresa. Não se sinta pressionado a chegar a uma conclusão certa simplesmente porque o usuário está conduzindo a situação nesse sentido.

Eu ainda não encontrei um usuário que não gostaria de ver os problemas de seu computador serem eliminados através da compra de um novo. No entanto, um chip de memória ruim nunca deveria determinar o abandono de um sistema que esteja bom em seu restante, por exemplo.

Até que você saiba a causa do problema, talvez seja melhor educadamente evitar perguntas sobre o diagnóstico. Perguntas como "O meu computador está ruim?" possuem segundas intenções e podem facilmente voltar contra você, quando o gerente recebe uma requisição de um novo desktop.

# 3: Seja Amigável
Não há absolutamente nada de errado em conhecer o usuário que você está prestando serviço. Perguntar "O que você faz" é um bom começo, seguido de comentários sobre cartazes ou itens presentes no escritório. Isso irá ajudá-lo a entender a personalidade de quem está trabalhando, e demonstra também que, como eles, você é uma pessoa com interesses, gostos e desgostos também.

# 2: Tome posse do problema
Trate as preocupações e os dados do usuário como se fossem seus. Deixe o seu ramal e celular, além do ramal do Centro de Suporte. No caso de um problema em curso, elabore um plano de ação e mantenha o usuário informado sobre os acontecimentos, enquanto eles ocorrem.

Isso demonstra que a incapacidade do usuário em realizar suas tarefas de negócios é importante para você, e se a solução para seu problema é simples ou complexo, você estará ali para ajudá-lo.

Em um ambiente onde o suporte é dividido entre equipes com diferentes responsabilidades, não simplesmente passe o usuário a uma nova equipe sem primeiro descrever o processo. Explique que, embora possua conhecimentos nesta área, outra equipe poderia ser mais adequada para resolver este problema em particular.

# 1: Saber o momento de desistir
Se você já gastou mais de 15 minutos de trabalho para diagnosticar um problema, pergunte ao usuário se este é um momento conveniente para continuar. É muito fácil algumas horas passarem como se fossem poucos minutos "apenas tentando mais uma coisa". Talvez seria melhor marcar uma data para quando o usuário estiver fora do escritório. Alternativamente, se o problema é crítico, pergunte se o equipamento pode ser levado à sua área de laboratório para o problema ser diagnosticado.

Independentemente se o usuário aceita ou não, dar-lhes a opção demonstra novamente o seu desejo e vontade de ajudar - o que em última análise, é exatamente o motivo de você estar lá.

(*)Sobre o autor:
Thomas S. Wolfe é um veterano de 15 anos da indústria de tecnologia que tem servido como um consultor para grandes empresas, e como proprietário e gerente-executivo de uma empresa de consultoria de tecnologia. Ele pode ser contatado pelo site www.networkstech.net.