Quase toda a automação documental é vendida como o meio de um processo e entregue como o meio de um processo. O ficheiro já está no sistema, alguém já decidiu o que ele é, e a parte inteligente lê-o. Isso deixa as duas pontas — pôr lá dentro, e fazer alguma coisa a partir daí — exactamente onde estavam: com uma pessoa, uma caixa de correio, e o ecrã de login de outro sistema.
Isto é a coisa inteira, com um caso que uma seguradora reconhece.
09:14 — chega um e-mail
Um tomador escreve para o endereço de sinistros. Três fotografias de um pára-choques, uma fotografia do cartão de seguro do outro condutor, e duas linhas de texto.
Nada naquele e-mail diz a que apólice pertence, que tipo de sinistro é, ou o que mais vai ser preciso. É, nas palavras do próprio sistema, um ficheiro que chegou sem destino.
Isso aqui tem nome, não é um buraco: um documento de entrada, com referência própria
(IN-2026-004182), estado próprio, e registo de onde veio — o canal, e o identificador que o remetente
deu à entrega. Um e-mail com três anexos torna-se três documentos de entrada que partilham esse
message-id e diferem no hash do conteúdo, que é exactamente o que permite a um conector de correio
repetir a entrega sem criar duplicados. A idempotência não é uma funcionalidade que se note; é a razão
pela qual ninguém tem de limpar o que ficou de uma repetição.
O que não é: um caso estacionado num estado «Novo» a servir de sala de espera. A distinção parece académica até se tentar medir — uma fila de coisas que talvez sejam trabalho, misturada com uma fila de coisas que são de certeza, é uma fila que ninguém consegue medir.
09:14 — o sistema propõe um destino
A extracção lê as fotografias e o cartão: uma matrícula, um número de apólice, uma data, um local. Faz corresponder a uma apólice existente e propõe um processo — sinistro automóvel, terceiros — e um dossiê.
Uma pessoa só aparece quando a máquina não tem confiança suficiente. É esse o desenho, e é o contrário do arranjo habitual em que uma pessoa aprova todas as decisões automáticas com o fundamento de que uma delas pode estar errada. A confiança é um número que o sistema tem; usá-lo para decidir quem olha é o que torna o volume comportável.
09:15 — o dossiê nasce a saber do que precisa
O processo prescreve o que uma participação completa contém: fotografias dos danos, dados da outra parte, declaração assinada, orçamento de reparação. Quando o dossiê é criado, esses requisitos são copiados para dentro dele, de modo que o próprio caso sabe dizer o que lhe falta.
Dois dos quatro já estão satisfeitos pelo que veio no e-mail. Dois não.
É neste momento que a maioria das automações se transforma discretamente numa lista de tarefas. Aqui é um estado: o dossiê está incompleto, diz quais são os dois, e não avança até eles chegarem. Ninguém tem de se lembrar de ir ver.
09:16 — o que falta é pedido, e chega ao dossiê
O participante recebe uma ligação para o próprio dossiê, em vez de um e-mail a listar o que enviar. Abre-o, vê os dois itens em falta, e carrega cada um no sítio a que pertence. Sem conta, sem cadeia de anexos, sem nada para arquivar depois.
(Essa metade tem artigo próprio — ver «Envie o dossiê, não a lista de documentos».)
11:40 — o processo termina dando entrada da participação
Todos os requisitos satisfeitos, as aprovações registadas por ordem e contra o estado sobre o qual foram dadas, e o dossiê faz aquilo para que o exercício inteiro existia: chama o sistema de apólices.
Não é uma notificação. Não é uma exportação que alguém importa. Um processo pode carregar exactamente uma operação externa — zero ou uma, imposto por um índice único e não por convenção — e constrói a carga que a seguradora desenhou, chama a API dela com credenciais que vivem cifradas e nunca são legíveis a partir do dossiê, e depois espera.
A espera é a parte que costuma faltar. O sistema de apólices responde com um número de participação, e esse número volta para o dossiê. O caso fecha a carregar a referência que prova que o trabalho aconteceu, no sistema onde ele aconteceu de facto.
O que o tornou autónomo
Releia e repare no que está a fazer o trabalho. Não é a extracção — essa é a parte visível e a mais fácil de comprar. O que fez isto correr sem uma pessoa no meio é mais aborrecido:
- O documento pôde chegar sem destino, por isso nada tinha de existir antes dele.
- A entrega era idempotente, por isso repetir saiu de graça.
- O dossiê sabia o que era estar completo, por isso «o que falta» era uma consulta e não um juízo.
- A transição foi recusada enquanto estava incompleto, por isso nada avançou a meio.
- O processo era dono de uma operação externa, por isso o fim do fluxo foi trabalho e não uma pasta.
Tire qualquer uma delas e uma pessoa tem de se pôr no buraco que fica. É por isso que as automações que só são inteligentes no meio precisam de tantas pessoas como antes — o pessoal deixa de fazer o trabalho e passa a alimentar a máquina.
Os limites, ditos com honestidade
As fotografias continuam a ter de estar legíveis, e nenhum sistema lhe dirá se os danos nelas são compatíveis com a história contada. Um limiar de confiança demasiado alto manda tudo para uma pessoa e comprou-se uma fila; demasiado baixo e dá entrada de participações contra a apólice errada. E a chamada externa é tão fiável quanto a API do outro lado — razão pela qual a falha tem de ser um estado que o dossiê carrega, repetível e visível, e não uma excepção num log.
Nada disto é razão para não o fazer. São as partes a decidir deliberadamente, porque cada uma é o trabalho de alguém, e a automação não elimina esse trabalho. Passa-o para o princípio, onde é mais barato.