O Que Realmente Fragiliza Projetos de Salesforce Contratualmente
Quase nenhuma disputa em um projeto Salesforce começa com a pergunta "quanto custa". Ela começa com a pergunta "está finalizado?". O fornecedor acredita que o produto foi entregue; a organização acredita que não está utilizável. Ambas as partes estão certas dentro de suas próprias percepções, pois ninguém definiu previamente o que seria considerado concluído.
Daí se deriva um princípio que orienta todas as seções deste artigo: um bom contrato não protege sua parte em uma disputa — ele previne a disputa.
Doze Cláusulas Essenciais
1. Definição de Aceitação para Cada Entrega
A cláusula mais importante. Para cada entrega, é necessário um critério observável: não "tela de gerenciamento de clientes", mas sim "usuário no perfil X pode realizar o cenário Y e obter o resultado Z, conforme definido nos critérios de aceitação aprovados".
Redação recomendada: um período de teste definido a partir da data de entrega, ao final do qual o cliente aprova ou detalha por escrito as lacunas. O silêncio após o período é considerado aceitação — uma cláusula que protege o fornecedor e gera disciplina no cliente.
2. Mecanismo de Solicitação de Mudança
Define quem pode solicitar, quem avalia, em quanto tempo e por qual tarifa. A tarifa deve ser estabelecida na assinatura do contrato e não no momento da necessidade.
3. Dependência Bidirecional
A maioria dos contratos define o que acontece quando o fornecedor atrasa, mas não o que acontece quando o cliente atrasa. Resultado: quando a organização atrasa uma aprovação, o fornecedor absorve o impacto — e depois o repassa através de solicitações de mudança.
Redação equilibrada: o cronograma está condicionado à receptividade definida do cliente (tempo de aprovação, disponibilidade do proprietário do processo, entrega de dados), e um atraso excedente realoca o marco mediante notificação por escrito.
4. Propriedade do Código, Configuração e Documentação
Separação entre entregas personalizadas e componentes genéricos do fornecedor, com licença de uso vitalícia para os componentes genéricos, não condicionada à continuidade do relacionamento.
5. Documentação Como Entrega Obrigatória
A documentação que não é definida como uma entrega com critérios de aceitação — não será escrita, ou será escrita na última semana. Defina o mínimo: decisões arquitetônicas, modelo de dados, mapeamento de integrações, procedimentos operacionais.
6. Garantia e Correção de Defeitos
Um período definido, e uma distinção clara entre defeito e mudança. Uma definição que funciona: uma lacuna entre o comportamento real e os critérios de aceitação aprovados é um defeito.
7. Profissionais Chave
Nomes, percentual de alocação, aviso prévio para substituição e nível profissional equivalente com aprovação do cliente.
8. Acessos, Ambientes e Segurança da Informação
Quem tem acesso a quais ambientes, por quanto tempo, o que acontece com os acessos ao término e como os dados reais são tratados em ambientes que não são de produção.
9. Conformidade com Requisitos Regulatórios e de Privacidade
Local de armazenamento, tratamento de dados pessoais, direito de auditoria e comunicação de incidentes de segurança. Em organizações regulamentadas, esta é uma cláusula que exige redação específica e não um modelo padrão.
10. Portas de Decisão e Pontos de Saída
Direito de interromper ao final de um marco definido, com um acordo de pagamento pré-determinado. Uma cláusula como esta reduz o risco de ambas as partes, e por isso um bom fornecedor não se oporia a ela.
11. Transferência de Conhecimento
Não "treinamento", mas sim: número de horas, para quem, sobre o quê e qual a entrega. É desejável que a transferência ocorra ao longo do projeto e não se concentre apenas no final.
12. Finalização e Transição
Lista do que será entregue, formato, período de transição e tarifa para horas de suporte na transição. Esta é a cláusula que ninguém quer discutir no momento da assinatura, e é exatamente por isso que vale a pena insistir nela.
Mapa de Risco: O Que Cada Cláusula Previne
| Cláusula | Falha Prevenida | Custo da Ausência |
|---|---|---|
| Definição de Aceitação | Discussão sobre "finalizado" | Atraso no pagamento e na entrada em operação |
| Pedidos de Mudança | Precificação em crise | Custo adicional descontrolado |
| Dependência Bidirecional | Acusações mútuas sobre atraso | Ajuste de cronograma sem transparência |
| Propriedade e Documentação | Dependência do fornecedor | Alto custo na troca de fornecedor |
| Profissionais Chave | Troca silenciosa de equipe | Perda de relacionamento e conhecimento |
| Garantia | Discussão de defeito vs. alteração | Pagamento duplo por correção |
| Saída | Negociação em posição de fraqueza | Custo de transição inesperado |
Redações a Serem Evitadas
- "O fornecedor realizará o trabalho com a profissionalidade usual" — não pode ser aplicada sem um critério.
- "As partes concordarão posteriormente sobre..." — cada cláusula como esta é uma disputa futura em potencial.
- "Sujeito à cooperação total do cliente" — sem definir o que isso significa, é uma proteção unilateral.
- "A entrega será realizada ao final do projeto" — sem definir o que é o final.
- Cronograma de pagamentos baseado em datas de calendário em vez de aceitação.
Exemplo Ilustrativo: Rede de Varejo
O cenário é hipotético e destinado à ilustração. Uma rede varejista assinou um SOW que incluía "migração de dados de clientes de um sistema existente". A suposição da organização era que a migração incluía a limpeza de duplicatas; a suposição do fornecedor era que ele migraria o que lhe foi entregue.
Na prática, centenas de milhares de registros com duplicatas foram migrados. Ambas as partes leram a mesma frase e a entenderam de forma oposta. Não havia no contrato uma linha que definisse o que era considerado um registro válido.
A correção feita nos acordos subsequentes dessa rede foi esta: um anexo que define um limiar de qualidade mensurável para o carregamento — taxa de registros que passam por validação, regras de identificação de duplicatas e quem aprova. Este anexo substituiu dezenas de horas de discussão.
O Que Verificar Antes de Assinar
- Cada entrega da proposta aparece no SOW com um critério de aceitação.
- Toda suposição apresentada na proposta aparece como uma suposição explícita no contrato.
- O cronograma de pagamentos está vinculado à aceitação.
- Há uma cláusula de saída e uma cláusula de transferência de conhecimento.
- A definição de defeito é clara o suficiente para decidir um caso ambíguo.
O que foi acordado na comparação das propostas, mas não foi incluído no contrato — simplesmente não existe. O processo de comparação em si está detalhado no Guia de Comparação de Propostas Salesforce, e a base para a formulação dos requisitos é estabelecida já no documento de solicitação, conforme detalhado no Guia de RFP.
A Conexão com a Seleção do Fornecedor
Algumas das cláusulas aqui também servem como ferramentas de avaliação: um fornecedor que se opõe a uma cláusula de propriedade da documentação ou a uma cláusula de saída está dizendo algo sobre seu modelo de trabalho. A combinação de avaliação profissional e prontidão contratual é pontuada em conjunto no Guia de Scorecard para Seleção de Fornecedores, e os critérios amplos para a avaliação da empresa estão resumidos no Guia de Escolha de uma Empresa de Implementação Salesforce. A adequação do tipo de contratação ao tipo de serviço adquirido está detalhada no Guia de Serviços Salesforce.
Próximo Passo
Pegue o SOW que você tem em mãos e marque todos os locais onde está escrito "será entregue" ou "será executado" sem que esteja ao lado como se saberá que isso aconteceu. Cada marcação dessas é uma disputa potencial, e cada uma delas leva cinco minutos para ser corrigida agora.