Chega uma notificação: um utilizador não consegue iniciar sessão, uma impressora não funciona, um servidor apresenta erros. Alguém no serviço de assistência transforma isso num ticket, escolhe uma categoria e determina a urgência. Pode a IA assumir isso? Em grande parte sim, com uma excepção importante que varia de empresa para empresa.
Três eixos são decisivos: volume, margem de julgamento e contacto com o cliente.
O volume é elevado. Um serviço de assistência processa diariamente dezenas a centenas de notificações, e muitas delas são variações de um pequeno número de problemas conhecidos: palavra-passe esquecida, sem acesso a uma partilha, o portátil não arranca. Com volumes elevados e repetição, uma tarefa é, por definição, adequada para automatizar, porque um modelo aprende a partir de padrões que se repetem com frequência.
A margem de julgamento é limitada. A urgência e a categoria resultam geralmente de uma árvore de decisão: quantos utilizadores são afectados, existe uma solução alternativa, de que sistema se trata. É exactamente o tipo de trabalho em que os modelos de texto são bons: ler uma notificação, extrair as características e cruzá-las com um modelo de categorização. O que a IA consegue lidar hoje é texto — as próprias notificações, muitas vezes escritas em linguagem livre pelo utilizador, e a sua tradução de volta para um ticket estruturado.
O contacto com o cliente é funcional, não relacional. Um utilizador que comunica uma avaria quer sobretudo que o problema seja resolvido, não que se inicie uma conversa. Isso é diferente quando algo corre mal ou se torna sensível — veja também como a comunicação de uma avaria aos utilizadores é tratada, pois trata-se de uma tarefa diferente com um perfil diferente.
A componente física não desempenha qualquer papel: trata-se de trabalho administrativo num ecrã, não de uma acção sobre equipamento. Os custos de erro são médios. Uma notificação mal priorizada raramente causa dano directo, mas em sistemas sujeitos a compliance — um sistema financeiro, um processo clínico — isso é diferente, e o eixo compliance obtém aqui uma pontuação superior à média. Uma avaria num ambiente com obrigação legal de notificação exige um motivo registado para a classificação, não apenas uma etiqueta.
O ponto fraco é a criatividade, e é exactamente por isso que não se trata de uma substituição integral. Uma notificação que não se encaixa no padrão conhecido — uma combinação nova de sintomas, um sistema que falha por primeira vez, um utilizador que descreve o problema de forma pouco clara — exige alguém que pense em vez de classificar. Isso implica supervisão: a IA propõe uma categoria e uma urgência, uma pessoa aprova ou corrige, com fundamento. Trata-se de uma configuração diferente da substituição integral, e é também a prática mais comum entre as empresas que já trabalham com isto.
Numa empresa com um panorama de aplicações pequeno e claro e algumas centenas de utilizadores, noventa por cento das notificações são repetições de algo que já ocorreu cem vezes. Nesse caso, um modelo com um bom modelo de categorização pode tratar de forma autónoma a maior parte da entrada, com uma pessoa a ver apenas as excepções.
Numa empresa com muitos sistemas legados, software à medida e um historial de fusões, o padrão é menos previsível. As notificações são mais diversas, as categorias estão menos bem definidas, e a probabilidade de uma notificação sair do padrão conhecido é maior. Nesse caso, uma parte maior do trabalho continua a caber a uma pessoa, não porque a IA não o quisesse fazer, mas porque a entrada é demasiado desestruturada para se transformar de forma automática em algo fiável.
A condição determinante não é, portanto, a tecnologia, mas a entrada: formulários de admissão estruturados e um modelo de categorização de incidentes bem desenvolvido determinam em grande medida quanto deste trabalho já é hoje transferível. Sem esses dois elementos, a maior parte continua a ser trabalho manual, com a IA como ferramenta de apoio em vez de executante.
Isto não é aconselhamento em matéria de pessoal nem uma justificação para reduzir uma equipa de serviço de assistência. Se e como uma organização retira consequências para o pessoal a partir da alteração do trabalho é uma decisão do empregador, e para isso aplicam-se requisitos legais próprios; para o rigor que isso exige, veja os pontos de atenção na eliminação de funções. Esta página descreve apenas o que acontece com a tarefa em si.
É também útil não isolar esta tarefa do resto da operação de TI. O registo de incidentes está relacionado com trabalho como a monitorização do desempenho dos sistemas, que muitas vezes dá os sinais iniciais antes de existir uma notificação, e com tarefas de gestão como a execução e verificação de cópias de segurança ou a manutenção da actualidade dos dados-mestre, que partilham a mesma combinação de volume elevado e margem de julgamento limitada. Quem quiser saber, para todo o departamento de TI, onde já está a ocorrer a transição, faz melhor em olhar para todas as tarefas em conjunto, e não apenas para um processo de tickets.
O resultado para o seu próprio serviço de assistência depende de quanto das suas notificações se encaixam em padrões reconhecíveis e de quão bem estruturada já está a sua admissão. Isso varia de empresa para empresa e não se pode determinar com uma regra fixa.
O teste rápido e gratuito da FTE TO AI dá uma primeira indicação disso: doze perguntas, sem necessidade de conta, com uma indicação de que parte das horas no seu perfil pode hoje ser assumida pela IA. O teste de trabalho completo, que calcula o trabalho de uma empresa inteira, tarefa a tarefa, em capacidade de fte, está ainda em desenvolvimento.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.