O erro que me custou meses de trabalho
Durante muito tempo, eu tinha um problema sério no meu processo comercial: fechava reuniões, apresentava propostas bem elaboradas, recebia feedbacks positivos — e não fechava os projetos. Minha taxa de conversão de proposta para contrato estava em torno de 18%. Para cada 10 propostas que eu enviava, 8 e meia iam para o lixo.
O custo disso não era apenas financeiro — embora fosse significativo. Era o custo de tempo e energia dedicados a elaborar propostas detalhadas para clientes que, na verdade, nunca estiveram prontos para comprar. Diagnósticos superficiais viram propostas. Propostas viram apresentações. Apresentações viram silêncio.
O turning point foi quando me aprofundei no framework SPICED — uma metodologia de qualificação comercial desenvolvida pela Winning by Design que vai muito além do clássico BANT (Budget, Authority, Need, Timeline) que eu usava antes. Com o SPICED, minha taxa de conversão foi de 18% para 54% em dois ciclos de venda. Não porque eu melhorei minha proposta — porque parei de apresentar propostas para quem não estava pronto.
Neste artigo, vou explicar exatamente como aplico o SPICED no contexto específico de consultoria de IA: como adapto cada dimensão para o perfil desse tipo de projeto, quais perguntas faço em cada etapa, e como o framework da Trilion se integra ao processo de qualificação.
O que é o SPICED e por que é superior ao BANT para consultoria de IA
O BANT (Budget, Authority, Need, Timeline) foi criado pela IBM nos anos 1960 para qualificar oportunidades de venda de hardware. Funciona razoavelmente bem para vendas transacionais com critérios objetivos. Para consultoria complexa de IA, é absolutamente insuficiente.
O problema do BANT para consultoria de IA é que ele qualifica a transação, não a situação. Você pode ter um prospect com budget, autoridade, necessidade e prazo definidos — e ainda assim o projeto vai falhar porque a organização não está pronta para mudar, o decisor não tem patrocínio interno suficiente ou o problema que eles definiram não é o problema real.
O SPICED qualifica a situação completa. As cinco dimensões são:
- S — Situation (Situação): Contexto atual do negócio, estrutura, momento, maturidade
- P — Pain (Dor): O problema real, em termos de impacto mensurável no negócio
- I — Impact (Impacto): O que acontece se a dor não for resolvida — e o que muda quando for
- C — Critical Event (Evento Crítico): O que cria urgência real — uma data, uma pressão externa, uma consequência
- E — Decision (Decisão): Como a decisão vai ser tomada, quem está envolvido, qual é o critério
Para consultoria de IA especificamente, adiciono uma sexta dimensão informal que o framework original não tem explicitamente: Readiness (Prontidão) — a capacidade organizacional de absorver e implementar uma solução de IA. Sem essa dimensão, mesmo com SPICED completo, você pode entrar em um projeto que vai travar na implementação por falta de maturidade da organização.
Como aplico cada dimensão do SPICED na prática
S — Situation: entendendo o contexto antes de qualquer coisa
A situação não é o problema. É o mapa do território onde o problema existe. Para projetos de IA, o mapeamento de situação que faço cobre:
Maturidade de dados: A empresa tem dados estruturados e histórico suficiente para suportar modelos preditivos? Já tem alguém responsável por dados internamente? Os dados de diferentes sistemas são integrados ou estão em silos? Um projeto de IA em uma empresa sem maturidade de dados mínima é um projeto de preparação de dados disfarçado de IA — e o cliente precisa saber disso antes de contratar.
Momento organizacional: A empresa está em modo de crescimento, estabilização ou crise? Projetos de IA em empresas em crise têm dinâmica completamente diferente — urgência maior, tolerância a mudança menor, budget mais restrito e sujeito a cortes. Preciso entender esse contexto para calibrar o escopo e o prazo.
Histórico com tecnologia: A empresa já passou por implementações tecnológicas relevantes? Como foram? Se há um histórico de projetos que 'não funcionaram', preciso entender o que aconteceu — porque as causas desses insucessos geralmente se repetem.
P — Pain: chegando ao problema real
A maior armadilha na qualificação de projetos de IA é aceitar o problema como o prospect o descreve na primeira reunião. A dor declarada raramente é a dor real.
Exemplo: prospect me procura dizendo que quer 'implementar IA no atendimento ao cliente para reduzir o tempo de resposta'. Dor declarada: tempo de resposta alto. Mas ao aprofundar, descubro que o problema real é churn de clientes ligado à percepção de qualidade de atendimento, e que o tempo de resposta é apenas um sintoma. A solução de IA pode ser muito diferente — e mais valiosa — do que um chatbot de atendimento.
As perguntas que uso para chegar à dor real:
- 'Quando você diz que [problema declarado] está te custando, consegue me dar um número específico?'
- 'Esse problema existe há quanto tempo? O que foi tentado antes para resolvê-lo?'
- 'Se esse problema desaparecesse amanhã, o que mudaria especificamente para a empresa?'
- 'Quem mais na empresa sente esse problema no dia a dia? Eles descrevem da mesma forma que você?'
A última pergunta é especialmente reveladora. Se o decisor descreve o problema de uma forma e os usuários operacionais descrevem de outra, há um desalinhamento interno que precisa ser endereçado antes de qualquer proposta.
'Na consultoria de IA, a dor declarada é o ponto de partida da conversa, nunca o ponto de chegada. O consultor que não questiona a dor presentada acaba propondo a solução errada para o problema errado — e isso é um fracasso garantido.'
I — Impact: quantificando o antes e o depois
O impacto é onde a conversa fica interessante do ponto de vista do negócio. Para projetos de IA, preciso quantificar dois vetores:
Impacto da inação: O que vai continuar acontecendo — e piorando — se o problema não for resolvido? Aqui uso projeções simples: se a taxa de churn atual é de 22% e o padrão histórico mostra crescimento de 2 pontos percentuais por ano, em 18 meses o churn estará em 25%. O que isso representa em MRR perdido? Esse número precisa estar na mesa antes da proposta.
Impacto da solução: Quais resultados mensuráveis a empresa pode esperar se o projeto for bem executado? Aqui tenho muito cuidado — projetos de IA têm resultado dependente de execução e de qualidade de dados, e prometer resultados específicos sem diagnóstico completo é arriscado. O que faço é apresentar benchmarks de projetos similares com disclaimers claros: 'Em projetos comparáveis, vimos redução de churn entre 30% e 50% em 12 meses. No seu caso específico, precisaríamos de um diagnóstico mais aprofundado para dar uma estimativa mais precisa.'
A Trilion me ensinou a ser rigoroso nessa etapa: o impacto precisa ser quantificado em dinheiro, não em percepção. 'Melhorar a experiência do cliente' não é impacto mensurável. 'Reduzir o CAC em 20% ao aumentar a taxa de retenção' é.
C — Critical Event: por que agora?
Esta é a dimensão que mais separa prospects que vão comprar de prospects que vão ficar em modo de 'vou pensar e te retorno'. Todo projeto de consultoria tem um custo de oportunidade temporal — adiar a decisão tem um preço. Mas o cliente só vai agir com urgência se houver um evento crítico que torne o adiamento custoso.
Para projetos de IA, os eventos críticos mais comuns que encontro:
- Um concorrente que acabou de implementar algo similar e está ganhando mercado
- Uma meta de resultado para o próximo ciclo que não será batida sem mudança de abordagem
- Uma renovação de contrato importante com cliente estratégico que está em risco
- Uma mudança de liderança que criou uma janela de decisão (novo C-level querendo marcar território com transformação digital)
- Um problema de compliance ou auditoria que pode ser endereçado com IA
Se não há um evento crítico claro, o projeto vai ficando para 'próximo trimestre' indefinidamente. Parte do meu trabalho é ajudar o prospect a ver o evento crítico que já existe mas que ele talvez não tenha reconhecido como tal.
E — Decision: mapeando o processo de compra
Em B2B complexo, especialmente para projetos de IA que envolvem mudança organizacional, raramente existe um único decisor. Existe um comitê de compra — formal ou informal — com diferentes papéis e diferentes critérios.
O mapeamento que faço cobre quatro perfis:
- Economic Buyer (EB): Quem tem a caneta para o budget. Nem sempre é quem está na reunião comigo.
- Technical Buyer (TB): Quem vai avaliar a viabilidade técnica da solução — geralmente TI, dados ou engenharia.
- User Buyer (UB): Quem vai usar ou ser impactado pela solução no dia a dia. A opinião deles pode barrar o projeto mesmo depois do EB aprovar.
- Champion (CH): Quem está me defendendo internamente, convencendo os outros de que o projeto vale a pena. Se não tenho um champion identificado, minha chance de fechar cai dramaticamente.
Sem mapear e alinhar todos esses perfis, a proposta pode ser tecnicamente perfeita e estrategicamente certeira — e ainda assim travar na etapa de aprovação interna.
'Um dos maiores erros que cometi no começo foi tratar projetos de IA como decisão unilateral do CEO ou diretor que me contatou. Na prática, um projeto de IA que não tem a TI alinhada vai travar na implementação. Um projeto que não tem o time operacional alinhado vai ser sabotado no uso. Mapear o comitê de compra é tão importante quanto mapear o problema.'
A dimensão extra: Readiness (Prontidão organizacional)
Como mencionei, adiciono ao SPICED uma dimensão de prontidão organizacional específica para projetos de IA. Ela avalia:
Maturidade de dados: Já detalhado acima — qualidade, histórico, governança.
Capacidade de absorção de mudança: A organização tem histórico de implementações bem-sucedidas? A liderança tem autoridade e vontade de sustentar a mudança além do projeto inicial?
Recursos internos para suporte: Quem vai manter os modelos depois que eu sair? Há alguém com capacidade técnica mínima para entender e usar o que vou entregar?
Se a prontidão está abaixo de um threshold que defino internamente (uma pontuação composta de 1 a 10 nas três dimensões), não apresento proposta de projeto completo. Apresento uma proposta de capacitação e preparação — que pode ser o ponto de entrada para o projeto maior 3 a 6 meses depois.
Como o framework da Trilion se integra ao SPICED
O framework Trilion que uso na consultoria tem um componente de diagnóstico de prontidão que é complementar ao SPICED. Enquanto o SPICED avalia a oportunidade de negócio, o diagnóstico Trilion avalia a capacidade da organização de capturar valor de um projeto de IA.
Nos projetos mais complexos, uso as duas ferramentas em sequência: SPICED para qualificar a oportunidade e decidir se apresento proposta, diagnóstico Trilion para calibrar o escopo e a abordagem da proposta. O resultado é uma proposta que não apenas descreve o que vou fazer, mas justifica por que aquele escopo específico é o adequado para aquela organização específica naquele momento.
Isso muda completamente a percepção do cliente sobre a proposta. Em vez de parecer que estou vendendo um serviço, pareço que estou prescrevendo um tratamento baseado em diagnóstico.
O template de qualificação que uso
Para cada prospect, mantenho um documento de qualificação que acompanha a evolução das conversas. As colunas são as dimensões do SPICED mais Readiness — com espaço para evidências (o que o prospect disse), lacunas (o que ainda não sei) e próximos passos para preencher as lacunas.
A regra que aplico: só apresento proposta quando todas as dimensões têm evidências documentadas. Se alguma dimensão está em branco ou com dúvida, a próxima reunião tem como objetivo preencher essa lacuna — não avançar para a proposta.
Isso pode parecer que desacelera o processo comercial. Na prática, acelera — porque elimina o tempo perdido em propostas que não fecham e em projetos que começam sem o alinhamento necessário para ser bem executados.
Os números depois de adotar o SPICED
Para fechar com concretude: minha taxa de conversão foi de 18% para 54% em dois ciclos de venda completos. Mais importante: minha taxa de satisfação de clientes em projetos entregues subiu, porque parei de aceitar projetos onde as condições de sucesso não estavam presentes.
O ticket médio também aumentou — não porque aumentei o preço, mas porque o SPICED me ajuda a vender o projeto certo, não o projeto mínimo que o cliente está disposto a pagar. Quando você demonstra com profundidade que entende a dor e o impacto, a conversa de preço muda.
'O SPICED não é uma técnica de vendas. É uma metodologia de diagnóstico comercial. A diferença é sutil mas fundamental: você não está tentando convencer ninguém — você está avaliando se existe uma oportunidade genuína de gerar valor.'
Próximos passos
Se você quer ver como o SPICED se aplica em um caso concreto de consultoria de IA, tenho um exemplo que pode acelerar muito a sua curva de aprendizado.
Ver exemplo prático — acesse um case completo de qualificação SPICED aplicado a um projeto de consultoria de IA B2B, com o documento de qualificação preenchido e a proposta que resultou do processo.
Ou, se preferir discutir como adaptar o SPICED para o seu perfil de clientes e tipo de projeto, entre em contato diretamente.
