Um colaborador abre um chamado porque o notebook está lento.
Outro relata problemas na bateria.
Um terceiro não consegue utilizar determinado sistema.
A TI resolve.
Chamado encerrado.
Aparentemente, o processo funcionou.
Mas uma pergunta importante deveria vir depois:
quantas vezes esse mesmo tipo de problema aconteceu nos últimos meses?
Um chamado isolado pode representar apenas uma ocorrência.
Dez, vinte ou cinquenta chamados semelhantes podem revelar algo muito maior.
Talvez exista um modelo de notebook inadequado.
Talvez determinado equipamento esteja chegando ao fim do ciclo.
Talvez exista um problema de infraestrutura.
Talvez os usuários não tenham recebido treinamento suficiente.
Ou talvez o processo esteja mal desenhado.
Quando analisados em conjunto, os chamados de suporte podem funcionar como uma espécie de termômetro da operação tecnológica da empresa.
Fechar chamados não deveria ser o único objetivo
O indicador mais básico de uma operação de suporte costuma ser:
quantos chamados foram resolvidos?
É importante.
Mas não suficiente.
Imagine que a TI receba 100 chamados mensais e consiga resolver todos.
À primeira vista, parece uma operação eficiente.
Agora imagine que 40 desses chamados sejam causados exatamente pelo mesmo problema.
Nesse cenário, talvez exista outra pergunta mais importante:
por que esse problema continua acontecendo?
Resolver rapidamente é bom.
Eliminar a causa recorrente é melhor.
Chamados recorrentes podem revelar problemas de compra
Imagine que determinado modelo de notebook apresente repetidamente:
problemas de bateria;
falhas em dobradiças;
superaquecimento;
baixo desempenho;
defeitos no carregamento.
Individualmente, cada caso pode parecer uma manutenção comum.
Quando a empresa cruza os chamados por modelo, porém, aparece um padrão.
Talvez o problema não esteja apenas nos equipamentos individualmente.
Pode estar na própria decisão de aquisição.
Essa informação deveria influenciar futuras compras.
Se um determinado modelo gera muito mais ocorrências do que os demais, o menor preço de aquisição pode não representar o menor custo durante o ciclo de vida.
Lentidão recorrente pode revelar subdimensionamento
Outro exemplo.
A empresa recebe diversos chamados com a mesma reclamação:
“Notebook lento.”
A resposta tradicional pode ser:
limpar arquivos;
atualizar sistema;
reiniciar;
verificar aplicações;
realizar manutenção.
Mas, se os chamados se concentram em um determinado perfil de usuários, talvez a causa seja estrutural.
Imagine profissionais que trabalham diariamente com grandes planilhas utilizando equipamentos originalmente dimensionados para atividades administrativas leves.
O suporte pode resolver sintomas.
Mas o problema real é:
a ferramenta não corresponde mais ao trabalho.
Nesse caso, os chamados estão mostrando uma falha de dimensionamento.
Nem todo chamado é problema de tecnologia
Essa distinção é importante.
Imagine que dezenas de pessoas abram chamados perguntando como realizar o mesmo procedimento em determinado sistema.
Talvez o sistema esteja funcionando perfeitamente.
O problema pode ser treinamento.
Ou documentação.
Ou comunicação.
Se o suporte apenas responde individualmente a cada pessoa, o mesmo chamado continuará aparecendo.
Uma ação melhor poderia ser:
criar um guia;
gravar um treinamento;
melhorar o onboarding;
documentar o procedimento;
alterar uma instrução interna.
Assim, um padrão de suporte revela uma necessidade organizacional.
Problemas de Wi-Fi podem não estar nos notebooks
Outro cenário frequente:
vários usuários relatam lentidão, quedas de conexão ou videoconferências instáveis.
Se cada chamado for analisado isoladamente, é possível começar verificando os notebooks individualmente.
Drivers.
Configurações.
Adaptadores.
Sistema operacional.
Mas se diversos usuários apresentam o mesmo problema no mesmo local ou horário, a causa pode estar em outro ponto.
Rede.
Access point.
Cobertura.
Capacidade.
Link de internet.
Infraestrutura.
O conjunto dos chamados ajuda a diferenciar:
problema do equipamento
de
problema do ambiente onde ele está inserido.
O local dos chamados também importa
Não basta saber o tipo de ocorrência.
É interessante observar onde ela acontece.
Por exemplo:
uma filial apresenta muito mais chamados do que as demais;
um departamento possui taxa de falhas muito superior;
usuários remotos enfrentam determinado problema;
um andar específico registra dificuldades de conexão;
um grupo de máquinas apresenta a mesma falha.
Esses recortes ajudam a localizar causas.
Quanto melhor a classificação dos chamados, mais útil se torna o histórico.
O usuário também pode revelar padrões
Outra análise possível é observar a recorrência por perfil profissional.
Imagine que a equipe comercial concentre grande quantidade de problemas relacionados à bateria.
Isso talvez tenha relação direta com mobilidade.
Os equipamentos podem passar boa parte do dia longe de tomadas.
Nesse caso, autonomia deixa de ser apenas uma característica interessante.
Passa a ser um requisito operacional.
Da mesma forma, uma equipe criativa abrindo chamados constantes por falta de armazenamento pode indicar que as configurações atuais já não acompanham a rotina.
O chamado ajuda a mostrar como as pessoas realmente utilizam a tecnologia.
O histórico de suporte deveria influenciar o planejamento de compras
Imagine uma empresa planejando a próxima aquisição de 100 notebooks.
Antes de decidir os modelos, vale olhar para os últimos 12 meses de chamados.
Quais equipamentos mais falharam?
Quais componentes geraram mais problemas?
Quais reclamações de desempenho foram mais frequentes?
Quais perfis de usuários tiveram mais dificuldade?
Quais equipamentos exigiram mais manutenção?
Esses dados ajudam a melhorar a próxima decisão.
O suporte deixa de ser apenas o departamento que conserta o passado.
Passa a fornecer informações para comprar melhor no futuro.
Chamados também ajudam a decidir quando substituir equipamentos
Considere dois notebooks da mesma idade.
O primeiro praticamente nunca apresentou problema.
O segundo passou por diversas ocorrências no último ano.
Bateria.
Teclado.
Carregamento.
Travamentos.
Mesmo que ambos tenham sido comprados na mesma data, talvez não devam seguir o mesmo ciclo.
O histórico de chamados pode ajudar a identificar equipamentos que estão entrando em uma fase de baixa confiabilidade.
Nesse caso, substituir preventivamente pode fazer mais sentido do que continuar acumulando intervenções.
Quais indicadores podem ser acompanhados?
A empresa não precisa começar com dezenas de métricas.
Alguns indicadores simples já podem revelar bastante.
Chamados por equipamento
Quais ativos mais geram suporte?
Chamados por modelo
Existe algum modelo com incidência muito acima da média?
Chamados por categoria
Hardware, software, acesso, conectividade, treinamento ou outro motivo?
Reincidência
O mesmo problema está voltando?
Chamados por área
Algum departamento concentra ocorrências?
Tempo de indisponibilidade
Quanto tempo o usuário fica impactado?
Idade dos equipamentos
Os chamados aumentam depois de determinado período?
O objetivo não é medir por medir.
É transformar ocorrências em decisões.
Um chamado encerrado ainda pode conter informação valiosa
Depois que o problema é resolvido, existe uma tendência natural de esquecê-lo.
Mas o registro daquela ocorrência continua sendo útil.
Imagine milhares de chamados acumulados ao longo de dois anos.
Ali pode existir uma fotografia extremamente rica da infraestrutura:
quais equipamentos mais falham;
quais áreas mais sofrem;
quais problemas se repetem;
quando as ocorrências aumentam;
quanto tempo se perde;
onde estão os maiores gargalos.
Sem análise, são apenas registros antigos.
Com análise, tornam-se inteligência operacional.
O suporte pode ser reativo ou preventivo
No modelo exclusivamente reativo:
problema → chamado → solução → encerramento.
No modelo mais maduro:
problema → chamado → solução → registro → análise de padrão → ação preventiva.
A diferença está no que acontece depois que o ticket é fechado.
Se um problema aparece uma vez, talvez seja apenas uma ocorrência.
Se aparece cinquenta vezes, provavelmente existe algo que merece atenção gerencial.
O objetivo não é reduzir chamados a qualquer custo
Também é importante fazer uma distinção.
Poucos chamados não significam automaticamente uma boa infraestrutura.
Em algumas empresas, usuários simplesmente deixam de abrir chamados.
Aprendem a conviver com problemas.
Reiniciam o notebook.
Improvisam soluções.
Utilizam equipamento próprio.
Esperam a lentidão passar.
Por isso, a análise precisa combinar números com a realidade da operação.
O objetivo não deveria ser apenas reduzir a quantidade de tickets.
Deveria ser reduzir problemas reais e recorrentes.
O chamado é um sintoma. A gestão procura a causa.
Quando um equipamento falha, o reparo é necessário.
Quando muitos equipamentos falham da mesma forma, a pergunta muda.
Por quê?
Foi a compra?
Foi a configuração?
Foi a idade?
Foi a infraestrutura?
Foi o processo?
Foi falta de treinamento?
Essa investigação transforma o suporte em uma fonte de melhoria contínua.
Talvez os chamados que hoje parecem apenas trabalho acumulado já estejam dizendo exatamente onde a empresa deveria melhorar sua tecnologia.
A WSL auxilia empresas na manutenção de notebooks corporativos e na identificação de padrões de ocorrências que podem indicar necessidade de reparo, upgrade, substituição ou revisão do parque tecnológico.
Um chamado informa o problema de hoje.
O histórico de chamados pode ajudar a evitar os problemas de amanhã.
