Integração Sankhya e Zoho CRM:distribuição sem redigitação

Em distribuição e atacado, a operação funciona como uma balança calibrada de feira: tabela de preços de um lado, estoque do outro — e qualquer desalinho entre os dois gera cliente insatisfeito ou margem perdida. O problema não é falta de dado; é dado espalhado. O Sankhya tem tudo: preço praticado, saldo por depósito, limite de crédito, pedido em aberto. O Zoho CRM tem o relacionamento, o mix negociado e o histórico de visita. Quando os dois sistemas não conversam, o vendedor vira o intermediário manual — e tempo é exatamente o que ele não tem para desperdiçar.

A Outsmart, especializada em operações B2B com 20 ou mais colaboradores, projeta integrações entre Sankhya e Zoho CRM para distribuidoras e atacadistas que precisam eliminar a redigitação sem abrir mão do controle fiscal e da política comercial do ERP. O mapa completo de arquitetura está no guia CRM + ERP e na página de CRM B2B Inteligente. O que este artigo detalha é o que muda quando o ERP é o Sankhya — nas entidades, no padrão de API e nos pontos onde os projetos costumam perder semanas.

1. O tripé que decide tudo antes do primeiro pedido

Integração de distribuição cai ou sobe em três definições que precisam ser tomadas antes de qualquer linha de código: parceiro com chave estável vinda do Sankhya, produto com código único e tabela de preços consumida diretamente do ERP — nunca replicada em outro lugar. Quem tenta criar uma cópia da tabela no CRM garante divergência na primeira campanha de desconto.

A regra é simples mas precisa estar escrita: preço mora no Sankhya. O CRM apenas lê. Qualquer outra configuração transforma cada promoção em dois trabalhos de atualização — e dois lugares para o número estar errado no fechamento do mês. O que parece burocracia na fase de levantamento é o que evita a reunião constrangedora de reconciliação três semanas depois do go-live.

O cliente que parece novo mas já comprou trinta vezes

Cena fictícia, mas corriqueira: o vendedor abre uma oportunidade para "Distribuidora Alfa SP" e negocia 8% de desconto. Quando a proposta chega para aprovação, o gestor reconhece o CNPJ — é filial de um grupo que acumula dois títulos vencidos e limite de crédito comprometido. O desconto foi calculado sem esse contexto. A negociação volta ao ponto zero, o cliente fica dois dias sem resposta e o vendedor aprende a ligar para o back-office antes de qualquer proposta.

Matriz, filiais e rede de revendas conectadas via hierarquia de contas no CRM transformam "novo CNPJ" em "filial do grupo com histórico de doze meses e limite comprometido". Grupo econômico com chave de CNPJ raiz vinda do Sankhya resolve isso antes de qualquer negociação começar — e elimina o grupo de WhatsApp paralelo que existe em toda distribuidora para "confirmar a situação do cliente antes de fechar".

Tabela de preços: um único dono, nunca dois

O Sankhya estrutura política comercial em camadas: tabela-base, campanha por volume, desconto por região e condição por prazo de pagamento. Recriar qualquer dessas camadas no CRM é criar uma segunda verdade que vai divergir da primeira assim que a campanha mudar — e campanha muda o tempo todo em distribuição. O caminho correto é leitura sob demanda: o CRM consulta a API de serviços do Sankhya W no momento de montar a proposta e retorna o preço vigente para aquele parceiro, naquele produto, naquela condição. Sem cópia local. Sem defasagem. Sem a reunião de "qual dos dois números é o certo".

2. O vendedor fecha; o ERP fatura — sem ninguém no meio

O CRM é o território da negociação: histórico de compra, mix sugerido por frequência de pedidos, desconto dentro da alçada aprovada e registro de quem autorizou cada exceção. Aprovada a proposta, o pedido nasce no Sankhya via integração— e o ERP segue dono de reserva de estoque, separação, faturamento e entrega. Nenhuma redigitação. Nenhuma conferência de item. Nenhum assistente no meio.

O que muda para o vendedor: clicar em "Ganho" e esperar o número da nota chegar de volta no registro do CRM. Para a operação: o ciclo entre proposta aprovada e nota emitida encurta de horas para minutos. Para o back-office: o trabalho de transcrição desaparece e o analista passa a monitorar exceções — os pedidos que a integração não conseguiu processar — em vez de digitar os que conseguiu.

O pedido parcial que vira dor de cabeça no go-live

Pedido com entrega fracionada, substituição de item por indisponibilidade e devolução são os casos que a integração precisa tratar antes do go-live, não depois. No Sankhya, o rastreamento de saldo por depósito e o status de separação por romaneio permitem que o CRM mostre exatamente em que ponto da fila de faturamento o pedido está. O vendedor para de ligar para o depósito para descobrir se o caminhão saiu — e o cliente para de ouvir "estamos conferindo".

3. Saldo congelado é mais perigoso do que saldo ausente

Estoque muda dezenas de vezes por dia em distribuição de médio volume. Replicar saldo de hora em hora cria um dado que parece confiável — mas já envelheceu antes de a consulta carregar. A prática correta é consulta sob demanda no momento da proposta: o vendedor vê o número atual do depósito correto e promete prazo com base na realidade, não em uma foto de três horas atrás.

Há operações que tentam resolver isso com replicação de cinco em cinco minutos. O resultado costuma ser uma combinação de alto custo de chamadas à API, sobrecarga no servidor do ERP nos horários de pico e um dado que ainda pode estar desatualizado no exato momento em que importa. Consulta sob demanda — onde o CRM chama a API apenas quando o vendedor abre a tela de proposta — tem custo menor e dado mais fresco quando mais precisa ser fresco.

Depósito correto na tela certa

Em distribuidoras com múltiplos centros de distribuição, mostrar o saldo do depósito errado é pior do que não mostrar nada. A integração precisa mapear a regra de atendimento por região de entrega e exibir a disponibilidade do depósito que realmente vai servir aquele pedido — não o saldo consolidado que parece bom no papel mas esconde que o item está armazenado a mil quilômetros do endereço de entrega.

4. A API Sankhya W: o que ela entrega e onde exige atenção

O Sankhya expõe seus dados pelo Sankhya W — a plataforma de serviços web que permite leitura e escrita de entidades como parceiros, produtos, tabelas de preço e pedidos. A autenticação é por token de sessão renovável, e o volume de chamadas é governado pela instância: instalações em servidor próprio do cliente costumam ter limites que surpreendem quem veio de ERPs em nuvem com cota elástica.

Três pontos exigem atenção antes do desenho técnico. O primeiro é a paginação: listagens grandes retornam em blocos e precisam de controle de cursor para não duplicar registros na sincronização inicial — o erro clássico de quem começa a integração sem ler a documentação da API até o fim. O segundo é o modelo de campos customizados: o Sankhya permite extensão de esquema, e cada campo extra do cliente precisa ser mapeado explicitamente antes de qualquer sincronização. O terceiro é a disponibilidade: o servidor roda no ambiente do cliente e pode ter janelas de manutenção que exigem fila persistente do lado da integração.

Quando a camada intermediária deixa de ser opcional

Em volume abaixo de cem pedidos por dia, uma função Deluge no Zoho CRM chamando a API do Sankhya resolve com custo de manutenção baixo. Deluge é a linguagem de script nativa do ecossistema Zoho — ela roda no servidor e pode chamar APIs externas diretamente, sem código extra em outro lugar. Acima de cem pedidos diários, ou quando a operação tem múltiplas empresas, múltiplos depósitos e regras de roteamento por filial, a camada intermediária com fila, retry automático e log estruturado deixa de ser opcional. É o que transforma "a integração caiu e ninguém sabe" em "ficou indisponível 22 minutos, 14 pedidos foram enfileirados e processados em ordem quando o ERP voltou" — com rastro auditável de cada evento.

5. O ciclo de recompra que transforma carteira em receita previsível

Com histórico de faturamento dentro do CRM, dá para calcular o ciclo de recompra por item — quantos dias em média aquele cliente demora para pedir de novo — e disparar a ação comercial antes de o cliente precisar pedir. Não é inteligência artificial; é aritmética com dado integrado. É o insumo que alimenta os nossos modelos de propensão e que transforma carteira grande em receita que pode ser prevista, não só esperada.

Mix e frequência de compra são indicadores simples de extrair quando pedido e faturamento estão integrados. No mundo da planilha, ninguém tem tempo de calcular isso para dois mil clientes ativos. Com integração, o dado está disponível por padrão — e o vendedor recebe um alerta quando o cliente que comprava todo mês não apareceu nos últimos quarenta dias, antes que o concorrente apareça primeiro.

A carteira que ninguém ousava cobrir — e o que ela esconde

Frequência de compra por produto revela os clientes que compraram uma vez e sumiram — e que nunca receberam uma abordagem porque ninguém tinha esse dado organizado. Em distribuidoras com dois mil clientes ativos, esses "compradores únicos" costumam representar entre 25% e 35% da carteira e menos de 10% da receita. Com o ciclo integrado, eles viram meta de reativação antes de virar churn confirmado — e o vendedor tem argumento concreto para a ligação: "seu último pedido foi há noventa dias, temos campanha ativa no item X".

6. Os números que encerram a discussão sobre o retorno

Toda operação de distribuição tem ao menos uma reunião por trimestre onde alguém questiona o retorno da integração. Os indicadores que encerram essa conversa são objetivos e mensuráveis antes e depois: tempo entre proposta e pedido faturado, taxa de erro de pedido, horas de retaguarda consumidas, positivação de carteira e ticket médio por rota.

A lógica é simples: meça os cinco antes de começar. Sem linha de base, qualquer resultado após o go-live vira questão de percepção — e percepção em reunião de resultados nunca ganha de número concreto do trimestre anterior. Se a integração não moveu nenhum desses indicadores em noventa dias, o problema não foi a tecnologia: foi que o processo ainda não estava pronto para ser automatizado.

Limites honestos

Se a política comercial é definida caso a caso e o cadastro de produto tem códigos duplicados, a integração vai expor esses problemas em vez de resolvê-los — com velocidade maior. Nesses cenários, a primeira entrega do projeto é organização de dados: limpeza de parceiro, padronização de produto e declaração formal da tabela vigente. Esse trabalho precisa estar no cronograma desde o início, porque costuma consumir mais tempo do que a integração em si. Ver também cadastro duplicado CRM/ERP.

O Sankhya W tem teto de chamadas que varia por instância e licença contratada. Em operações com pico de pedidos em datas específicas — fim de campanha, virada de mês —, dimensionar a fila e o número de workers da integração antes do go-live não é preciosismo técnico. É o que evita descobrir o limite no dia de maior volume da operação, quando não há tempo para ajuste.

Perguntas frequentes

Continue por aqui