A resposta direta: não peça à IA para escolher qual sistema está certo. Defina uma autoridade por fato, preserve cada evento e calcule estados comerciais explícitos — pagamento, fulfillment, devolução, assinatura, atendimento e oportunidade — antes de liberar uma ação. Use IA para extrair sinais de notas, emails e documentos, classificar exceções e priorizar revisão. Use regras e transições auditáveis para dinheiro, consentimento, elegibilidade e supressão.
Uma pessoa pode estar ativa no CRM, com pedido pago no commerce, reembolso pendente no gateway e chamado aberto no atendimento. Nenhum rótulo sozinho responde se deve receber upsell, pesquisa, win-back ou silêncio. Depois de resolver quem é o cliente, a empresa precisa concordar sobre o que aconteceu, quando aconteceu e qual ação ainda é permitida.
Escreva o Contrato de Estado Comercial
- Objeto — cliente, pedido, assinatura, chamado, oportunidade, unidade ou relação.
- Fatos de origem — evento bruto, identificador, produtor, versão e payload mínimo.
- Autoridade por fato — quem confirma pagamento, entrega, devolução, consentimento, serviço ou venda.
- Dimensões — não comprima financeiro, fulfillment, relacionamento e atendimento em um único campo.
- Tempo — quando ocorreu, quando chegou e até quando pode ser corrigido.
- Transição — estados anteriores permitidos, próximo estado válido e condição de reversão.
- Precedência — qual fato prevalece quando fontes conflitam e por quê.
- Idempotência — como impedir que retry ou duplicata execute a ação duas vezes.
- Correção e replay — como registrar ajustes, recalcular estado e reproduzir downstream.
- Exceção — limiar, fila, owner, SLA e evidência para revisão.
- Permissão downstream — quais estados liberam, pausam, suprimem ou encerram cada ação.
- Evidência — lineage, versão da regra, decisão e resultado permanecem auditáveis.
O Contrato evita um campo tentador chamado status_cliente. Um pedido pode estar financeiramente pago e ainda não enviado; uma devolução pode ter sido solicitada sem item recebido; uma assinatura pode estar ativa enquanto uma fatura está em atraso; uma oportunidade pode estar ganha enquanto a implantação foi cancelada. Mantenha as dimensões separadas e derive apenas o estado necessário para cada decisão.
Onde regras terminam e IA começa
- Regras validam transições, autoridade, precedência, janela, elegibilidade, consentimento e idempotência.
- Integração captura eventos, consulta objetos atuais, normaliza chaves e mantém lineage.
- IA extrai motivo de devolução em texto livre, identifica provável resolução em notas, agrupa exceções e resume contexto.
- Humano decide conflito material, mudança sem fonte confiável, exceção financeira e impacto em conta estratégica.
- Abstenção é obrigatória quando falta evidência; o estado fica desconhecido e a ação de risco não ocorre.
- Valor pago, reembolso concluído, opt-out vigente ou entitlement nunca devem ser inventados por um modelo.
Stripe documenta que webhooks podem chegar fora de ordem, repetir e ser reenviados; recomenda rastrear IDs e recuperar objetos quando necessário. Shopify expõe estados financeiros e de fulfillment distintos e trata reembolso, devolução e fechamento como operações relacionadas. A lição é projetar o consumidor para eventos atrasados, duplicados e corretivos sem enviar duas mensagens nem manter uma ação obsoleta.
Um piloto de seis semanas em uma decisão
- Semana 1 — escolha uma decisão de alto atrito, como pausar cross-sell durante devolução ou impedir win-back de assinatura ainda ativa.
- Semana 2 — desenhe o Contrato e amostre sequências normais, atrasadas, duplicadas, fora de ordem e corrigidas.
- Semana 3 — conecte fontes em modo sombra; guarde fatos e compare o estado calculado ao sistema operacional.
- Semana 4 — adicione IA somente às exceções não estruturadas; exija evidência e confiança calibrada.
- Semana 5 — libere uma coorte reversível com fila humana, kill switch e replay.
- Semana 6 — compare erro, tempo, contato evitado, conversão elegível e custo; decida batch, near-real-time ou encerramento.
O menor projeto útil não é um customer 360. É um objeto, uma decisão e uma sequência crítica: return_requested → item_received → refund_pending → refund_succeeded. Até o ponto definido, a ação comercial espera. Se refund_succeeded chegar antes de item_received por atraso, o consumidor recupera o objeto atual e recalcula; não volta o cliente ao estágio anterior.
Meça verdade operacional antes de uplift
- Qualidade — estados corretos por dimensão, conflito aberto, transição inválida, atraso e estado desconhecido.
- Confiabilidade — duplicatas absorvidas, eventos recuperados, replay bem-sucedido e ações repetidas.
- Operação — exceções por mil eventos, tempo de revisão, backlog, correções e horas manuais.
- Cliente — mensagens contraditórias, oferta durante problema, pesquisa prematura e reclamação.
- Negócio — receita elegível, conversão após estado confirmado, retenção, refund leakage e contato evitado.
- Economia — integração, armazenamento, observabilidade, modelo, revisão, suporte e custo por decisão confiável.
Primeiro reduza falsos positivos críticos: promoção após cancelamento, autorização tratada como compra, win-back com contrato ativo ou upsell durante reclamação. Só depois avalie ganho incremental com holdout ou rollout escalonado. Conversão bruta pode subir porque a regra mudou elegibilidade, não porque a IA criou demanda.
Responsabilidade, arquitetura e custo
O domínio que produz o fato responde por sua semântica; CRM ou produto de dados mantém o Contrato; engenharia opera ingestão, idempotência e replay; marketing define ações; atendimento, vendas e commerce validam exceções; dados mede; privacidade e jurídico revisam finalidade e retenção. O custo cresce com fontes, volume, frequência, histórico, versões, correções, SLA, destinos, observabilidade e revisão. Event sourcing completo pode ser excessivo; uma tabela append-only de fatos e uma projeção versionada podem bastar.
Conecte identidade, estado e decisão
Resolva primeiro quem é o cliente em https://makinai.co/insights/pt/ia-resolucao-identidade-clientes-crm-duplicados, proteja campanhas durante atendimento em https://makinai.co/insights/pt/ia-crm-atendimento-pausar-campanhas-problema-cliente, escolha latência em https://makinai.co/insights/pt/ia-tempo-real-crm-quando-batch-basta e só então orquestre a próxima melhor ação em https://makinai.co/insights/pt/ia-proxima-melhor-acao-crm-personalizacao. A MAKINAI estrutura CRM, commerce, integração e automação em https://makinai.co/services/pt/consultoria-crm-ecommerce-commerce. Traga um diagrama das fontes e vinte sequências problemáticas; podemos delimitar um piloto antes de reescrever a arquitetura inteira.
As fontes documentam comportamento de eventos, estados de commerce, reconstrução de estado e gestão de risco. Não provam que um modelo específico aumentará receita nem tornam IA necessária. O Contrato, o piloto, os limites e as métricas são recomendações editoriais da MAKINAI a validar com sistemas, responsáveis, dados e requisitos locais.