É preciso organizar os dados de toda a empresa antes de colocar um agente de IA?
O minuto exato em que um agente responde errado por um dado escrito em dois lugares, e o que realmente precisa ser organizado antes. Não é a empresa inteira.

Iván Itzcovich
Co-fundador
É preciso organizar os dados de toda a empresa antes de colocar um agente? A resposta curta é não, e a longa fica mais clara olhando o minuto exato em que um agente responde errado.
Onde exatamente isso quebra?
Um pedido, um dia comum. Às 09:10 o cliente compra e fica registrado no sistema de gestão. Às 11:40 a produção avisa em um grupo de WhatsApp que vai atrasar dois dias, e o vendedor anota na planilha que ele olha todos os dias. Às 12:05 o cliente pergunta quando chega, o agente consulta o sistema de gestão, o único lugar ao qual está conectado, e responde que sai hoje.
Essa resposta está errada, bem escrita e soa segura. Às 17:30 o cliente escreve de novo, incomodado, e só então uma pessoa entra.
O problema não foi o agente. Foram os vinte minutos em que o status real morou em um lugar e o status que o agente lê morou em outro.
Exemplo ilustrativo
Dois sistemas escrevendo o mesmo dado
O cliente confirma a compra. Fica registrada no sistema de gestão e o vendedor também anota na planilha dele.
Sistema de gestão
Confirmado
Planilha do time
Confirmado
O que o agente responde se o cliente perguntar agora
Seu pedido está confirmado. Aviso quando ele sair do depósito.
Os dois lugares dizem a mesma coisa, então o agente acerta.
O que aconteceu
O agente nunca falhou tecnicamente. Leu o dado que tinha disponível e respondeu bem redigido. A falha foi vinte minutos antes, quando o status real foi escrito em um lugar ao qual o agente não está conectado, e ninguém teve como perceber até a reclamação.
Os dois modos, momento por momento
Dois lugares escrevem o status
- 09:10. O cliente confirma a compra. Fica registrada no sistema de gestão e o vendedor também anota na planilha dele. Sistema de gestão: Confirmado. Planilha do time: Confirmado. O que o agente responde se o cliente perguntar agora: Seu pedido está confirmado. Aviso quando ele sair do depósito. Os dois lugares dizem a mesma coisa, então o agente acerta.
- 11:40. A produção avisa em um grupo de WhatsApp que o pedido vai atrasar dois dias. O vendedor anota na planilha dele, que é onde ele olha todos os dias. Sistema de gestão: Confirmado. Planilha do time: Atrasado, sai na quinta. Aqui começa a diferença. O sistema ficou com o dado velho e ninguém atualizou.
- 12:05. O cliente pergunta pelo WhatsApp quando o pedido chega. O agente consulta o sistema de gestão, o único lugar ao qual está conectado. Sistema de gestão: Confirmado. Planilha do time: Atrasado, sai na quinta. O que o agente responde se o cliente perguntar agora: Seu pedido está confirmado e sai hoje do depósito. Deve chegar amanhã. Este é o momento. A resposta está errada, bem escrita e soa segura.
- 12:06. O agente registra a conversa como resolvida e não escala para ninguém, porque de onde ele olha nada de estranho aconteceu. Sistema de gestão: Confirmado. Planilha do time: Atrasado, sai na quinta. Ninguém do time percebe. Não há alerta, porque não houve erro técnico.
- 17:30. O cliente escreve de novo porque o pedido não chegou. Agora sim uma pessoa entra, e precisa explicar e pedir desculpas. Sistema de gestão: Confirmado. Planilha do time: Atrasado, sai na quinta. O custo não foi o erro: foi a reclamação, e que o cliente descobriu antes da empresa.
- Dia seguinte. Alguém atualiza o sistema à mão para bater com a planilha. O caso é fechado e a causa fica igual à de ontem. Sistema de gestão: Atrasado, sai na quinta. Planilha do time: Atrasado, sai na quinta. Amanhã acontece de novo com outro pedido, porque os dois lugares continuam escrevendo o mesmo dado.
O que aconteceu. O agente nunca falhou tecnicamente. Leu o dado que tinha disponível e respondeu bem redigido. A falha foi vinte minutos antes, quando o status real foi escrito em um lugar ao qual o agente não está conectado, e ninguém teve como perceber até a reclamação.
Uma única via de escrita
- 09:10. O cliente confirma a compra. Fica registrada no sistema de gestão, que agora é o único lugar onde o status é atualizado. Sistema de gestão: Confirmado. Segunda fonte: Já não existe para este dado. O que o agente responde se o cliente perguntar agora: Seu pedido está confirmado. Aviso quando ele sair do depósito. Existe uma única fonte, então não há nada a reconciliar.
- 11:40. A produção avisa do atraso de dois dias e lança no sistema, que é onde o status é registrado agora. Sistema de gestão: Atrasado, sai na quinta. Segunda fonte: Já não existe para este dado. O time continua olhando a informação onde sempre olhou, mas escreve em um só lugar.
- 12:05. O cliente pergunta quando o pedido chega. O agente consulta o sistema. Sistema de gestão: Atrasado, sai na quinta. Segunda fonte: Já não existe para este dado. O que o agente responde se o cliente perguntar agora: Seu pedido atrasou e sai na quinta. Aviso assim que ele sair do depósito. Mesma pergunta, mesma hora, resposta correta. O único que mudou é onde o status é escrito.
- 12:05, variante. Se a produção ainda não tivesse lançado nada, o sistema não teria o dado novo. Um agente bem construído diz isso em vez de improvisar. Sistema de gestão: Confirmado, sem novidades desde as 09:10. Segunda fonte: Já não existe para este dado. O que o agente responde se o cliente perguntar agora: Não tenho uma data nova confirmada. Consulto com o time e te respondo hoje mesmo. Um agente que nunca diz que não sabe está mal construído, não mal alimentado.
O que mudou. Não se unificaram os sistemas da empresa nem se migrou nada. Foi decidido qual é o único lugar onde um campo é atualizado, o do status do pedido, que é o que o agente precisa. O resto dos sistemas ficou exatamente como estava.
O exemplo é ilustrativo e usa um pedido porque é o caso mais reconhecível, não a medição de um cliente. O mesmo padrão aparece com um saldo, um horário disponível, um estoque ou o status de um processo.
Por que ninguém percebe antes da reclamação?
Porque não houve erro técnico. O agente leu um dado válido de um sistema que funciona, então nenhum alerta dispara, nenhum log fica vermelho e a conversa é registrada como resolvida.
Essa é a diferença entre dado desorganizado e dado contraditório. A desorganização se anuncia: falta um campo, uma consulta não retorna nada, alguém pergunta. A contradição não, porque as duas versões parecem igualmente válidas por dentro.
Uma parte disso se resolve com design e não com dados: um agente precisa conseguir dizer que não tem a informação e transferir. Um agente que nunca diz que não sabe está mal construído, não mal alimentado.
Então o que precisa ser organizado antes?
Uma única via de escrita para cada dado que o agente vai registrar, ou que vai ler para decidir alguma coisa. Nada além disso.
No exemplo acima basta decidir que o status do pedido é atualizado em um único lugar. Sem unificar sistemas, sem migrar histórico, sem trocar de software: escolher onde esse campo é escrito e fazer o resto ler dali.
E o resto dos sistemas da empresa?
Pode continuar exatamente como está. Se o ERP e o CRM escrevem o nome do mesmo cliente de formas diferentes, isso é um problema real de relatório e não é um problema do agente que qualifica consultas novas, porque esse agente não toca no ERP.
A pergunta útil não é se os dados da empresa estão organizados, porque a resposta honesta em qualquer empresa com mais de cinco anos é que não. É quais dados esta tarefa toca, e de onde eles são escritos hoje.
Quando a consolidação precisa mesmo vir antes?
Quando o problema a resolver é o relatório, a rastreabilidade ou o fechamento contábil, e não uma tarefa conversacional. Ali a consolidação é o projeto, não um requisito prévio de outro projeto.
E se a empresa realmente precisa consolidar, um agente não substitui isso. O que ele faz é entregar o mapa real de um trecho, com uso medido, antes de o orçamento grande ser gasto. É a ordem que arrisca menos dinheiro, não uma forma de evitar o trabalho.
Quanto custa cada caminho?
A consolidação é medida em meses, envolve todas as áreas e entrega valor no fim. Uma tarefa conversacional é medida em semanas, envolve as pessoas daquele trecho e entrega valor quando vai ao ar. Na Takenos, o agente de suporte resolve 7 de cada 10 conversas sem intervenção humana, em torno de um minuto por chamado, consultando o estado real de uma conta.
| Consolidar os sistemas | Dar uma tarefa a um agente | |
|---|---|---|
| Escopo | Todos os sistemas da empresa | Os dados que uma tarefa toca |
| Duração | Meses | Semanas |
| Quem participa | Todas as áreas | As pessoas daquele trecho |
| O que é tocado | ERP, CRM, gestão, histórico | Um campo e sua via de escrita |
| Quando aparece o valor | No fim | Quando vai ao ar |
Confundir os dois projetos é o que transforma uma implementação de oito semanas em uma de um ano, e costuma terminar com nenhuma das duas aprovada.
Perguntas frequentes
Dá para colocar um agente em cima de um CRM desorganizado?
Dá, desde que a bagunça não esteja nos campos que o agente lê ou escreve. Vale olhar a saúde desses campos específicos e não a do sistema em geral, que raramente é boa e raramente é o problema.
O que quer dizer uma única via de escrita?
Que cada dado tenha um único lugar onde é criado e atualizado, e que todo o resto leia dali. Quando dois sistemas podem escrever o mesmo campo, alguém precisa decidir qual vence toda vez que eles divergem, e esse trabalho de reconciliação se repete para sempre.
Como sei se tenho esse problema sem revisar tudo?
Olhando uma coisa só: para cada dado que o agente vai usar, em quantos lugares ele é atualizado hoje. Se a resposta é um, não há nada a fazer. Se é dois, ali está o trabalho prévio, e ele leva dias.

Iván Itzcovich · Co-fundador, StudioChat
Quer ver agentes assim trabalhando para a sua equipe?
Fale conosco agora