Registar uma conversa parece um passo pequeno. Alguém liga, escreve, envia um e-mail — e o sistema memoriza o que foi dito e garante que algo seja feito com isso. Por debaixo da janela de chat ou da transcrição, no entanto, existe um conjunto de condições que muitas vezes só se torna visível quando o projeto-piloto encalha. Esta página descreve o que isso exige concretamente, não se a sua organização vai conseguir.
Registar uma conversa significa que a fala ou o texto são convertidos num registo: quem disse o quê, quando e com que motivo. Acompanhar significa que desse registo resulta uma ação — cria-se uma tarefa, um estado muda, alguém recebe um sinal. Trata-se de uma cadeia: registar, interpretar, encaminhar, executar. Cada elo tem o seu próprio requisito. A interpretação precisa de saber quais os campos relevantes. O encaminhamento precisa de saber quem é responsável por quê. A execução tem de ter um destino — um sistema que também consiga processar essa ação. A forma exata como estes passos se sucedem e onde encalham está descrita em cadeias em que os passos se sucedem.
Antes de um sistema poder registar uma conversa de forma útil, a própria organização tem de ter definido o que é relevante nessa conversa. Trata-se de uma reclamação, um pedido, uma alteração, uma pergunta que não leva a nada? Se essa classificação não existir, ou se cada departamento aplicar uma versão diferente, não é possível registar nada de forma consistente. Trata-se de uma questão organizacional, não de um problema técnico: envolve papéis, responsabilidades e a questão de quem determina o que é um tratamento correto. Sem esses acordos, o sistema até regista algo, mas não algo sobre o qual se possa atuar.
Registar sem acompanhar é um arquivo. Acompanhar exige que a conversa chegue a um sistema capaz de iniciar uma ação — um ticket, uma tarefa, uma alteração num processo. Isso exige uma ligação entre o local onde a conversa ocorre e os sistemas onde o trabalho continua. Se essa ligação não existir, o resultado da conversa é transcrito manualmente, e nesse caso pouco se ganha. Antes de registar e acompanhar funcionarem em conjunto, é preciso, portanto, existir uma infraestrutura capaz de mover mensagens, estados e registos entre sistemas — não como uma integração pontual para um único processo, mas como uma capacidade reutilizável.
Uma conversa registada só é utilizável se os dados que contém — um nome, um número de processo, uma data — corresponderem ao que já é conhecido. Se esses dados não estiverem registados de forma inequívoca, ou se existirem várias versões do mesmo cliente ou do mesmo processo, surge um acompanhamento iniciado com base na ligação errada. Isto não é uma questão de um modelo melhor, mas de gestão de dados organizada previamente: identificação inequívoca, uma fonte de verdade estabelecida e uma forma de sinalizar desvios antes de estes se refletirem numa ação. Onde essa sinalização exige, ela própria, uma camada separada, é explicado em monitorização e sinalização.
Acompanhar não é sempre seguir uma regra fixa. Frequentemente, é necessário fazer uma ponderação em algum ponto da cadeia: esta conversa é urgente, deve ser escalada, encaixa numa categoria existente ou não? Essa ponderação pode ser apoiada, mas então tem de estar previamente claro que informação é necessária para essa ponderação e quem pode ajustar o resultado. O que é e não é possível nesse âmbito está descrito em apoio à decisão. Sem essa preparação, a ponderação continua a caber a uma pessoa, o que em si não é um problema — só se torna um problema quando ninguém estabeleceu que essa é a intenção.
Um piloto para registar conversas funciona muitas vezes dentro de uma única equipa, com uma única linha telefónica ou uma única caixa de entrada, e parece funcionar. Assim que o processo é alargado, verifica-se que os pressupostos desse piloto não se aplicam em todo o lado: outros sistemas, outras definições, outros responsáveis. Por que motivo um piloto que apenas funciona no seu próprio cantinho raramente traz benefícios para o resto da organização está desenvolvido em pilotos que não vão além do seu próprio canto. E se, após o piloto, ninguém for proprietário do próprio acompanhamento, a iniciativa desaparece assim que a atenção se desloca — ver também demonstrações sem proprietário.
Quando o registo e o acompanhamento estão bem alinhados, cada conversa é rastreável e cada ação remonta ao motivo que a originou. Trata-se de uma condição para tranquilidade no processo, não de uma garantia de rapidez ou de menos trabalho. Se o registo de conversas também pode ser executado por um sistema que toma a ação por si próprio depende de como essa execução está organizada — ver agentes que executam trabalho.
Esta página descreve o que o registo e o acompanhamento de conversas exigem para poderem funcionar. Outra questão é que parte desse trabalho pode efetivamente ser assumida pela IA, e que parte permanece a cargo de pessoas. Essa questão é respondida pela werkscan da FTE TO AI, que calcula, por tarefa, que parte do trabalho pode ser transferida e que parte não pode.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.