O Problema Começa no Pedido, Não na Execução
Quando uma organização procura um fornecedor Salesforce, o pedido inicial é quase sempre "uma proposta de implementação". Em muitos casos, este não é o pedido correto. Algumas organizações já possuem um sistema e o que falta é um diagnóstico; outras ainda não definiram o processo que desejam; e há aquelas cujo sistema funciona razoavelmente bem, mas lhes falta a manutenção contínua.
Solicitar o tipo de serviço errado resulta em um projeto que entrega um produto irrelevante, e isso geralmente só é descoberto meses depois. Este guia mapeia os quatro tipos de serviço com base no sintoma que leva uma organização a buscar ajuda.
Mapeamento Rápido por Sintoma
| O que você diz | O que provavelmente é necessário | O principal produto final |
|---|---|---|
| "Trabalhamos no Excel e precisamos organizar" | Análise e implementação em fases | Mapa de processos, modelo de dados, primeira fase em produção |
| "Temos Salesforce, mas ninguém usa" | Health Check e plano de adoção | Relatório de descobertas priorizadas e ordem de correção |
| "O sistema está lento e quebrado após anos" | Diagnóstico técnico e plano de dívida técnica | Mapeamento de dívidas, recomendação de refatoração ou reconstrução |
| "O projeto está parado há seis meses" | Recuperação de projeto | Avaliação de status, decisão de continuação, plano de estabilização |
| "Precisamos de alguém para fazer a manutenção contínua" | Suporte ou Managed Services | SLA, cadência de lançamentos, ponto de entrada para solicitações |
| "O CEO quer saber se o Salesforce é adequado" | Consultoria breve, não um projeto | Parecer e recomendação de adequação |
Esta tabela é suficiente para a maioria dos casos. O restante do artigo detalha exatamente o que solicitar em cada serviço.
Serviço 1: Consultoria e Análise de Requisitos
Quando solicitar: Quando o processo ainda não está claro, qual é a fonte da verdade e quais são os limites do projeto; ou quando há um conflito interno entre departamentos.
O que deve estar no produto final: Um mapa de processos em nível de decisão, um modelo de dados principal, um modelo de permissões, um mapa de sistemas, critérios de aceitação e métricas base. Um produto que não inclua os primeiros cinco itens não é uma análise de requisitos, mas um resumo de reuniões.
Escopo típico: Entre duas e oito semanas, dependendo do número de processos interdepartamentais. O que exatamente deve ser recebido e como identificar um bom consultor está detalhado no Guia de Consultoria Salesforce.
Serviço 2: Implementação e Execução
Quando solicitar: Quando a análise de requisitos foi concluída, os proprietários do processo são conhecidos e foi decidido o que entra na primeira fase.
O que deve estar no contrato: Definição de fases, critérios de aceitação para cada fase, responsabilidade pela migração de dados, mecanismo de solicitação de mudança, período de garantia e plano de transferência de conhecimento. A ausência dos dois últimos é o fator mais comum para a dependência de longo prazo de um fornecedor.
Sinal de alerta: Uma proposta que detalha o número de horas de desenvolvimento, mas não especifica o que é considerado "concluído".
Serviço 3: Health Check e Diagnóstico
Quando solicitar: Quando o sistema está em funcionamento, mas algo não está funcionando — baixa adoção, dados não confiáveis, desempenho ou incapacidade de fazer mudanças sem causar problemas.
O que deve estar no produto final: Uma lista de descobertas com gravidade, impacto nos negócios, esforço de correção e ordem recomendada. Um relatório que lista cinquenta descobertas sem priorização não é útil; um relatório que diz "primeiro, corrija estes três e não mexa nos outros ainda" é um produto.
Diferença importante: Um Health Check não é um projeto de correção. Ele visa permitir a decisão sobre o que corrigir e em que ordem.
Serviço 4: Suporte, Manutenção e Managed Services
Quando solicitar: Quando o sistema está em produção e não há uma equipe interna que possa assumir a manutenção contínua.
O que deve ser definido: O que está incluído e o que não está. A distinção crítica é entre a correção de um bug, uma pequena alteração de configuração e o desenvolvimento de uma nova funcionalidade. Um contrato que agrupa os três em um "banco de horas" tende a explodir em um trimestre, porque o desenvolvimento de novas funcionalidades consome as horas destinadas ao suporte.
Além disso: Tempos de resposta por gravidade, cadência regular de lançamentos e propriedade da documentação.
Combinação Correta de Serviços
A maioria das organizações não consome apenas um serviço, mas uma sequência. A sequência saudável se parece com isto:
- Consultoria breve para decisão de adequação — dias, não semanas.
- Análise de requisitos focada na primeira fase.
- Implementação em fases.
- Período de estabilização definido após a entrada em produção.
- Suporte contínuo.
- Health Check periódico, preferencialmente não realizado por quem construiu.
O sexto ponto é o mais frequentemente ignorado, e é o mais barato.
Exemplo Ilustrativo: Rede de Hotéis Boutique
O cenário é hipotético e serve para ilustração. Uma rede com quatro hotéis procurou três fornecedores solicitando uma proposta para a implementação do Salesforce para gestão de eventos e solicitações de hóspedes. As duas primeiras propostas eram para uma implementação completa com escopo de muitos meses.
O terceiro fornecedor fez uma única pergunta: quem define o que é um "evento" — o gerente de eventos de cada hotel ou a sede. A resposta foi que não havia uma definição compartilhada. Nesse caso, uma implementação completa teria criado quatro sistemas diferentes sob o mesmo nome. A rede solicitou, em vez disso, uma análise de requisitos breve, obteve uma definição acordada e um modelo de dados, e só então prosseguiu com a implementação — com um escopo menor do que o originalmente proposto.
Sinais de Alerta ao Solicitar um Serviço
- A proposta precifica horas, mas não define o produto final.
- A mesma proposta inclui análise de requisitos e implementação em um único valor, sem um marco que permita a interrupção.
- Não há período de garantia definido após a entrega.
- Não há cláusula de transferência de conhecimento e documentação de propriedade da organização.
- O fornecedor se recusa a fornecer um parecer arquitetônico antes da assinatura.
As ferramentas para verificar o próprio fornecedor — e não apenas o serviço — são detalhadas no Guia de Escolha de Empresa de Implementação Salesforce.
Do Pedido ao Documento
Uma vez decidido qual serviço é necessário, o próximo passo é formulá-lo de forma que as propostas recebidas sejam comparáveis. A estrutura do documento de solicitação e a lista de perguntas a serem incluídas estão detalhadas no Guia de RFP para Implementação Salesforce, e as cláusulas que devem ser incluídas no próprio contrato estão detalhadas no Guia de Contrato e SOW.
Próximo Passo
Antes de solicitar uma proposta, escreva em uma frase o sintoma — não a solução. "Não temos uma visão unificada do cliente entre vendas e serviços" leva a um pedido diferente de "Queremos Salesforce". Essa frase vale mais do que qualquer documento de requisitos que venha a ser escrito depois.