Seus sensores enxergam muita coisa. Um medidor de vazão lê o consumo a cada minuto. Um contato de porta sabe quando o freezer foi aberto. Um motor relata uma vibração que sai da faixa normal antes de falhar. Tudo isso é real, e a maior parte nunca chega aos sistemas que de fato movem o negócio. O faturamento acontece no ERP. O histórico do cliente vive no CRM. O chamado de serviço é aberto por uma pessoa que ficou sabendo do problema horas depois de o dispositivo já saber.
O trabalho é fechar esse ciclo. Quando um sensor percebe algo, o negócio deveria agir: uma leitura de consumo vira uma linha de fatura, uma falha vira um chamado, a leitura de um ativo atualiza o registro que o time de contas consulta. Este post mostra os padrões para conectar dados de dispositivos a sistemas ERP e CRM, as partes que te derrubam se você pular, e como fazer isso na TagoIO com a REST API, scripts de Analysis e Actions de webhook.
Por que conectar dados de dispositivos aos sistemas do negócio
Dados de dispositivo sozinhos são monitoramento. Conectados a um sistema do negócio, viram ação.
Alguns exemplos deixam o valor concreto:
- Um medidor de utility reporta o consumo acumulado. Enviado ao ERP no ciclo de faturamento, vira uma fatura precisa, sem leitura manual.
- Uma máquina dispara um código de falha. Enviado ao CRM ou a um módulo de field service, abre um chamado e designa um técnico antes de o cliente ligar.
- As horas de operação de um ativo cruzam um limite. O registro do ativo é atualizado, e um contrato de manutenção é acionado no prazo.
- Uma instalação de alto valor fica em silêncio. O responsável de vendas que cuida daquela conta recebe um aviso, em vez de descobrir na próxima revisão trimestral.
Em todos os casos o dispositivo já sabia. A lacuna era levar esse sinal até o sistema onde alguém pudesse agir.
Os padrões de integração
Existe um punhado de padrões aos quais você vai recorrer, e a maioria das integrações reais combina dois ou três deles.
Webhooks. A plataforma de dispositivos envia dados para uma URL quando algo acontece. É o padrão certo para eventos: uma falha, o cruzamento de um limite, uma mudança de estado. O sistema receptor recebe o payload no momento em que ele importa, e você não fica fazendo polling.
REST APIs. O lado de puxar da mesma moeda. Seu ERP ou CRM, ou um script no meio, chama um endpoint para ler dados do dispositivo sob demanda ou em horário agendado. Bom para sincronização em lote, como puxar um dia de leituras de medidores à meia-noite, e para qualquer sistema que prefira perguntar a ser avisado.
Middleware e iPaaS. Ferramentas como n8n, Make ou um motor de workflow ficam entre a plataforma e o sistema do negócio. Elas cuidam de retentativas, transformação e do mapeamento chato em que os nomes de campo de um sistema não batem com os do outro. Quando você tem mais de um sistema de destino ou a lógica fica cheia de ramificações, o middleware mantém isso fora das duas pontas.
Gatilhos orientados a eventos. Lógica que roda quando uma condição é atendida, e não pelo relógio. Uma leitura chega, uma regra avalia, e uma ação dispara só se a condição se sustentar. Isso evita martelar o CRM com toda leitura quando você só se importa com as que cruzam uma linha.
Considerações sobre mapeamento e sincronização de dados
É aqui que as integrações quebram em silêncio. O transporte é a parte fácil. Manter dois sistemas concordando sobre os mesmos fatos é a parte difícil.
Identificadores. Cada dispositivo precisa de um mapeamento estável com sua contraparte no sistema do negócio: um dispositivo para um registro de ativo, um medidor para uma conta de cliente, uma máquina para um contrato de serviço. Decida onde esse mapeamento vive e mantenha-o como fonte autoritativa. Marque o dispositivo com o ID do ativo no ERP, ou mantenha uma tabela de consulta que a integração leia. O que você não quer é casar por nomes que alguém vai renomear no próximo trimestre.
Frequência. Ajuste a taxa de sincronização ao caso de uso. Leituras de faturamento podem rodar uma vez por dia. Chamados de falha precisam disparar em segundos. Atualizações de horas de operação de ativos talvez sejam de hora em hora. Mandar tudo em tempo real é desperdício e vai te jogar contra os limites de taxa do sistema de destino. Mandar devagar demais significa registros desatualizados.
Idempotência. Redes fazem retentativas. Se a entrega de um webhook expirar e disparar de novo, você não quer duas faturas nem dois chamados duplicados. Dê a cada evento uma chave única na qual o sistema receptor possa deduplicar, e desenhe a operação de destino de modo que rodá-la duas vezes com a mesma chave não mude nada na segunda vez.
Autenticação e segurança
Você está conectando uma plataforma operacional a sistemas que guardam dinheiro e dados de clientes, então as credenciais importam.
Use tokens com escopo, não chaves de conta inteira. O token que uma integração usa para enviar uma leitura de medidor ao ERP deveria poder fazer isso e nada mais. Se vazar, o raio de impacto é uma operação, não a sua conta inteira.
Aplique o menor privilégio nas duas pontas. O lado da TagoIO lê apenas os dispositivos de que a integração precisa. O lado do ERP ou CRM aceita escrita apenas nos objetos em escopo. Rotacione as chaves periodicamente e guarde-as onde não fiquem em texto puro dentro de um script. A TagoIO é certificada ISO 27001 e alinhada ao GDPR, mas essa postura só se sustenta se as credenciais que você emite seguirem a mesma disciplina.
Como a TagoIO se conecta a sistemas ERP e CRM
A TagoIO não traz um botão de SAP ou Salesforce de um clique só, e você deveria desconfiar de qualquer plataforma que alegue ter um conector pronto para cada sistema corporativo. O que a TagoIO te dá são os blocos de construção para montar a integração você mesmo, com a lógica vivendo onde você consegue ver e mudar.
A REST API. Cada dispositivo, variável e dado armazenado está acessível pela API. Um sistema externo, ou um iPaaS como n8n, pode puxar leituras em horário agendado e enviá-las ao destino. Sua integração com o NetSuite pode chamar a API da TagoIO toda noite, ler o consumo do dia por medidor e lançar as linhas de fatura.
Scripts de Analysis. São scripts serverless que rodam dentro da TagoIO, em Node.js ou Python. Geralmente é aqui que o trabalho de verdade acontece. Um Analysis pode disparar na chegada de dados, avaliar uma condição, transformar o payload no formato que o sistema de destino espera e chamar a API do ERP ou CRM diretamente. Conectar ao HubSpot ou ao Salesforce vira uma questão de uma chamada HTTP do seu script para a API deles com um token de escopo, mais a lógica de mapeamento no meio. Como roda na plataforma, você não precisa subir um servidor para hospedá-lo.
Actions de webhook. As Actions da TagoIO podem disparar um webhook quando uma condição é atendida. Uma variável de falha cruza um limite, a Action faz um post no endpoint do seu service desk, e um chamado abre. Para trabalho orientado a eventos em que você quer um push no instante em que algo acontece, esse é o caminho mais curto. Combine com um Analysis quando o payload precisar ser remodelado antes de chegar ao SAP ou ao seu CRM.
Um formato comum de integração real: uma Action detecta o evento, um script de Analysis remodela e enriquece os dados e cuida da idempotência, e o script chama a REST API do sistema corporativo com um token de escopo. Isso cobre o caso de falha para chamado, o caso de consumo para fatura e o caso de atualização de ativo, com as mesmas três peças em arranjos diferentes.
Por onde começar
Escolha um ciclo que hoje é manual e feche ele. Consumo para fatura e falha para chamado são os dois que dão retorno mais rápido, porque tiram uma pessoa de um caminho repetitivo. Mapeie os identificadores primeiro, decida a frequência de sincronização, construa o Analysis que faz a transformação e teste a idempotência disparando o mesmo evento duas vezes de propósito. Quando um ciclo funciona de ponta a ponta, o resto segue o mesmo padrão.
