A implementação entrega o sistema. O valor, e o custo, começam no dia seguinte. Todo projeto de Salesforce tem um dia de festa. O go-live acontece, a equipe comemora, a consultoria encerra o contrato e a liderança reporta ao board que a entrega foi concluída.

Essa é a foto que engana. O sistema que subiu no go-live é a versão mais simples que ele jamais terá. A partir dali o negócio muda, os dados envelhecem, os usuários pedem ajustes e a plataforma ou acompanha esse movimento ou fica para trás. Tratar o go-live como fim de projeto é o erro de orçamento que transforma um bom investimento em um ativo que se deteriora em silêncio. E deterioração silenciosa é o pior tipo, porque quando o problema chega ao relatório da liderança, já custou meses de decisão tomada sobre base ruim.

A conta que não estava na proposta

Quando a liderança aprova um projeto de Salesforce, o número que ela leva para o board costuma ser o da implementação. Licenças mais parametrização, com data de início e de fim. Esse número descreve só a largada.

Estimativas de TCO do ecossistema Salesforce apontam que manutenção e evolução consomem de 15% a 20% do custo inicial do projeto por ano. Em três a cinco anos, o gasto total costuma chegar a duas ou três vezes o valor do projeto original, principalmente em negócios que mudam rápido (guias de TCO do ecossistema Salesforce, 2026).

Esse percentual recorrente não é só conserto. Ele paga a adaptação às atualizações da plataforma, o desenvolvimento de novas automações conforme as áreas crescem, a limpeza contínua da base e a governança que impede a org de virar uma colcha de retalhos. É investimento em manter o ativo produzindo, não taxa de conservação do que já existe.

Isso não é desperdício. É a natureza de um sistema que opera o core comercial da empresa. O problema não está em gastar depois do go-live, está em não ter previsto esse gasto. Quando a sustentação entra no business case desde o dia zero, ela deixa de ser uma surpresa no meio do ano fiscal e vira uma decisão consciente de orçamento.

Entregar não é o mesmo que dar certo

Um go-live bem executado prova que o sistema funciona. Não prova que o projeto deu certo. A distância entre as duas coisas é o que a estatística de CRM mostra há anos. Cerca de metade das implementações não atinge os objetivos que justificaram o investimento, com a Forrester apontando faixa semelhante, na casa dos 47% (Gartner e Forrester, levantamentos de referência sobre CRM).

A causa mais citada não costuma ser técnica, e sim a adoção. As pessoas param de usar, ou usam de qualquer jeito, e o dado que entra deixa de ser confiável. Adoção não se resolve no treinamento da semana do go-live. Ela se sustenta com ajuste contínuo, quando o time percebe que a ferramenta acompanha o jeito real de trabalhar e que os problemas que relata viram melhoria. Sem alguém cuidando disso depois da entrega, a adoção cai, e o retorno prometido ao board cai junto.

O que é AMS, sem a sopa de siglas

Sustentação, no vocabulário do mercado, atende pela sigla AMS (Application Management Services). Por trás do nome técnico, o trabalho é direto: manter a plataforma no ar, corrigir o que falha, adaptar o que o negócio pede e evoluir o que ficou para trás.

O mal-entendido mais comum é achar que sustentação se resume a suporte para quando algo quebra. Esse modelo reativo é o piso, não o serviço. Uma operação Salesforce bem sustentada gasta menos tempo apagando incêndio e mais tempo melhorando processo, limpando dado e preparando a base para o que vem. Corrigir mantém a luz acesa. Evoluir é o que faz a plataforma continuar valendo o que custou.

Na prática, o escopo cobre frentes que andam juntas. Monitorar a saúde da org e resolver incidentes. Gerir cada release da Salesforce antes que ela chegue à produção. Manter a higiene dos dados e a disciplina dos acessos. Ajustar processos conforme o negócio pede e desenvolver as evoluções priorizadas. É a diferença entre ter um telefone de emergência e ter um time que já conhece a sua operação quando você precisa dele.

Por que sistema vivo não tem data de entrega

Um Salesforce parado não existe por muito tempo, por três motivos que não param de agir.

O primeiro é a própria plataforma. A Salesforce entrega três releases por ano, em fevereiro, junho e outubro, aplicadas automaticamente a todas as orgs (Salesforce, 2026). Suas customizações precisam acompanhar essas mudanças, ou passam a conviver com comportamento inesperado.

O segundo é o negócio. Áreas novas, produtos novos e processos que mudam pressionam a configuração feita no projeto original. O que fazia sentido no go-live raramente continua fazendo sentido dois anos depois.

O terceiro é o dado, que envelhece sozinho. Cerca de 30% a 40% dos contatos de uma base B2B mudam de cargo ou empresa a cada ano, acompanhando um tempo médio de permanência no emprego de menos de três anos (benchmarks de data decay, 2026). A Gartner estima que dados de baixa qualidade custam, em média, US$ 12,9 milhões por ano para cada organização (Gartner, 2020). Um CRM alimenta decisão comercial, e decisão sobre dado sujo custa caro.

Some a isso o acúmulo natural de excesso. A Pendo mediu que 80% das funcionalidades de um software são raramente ou nunca usadas, e que 12% delas concentram 80% do uso (Pendo, 2019). Numa org sem curadoria, esse padrão vira campos, telas e automações mortas que ninguém lembra por que existem. Evolução contínua é o que impede a distância entre a plataforma e o negócio de crescer até virar um projeto de resgate. E se a próxima ambição da empresa for IA sobre esses dados, a régua sobe ainda mais, porque agente nenhum entrega resultado sobre uma base que ninguém cuida.

Quem é o dono do seu Salesforce?

No dia seguinte ao go-live, uma pergunta costuma ficar sem resposta clara. Quem responde por essa plataforma agora?

A consultoria de implementação cumpriu o contrato e saiu. O time interno, na maioria dos casos, não foi formado para governar a org, só para usá-la. Então cada área começa a pedir mudança direto para quem estiver disponível. Sem alguém que decida prioridade e critério, cada pedido vira uma customização isolada. Em 12 a 18 meses, a soma dessas decisões avulsas é o débito técnico que deixa a org lenta, cara e difícil de mudar.

O padrão se repete em qualquer setor. Um campo novo criado às pressas para uma campanha. Uma automação montada por um fornecedor pontual que já foi embora. Um relatório que só uma pessoa sabe interpretar. Isoladamente, cada decisão parece pequena e razoável. Somadas ao longo de um ano, viram uma org que ninguém consegue explicar por inteiro, onde toda mudança assusta porque não se sabe o que ela vai quebrar do outro lado.

Governança não significa burocracia. Significa ter definido quem decide o quê, com qual critério e em qual ritmo. É o papel que frameworks como ITIL, COBIT e PDCA cumprem, dando método para priorizar o backlog, mudar sem quebrar o que funciona e medir se a mudança gerou valor. A pergunta sobre o dono não é sobre culpa. É sobre desenhar, antes do go-live, o modelo de sustentação que vai ter responsável, SLA e cadência de evolução.

Um modelo saudável costuma ter três peças. Um responsável pela org com mandato de verdade, inclusive para dizer não a um pedido que não faz sentido. Um ritual em que as áreas trazem suas demandas e são priorizadas juntas, em vez de furar fila por proximidade. E capacidade técnica para executar com qualidade, seja de um time interno formado para isso, seja de um parceiro de sustentação. Não precisa ser pesado. Precisa existir e ter nome.

Fechamento

A sustentação decide se o investimento da implementação vai se pagar ou se corroer com o tempo. A pergunta que importa para a liderança não é quanto custa manter a plataforma. É quanto custa deixar “morrer” o que já custou caro para construir.

Vale fazer a conta pelo outro lado. Uma org que perde adoção, acumula dado sujo e trava a cada mudança não fica parada no ponto em que estava no go-live. Ela regride. E o custo de recuperar uma base já degradada, com meses de saneamento e retrabalho, costuma ser maior do que o de tê-la mantido saudável desde o começo. Sustentar sai mais barato que resgatar.

Na prática, isso significa três decisões tomadas cedo. Incluir o modelo de sustentação no business case junto com o projeto, definir quem é o dono da org antes de a consultoria sair e estabelecer um ritmo de evolução em vez de esperar a próxima crise. É esse o trabalho do Hyper Care da Maitha, que mantém, governa e evolui a operação Salesforce com método (ITIL, COBIT e PDCA), para que a plataforma acompanhe o negócio no ritmo em que ele muda.

Se o seu Salesforce já está no ar e você não sabe dizer quem é o dono dele hoje, essa é a conversa que vale a pena ter agora, não no próximo momento de dor do negócio ou dos times que interagem com a plataforma.