Os pedidos raramente chegam como formulário. Chegam como emails, mensagens e notas de chamada, e alguém tem de ler cada um, perceber o que é, confrontá-lo com as regras, e responder. Um sistema bem construído faz essa primeira passagem: o modelo lê o texto livre para campos estruturados, as regras fazem a triagem, e uma pessoa fica com as decisões que têm peso. A leitura e a triagem deixam de consumir o dia; o juízo continua humano. Aqui fica como construir triagem em que uma equipa confia.
O trabalho que enche uma caixa de entrada
Em muitos negócios, uma fila de pedidos que chegam consome o tempo de pessoas experientes. Cada um tem de ser lido, compreendido, confrontado com o que o negócio pode e quer fazer, e respondido ou encaminhado. É repetitivo, é de volume alto, e é onde as coisas se perdem: o pedido que ficou à espera de um único dado em falta, o que nunca ia encaixar e ainda assim consumiu uma semana de idas e voltas.
O formato deste trabalho faz dele um candidato forte para um sistema, com uma condição: o sistema lê e redige, e a decisão continua governada por regras explícitas e por um humano. Entregar o juízo a um modelo dá uma inconsistência que não se consegue defender. Manter o juízo em regras dá um sistema rápido na leitura e firme na decisão.
Os três passos de um sistema de triagem
Extrair: transformar texto livre num pedido estruturado
O modelo lê a mensagem que chega e preenche um registo estruturado: de quem vem, o que quer, os detalhes que importam para a decisão. Tudo o que não está no texto é marcado como em falta em vez de adivinhado, porque um valor inventado plausível é pior do que um espaço em branco. Esse registo estruturado é o que as regras conseguem depois usar.
Triar: confrontar o registo com regras explícitas
O pedido estruturado é confrontado com os critérios do próprio negócio, cada um uma condição explícita: um limiar, uma categoria excluída, um detalhe obrigatório. Quando as condições de uma regra se verificam todas, ela dispara. Esta é a parte que não pode ficar com o modelo, porque o negócio precisa de que o mesmo pedido produza a mesma decisão de cada vez, e precisa de explicar porquê quando lhe perguntam.
Responder: redigir a resposta certa para o resultado
Consoante a regra que disparou, o sistema prepara a resposta: um email para quem pediu, uma nota interna para quem tem de agir. A pessoa revê e envia, em vez de compor de raiz. A redação está feita; o envio continua uma escolha humana.
Um exemplo real: uma mesa de subscrição
Construímos isto para uma corretora de seguros comerciais, descrito em termos gerais porque o cliente fica anónimo. Um pedido de seguro comercial chega como texto livre, e uma pessoa experiente tem de o ler, perceber o risco, confrontá-lo com os critérios acordados com as seguradoras, e responder. O sistema faz a primeira passagem, e os resultados encaixam de forma limpa em alguns casos.
Quando falta informação, o pedido é legítimo mas incompleto. O sistema identifica exatamente o que falta e redige um email a pedir esses elementos, um por linha, sem promessas de preço ou de aceitação. É o caso mais frequente e mais caro de tratar à mão, e a resposta sai agora no próprio dia em vez de o pedido ficar à espera até alguém ter tempo.
Quando a atividade está fora de apetite, o pedido é declinado com clareza, com oferta de encaminhamento para outro lado. Não são pedidos dados adicionais, porque fazer alguém reunir documentos para um “não” desperdiça o tempo dessa pessoa e da corretora. Quem pediu recebe uma resposta rápida e fundamentada em vez de silêncio, o que preserva a relação para o pedido seguinte.
Quando o risco é bom mas excede o limite de aceitação automática, segue para um subscritor humano com uma nota telegráfica do que há a decidir. O subscritor deixa de ler emails de três páginas para extrair quatro números, e recebe o risco já estruturado, sabendo de imediato porque é que lhe chegou. E quando nada dispara, o pedido está dentro dos limites e completo, por isso avança direto para o passo seguinte em vez de se perder entre os que precisam de análise.
Porque as regras têm de decidir, e não o modelo
O princípio único que faz isto funcionar é que as regras decidem e o modelo só lê e escreve. A decisão, aceitar, declinar, referir, pedir, sai de uma tabela de critérios em código, auditável e editável. Isto importa por três razões concretas. É defensável: quando um pedido é recusado e alguém pergunta porquê, há uma regra com nome e condições, não “a AI achou”. É consistente: o mesmo pedido produz a mesma decisão seja quem for a enviá-lo ou como o escreva. E é controlável: o negócio é dono dos critérios e altera um limiar ou acrescenta uma exclusão sozinho, sem um programador, o que importa porque esses limiares mudam à medida que os acordos mudam.
Tratar os casos incómodos
Dois detalhes práticos separam um sistema que sobrevive ao contacto com a realidade de um que não sobrevive. Primeiro, o idioma. Quando os pedidos chegam em mais do que uma língua, normalizar os dados extraídos para uma única língua para as regras funcionarem seja qual for a origem, e escrever a resposta na língua que o gestor escolher. Um único conjunto de critérios serve então todos os que pedem, em vez de manter regras duplicadas em paralelo.
Segundo, critérios editáveis. Os limiares e as exclusões mudam à medida que os acordos do negócio mudam. Se cada alteração precisasse de um programador, o sistema desatualizava-se em meses e deixava de ser usado em silêncio. Os critérios têm de viver num sítio que o negócio consiga editar diretamente, com a triagem a recalcular de imediato.
Como é o bom resultado
Um sistema de triagem está a funcionar quando a leitura e a triagem deixam de consumir pessoas experientes, os pedidos que precisam de decisão ficam separados de forma limpa dos que não precisam, e cada resultado se explica por uma regra. A medida é quanto do fluxo que entra é tratado sem uma pessoa a fazer a leitura repetitiva, enquanto as decisões com consequências continuam a passar por mãos humanas. É o mesmo padrão de o modelo lê e as regras decidem que está por trás dos nossos outros sistemas, exposto em sistemas de AI que fazem o trabalho repetitivo do negócio.
Perguntas frequentes
O que é a triagem de pedidos com AI?
Um sistema que lê os pedidos em texto livre que chegam, estrutura-os, confronta-os com as regras do negócio, e redige a resposta certa, enquanto uma pessoa fica com as decisões que importam. O modelo lê e escreve; regras explícitas fazem a triagem.
Deve a AI decidir como tratar cada pedido?
Não. O modelo lê o pedido e redige respostas, mas a decisão, aceitar, declinar, referir, pedir mais, sai de regras explícitas em código. Isso mantém os resultados consistentes e explicáveis, e deixa o negócio alterar uma regra sem um programador.
O que acontece aos pedidos sobre os quais o sistema tem dúvidas?
São encaminhados para uma pessoa, com o pedido já estruturado e o motivo pelo qual precisa de um humano em anexo. O sistema nunca força uma decisão quando uma regra não dispara com clareza ou falta informação.
Consegue tratar pedidos em línguas diferentes?
Sim. A extração normaliza os dados para uma língua para um único conjunto de regras funcionar seja qual for a origem, e a resposta é escrita na língua que o gestor escolher.
Uma caixa de entrada de pedidos a consumir a equipa?
A triagem é muitas vezes um sítio claro e de volume alto para um primeiro sistema. Numa sessão de estratégia, vemos o que entra e quanto se poderia tratar automaticamente.
