notícia 6 erros que as equipes de Suporte Técnico/Help desk cometem

[GNMilasi]

6 erros que as equipes de Suporte Técnico/Help desk cometem

 

Embora o serviço de suporte técnico de TI nas organizações consuma, em média, apenas 9% do centro de custos atual de todo o departamento de TI, ele é responsável por grande parte da percepção de valor por parte do usuário com o setor. Estima-se que 85% dessa percepção do usuário com os serviços de TI são originadas pelo serviço de helpdesk, logo, isso mostra o quão importante é transmitir um bom serviço para o cliente e que pequenas mudanças nessa área poderá impactar a experiência do usuário positivamente ao utilizar serviços informacionais.

 

Veja abaixo 6 erros cometidos pelas equipes de suporte e atue para ajustá-los!

 

 

1- Corrigir a falha e não a causa

 

Como já dizia Confúcio: “Não corrigir falhas é o mesmo que cometer novos erros”. Uma máquina que sempre dá defeito, uma impressora que nunca imprime ou um access point que sempre trava podem consumir horas e horas de trabalho e técnicos diferentes em um período curto, e seus efeitos são inúmeros. Além de aumentar a fila de atendimento, a percepção de valor do cliente com o serviço cairá e o custo para uma solução definitiva provavelmente sairá menos custosa que todas as horas que seriam empregadas para resolver o problema de forma repetida.

Muitas das vezes pode ser difícil identificar causas raízes de falhas recorrentes de sistemas ou hardware, para isso existem ferramentas que nos auxiliam a encontrar a real causa como, por exemplo, diagrama de Ishikawa, técnica dos 5 porquês, teste de hipóteses e soluções conjuntas.

 

 

2- Aceitar gambiarras

 

Não é raro acharmos aquela gambiarra provisória que está intacta no mesmo lugar há mais de 5 anos. Muitas das vezes as gambiarras são usadas por falta de qualificação, não cumprimento das normas e falta de verba/tempo necessária(o) para aplicar a correção adequada. Gambiarras podem trazer danos irreparáveis à segurança da informação, equipamentos e até a integridade física das pessoas.

 

 

3- Pensar que cumprir a SLA já é o bastante

 

Recentemente um artigo excelente aqui no PTI explicou muito bem esse ponto (Tudo que você precisa saber sobre o que é XLA). É muito comum em ambientes de TI com maior controle, onde existe uma SLA bem formalizada e de conhecimento de todos os clientes e técnicos, julgar que atende-las é o bastante. Não adianta o cliente ser atendido a tempo e com a qualidade acordada se outros itens não estiverem satisfazendo. Imagine um restaurante com uma comida incrível, com excelentes pratos, tudo impecável, com exceção de um detalhe: você vê uma pequena barata num cantinho… Toda a sua experiência muda!

 

Olhar apenas analiticamente o SLA pode ser enganoso, devemos olhar toda a experiência do usuário durante o serviço e em todas as etapas e identificar para onde a percepção de valor está sendo canalizada.

 

 

4- Priorizar demandas de maneira inadequada

 

Determinar criticidade de incidentes vária de acordo com as organizações. A TI deve sempre determinar prioridade de atendimento de acordo com a visão de negócio da empresa. Para isso, devemos responder algumas perguntas chaves:

 

===> Quais são as áreas, atividades, funções e/ou cargos que não podem ficar sem os serviços de TI de forma alguma?

===> Para o caso específico de sua organização, o que configura um incidente como crítico: queda/indisponibilidade de serviço?

===> Afeta alguma área crítica?

===> Afeta a algum usuário/cargo específico?

 

Se um cliente interno solicitasse a troca de um cartucho de impressora, qual grau de prioridade daria ao chamado aberto? Se sua resposta foi depende, você está certo. Um problema simples como esse pode causar sérios prejuízos, e se essa impressora ficasse em um guichê de liberação de frota de uma empresa de um grande centro de distribuição? Imagine a situação desse chamado ser considerada de prioridade normal ou baixa com SLA de 12 horas.

 

 

5- Não se atentar a métricas

 

Apesar de falarmos no item 3 sobre isso, as métricas são importantes ferramentas para a gestão do departamento de TI da organização e, além disso, é uma excelente forma de mensurar um pouco do trabalho de cada técnico a fim de uma autopercepção que condiz com a realidade. Ela poderá fazer com que você reconheça seus pontos fortes e fracos e também permitirá uma reação mais ágil conforme seus indicadores mudem.

 

 

6- Falta de base de conhecimento

 

Os técnicos não devem perder tempo solucionando casos que já foram previamente solucionados por outro técnico. Tenha uma base de conhecimento própria para seus técnicos, documente os possíveis incidentes para que quando o problema venha a se repetir sua resolução seja incisiva, restabelecendo o serviço o mais rápido possível, minimizando assim o impacto negativo sobre o negócio. Há diversas bases de conhecimento prontas na internet, porém, elas dificilmente terão o mesmo efeito de uma solução caseira. Lembre-se que cada organização tem incidentes diferentes.

 

Ter uma rica base de conhecimento é muito importante para o dia a dia do atendimento, ela entrega maior agilidade ao técnico com sua resolução incisiva restabelecendo o serviço da maneira mais rápida possível minimizando assim o impacto negativo sobre o negócio. Ela pode ser elaborada de diversas maneiras, seja em uma página restrita na web, planilhas, papel ou diretamente no seu software de help desk. Instrua seus técnicos a participarem desse processo de alimentação e que consultem ou alterem quando necessário.

 

Para manter a equipe de suporte relevante e entregando valor ao cliente devemos sempre compreender seu funcionamento e buscar melhores experiências ao usuário.

 

 

Fonte

[marcelosly]

Já cometi alguns desses, hoje não mais organização nos leva a excelência.

[Victor Show]

Ainda não tinha-me dado conta, agora vejo que cometo quase todos erros, valeu pela dica.

[Rafaela Correia]

Trabalhei por 3 anos como suporte N1. Tinha muita gente, eu inclusa, que queria fazer um trabalho bom e de qualidade, mas por conta da SLA, nossos supervisores apressavam o atendimento.
De 15 minutos que tínhamos, diminuíram pra 10!
Era bem frustrante. O cliente se irritava, o chamado demorava para ser resolvido e assim continuava o ciclo.
A culpa não é totalmente dos técnicos. As vezes a gente fica preso as políticas da empresa.

[wagner_claro]

otimo topico, li e reli, vou me aprofundar

[GNMilasi]

Até 15 anos atrás, o Erro 1 era uma constante aqui, atualmente pesquiso a fundo com a finalidade de resolver um problema (falo de SOs não de Eletrônica) e já perdi clientes por conta dessa demanda de tempo que na maioria das vezes era falha de hardware, tipo Fonte de Alimentação com defeito, placa-mãe com Capacitores estufados ou vazando, falhas nos módulos de memória etc...

 

Abs.

[Igor Coimbra Szigethy]

O numero um é o mais comum hoje (na minha opinião) na maior parte das vezes o foco é fechar o chamado e não resolver o problema. Tinha brigas enormes com as equipes de N3 na minha empresa antiga porque o chamado subia, ficava uma semana la e na sexta feira voltava com a orientação de "formatar a maquina". Agora imagina o cenário: um setor composto por traders financeiros com diversos programas que dependiam de fornecedores externos para a instalação e o cara me retorna uma orientação dessa depois de 5 dias de chamado parado.

[SuperiorGamerBR]

Não utilizar equipamentos de Proteção ESD

[bruno_pi]

Ótimo tópico,li umas 2 vezes