Quanto custa um CRM: o que entra no preço e o que fica de fora

Não vai encontrar um preço nesta página, e a razão é a mesma por que ninguém dá um preço para «uma obra»: até saber quantas divisões tem a casa e o que se quer mudar em cada uma, qualquer número é uma adivinha ou uma isca. O que se pode dar — e é mais útil do que um valor — é a estrutura do custo: que rubricas existem, quem as paga quando não aparecem na proposta, e que perguntas fazem duas propostas diferentes ficarem comparáveis.

Porque é que um preço por utilizador não é um preço

O valor mensal por utilizador é a forma mais fácil de comparar propostas e a que menos informa. Diz quanto custa o acesso ao software; não diz nada sobre quanto custa ter aquilo a funcionar sobre o seu processo, que é a única coisa que interessa.

Duas propostas com o mesmo valor por utilizador podem ter, de um lado, o desenho, a migração e a formação incluídos e, do outro, nada disso. A diferença entre as duas não se vê na comparação: vê-se na segunda fatura, ou no mês em que alguém pergunta porque é que ainda não está a trabalhar. Um preço só é comparável quando se sabe que rubricas cobre — e é por isso que vale a pena conhecê-las antes de pedir valores.

As rubricas que compõem o custo

São seis, e existem sempre, mesmo quando a proposta só mostra uma:

• Acesso ao software. A parte recorrente e a mais fácil de ler. Cobrada por utilizador, por módulo ou como parte de um serviço.
• Desenho e configuração. Decidir etapas, campos, permissões, automatismos e relatórios sobre a operação real. É trabalho de consultoria, não de instalação, e é a rubrica que mais determina se a plataforma vai ser usada.
• Migração de dados. Tirar o que existe de onde está, decidir o que vale a pena trazer e verificar o resultado. Raramente é só um ficheiro a ser importado.
• Formação. Não é uma sessão de apresentação. É a diferença entre uma equipa que usa o sistema e uma equipa que o preenche depois, à pressa, para não ter chatices.
• Evolução. O negócio muda: entra um serviço novo, muda uma regra, abre uma equipa. A pergunta não é se vai ser preciso mexer, é se mexer está no contrato ou é orçamento novo.
• Suporte. Quem responde quando algo não funciona, em quanto tempo, e com que conhecimento do seu desenho.

Nenhuma destas desaparece por não estar escrita. Se não está na proposta, vai ser feita pela sua equipa — o que nos leva à rubrica que nunca aparece em documento nenhum.

A rubrica que nenhuma proposta escreve: o tempo da sua equipa

Toda a implementação consome horas de quem conhece a operação, e essas são as horas mais caras da empresa, porque são as das pessoas que não podem parar.

Imagine uma oficina com três rampas e dois mecânicos. Alguém tem de descrever como entra uma viatura, o que acontece quando falta uma peça, quem avisa o cliente e em que momento a ordem se fecha. Depois tem de experimentar o que foi configurado, dizer o que está errado e voltar a experimentar. São horas reais, tiradas ao trabalho que fatura, e são a razão por que implementações feitas «ao mesmo tempo que o resto» se arrastam.

Um fornecedor que não fala deste custo ou nunca fez uma implementação, ou está a deixar de fora uma parte do preço que alguém vai pagar de qualquer maneira. Peça a estimativa: quantas horas de que pessoas, em que semanas. A resposta diz muito mais sobre a experiência de quem está do outro lado do que qualquer apresentação.

O custo de não decidir, e o de decidir mal

Esta é a única rubrica do lado oposto, e a mais fácil de ignorar porque já está paga. Uma empresa que reconcilia duas listas todas as semanas já compra aquele trabalho — só não lhe chama investimento em software, chama-lhe «como sempre fizemos».

Não é preciso um número de fora para tornar este custo visível, e é melhor que não seja. Escolha dois ou três trabalhos manuais que se repetem — passar informação de um sítio para outro, montar um relatório, reconstruir o histórico de um cliente antes de uma reunião — e estime quantas horas por mês levam e quem as faz. Essa conta é sua, com os seus valores, e é a única que serve para pôr ao lado de uma proposta.

Há um segundo custo, ainda menos visível: o de decidir mal. Uma plataforma abandonada ao sexto mês custou o que se pagou, custou as horas que se gastaram, e custa a credibilidade da tentativa seguinte, que passa a ter de convencer uma equipa que já viu aquilo falhar. Vale a pena saber o que faz uma implementação descarrilar antes de assinar, e não depois.

As perguntas que tornam duas propostas comparáveis

Faça-as por escrito, todas ao mesmo fornecedor e todas ao seguinte:

• O que está incluído no primeiro ano, e o que muda no segundo?
• Quem desenha a configuração sobre o meu processo, e essas horas estão no valor ou são faturadas à parte?
• A migração está incluída, e até que limite? O que é que, a partir de certo ponto, passa a ser trabalho extra?
• Quando o negócio mudar, um ajuste é serviço contratado ou orçamento novo?
• Quantas horas da minha equipa é que esta implementação pressupõe, e de quem?
• Quem responde quando algo não funciona, e conhece o desenho da minha instalação?

Repare que nenhuma é sobre funcionalidades. Quem responde a todas com clareza está a vender um trabalho; quem responde a metade com «depende» sem dizer de quê está a vender um acesso e a deixar o resto para uma conversa futura, em que a posição de negociação já não é a mesma.

Como pedir um preço que sirva para decidir

Inverta a ordem habitual. Em vez de pedir um orçamento e explicar a operação depois, descreva primeiro o processo que quer resolver, diga quantas pessoas o executam e exija que o valor venha em rubricas separadas. Uma proposta com um número único não é mais simples: é menos verificável.

É por isto que não publicamos tabela de preços e que nenhuma proposta nossa sai antes de um diagnóstico. Um valor escrito antes de conhecer a operação é um valor que alguém vai ter de corrigir mais tarde, e essa correção tem sempre o mesmo nome: «não estava no âmbito». O nosso modelo de trabalho cobra um serviço contínuo em vez de licenças avulsas, e isso muda a conversa sobre custo — a evolução deixa de ser uma fatura nova para passar a ser parte do que foi contratado.

Antes de pedir propostas, resolva a questão que mexe no preço mais do que qualquer negociação: decida que parte da sua operação aceita um padrão e que parte exige desenho próprio. É o tema de software à medida ou de prateleira, e responder a isso primeiro é a diferença entre comparar preços e decidir.