Automatizar comunicação interna sem perder contexto

São 9h14. No canal geral de uma empresa de trinta pessoas aparece a mensagem de sempre: «Novo formulário submetido». Sem nome, sem valor, sem prazo, sem indicação de quem tem de decidir o quê. Para saber se aquilo lhe diz respeito, cada pessoa teria de abrir o portal. Quase ninguém abre.

A automatização funcionou. A comunicação não.

Ligar um formulário ao Slack ou ao Microsoft Teams é trabalho de dez minutos. O que distingue automatizar comunicação interna de simplesmente gerar mais uma fonte de ruído é o contexto que a mensagem transporta — e essa parte não vem de origem em ferramenta nenhuma.

Automatizar comunicação interna começa pelo ruído que já existe

Antes de acrescentar mensagens ao dia da equipa, vale a pena olhar para o que lá está.

A Microsoft analisou sinais agregados de utilização do Microsoft 365 e publicou os resultados em Breaking down the infinite workday. Um trabalhador médio é interrompido de dois em dois minutos durante o horário de trabalho, por reunião, e-mail ou notificação. Recebe 153 mensagens de Teams por dia útil e 117 e-mails, a maioria dos quais lidos na diagonal em menos de 60 segundos. Quase metade — 48% — descreve o próprio trabalho como caótico e fragmentado.

São números de grandes organizações, não de PME portuguesas. Mas a direção é a mesma, e a implicação é simples: a atenção da sua equipa já está toda distribuída. Uma automatização que despeja mais dez mensagens por dia neste ambiente não é neutra. Compete por atenção com tudo o resto, e costuma perder.

A regra que a Google usa para alertas serve para isto

A engenharia de fiabilidade da Google enfrentou este problema há muito, com alertas de sistemas. O capítulo sobre monitorização do Site Reliability Engineering book diz duas coisas que se aplicam inteiras à comunicação interna.

A primeira é o diagnóstico:

Quando os alertas ocorrem com demasiada frequência, as pessoas questionam, leem na diagonal ou ignoram os alertas que chegam — por vezes ignorando até um alerta real, mascarado pelo ruído.

A segunda é a regra que daí decorre: se um alerta apenas merece uma resposta robótica, não devia ser um alerta.

Aplicada a uma notificação interna, a pergunta fica desconfortavelmente clara. Se a resposta a esta mensagem é sempre «abrir o portal e ir ver», a mensagem não está a comunicar nada. Está a distribuir trabalho.

O que é, ao certo, o contexto de uma mensagem

Contexto não é escrever mais. É incluir exatamente o que a decisão exige, e nada além disso. Na prática, são quatro coisas.

O que aconteceu, em linguagem de negócio e não de sistema. «Requisição de compra de 2 400 €» diz mais do que «Registo 4471 criado».
A quem diz respeito. Uma menção direta a uma pessoa ou a um grupo pequeno, não um canal com sessenta membros onde a responsabilidade se dilui.
Os dados que a decisão exige. Fornecedor, valor, rubrica orçamental, saldo restante, quem pediu. Se o decisor tiver de ir procurar um destes campos, a mensagem falhou.
A ação possível ali mesmo. Um botão de aprovar ou recusar, ou uma resposta em texto que o fluxo consiga interpretar.

O quarto ponto é o que a maioria das automatizações não faz. É também o que separa uma notificação de uma decisão.

Um exemplo com números: aprovar uma requisição sem sair do Teams

Considere um circuito de aprovação de compras numa empresa de serviços com 40 pessoas. O desenho do circuito em si — quem aprova o quê, com que limites e em quantos passos — é outra conversa, e já a tivemos ao escrever sobre como encurtar ciclos de decisão com automação de aprovações. Aqui interessa apenas a mensagem.

Antes: o pedido entra por formulário, o sistema publica «Nova requisição pendente» num canal, o responsável abre o portal, autentica-se, procura o registo, verifica o histórico do fornecedor e o saldo da rubrica, decide, e regressa ao que estava a fazer.

Depois: a mensagem chega em privado ao responsável certo, com o fornecedor, o valor, a rubrica, o saldo restante e as três últimas compras ao mesmo fornecedor. E com dois botões.

O ganho não está no tempo de decidir. Está no tempo de reconstruir contexto. Estimativa própria, com o cálculo à vista: 30 aprovações por semana, três minutos poupados em cada uma, 45 semanas úteis por ano. Dá cerca de 67 horas por ano, só neste circuito. Não é um dado de estudo, é aritmética sobre pressupostos que pode substituir pelos da sua empresa. Para converter horas em euros com um método defensável, escrevemos sobre como calcular o custo real de um processo manual.

Repare no que fica de fora da conta: o ato de decidir em si, que não muda. O que desaparece é a viagem até ao contexto.

O que isto exige na prática, e onde costuma falhar

No n8n, este padrão tem um nome próprio: a operação Send and Wait for Response, disponível nos nós de Slack, Microsoft Teams, Gmail, Telegram e outros. O fluxo envia a mensagem e fica em pausa até alguém responder. Aceita três formatos de resposta: aprovação por botão, texto livre ou um formulário próprio.

A documentação oficial das aprovações no Slack é honesta quanto aos requisitos, e vale a pena conhecê-los antes de prometer isto a alguém.

A instância de n8n tem de estar acessível publicamente por HTTPS. Uma instalação em rede local não recebe as respostas do Slack.
O URL de callback é um só por instância, partilhado por todos os fluxos. Isso implica uma aplicação de Slack por instância de n8n, não uma por departamento.
Sem o signing secret configurado na credencial, os botões aparecem na mensagem e não acontece rigorosamente nada quando alguém carrega. É a falha mais desagradável das quatro, porque é silenciosa: para quem está a testar, parece que está a funcionar.
Para registar quem respondeu, a aplicação precisa da permissão de leitura do e-mail dos utilizadores. Sem ela, o campo vem vazio e fica sem rasto de quem aprovou.

Há ainda um detalhe fácil de esquecer nas mensagens formatadas com blocos: mesmo quando o conteúdo visível vem dos blocos, o campo de texto simples continua a ser necessário. É ele que aparece na pré-visualização da notificação no telemóvel e nos leitores de ecrã. Deixá-lo vazio é enviar um aviso que, no momento em que interrompe alguém, não diz nada.

A IA escreve a mensagem, não apura os factos

É tentador pedir a um modelo de linguagem que resuma a conversa e componha a notificação. Funciona bem para a parte narrativa: transformar um fio de vinte mensagens em três linhas legíveis, ou traduzir jargão de sistema em português corrente.

Não funciona para os números. Um resumo que troque 2 400 € por 2 040 €, ou que deixe cair o prazo, é pior do que resumo nenhum. A mensagem ganha a credibilidade de um texto bem escrito e perde-a exatamente onde a decisão assenta.

A regra prática é separar as duas responsabilidades. Os campos que sustentam a decisão — valores, datas, identificadores, nomes — vêm diretamente do sistema de origem, por expressão, sem passar pelo modelo. O modelo só toca na prosa. É a mesma lógica de supervisão que descrevemos a propósito da IA generativa no back-office e das tarefas onde o controlo humano continua essencial, e vale a pena não a diluir só porque desta vez o resultado é uma mensagem curta.

Comece pela notificação que a equipa mais ignora

Quase todos os projetos de comunicação interna automatizada começam pelo lado errado: pela mensagem que é mais fácil de construir. Não há grande mérito em desenhar o fluxo perfeito para uma mensagem que ninguém queria receber.

Faça o inverso. Escolha a notificação automática que a sua equipa mais ignora e pergunte a quem a recebe o que faz com ela. Se ninguém conseguir justificar a existência dela, desligue-a. É a automatização mais barata que vai fazer este mês, e a única que reduz ruído sem construir seja o que for.

Se a mensagem for mesmo necessária, a pergunta seguinte é concreta: que três dados teriam de estar nela para que a decisão não exigisse abrir mais nada? Automatizar comunicação interna sem perder contexto é, quase sempre, este exercício repetido processo a processo, e não um projeto com data de fim.

Uma última nota, porque vai encontrá-lo em todo o lado quando pesquisar sobre isto: o número dos «23 minutos para recuperar de uma interrupção» circula como se viesse de um estudo revisto por pares. Não vem. Aparece em entrevistas da investigadora Gloria Mark e foi repetido até virar facto adquirido, mas os artigos habitualmente citados como fonte não contêm essa medição. Se está a construir um caso interno para reduzir interrupções, use os dados da Microsoft, que são verificáveis, e deixe os 23 minutos de fora. Um argumento sólido não precisa do número que toda a gente repete sem ter lido.