A Resposta Curta
As propostas de diferentes integradores Salesforce quase sempre parecem semelhantes: as mesmas palavras, como Discovery, Agile, Melhores Práticas (Best Practice), e a mesma promessa de "suporte próximo". A verdadeira diferença só é revelada ao confrontar cada proposta com perguntas concretas que expõem a forma de pensar do fornecedor, e não apenas o que ele oferece. O objetivo das 15 perguntas seguintes é identificar lacunas antes da assinatura, e não depois que o projeto já está travado.
As perguntas são divididas em seis tópicos: Equipe, Metodologia, Arquitetura, Dados, Termos Comerciais e Continuidade. Cada pergunta é acompanhada de uma breve explicação de sua importância e de uma descrição de como soa uma resposta fraca – para facilitar sua identificação em tempo real, seja em uma reunião ou em um documento de proposta.
As implicações práticas da escolha para todo o processo de implementação foram detalhadas separadamente em Empresa de Implementação Salesforce.
Por que 15 Perguntas e Não uma Lista de Requisitos Técnicos
Uma lista de requisitos técnicos — quantos Sandboxes, quais licenças, tempos de SLA — é importante, mas não suficiente. Ela verifica o que o fornecedor diz que fará, não como ele lidará com a situação em que o plano original se mostra impreciso. As perguntas aqui foram escolhidas porque revelam padrões de trabalho: como a equipe documenta decisões, como lida com dados inconsistentes e o que acontece quando algo não sai como planejado.
Tabela Resumo: Resposta Forte vs. Resposta Fraca
| Tópico | Resposta Forte Soa Assim | Resposta Fraca Soa Assim |
|---|---|---|
| Equipe | "A consultora X lidera a arquitetura, o desenvolvedor Y executa. Enviaremos CV e permitiremos uma breve entrevista." | "Temos uma equipe experiente, alocaremos o mais adequado no momento do Kickoff." |
| Metodologia | "Sprints de duas semanas, Demo real ao final de cada Sprint, Backlog compartilhado no Jira." | "Trabalhamos com metodologia Agile, é flexível e se adapta a qualquer projeto." |
| Arquitetura | "Construiremos um ADR para cada decisão central, incluindo a alternativa rejeitada e o motivo." | "Escolheremos a melhor solução com base em nossa experiência." |
| Dados | "Executaremos um Data Profiling antes da proposta final, apresentaremos a qualidade das fontes." | "Lidaremos com a limpeza dos dados durante o desenvolvimento." |
| Comercial | "Preço fixo para escopo definido, horas extras conforme Change Request documentado." | "T&M flexível para não restringir vocês." |
| Continuidade | "Documento de transição, treinamento para Admin interno, duas semanas de Hypercare após o Go Live." | "Estamos sempre aqui para vocês, não há necessidade de protocolo de desligamento." |
Equipe: Quem Realmente Trabalhará no Projeto
1. Quem realmente acompanhará o projeto, não apenas na proposta?
Esta pergunta é crucial porque muitas propostas apresentam o membro sênior da equipe na reunião de vendas e o substituem por um consultor júnior após a assinatura. Uma resposta forte inclui nomes, cargos e a porcentagem de dedicação alocada. Uma resposta fraca soa como "selecionaremos o mais adequado de acordo com a disponibilidade" — ou seja, não há alocação real até o último momento.
2. Quantos projetos paralelos cada consultor gerencia no mesmo período?
Um consultor que gerencia cinco projetos simultaneamente não pode dedicar atenção aos detalhes. Uma resposta forte reconhecerá a limitação e apresentará um número razoável (geralmente dois a três projetos). Uma resposta fraca evade ou responde "depende da carga de trabalho", sem um número concreto.
3. O que acontece se o consultor líder sair no meio do projeto?
Uma resposta forte descreve um processo de transição documentado, um Overlap de duas semanas e documentação contínua que permite a substituição sem perda de conhecimento. Uma resposta fraca afirma que "isso quase nunca acontece conosco" sem um plano de contingência. Mais detalhes sobre uma estrutura de trabalho eficaz com um consultor Salesforce podem ser encontrados em nosso artigo.
Metodologia: Como o Trabalho é De Fato Conduzido
4. Como é um Sprint típico? O que acontece se algo não estiver pronto a tempo?
Uma resposta forte descreve o Sprint Planning, Daily Scrum, Demo e Retrospective, e também o que acontece quando uma tarefa trava — se ela é adiada para o próximo Sprint de forma transparente. Uma resposta fraca se contenta com "trabalhamos com Agile" sem detalhar um único ritual concreto.
5. Como é a comunicação diária? Canal, frequência e responsável.
Uma resposta forte detalha o canal (Slack, Teams), reunião de status semanal fixa e um único ponto de contato para escalonamento. Uma resposta fraca diz "estaremos sempre disponíveis por e-mail", o que na prática significa que não há SLA para resposta.
6. Como o trabalho é testado antes de ser apresentado ao cliente como concluído?
Uma resposta forte descreve um teste de QA interno, Checklist de aceitação e verificação de acessibilidade e permissões antes do Demo. Uma resposta fraca admite indiretamente que o primeiro Demo para o cliente é também o primeiro teste.
Arquitetura: Como as Decisões São Construídas
7. Como as decisões arquitetônicas são documentadas e quem as aprova?
Uma resposta forte apresenta um modelo de decisão conciso — problema, alternativas, escolha e razão — que é salvo e acessível ao cliente. Uma resposta fraca afirma "escolhemos a solução certa" sem documentar por que as outras alternativas foram rejeitadas.
8. Como a solução lidará com a carga e o crescimento em dois a três anos?
Uma resposta forte se refere às limitações de Governor Limits, ao volume de dados esperado e ao planejamento para expansão. Uma resposta fraca responde "Salesforce é escalável por natureza" sem conectar isso ao caso específico.
9. O que acontece quando um novo requisito entra em conflito com uma decisão anterior?
Uma resposta forte descreve um processo de Change Request que avalia o impacto sobre o que já foi construído. Uma resposta fraca simplesmente promete "nos adaptaremos a qualquer mudança", o que geralmente resulta em uma dívida técnica que se acumula silenciosamente.
Dados: O Ponto Onde a Maioria dos Projetos Engasga
10. Como a qualidade dos dados é verificada antes de iniciar a construção?
Uma resposta forte inclui uma etapa de Data Profiling precoce — duplicidades, campos vazios, formatos inconsistentes — e um cronograma para correção. Uma resposta fraca adia isso para "lidaremos com isso durante a migração", o que quase sempre prolonga o projeto.
11. Qual é a fonte de verdade para cada tipo de dado, e como a duplicação entre sistemas é tratada?
Uma resposta forte identifica antecipadamente quais sistemas "vencem" em caso de conflito (por exemplo, ERP versus Salesforce para clientes existentes) e documenta a regra. Uma resposta fraca responde "Salesforce será a fonte de verdade" de forma abrangente, sem verificar se isso é válido para todos os objetos.
12. Qual é o plano de backup e recuperação, e quem é responsável por ele após a implementação?
Uma resposta forte detalha ferramentas de backup, frequência e quem executa a recuperação de fato quando necessário. Uma resposta fraca presume que a Salesforce "já cuida disso" sem distinguir entre backup da plataforma e backup em nível organizacional.
Comercial e Continuidade: O Que Acontece Após a Assinatura
13. Como o preço é estruturado — fixo, T&M ou combinado, e o que está realmente incluído?
Uma resposta forte detalha o preço em Workflows com horas estimadas para cada um, e define o que é considerado Change Request com custo adicional. Uma resposta fraca apresenta um único número global sem detalhamento, o que dificulta a comparação entre propostas.
14. O que acontece se o projeto exceder o prazo — quem arca com o custo?
Uma resposta forte diferencia entre um desvio causado pelo fornecedor (às suas custas) e um desvio causado por uma mudança de requisitos do cliente (pago). Uma resposta fraca é formulada de forma ambígua, permitindo que o fornecedor repasse qualquer atraso ao cliente.
15. O que acontece no final do projeto — qual suporte, por quanto tempo e a que custo?
Uma resposta forte inclui um período de Hypercare definido (geralmente duas a quatro semanas), um documento de transição e treinamento para o Admin interno. Uma resposta fraca promete "suporte contínuo" sem um custo, escopo ou data de término claros. Mais detalhes sobre a formulação correta de cláusulas contratuais como essas podem ser encontrados em SOW Projeto Salesforce.
Cenário Organizacional de Exemplo
Uma empresa de serviços financeiros recebeu três propostas para integrar dois sistemas CRM antigos em um único Salesforce. Duas das propostas tinham preços 20% a 25% mais baixos que a terceira. Quando o CIO fez a pergunta 10 (verificação da qualidade dos dados antecipadamente), os dois fornecedores mais baratos responderam "lidaremos com isso como parte da migração" — enquanto o fornecedor mais caro apresentou um plano de Data Profiling de uma semana antes que o valor final fosse acordado.
A organização escolheu o fornecedor mais caro. A semana de Data Profiling revelou aproximadamente 12.000 registros duplicados e um campo de data em formato inconsistente em 3 das fontes de dados. Essa correção inicial foi incluída no preço original; nos outros dois fornecedores, ela teria sido descoberta durante a migração, como uma mudança de escopo com custo adicional.
A lição aqui não é "o barato é sempre ruim" — mas sim que a diferença entre uma resposta detalhada e uma resposta geral vale dinheiro real, e isso só pode ser revelado com perguntas focadas antes da assinatura, e não depois.
Checklist para Comparação de Propostas
- ☐ Recebemos nomes e porcentagens de dedicação da equipe proposta, não apenas uma descrição geral.
- ☐ Verificamos como as decisões arquitetônicas são documentadas por cada fornecedor.
- ☐ Solicitamos um plano de Data Profiling antes da assinatura.
- ☐ Detalhamos o preço por Workflows com horas estimadas.
- ☐ Esclarecemos quem arca com o custo de desvios não causados pelo cliente.
- ☐ Recebemos uma descrição explícita do período de Hypercare e suas condições.
- ☐ Verificamos referências de clientes com projetos de escopo semelhante.
- ☐ Confirmamos que o consultor apresentado na reunião será o que realmente trabalhará no projeto.
- ☐ Verificamos quantos projetos paralelos cada consultor líder gerencia.
- ☐ Definimos antecipadamente qual será a evidência de sucesso ao final do projeto.
Observação Final: As Perguntas São uma Ferramenta, Não um Ritual
O objetivo das 15 perguntas não é constranger um fornecedor ou prolongar desnecessariamente o processo de seleção. É revelar antecipadamente onde a proposta se baseia em uma suposição não documentada. Um bom fornecedor não se ofenderá com as perguntas — ele ficará feliz em respondê-las porque elas reduzem riscos para ele no futuro. Um fornecedor que as evade, ou que responde com generalidades repetitivas, oferece com isso uma resposta por si só.
Quando há falta de capacidade interna para conduzir um processo de comparação como este por conta própria, o serviço de consultoria e discovery é o caminho prático a seguir — incluindo a construção de um Scorecard ponderado, acompanhamento nas reuniões com os proponentes e comparação das respostas com critérios objetivos.
Fontes Profissionais
- HPI Pro – Consultoria e Discovery — https://hpi.pro/consulting-discovery
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Serviços Salesforce — https://hpi.pro/services