Custo de sustentação do Salesforce: quanto custa manter por mês

A pergunta que todo gestor faz antes de assinar o projeto é quanto custa implantar. A pergunta que quase ninguém faz, e que dói mais no bolso ao longo dos anos, é quanto custa manter depois que a org foi ao ar. O Salesforce não é um software que você instala e esquece. Ele evolui três vezes por ano, sua equipe muda, seu processo muda, e a conta da sustentação chega todo mês, orçada ou não.

A sustentação mensal do Salesforce costuma seguir dois modelos: banco de horas, contratado por pacote e consumido conforme a demanda, e alocação dedicada, um valor fixo por mês com horas garantidas. O banco atende quem pede ajustes esporádicos; o dedicado, quem evolui a org toda semana. Ambos cobrem correção, ajuste e evolução do que já está no ar.

O que quebra com o tempo (e vira custo)

Sustentação existe porque uma org viva se desgasta. Não é manutenção de coisa quebrada, é o trabalho de manter funcionando um sistema que o mundo ao redor não para de empurrar. Três forças puxam esse custo:

• As releases do Salesforce: são três por ano (Spring, Summer, Winter). Cada uma muda comportamento de plataforma, e automações antigas às vezes param. Já vi um Flow deixar de disparar depois de uma release porque dependia de uma ordem de execução que mudou. Testar em sandbox antes de cada release é trabalho recorrente, e quem não faz descobre o problema em produção.
• Usuários e processos novos: a empresa contrata, cria um time, muda a política de desconto. Cada mudança dessas pede campo novo, permissão nova, relatório novo. Uma permissão empilhada no lugar errado é o tipo de coisa que se acumula em silêncio, e por isso vale entender por que um usuário vê (ou não vê) um registro antes que o acesso vire uma bagunça.
• Dado que envelhece: lead duplicado, conta sem dono, campo que ninguém preenche mais. O dado sujo não aparece na fatura, mas mata a confiança no relatório. Limpar isso é sustentação recorrente, e ferramentas de deduplicação com matching fuzzy ajudam, mas alguém precisa cuidar do processo.

Os modelos de contrato de sustentação

Existem três formas comuns de contratar a manutenção mensal, e a diferença entre elas é quanto risco e quanta previsibilidade cada lado assume. A tabela abaixo resume onde cada modelo brilha e onde ele te machuca:

A regra prática que uso: conte quantos chamados reais você abre por semana. Menos de um, banco de horas ou sob demanda. Vários por semana, o dedicado sai mais barato por hora e ainda te dá alguém que conhece a org de cor, o que economiza o tempo que um consultor novo gastaria para se situar.

O que a sustentação inclui (e o que não inclui)

Aqui mora a maior fonte de discussão em contrato de manutenção: a fronteira entre ajustar o que existe e construir o que é novo. Sustentação bem definida cobre correção de bug, ajuste de configuração, criação de relatório, novo campo, nova permissão, suporte ao usuário e o teste de release em sandbox. O que costuma ficar de fora é o projeto novo: uma integração inédita, um módulo grande, uma migração de dados pesada. Isso vira escopo à parte, com estimativa própria.

A confusão nasce quando "novo campo" é na verdade "novo processo com cinco automações e uma tela". Por isso vale saber quando um pedido justifica Flow ou Apex: um ajuste declarativo cabe na sustentação, mas uma regra que exige código escrito e testado é engenharia, e engenharia consome horas de verdade. Definir essa linha no começo evita a briga de "isso não estava no combinado" todo fim de mês.

Sinais de que você está pagando demais (ou de menos)

Nem todo custo alto é desperdício, e nem toda economia é boa. Alguns sinais de que a conta está errada para mais:

• Você paga por um consultor dedicado, mas abre dois chamados por mês. Está pagando disponibilidade que não usa; um banco de horas menor resolveria.
• A fatura tem "horas de gestão" ou "reuniões" que consomem metade do pacote sem virar entrega.
• Cada release do Salesforce vira um projeto cobrado à parte, quando o teste de release deveria estar dentro da sustentação.

E os sinais de que você paga de menos, que costumam sair mais caro no longo prazo:

• Ninguém testa a org antes das releases, e uma vez por ano algo para em produção sem aviso.
• Pedido simples demora semanas porque você depende de um favor, não de um contrato.
• O dado nunca é limpo, os relatórios perderam a credibilidade e a diretoria já não confia no número.

O que aprendi sustentando a org do meu portfólio

A Vetra Distribuidora é a empresa fictícia que uso como org de demonstração deste portfólio, e mantê-la viva me mostrou onde o custo de sustentação realmente se esconde. Depois de subir uma regra de comissão por linha de produto, cada ajuste posterior, mudar uma faixa de desconto, adicionar um produto, corrigir um caso de borda, exigia rodar de novo os testes de Apex para garantir que nada quebrou. Não é trabalho glamouroso, mas é o que mantém a automação confiável. A lição que levo para todo contrato: a sustentação barata de verdade não é a de menor mensalidade, é a que impede o problema de acontecer. Um teste de release feito na sandbox custa uma fração do que custa reconstruir a confiança da equipe depois que um relatório errado foi para a diretoria.

Por onde começar

Antes de contratar qualquer sustentação, faça três coisas. Primeiro, meça sua demanda real: quantos pedidos de ajuste sua operação gerou nos últimos três meses? Esse número escolhe o modelo por você. Segundo, exija que o contrato liste o que está incluído e o que é escopo à parte, por escrito. Terceiro, garanta que o teste de release em sandbox esteja dentro do pacote, porque é o item que mais evita dor. Se você ainda está orçando a implantação e quer a conta completa antes da sustentação, comece pelo guia de quanto custa um projeto Salesforce, e lembre que o profissional certo pesa mais que o modelo de contrato, então vale saber como escolher um consultor ou freelancer Salesforce antes de assinar.

Perguntas frequentes

Quanto custa manter o Salesforce por mês?

Depende do modelo de contrato e do tamanho da org. Um banco de horas pequeno, consumido conforme a demanda, é o piso e atende quem pede ajustes esporádicos. Um consultor dedicado com horas garantidas custa mais, mas faz sentido quando a operação não para de pedir melhorias. O que define a conta é o volume de mudanças que você gera, não o número de usuários.

Preciso de sustentação depois que o projeto vai ao ar?

Na prática, toda org viva precisa. O Salesforce libera três atualizações por ano, entram usuários novos, o processo muda e o dado envelhece. Sem alguém responsável por absorver isso, a org acumula pequenos problemas que um dia viram um grande. Sustentação não é luxo, é o custo de manter funcionando o que você já pagou para construir.

Banco de horas ou consultor dedicado: qual escolher?

Banco de horas serve para demanda irregular, quando você quer pagar só pelo que usa. Consultor dedicado serve para quem evolui a org toda semana e precisa de disponibilidade garantida. A regra prática: se você abre menos de um chamado por semana, o banco é mais barato; se abre vários, o dedicado sai por hora mais em conta e ainda dá previsibilidade.

As atualizações do Salesforce podem quebrar minha org?

Podem, principalmente automações e código que dependem de comportamento antigo. As três releases anuais trazem mudanças que às vezes exigem ajuste em Flows, Apex ou integrações. Testar a org em sandbox antes de cada release é parte do trabalho de sustentação, e é o que evita a surpresa de descobrir um processo parado na segunda-feira.