Antes de automatizar: cinco perguntas para definir o problema

Antes de automatizar um processo, responda a cinco perguntas: o que precisa melhorar, quais dados estão disponíveis, como tratar falhas, como avaliar o resultado e quem será responsável pela operação. Essas respostas ajudam a definir um primeiro piloto e a escolher onde regras, integrações ou inteligência artificial fazem sentido.

Para quem é este guia: gestores e equipes que precisam organizar uma primeira iniciativa de automação. A aplicação abaixo é hipotética; não relata um projeto de cliente nem apresenta resultados comerciais da Syntech.

O exemplo que vai acompanhar a leitura

Imagine uma empresa de manutenção que recebe solicitações de orçamento por e-mail e formulário. Uma pessoa lê as mensagens, pede informações ausentes, copia dados para uma planilha e avisa a equipe responsável. O gestor percebe atrasos, mas ainda não sabe se o gargalo está na triagem, na definição do responsável ou na elaboração da proposta.

A intenção inicial é “colocar uma IA no atendimento”. Essa frase ainda não define uma entrega. Um recorte mais útil seria: organizar as solicitações recebidas pelo formulário, registrar cada uma com um protocolo e tornar visível quem deve dar a primeira resposta. A elaboração de preços e a aprovação de propostas ficam fora do piloto.

1. Qual decisão ou tarefa precisa melhorar?

Comece descrevendo um episódio concreto: de onde veio a solicitação, o que a equipe recebeu, quais ações executou e em que ponto houve espera ou retrabalho. Observe o percurso completo. Uma tarefa que parece demorada pode estar aguardando uma informação que outro setor ainda não forneceu.

Na empresa do exemplo, vale separar três situações: pedido sem dados suficientes, pedido completo sem responsável e pedido já encaminhado sem atualização de status. Cada uma exige uma intervenção diferente. Automatizar a cópia para a planilha resolve pouco se ninguém assumiu o atendimento.

Converse com quem executa o trabalho e compare o procedimento descrito com o que acontece de fato. Se pessoas diferentes entendem “atendido” de formas diferentes, a primeira melhoria pode ser combinar os estados do processo. A tecnologia deve implementar uma definição compartilhada.

2. Quais dados e sistemas participam — e onde a IA entra?

Faça um inventário pequeno, suficiente para o piloto. Para cada informação, registre sua origem, quem pode corrigi-la e onde ela deve ser mantida. Nome do solicitante, canal de retorno, tipo de serviço e descrição do pedido podem ser suficientes para a triagem; outros campos precisam de uma finalidade clara.

No exemplo, o formulário é a origem da solicitação e o registro central é a referência para o status. O e-mail serve para avisar a equipe. Uma caixa de entrada não deve funcionar como o único lugar onde se descobre se o pedido existe ou quem o assumiu.

A Anthropic distingue fluxos com caminhos definidos em código de agentes que escolhem dinamicamente seus próximos passos. O artigo recomenda começar pela solução mais simples que atende à necessidade. Essa distinção ajuda a perguntar se o trabalho exige interpretação ou apenas execução consistente de uma regra.

A Sequoia discute, em “Goldilocks” Agents, o equilíbrio entre flexibilidade e controle. É uma análise de 2024 sobre agentes, não uma garantia de desempenho atual. Nossa aplicação ao exemplo: uma sugestão de categoria pode ser flexível; permissões, registro do pedido e autorização comercial precisam de limites explícitos.

Se os dados necessários não estão disponíveis, se o sistema não oferece uma integração viável ou se não existe autorização para o acesso, o escopo precisa mudar. A presença de uma ferramenta de IA não elimina essas dependências.

3. O que acontece quando algo falha?

O caminho de sucesso é apenas parte do processo. Um pedido pode chegar duas vezes, a integração pode ficar indisponível e a notificação pode falhar depois que o registro já foi criado. Tratar todas essas situações como um único erro leva a respostas inadequadas.

Suponha que o sistema grave o pedido, mas não consiga confirmar a resposta ao formulário. Uma nova tentativa do solicitante pode criar outro registro. A Amazon Builders’ Library explica como a idempotência torna novas tentativas mais seguras: repetir uma solicitação deve evitar efeitos adicionais indevidos. Isso exige definir como reconhecer a mesma operação, e não apenas comparar nomes ou textos parecidos.

Para o piloto, diferencie pelo menos: informação inválida que precisa de correção; falha temporária que admite nova tentativa controlada; e situação ambígua que exige revisão. Registre o status, limite as tentativas e deixe uma pessoa responsável pela fila de pendências. Evite copiar dados desnecessários para logs de erro.

4. Como saberemos que a solução atende ao objetivo?

Separe duas perguntas: a solução funciona como foi especificada? E a mudança ajudou a operação? A primeira é verificada com testes de aceite; a segunda exige observação do trabalho antes e durante o piloto. Um registro correto no sistema não demonstra, sozinho, redução de espera ou aumento de vendas.

Antes de iniciar, combine o significado de cada evento: recebimento, validação, atribuição e primeira resposta. Defina também se a contagem considera horário corrido ou expediente. Sem esse acordo, dois relatórios podem produzir números diferentes para o mesmo atendimento.

Compare períodos e grupos com contexto semelhante sempre que possível. Uma semana com menos pedidos ou uma mudança na equipe pode alterar o tempo de resposta mesmo sem efeito da automação. Se a comparação não permitir separar esses fatores, descreva o resultado como indício, com a limitação correspondente.

O aceite técnico pode exigir que nenhum campo obrigatório se perca nos cenários combinados e que cada falha deixe um estado recuperável. Já a decisão de ampliar deve considerar o conjunto: espera, qualidade, custo de revisão e capacidade de manter a solução. As metas precisam ser acordadas a partir da linha de base, sem percentuais genéricos.

5. Quem vai operar, revisar e decidir a continuidade?

Nomeie o responsável pelo processo, quem acompanha pendências e quem pode mudar regras ou permissões. Em uma equipe pequena, a mesma pessoa pode exercer mais de uma função; ainda assim, precisa estar claro quem age quando a integração para ou uma classificação é contestada.

Se houver IA, reúna exemplos representativos, incluindo descrições incompletas, pedidos fora do escopo e mensagens ambíguas. Compare a sugestão com a decisão de quem conhece o trabalho. Uma resposta convincente pode estar errada; por isso o teste precisa avaliar a decisão e sua consequência, além da fluência do texto.

O AI Risk Management Framework do NIST oferece uma referência voluntária para incorporar riscos ao desenvolvimento e à avaliação de sistemas de IA. No piloto, isso pode se traduzir em registrar limitações conhecidas, responsáveis e condições de interrupção. Essas medidas são propostas de operação para o exemplo, não uma certificação.

Documente o suficiente para outra pessoa conseguir operar: onde consultar a fila, como corrigir um registro, como pausar a automação e como retomar o atendimento manual. Se a solução só funciona enquanto seu criador está disponível, essa dependência precisa entrar na decisão de expansão.

Checklist: avançar, ajustar ou adiar

Use as perguntas abaixo em uma reunião com quem executa e quem responde pelo processo. A lista organiza a decisão; não é uma pontuação automática de maturidade.

• Problema: conseguimos mostrar onde ocorre espera, erro ou retrabalho?
• Escopo: entrada, saída e decisões fora do piloto estão claras?
• Dados: sabemos a origem, o responsável e o acesso necessário?
• Exceções: dados ausentes, duplicidade e indisponibilidade têm tratamento definido?
• Aceite: há exemplos de sucesso e falha que a equipe consegue verificar?
• Mensuração: existe uma linha de base e uma definição compartilhada dos indicadores?
• Operação: alguém acompanha pendências e pode pausar o fluxo?
• Continuidade: está combinado o que justificaria ampliar, ajustar ou interromper?

Avançar: quando o recorte é testável, os acessos estão disponíveis e a equipe consegue acompanhar o piloto. Ajustar: quando existe um problema claro, mas faltam definições ou dados. Adiar: quando a intervenção ainda não tem responsável, não pode ser observada ou depende de permissões indisponíveis.

Uma boa primeira entrega torna o processo compreensível

Na empresa de manutenção, o primeiro ganho procurado é saber quais solicitações existem, em que situação estão e quem deve agir. A classificação por IA só merece entrar se resolver uma dificuldade que as regras e os dados disponíveis não atendem bem. A expansão vem depois de observar o piloto e entender seus limites.

Antes de contratar uma ferramenta, reúna uma amostra do trabalho, desenhe o percurso e responda às cinco perguntas. Esse material transforma uma conversa abstrata sobre tecnologia em uma decisão de engenharia que pode ser executada, testada e revisada.

Perguntas frequentes

Toda tarefa repetitiva deve ser automatizada?

Não necessariamente. A repetição indica um candidato, mas a decisão depende de o problema estar claro, de os dados estarem acessíveis e de haver alguém para acompanhar a operação. Às vezes, combinar os estados do processo ou ajustar um formulário resolve mais do que uma ferramenta nova.

Quando usar inteligência artificial em vez de regras?

Regras atendem bem quando o critério pode ser descrito com precisão, como conferir se um campo foi preenchido. A IA faz sentido quando o trabalho exige interpretar texto livre ou situações variadas — e, mesmo assim, com exemplos de avaliação e revisão humana nos pontos de maior impacto.

Qual deve ser o tamanho de um primeiro piloto?

Pequeno o suficiente para ser observado e corrigido: uma entrada, uma saída esperada e limites explícitos sobre o que fica de fora. No exemplo do artigo, o piloto organiza as solicitações e mostra o responsável; preços e aprovações continuam com a equipe.

Como evitar registros duplicados ao automatizar?

Defina como reconhecer a mesma operação — por exemplo, com um identificador gerado no envio — e trate novas tentativas a partir dele. Comparar nomes ou textos parecidos não basta. Teste o envio repetido antes de liberar o fluxo.

Quem deve participar do diagnóstico?

Quem executa o trabalho no dia a dia, quem responde pelo resultado do processo e quem conhece os sistemas e os acessos envolvidos. Em equipes pequenas, uma pessoa pode acumular papéis, mas cada responsabilidade precisa estar nomeada.

O que fazer quando os dados necessários não estão disponíveis?

Ajuste o escopo antes de escolher a tecnologia. Pode ser preciso começar organizando a coleta, obter autorização de acesso ou adiar a automação. Uma ferramenta de IA não elimina essas dependências.

Referências e contexto da leitura

• Sequoia Capital — “Goldilocks” Agents and the Power of Custom Cognitive Architectures. Sonya Huang e Pat Grady, 18/06/2024. Referência de análise sobre flexibilidade e controle.
• Anthropic — Building effective agents, 19/12/2024. Distinção entre fluxos e agentes; o próprio texto alerta que o cenário de ferramentas mudou desde a publicação.
• Amazon Builders’ Library — Making retries safe with idempotent APIs. Malcolm Featonby. Referência técnica sobre novas tentativas e efeitos duplicados.
• NIST — AI Risk Management Framework. Referência voluntária de gestão de riscos.

Fontes consultadas em 27/10/2026. Síntese e aplicação ao exemplo elaboradas pela Syntech. As referências sustentam os conceitos indicados; não validam resultados da empresa hipotética nem implicam vínculo ou endosso à Syntech.