Um utilizador não consegue iniciar sessão, uma impressora não é encontrada, uma palavra-passe precisa de ser reiniciada. Estas são as participações que preenchem a maioria dos service desks: problemas conhecidos com um percurso de resolução fixo. A questão é se a IA consegue tratar de forma autónoma este tipo de incidente de TI de primeira linha. A resposta é, em grande medida, sim, com algumas condições que determinam exatamente qual a dimensão dessa parte.
Três eixos são aqui decisivos: volume, estrutura e contacto com o cliente.
O volume é elevado. Os incidentes de primeira linha são, por definição, repetitivos: o mesmo problema regressa em dezenas ou centenas de utilizadores. Onde há muitos casos semelhantes entre si, há muito tempo a ganhar ao automatizar um único método de trabalho em vez de tratar cada caso individualmente.
A estrutura é elevada. Um problema conhecido com um percurso de resolução fixo significa: se x, faça y. Reiniciar uma palavra-passe, reiniciar uma ligação de rede, atribuir novamente um direito de acesso — são passos que constam de uma base de conhecimento e que um sistema pode percorrer tão consistentemente como uma pessoa, muitas vezes de forma mais consistente.
O contacto com o cliente está presente, mas é de natureza limitada. O utilizador quer sobretudo que o problema desapareça, não necessariamente uma conversa longa. Uma conversa de chat ou uma sessão automatizada através de uma ferramenta de suporte remoto é suficiente para a maior parte destas participações. A situação é diferente com um utilizador irritado ou confuso, em que o tom e a paciência passam a ter influência — aí a tarefa desloca-se para o trabalho humano.
A margem de apreciação obtém uma pontuação baixa: há pouca margem para determinar por si próprio qual é a abordagem correta, pois esta já está definida. É precisamente por isso que a IA vai mais longe aqui do que em tarefas com muita margem de interpretação. A criatividade também obtém uma pontuação baixa, o que neste caso é uma vantagem para a automatização: não é preciso inventar nada de novo, apenas executar um passo já existente.
A intervenção física normalmente não é necessária — daí a pontuação de 4 — excepto quando o problema está, de facto, relacionado com o próprio hardware: um cabo, um interruptor, uma peça a substituir fisicamente. Nesse caso, o percurso automatizado bloqueia e é necessário um técnico.
Os custos de erro e a conformidade obtêm ambos uma pontuação relativamente favorável, com um 4. Uma reinicialização de palavra-passe efetuada de forma incorreta é normalmente fácil de corrigir e raramente constitui, por si só, um risco de conformidade. Isso pode ser diferente quando o incidente afeta o acesso a sistemas sensíveis ou a dados pessoais; nesse caso, aplicam-se requisitos específicos quanto a quem pode tomar que decisão, e isso depende dos procedimentos e da regulamentação próprios da organização, não de uma escolha de automatização.
A tarefa presta-se a um agente: um sistema que não se limita a aconselhar, mas também atua, por exemplo ajustando uma configuração ou reiniciando um serviço através de acesso remoto ao posto de trabalho. Isto é um passo além de um chatbot que se limita a dar explicações. A condição é uma base de conhecimento com passos de resolução claros e acesso remoto efetivo — sem estes dois elementos, fica-se pelo responder a perguntas de utilizadores sobre a utilização de software, o que é uma tarefa diferente e mais limitada do que resolver o próprio incidente.
Nas empresas onde isto já funciona hoje, há geralmente um aspeto em ordem: as participações já chegam estruturadas. Isto não é coincidência. Um incidente bem registado e priorizado antes de um agente começar a trabalhar nele dá a esse agente a informação correta para seguir imediatamente o percurso certo. Nas empresas onde a admissão ainda é desorganizada — participações por e-mail, telefone e chat lado a lado, sem categorização uniforme — isso tem primeiro de ser posto em ordem antes de a resolução poder decorrer automaticamente. Por isso o panorama varia de empresa para empresa: não porque a tecnologia seja diferente noutro sítio, mas porque o terreno de partida é diferente.
É também por isso que a mesma lógica subjacente — repetição, passos fixos, consulta limitada — leva, noutras partes de uma empresa, a um ritmo diferente de assunção. A execução e verificação de cópias de segurança segue um padrão semelhante de rotinas fixas, enquanto o trabalho com muitas excepções e apreciação se desloca mais lentamente.
A parte que permanece trabalho humano não é trivial: incidentes que não constam da base de conhecimento, utilizadores que precisam de mais do que uma solução técnica, e avarias em que é necessária intervenção física. Também a vigilância do limite — quando um agente precisamente não deve tratar um incidente por si próprio e deve encaminhá-lo — é uma responsabilidade humana, com supervisão que aprova ou rejeita com base em razões registadas. Isto não é um argumento contra a automatização do trabalho de primeira linha, mas uma indicação de onde está o limite hoje.
Saber se isto se aplica ao seu service desk depende de quão uniformes são as suas participações, quão completa é a sua base de conhecimento e que parte dos seus incidentes exige, de facto, intervenção física. Uma indicação disso é dada pela quickscan gratuita: doze perguntas, sem necessidade de conta, com uma indicação de que parte das horas neste perfil pode hoje ser assumida pela IA. O scan de trabalho completo, que decompõe o trabalho de uma empresa inteira em tarefas e as traduz, tarefa a tarefa, em capacidade de fte, está ainda em construção.
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.