Monitorizar tickets de serviço quanto a atraso iminente é uma tarefa que a IA, em essência, pode assumir por completo. Não se trata aqui de uma zona cinzenta com supervisão humana incluída: a própria sinalização é uma tarefa que hoje já é possível automatizar com tecnologia existente (rpa), desde que algumas condições prévias estejam em ordem.
Três eixos são aqui decisivos: estruturação, volume e margem de julgamento. Todos os três apontam na mesma direção.
Estruturação (5 de 5). A tarefa consiste em comparar uma data com uma regra: há quanto tempo um ticket está aberto e quando termina o prazo de atendimento acordado? Isto não é interpretação, é cálculo. Um sistema de tickets regista a hora de abertura, o prazo de SLA está previamente estabelecido, e o único necessário é uma comparação entre dois números. Assim que esses prazos de SLA estejam definidos de forma inequívoca, não há espaço para dúvidas sobre o que significa "iminente".
Volume (5 de 5). Uma equipa de atendimento ao cliente processa normalmente dezenas a centenas de tickets por dia, cada um com o seu próprio relógio a decorrer. Um chefe de equipa que faça isto manualmente tem de percorrer constantemente uma lista e fazer contas. É precisamente o tipo de trabalho repetitivo e volumoso do qual o software não se cansa e no qual não perde tickets de vista.
Margem de julgamento (4 de 5). A própria sinalização exige quase nenhum julgamento: o prazo é o prazo. Há uma pequena margem porque algumas organizações têm nuances (por exemplo: o tempo de espera do lado do cliente conta ou não para o relógio do SLA), mas assim que essas regras estejam estabelecidas, já não há espaço para interpretação na própria sinalização.
Os restantes eixos são aqui praticamente irrelevantes para a questão central. O contacto com o cliente e as ações físicas não desempenham papel nesta tarefa: trata-se de um processo em segundo plano, não de uma conversa com um cliente. A criatividade não está em causa: não há uma nova solução a conceber, apenas um prazo a vigiar. Os custos de erro e a conformidade têm uma pontuação média (3), não porque a própria sinalização seja arriscada, mas porque um alerta omitido ou incorreto pode repercutir-se na satisfação do cliente ou em acordos contratuais. Isto não desaconselha a automatização, mas exige uma configuração correta à partida.
A tecnologia adequada aqui é relativamente modesta: automatização robótica de processos (rpa). Não é necessário um modelo de linguagem ou IA complexa para comparar uma data com uma regra. Um script que lê periodicamente o sistema de tickets, calcula o tempo restante até ao prazo do SLA e, ao atingir um limite pré-definido, envia um alerta ao chefe de equipa, faz o trabalho. Isto pode ser feito por e-mail, widget de painel ou notificação no próprio sistema de tickets.
As condições prévias são simples mas essenciais: os prazos de SLA têm de estar definidos de forma clara e inequívoca, e a sinalização tem de estar tecnicamente configurada com base nesses prazos. Se faltar uma destas condições, a automatização não funciona bem — não porque a tarefa seja inadequada, mas porque a base não está correta.
Este resultado aplica-se à sinalização. Não se aplica automaticamente ao que acontece após o alerta. Numa organização onde a escalada de um atraso iminente desencadeia imediatamente uma ação fixa e previsível (por exemplo: o ticket é automaticamente encaminhado para um especialista), também esse passo seguinte pode ser largamente automatizado. Numa organização onde a escalada depende da relação com o cliente, do tipo de contrato ou de sensibilidade política, esse passo seguinte continua a ser trabalho humano — aí, supervisão humana sobre a IA, em concreto é um ponto de partida relevante.
Também a definição de "prazo de SLA" varia por organização. Uma empresa com um prazo de atendimento único e simples tem uma questão de automatização mais simples do que uma empresa com dezenas de variantes contratuais, níveis de prioridade e regras de excepção. Quanto mais complexo esse conjunto de regras, mais trabalho preparatório é necessário antes de a sinalização poder funcionar de forma automática e fiável. É precisamente por isso que é necessária uma análise por tarefa, e não por função: o mesmo cargo de "chefe de equipa de atendimento ao cliente" pode, numa empresa, ter uma tarefa de sinalização largamente automatizável, e noutra, uma tarefa que ainda exige, em grande parte, trabalho manual.
Esta página descreve uma tarefa, não uma decisão de pessoal. Se e como a capacidade libertada numa equipa é redistribuída é uma escolha que compete à própria organização e para a qual se aplicam requisitos legais próprios, especialmente se tiver consequências para funções ou quadro de pessoal. O cuidado necessário nesse processo, incluindo informar os órgãos de participação dos trabalhadores, é um percurso separado — veja, por exemplo, informar o conselho de trabalhadores sobre IA e rigor ao eliminar funções. Esta página não fornece fundamentação para isso, apenas factos sobre a própria tarefa.
A sinalização de atraso iminente de SLA não existe isoladamente. Tarefas de monitorização e sinalização semelhantes também ocorrem em processos financeiros, como a faturação periódica de subscrições ou a troca de faturas digitais através de faturação eletrónica. Também aí se aplica: quanto mais estruturadas as regras e quanto maior o volume, mais adequada é a tarefa para automatização.
Quer saber como isto se aplica à sua própria equipa, incluindo a estrutura exata de SLA e o volume de tickets com que trabalha? O quickscan gratuito da ftetoai consiste em doze perguntas, pode ser feito sem conta, e dá uma indicação de que parte das horas no seu perfil pode hoje ser assumida pela IA. A análise de trabalho completa, que aprofunda ao nível da tarefa nos seus próprios processos, ainda está em construção — essa promessa não a fazemos aqui maior do que realmente é.
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.