CRM, ERP e service desk: qual problema cada sistema resolve

Problema

Quem começa a procurar sistema descobre rápido que existem três nomes circulando — CRM, ERP e service desk — e que cada fornecedor apresenta o seu como se cobrisse tudo. O vendedor de CRM fala em “gestão completa do cliente”. O de ERP abre um módulo de vendas na demonstração. O de atendimento diz que centraliza “todo o relacionamento”. Nenhum está exatamente mentindo: cada um descreve o pedaço do problema que o produto dele resolve como se fosse o problema inteiro.

Sem critério próprio, o comprador erra de duas maneiras caras. Compra o sistema errado — paga implantação e mensalidade para organizar uma parte da operação que não estava sangrando. Ou compra cedo demais — assina uma suíte de três módulos quando usa um; os outros dois ficam pela metade e, em poucos meses, ninguém confia no que o sistema mostra.

O que evita os dois erros não é comparar propostas comerciais: é ter um critério que funcione antes de falar com qualquer fornecedor.

Análise técnica

A confusão desaparece quando se para de comparar lista de funcionalidades e se olha duas coisas: qual é o centro de gravidade do sistema e qual é a unidade de registro que ele controla — o objeto que ele cria, move entre estados, cobra quando fica parado e encerra. É isso, não o menu, que define o que um sistema é.

Uma ressalva antes das definições, porque ela muda como você deve lê-las: as três categorias se sobrepõem de verdade, e quem afirmar fronteira absoluta está simplificando. Plataformas de CRM podem abranger marketing, vendas, comércio e atendimento ao longo de todo o ciclo de vida do cliente. ERPs integram de contabilidade e compras a gestão de projetos, estoque e cadeia de suprimentos — inclusive com módulo de CRM embutido. E o service desk, na definição do ITIL, é o ponto de contato entre o provedor de serviços e os usuários, o que inclui o usuário interno, não só o cliente final. Por isso o critério aqui é centro de gravidade: as bordas se sobrepõem, mas o registro principal e o mecanismo de controle continuam diferentes.

CRM comercial — centro de gravidade: a oportunidade. No recorte de vendas usado neste artigo, o registro central é algo que pode ser ganho ou perdido, com valor, responsável, fase e próxima ação. Ciclo: aberta → ganha ou perdida, com motivo. O relógio que corre nela é o da inatividade: negociação parada há três semanas é problema, e o sistema existe para tornar isso visível antes de virar prejuízo. A ressalva do “comercial” importa — um CRM de atendimento tem o caso como registro central, e um de marketing trabalha com lead, campanha e jornada.

ERP — centro de gravidade: o processo operacional e seu evento econômico. Aqui não há um registro único: convivem pedido, contrato, nota fiscal, conta a pagar ou receber, movimento de estoque, ativo e lançamento contábil. O que os conecta é o efeito sobre recursos, obrigações, execução, custos e registros financeiros e fiscais da empresa — sem que todo registro precise ter efeito imediato, já que cadastros, requisições e aprovações também vivem ali. Ciclo: emitido → liquidado, vigente → encerrado. O relógio é o do vencimento — data dura, com consequência.

Service desk — centro de gravidade: a solicitação de serviço. No ITIL, o service desk é o ponto de contato entre o provedor de serviços e os usuários, por onde entram incidentes, solicitações e outras comunicações — de cliente externo ou de funcionário interno. O registro é o chamado, com solicitante, categoria, prioridade, fila, responsável e prazo acordado (SLA). Ciclo: aberto → em atendimento → resolvido. O relógio é o do prazo prometido: o valor está em responder quantos chamados estão perto de estourá-lo agora.

Help desk e service desk: próximos, não idênticos. Help desk costuma ser usado para descrever o suporte predominantemente reativo, voltado à resolução de problemas. Service desk, no ITIL, é aquele ponto de contato que recebe incidentes, solicitações e comunicações. Catálogo de serviços, SLA, aprovações e gestão de mudança podem compor uma solução completa de gestão de serviços, mas pertencem a práticas complementares — a própria estrutura do ITIL trata service desk, gestão de incidentes, gestão de requisições e habilitação de mudanças como coisas distintas. Para quem compra, a conclusão prática é ignorar o rótulo e verificar quais desses controles o produto entrega.

Isso não é preciosismo de nomenclatura, é mecânica: um sistema desenhado para transação sabe cobrar vencimento e não sabe cobrar inatividade; um desenhado para oportunidade aponta negociação parada e não controla liquidação. Pedir a um o trabalho do outro custa justamente a cobrança automática que justificava a compra.

Critérios de decisão

1. O teste que diz qual sistema falta: onde a informação está morrendo hoje. Em vez de perguntar “de qual sistema eu preciso?”, ouça a frase que a equipe repete quando algo se perde. Cada uma aponta uma unidade de registro ausente:

• “Mandei a proposta e não sei se ele respondeu” → falta a oportunidade → CRM.
• “Não sei o que já foi faturado desse contrato” → falta o documento → ERP.
• “O cliente pediu e ninguém sabe quem ficou de resolver” → falta o chamado → service desk.

O teste é útil porque é observável: em vez de julgar maturidade ou porte, você anota por duas semanas o que a equipe pergunta quando uma informação não aparece.

2. Como avaliar sobreposição sem se enganar. Boa parte dos ERPs traz módulo de CRM, e boa parte dos CRMs promete gestão completa. Não é má-fé: o cadastro de cliente é o mesmo nos três, então parece barato acrescentar o resto em cima dele. O que falta no módulo secundário raramente é tela — é ciclo de vida. Três perguntas para a demonstração:

• Qual é a unidade de registro do módulo? Se o “CRM” do ERP guarda contato e histórico mas não tem oportunidade com fase, valor e responsável, é uma agenda de clientes.
• O que acontece quando o registro fica parado? Se nada acontece, o módulo guarda informação — não conduz processo.
• Quais perguntas ele responde sozinho? “Quanto tem em negociação?”, “quanto está vencido?”, “quantos chamados estouram o prazo hoje?” Módulo secundário exibe lista; não responde pergunta.

3. Por onde começar — sem sequência canônica. Não existe ordem universal de adoção. O primeiro sistema deve ser aquele que transforma em registro controlado a perda operacional mais relevante da empresa hoje. Três cenários comuns, e nenhum deles é regra:

• Venda consultiva, com proposta e vários contatos antes do fechamento, e receita sumindo em negociação não acompanhada → CRM. O sinal é ninguém saber dizer o valor em negociação sem consolidar à mão.
• Contratos e faturamento além do controle manual, emissão fiscal ou estoque virando gargalo → ERP. O sinal é alguém reconciliar planilha com extrato para saber o que já foi pago.
• Pós-venda que virou promessa recorrente com prazo acordado, com cliente perdido por prazo estourado → central de serviços. Enquanto o atendimento é ocasional, a caixa de e-mail dá conta.

Uma empresa de manutenção com contratos assinados e fila descontrolada não deveria começar pelo CRM só porque essa é a ordem que se ouve com mais frequência: ali a perda está no prazo não cumprido, que gera desconto contratual e cancelamento. O teste do item 1 é o diagnóstico; a sequência é consequência dele.

O custo entra na conta, mas com uma ressalva importante: preços anunciados por fornecedores diferentes raramente são comparáveis entre si, porque cada um precifica de um jeito — por usuário, por faixa de faturamento, por porte, por módulos contratados ou por volume de operações. No Omie, o ERP parte de R$ 309/mês, variando conforme a receita bruta mensal; na Conta Azul, o plano Essencial de R$ 159,90/mês (valor anual) atende Microempreendedor Individual com faturamento de até R$ 81 mil por ano e um usuário, com os demais planos em outras faixas de faturamento e de usuários (páginas oficiais consultadas em julho de 2026, nas fontes). O valor anunciado é apenas o ponto de entrada: a comparação real depende do cenário da empresa e do escopo incluído.

4. Integração: o que checar antes de assinar. O sintoma clássico de sistemas que não conversam é o mesmo cliente existindo como três cadastros, com o nome escrito de três jeitos e sem CNPJ em um deles. Aí nenhuma pergunta que atravesse os três tem resposta confiável: “esse cliente dá lucro?” exige cruzar venda, faturamento e custo de atendimento, e sem chave que bata o cruzamento vira manual — o que quer dizer que ninguém faz. Dois critérios verificáveis antes de comprar. O primeiro: existe API ou exportação completa dos registros — “exportamos em PDF” significa dado preso. O segundo: existe um identificador interno único e estável para cada cliente, independente de nome, telefone ou documento. CPF e CNPJ ajudam a validar e a deduplicar, mas não sustentam sozinhos a vinculação entre sistemas: há cliente sem documento informado, empresa estrangeira, filial, grupo econômico, cadastro legado e documento que muda. O desenho que aguenta integração é um identificador interno imutável, com o documento como atributo validado e uma tabela de correspondência entre os identificadores de cada sistema. É critério de compra, não promessa de integração pronta.

5. Quando você não precisa dos três. Muitas empresas pequenas precisam de um só, e o segundo sistema costuma ser erro de sequência, não de escolha:

• Poucos contratos de valor alto e ciclo longo, com financeiro que cabe entre o contador e o extrato: CRM resolve, ERP seria peso morto.
• Fatura muito e prospecta pouco (varejo, recorrência estável, venda de balcão): ERP resolve, e um CRM sem prospecção fica sem oportunidade para registrar.
• Pós-venda ocasional, resolvido por quem executou a entrega: chamado com fila e SLA vira burocracia — dois passos de registro para uma tarefa de dez minutos.

Sistema abandonado custa mais que a mensalidade: parte da operação passa a viver nele e parte continua fora, e ninguém sabe qual das duas versões está certa.

Exemplos ou evidências

A diferença de unidade de registro fica visível nos dois produtos que operamos.

No UltraHub CRM, o objeto central é a oportunidade: o funil lista cada negociação com fase, responsável, valor e probabilidade, e a visão de Cliente 360 reúne oportunidades e propostas do mesmo cliente numa linha do tempo. As propostas têm ciclo de aprovação e geração de PDF; o painel mostra funil, cobranças a receber e tarefas vencidas. Tudo gira em torno de algo que ainda pode ser ganho ou perdido — e esse núcleo (clientes, oportunidades, propostas, produtos e painel) está em produção comercial.

No Sonar ERP, ERP para locadoras de veículos, o objeto muda: contrato de locação com ciclo de vida completo (ativar, encerrar, cancelar), fatura com controle de inadimplência, veículo com transições de status na frota. Nenhum desses registros é ganho ou perdido — são emitidos, cumpridos e liquidados, cada um com consequência financeira direta. Ressalva necessária: o Sonar ERP tem núcleo funcional e testado em ambiente de desenvolvimento, mas ainda sem verificação formal de prontidão para produção (pentest, documentação de implantação) — não o trate como produto pronto para entrar na sua operação hoje.

Do lado de service desk não temos produto publicado, e inventar um aqui seria exatamente o comportamento que este artigo critica. Se o seu teste apontar que o registro faltante é o chamado, o caminho é avaliar ferramenta de mercado ou especificar uma central de serviços sob medida — trabalho que cabe na frente de Tecnologia & Operação.

Se você chegou até aqui sem saber qual dos três resolve o seu caso, comece pelo mais simples: escreva a frase que sua equipe repete quando alguma informação se perde. O botão abaixo leva à triagem gratuita, com o gargalo de processo interno já pré-selecionado — você descreve onde a informação está morrendo, a Ultrahub analisa o cenário informado e devolve uma recomendação inicial de próximo passo, sem compromisso comercial.

Solicitar avaliação de tecnologia e operação