Funil de [CLIENTE] · estado atual.
Mapa do funil como ele é hoje — não como o cliente acha que é. 6 etapas, com problemas e métricas reais por etapa. Base pra decidir o que entra no Build.
Pipeline em uma linha — fonte da verdade das etapas
Edite o nome das etapas, adicione novas com +, remova com ×. As Matrizes AS-IS e TO-BE refletem essas etapas automaticamente — adicionar etapa aqui cria linha lá; remover apaga; renomear atualiza nas duas.
Resumo do diagnóstico
Volume médio de entrada
- ~ XX leads novos / mês
- ~ XX MQLs (XX% conversão)
- ~ XX reuniões realizadas (XX% conversão)
Etapa 04 — Reunião realizada
- 3 dores mapeadas
- Maior queda de conversão (XX%)
- Atacar primeiro no Build
Tempo médio
- Lead → Cliente: ~XX dias
- Reunião → Proposta: ~XX dias
- Proposta → Fechamento: ~XX dias
O que não conseguimos ver
- Origem do lead em XX% dos casos
- Motivo de perda em XX% dos descartes
- Tempo em cada etapa não rastreado
Título do card
- Item 1
- Item 2
- Item 3
Título do card
- Item 1
- Item 2
- Item 3
Título de problema
- Item 1
- Item 2
- Item 3
Título do card
- Item 1
- Item 2
- Item 3
Como ler este documento. Cada etapa tem 5 dimensões mapeadas: definição atual, gatilhos de avanço, campos obrigatórios, problemas identificados, métricas atuais. As dores aparecem em destaque âmbar — são os pontos a priorizar no Build. Cards do Resumo: passe o mouse sobre cada um pra ver o × de remover, ou use + Adicionar card pra criar novos. Use a classe problem (ou edite o eyebrow) pra marcar cards como dor.
Síntese de problemas.
Visão consolidada das 8 dores mapeadas no funil, ordenadas por severidade. Esta tabela é o input direto pro escopo do Build.
| # | Etapa | Dor | Severidade | Ação proposta no Build |
|---|---|---|---|---|
| 1 | 04 · Reunião realizada | Sem registro estruturado da reunião | Alta | Template de notas estruturado + integração com HubSpot |
| 2 | 04 · Reunião realizada | Próximo passo fica vago | Alta | Regra: toda reunião termina com data marcada ou descarte explícito |
| 3 | 05 · Proposta enviada | Sem cadência de follow-up | Alta | Cadência padrão de 10 touchpoints (já documentada na Parte 2) |
| 4 | 04 · Reunião realizada | Discovery não é diagnóstico | Média | Roteiro de reunião com bloco obrigatório de descoberta antes de pitch |
| 5 | 05 · Proposta enviada | Proposta fica subjetiva | Média | Template de proposta + variáveis (já implementado na Parte 2) |
| 6 | 02 · MQL qualificado | Critério MQL é subjetivo | Média | Checklist objetivo no formulário + automação de qualificação |
| 7 | 01 · Lead novo | Origem ausente em 40% dos leads | Média | Campo de origem obrigatório em todo cadastro manual |
| 8 | 01 · Lead novo | Sem deduplicação automática | Baixa | Regra de merge no HubSpot por e-mail corporativo |
Próximo passo. Este AS-IS vira input do funil TO-BE (template separado). As 3 dores de severidade Alta são prioridade no Build — atacam o gargalo principal (Etapa 04 + cadência de fechamento).
Motivos de perda + campos condicionais.
Mapa dos motivos pelos quais um deal é perdido. Cada motivo tem campos condicionais que devem ser preenchidos quando o deal é marcado como perdido — esses campos viram propriedades obrigatórias no HubSpot.
12 etapas do funil — onde a perda pode acontecer
Motivos catalogados
Lista padrão. Edite as células ou adicione novos motivos. Os campos condicionais 1 e 2 viram propriedades obrigatórias no HubSpot quando o deal é marcado com esse motivo.
| Motivo de perda | Etapas (uma ou mais — separe por vírgula) | Campo condicional 1 | Campo condicional 2 | Campo condicional 3 | Campo condicional 4 | Campo condicional 5 | Campo condicional 6 | Campo condicional 7 | Campo condicional 8 | Campo condicional 9 | Campo condicional 10 | Campo condicional 11 | Campo condicional 12 | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Sem orçamento | 04, 05 | Orçamento disponível (R$) | Reabrir contato em N meses | |||||||||||
| Não é prioridade agora | 02, 04, 05 | Quando vira prioridade | Trigger esperado | |||||||||||
| Foi pra concorrente | 04, 05 | Qual concorrente | Por que escolheu | |||||||||||
| Sem fit (ICP) | 01, 02 | Por que não fit | Reclassificar? | |||||||||||
| Decisor saiu da empresa | 02, 04, 05 | Quando volta novo decisor | Substituto identificado | |||||||||||
| Sem retorno (frio) | 04, 05 | Última atividade registrada | Quantos toques tentados |
Como usar. Quando o deal for marcado como perdido no HubSpot, o motivo escolhido aciona os campos condicionais correspondentes — vendedor é obrigado a preencher antes de salvar. Isso protege contra "perdido" sem contexto, que destrói análise de motivos depois.
SLA de estagnação por etapa.
Tempo máximo que um deal pode ficar parado em cada etapa antes de ser sinalizado como estagnado. Cada etapa pode ter SLA diferente — etapas iniciais geralmente toleram menos que etapas finais.
| Etapa | SLA (dias) | Ação quando estagna | Responsável |
|---|---|---|---|
| 01 · Lead novo | 3 | SDR contata pelo canal de origem | SDR |
| 02 · MQL qualificado | 5 | Reescala pra gestor revisar qualificação | Gestor |
| 03 · Reunião agendada | 7 | Reagendar ou descartar | SDR |
| 04 · Reunião realizada | 5 | Definir próximo passo concreto | AE / Closer |
| 05 · Proposta enviada | 28 | Marcar como frio (cadência completa) | AE / Closer |
| 06 · Cliente fechado | — | — | — |
| 07 · Etapa 07 | |||
| 08 · Etapa 08 | |||
| 09 · Etapa 09 | |||
| 10 · Etapa 10 | |||
| 11 · Etapa 11 | |||
| 12 · Etapa 12 |
Como funciona no HubSpot. Cada etapa do pipeline ganha uma propriedade "Última atividade" + automação que checa diariamente se a diferença entre hoje e essa data ultrapassou o SLA. Quando ultrapassa, dispara a ação configurada (criar tarefa, notificar gestor, mover de estágio).
Automações por etapa.
Mapa de automações que rodam em cada etapa do funil. Trigger (gatilho) + ação automática + executor (HubSpot, agente Claw, manual). Adicione quantas linhas precisar — cada etapa pode ter várias automações.
| Etapa | Gatilho | Ação | Executor | |
|---|---|---|---|---|
| 01 · Lead novo | Lead criado | Atribuir SDR via round-robin + e-mail de boas-vindas | HubSpot | |
| 02 · MQL qualificado | Form respondido com critérios mínimos | Notificar SDR no Telegram + criar tarefa | Claw | |
| 03 · Reunião agendada | Slot escolhido no HubSpot Meetings | E-mail de confirmação + lembrete D-1 + lembrete D-1h | HubSpot Meetings | |
| 04 · Reunião realizada | Status do meeting marcado como "Held" | Criar tarefa de envio de proposta em D+2 | HubSpot | |
| 05 · Proposta enviada | Deal movido pra "Proposta enviada" | Iniciar cadência manual de 10 touchpoints (T01 D+0) | Manual / Ruy | |
| 06 · Cliente fechado | Deal Won + 1ª parcela paga | Mover pra estágio "Cliente · Onboarding" + notificar entrega | HubSpot |
Como ler. Cada linha é uma regra "QUANDO X ACONTECE, FAZER Y, EXECUTADO POR Z". Automações com Executor "Manual" indicam tarefas humanas recorrentes — candidatas pra automação futura. Executor "Claw" depende do agente qualificador estar ativo.
Propriedades da operação.
Mapa das propriedades (campos customizados) usadas na operação do cliente. Cada propriedade tem tipo de campo, valores possíveis (quando aplicável), objeto principal onde vive e quais outros objetos devem refletir o valor.
Tipos comuns no HubSpot: Single-line text, Multi-line text, Dropdown, Multi-select, Checkbox, Number, Date, Date+Time, Score. Objetos: Contact, Company, Deal, Ticket, Custom.
| Propriedade | Tipo de campo | Valores (se dropdown/select) | Objeto principal | Reflete em | Etapas obrigatórias (vírgula) | O campo existe? | |
|---|---|---|---|---|---|---|---|
| Origem do lead | Dropdown | LinkedIn · Formulário · Indicação · Evento · Outro | Contact | Deal | 01, 02 | Não — criar | |
| Faturamento aproximado | Dropdown | < R$ 500k · R$ 500k–2M · R$ 2M–10M · > R$ 10M | Company | Deal | 02 | Não — criar | |
| Tamanho do time comercial | Number | — | Company | Deal | 02 | Não — criar | |
| CRM atual | Dropdown | HubSpot · Salesforce · Pipedrive · Planilha · Outro | Company | Deal | 02 | Não — criar | |
| Patrocinador interno | Dropdown | Sim, sou eu · Sim, outra pessoa · Não tenho | Contact | Deal | 04 | Não — criar | |
| Conforto com investimento R$ 5k+ | Dropdown | Sim · Talvez · Não | Contact | Deal | 02, 04 | Não — criar | |
| Decisor ou influenciador | Dropdown | Decido · Influencio · Outro decide | Contact | Deal | 02, 04 | Não — criar | |
| Última atividade do deal | Date | — | Deal | — | 05 | Sim — built-in (notes_last_contacted) | |
| ICP score | Score | — | Contact | Deal · Company | 02 | Não — criar |
Reflexo entre objetos. Quando uma propriedade vive em Contact mas precisa aparecer em Deal (ex: "Patrocinador interno"), há 2 caminhos no HubSpot: (1) propriedade calculada que puxa do contato associado, ou (2) cópia automática via workflow ao criar deal. Escolher por caso — calculadas são mais limpas mas têm limitações em filtros e relatórios.
Higiene mínima. Toda propriedade nova deve ter: nome consistente (snake_case ou Title Case, padronizado), descrição preenchida, grupo (não jogar tudo em "Other"), e dono claro (quem é responsável por mantê-la limpa). Sem isso, propriedade vira lixo em 6 meses.
Matriz das 12 etapas.
Visão tabular consolidada das 12 etapas do funil — espelho das páginas individuais em formato comparativo. Útil pra revisão final e pra apresentar ao cliente numa página só. Edição feita aqui não sincroniza com as páginas individuais — escolha um lugar pra preencher e use o outro pra revisar.
| Etapa | O que é | Gatilhos de avanço | Campos obrigatórios | Problemas | Métricas atuais | Motivos de perda típicos | SLA estagnação | Automações | Propriedades obrigatórias | Oportunidades de AI | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 01 · Lead novo | Contato novo no CRM, ainda sem qualificação | Form respondido com critérios mínimos · Empresa no ICP | Nome · E-mail · Empresa · Origem · Data de entrada | Origem ausente em ~40% · Sem deduplicação automática | Volume mensal · Taxa de qualificação · Tempo nesta etapa | ||||||
| 02 · MQL qualificado | Lead passou pelos critérios mínimos, entra no pipeline ativo | SDR fez 1 contato · Lead aceitou agendar · Slot escolhido | Telefone validado · Cargo · Tamanho do time · Critério ICP | Critério MQL é subjetivo (cada SDR aplica regra diferente) | Conversão Lead → MQL · Tempo nesta etapa · No-show de MQL | ||||||
| 03 · Reunião agendada | Slot confirmado na agenda do consultor com convite Meet | Lead apareceu na reunião · Discovery conduzido · Próximo passo definido | Data/hora · Link Meet · Status do convite | — | Conversão MQL → Reunião · Tempo até agendamento · Taxa de no-show | ||||||
| 04 · Reunião realizada | Conversa de 30 min com decisor — método + fit + próximo passo | Necessidade clara · Orçamento confirmado · Aceitou receber proposta | Notas estruturadas · Próximo passo com data · Decisor confirmado | Sem registro estruturado · Próximo passo vago · Discovery vira pitch | Conversão Reunião → Proposta (maior queda) · Tempo até envio · Descarte pós-reunião | ||||||
| 05 · Proposta enviada | Proposta personalizada enviada ao lead, prazo pra responder | Lead aceitou explicitamente · Contrato assinado · Pagamento confirmado | Data de envio · Cadência iniciada · Última atividade | Sem cadência de follow-up · Proposta fica subjetiva | Conversão Proposta → Cliente · Tempo até decisão · Taxa de frio | ||||||
| 06 · Cliente fechado | Lead virou cliente formalmente — contrato + pagamento + onboarding | Contrato assinado · Pagamento confirmado · Acessos coletados | Data de fechamento · Ticket · Modalidade · Acessos | — | Conversão geral Lead → Cliente · Ticket médio · Ciclo total | ||||||
| 07 · Etapa 07 | |||||||||||
| 08 · Etapa 08 | |||||||||||
| 09 · Etapa 09 | |||||||||||
| 10 · Etapa 10 |
Como usar. A matriz é a fonte da verdade das etapas. As 6 primeiras colunas (Etapa, O que é, Gatilhos, Campos obrigatórios, Problemas, Métricas) você edita aqui mesmo. Default: 10 etapas — adicione mais com + Adicionar etapa ou remova com ×.
Colunas com ↗ (source-of-truth). Colunas marcadas com ↗ verde no header são auto-populadas a partir de outra seção e não são editáveis aqui. Atualizam em tempo real quando você edita a fonte:
· Motivos de perda típicos ← Motivos de perda (multi-etapa por motivo)
· SLA estagnação ← SLA de estagnação (1 SLA por etapa)
· Automações ← Automações por etapa (várias por etapa)
· Propriedades obrigatórias ← Propriedades (multi-etapa por propriedade)
O matching é por número da etapa — qualquer string começando com "01", "02" etc. é reconhecida.
Matriz TO-BE — estado proposto.
Como cada etapa vai funcionar após o Build. Par do AS-IS — você vê as melhorias propostas, gatilhos refinados, métricas-meta. As 4 colunas ↗ são as mesmas (auto-populadas das configs) — porque as configs são as especificações TO-BE.
| Etapa | Como vai ser | Gatilhos refinados | Melhorias vs. AS-IS | Métricas-meta | Motivos de perda típicos | SLA estagnação | Automações | Propriedades obrigatórias | Oportunidades de AI | |
|---|---|---|---|---|---|---|---|---|---|---|
| 01 · Lead novo | Lead capturado com origem obrigatória, deduplicação automática, score inicial | Form respondido com critérios mínimos · Origem registrada · Score ICP calculado | Origem em 100% dos leads · Sem duplicidade · Score atribuído na entrada | Origem ≥ 95% preenchimento · 0 duplicatas · Score em 100% dos leads | ||||||
| 02 · MQL qualificado | Qualificação por checklist objetivo (não subjetivo), automação de scoring | Score ≥ X · Critério ICP marcado · SDR aceitou pra reunião | Critério único e objetivo · Automação reduz tempo de qualificação manual | Conversão Lead→MQL ≥ Y% · Tempo nesta etapa ≤ Z dias | ||||||
| 03 · Reunião agendada | Mantém o que funciona — agendamento HubSpot Meetings + lembretes automáticos | Slot confirmado · Briefing pré-reunião enviado · Confirmação D-1 | Briefing automatizado pré-reunião (era manual) | No-show ≤ X% · Briefing lido em 100% das reuniões | ||||||
| 04 · Reunião realizada | Diagnóstico estruturado · próximo passo com data · registro padronizado no HubSpot | Dor real validada · Champion identificado · Decision Process mapeado · próximo passo com data | Template de notas · Discovery primeiro, pitch depois · Próximo passo obrigatório no CRM | Conversão Reunião→Proposta ≥ Y% · Tempo até envio proposta ≤ 48h | ||||||
| 05 · Proposta enviada | Proposta personalizada com template · cadência de 10 touchpoints automática | Aceite explícito · Contrato + pagamento confirmados | Template + variáveis (era subjetivo) · Cadência sistematizada (era ad-hoc) | Conversão Proposta→Cliente ≥ Y% · Taxa de frio ≤ X% | ||||||
| 06 · Cliente fechado | Onboarding automático · acessos coletados via checklist · kick-off em até 7 dias | Contrato assinado · Pagamento OK · Checklist de acessos completo | Onboarding sistematizado · Champion ativo na transição | Tempo até kick-off ≤ 7 dias · NPS pós-onboarding ≥ X | ||||||
| 07 · Etapa 07 | ||||||||||
| 08 · Etapa 08 | ||||||||||
| 09 · Etapa 09 | ||||||||||
| 10 · Etapa 10 |
Diferença AS-IS × TO-BE. AS-IS captura "estado atual problemático" — é o ponto de partida. TO-BE descreve "estado proposto pós-Build" — é o destino. As 4 colunas ↗ são iguais nos dois porque as configs (Motivos, SLA, Automações, Propriedades) são as especificações do TO-BE. Você vê o que será construído refletido em ambas as matrizes.
Como apresentar ao cliente. Mostre AS-IS primeiro (panorama do que dói hoje), depois TO-BE (panorama de como vai ficar). A comparação lado a lado vende a mudança — o cliente não compra Build, compra a transição AS-IS → TO-BE.
Framework de qualificação.
Define qual framework comercial o cliente usa (BANT, MEDDIC, SPIN, GPCT ou Custom) e como cada componente cascateia pelas etapas do funil — onde a info é capturada inicial, onde validada, onde usada na entrega final. Sem isso, o time vende no improviso.
Bloco A · Framework escolhido
MEDDIC
- Metrics — métricas que importam pro cliente
- Economic Buyer — quem assina o cheque
- Decision Criteria — como decide
- Decision Process — passos da decisão
- Identify Pain — dor real, não percebida
- Champion — quem patrocina internamente
Outros frameworks
- BANT — Budget, Authority, Need, Timing (mais simples, ticket baixo)
- SPIN — Situation, Problem, Implication, Need-payoff (vendas consultivas)
- GPCT — Goals, Plans, Challenges, Timeline (Inbound HubSpot)
- Custom — combinação adaptada ao ICP do cliente
Por que esse framework
- Ticket alto justifica MEDDIC (Champion crítico)
- Vendas longas (3+ meses) precisam Decision Process explícito
- SaaS B2B típico aplica MEDDIC bem
- BANT seria insuficiente — não captura Champion nem Decision Process
Bloco B · Componentes × etapas do funil
Cruzamento dos componentes do framework com as etapas. Define onde cada componente é capturado pela primeira vez, onde é validado/aprofundado, e onde é usado na entrega.
| Componente | Captura forms | Qualificação SDR | Diagnóstico Vendas | Entrega | |
|---|---|---|---|---|---|
| Metrics | Dor com número (campo livre) | Aprofunda métrica na ligação · valida unidade | Mensura impacto · vincula à dor real | Dashboard mede progresso da métrica | |
| Economic Buyer | Cargo declarado · empresa | Confirma autoridade real (decide ou influencia?) | Conhece o economic buyer · valida orçamento | Stakeholder oficial do projeto · aprova entregas | |
| Decision Criteria | — | Pergunta inicial: "o que precisa pra decidir?" | Mapeia todos os critérios · prioriza | Escopo do Build cobre critérios listados | |
| Decision Process | — | Identifica nº de aprovadores | Mapeia passos internos do cliente | Kick-off respeita o processo de decisão mapeado | |
| Identify Pain | Dor declarada (texto livre) | Aprofunda dor · pede exemplos concretos | Dor real vs. percebida · validada com dados | TO-BE atende a dor mapeada · cliente reconhece | |
| Champion | — | Identifica quem patrocina internamente | Confirma champion · entende motivação dele | Champion valida entregas · interface durante Build |
Bloco C · Cascata por etapa — o que precisa pra avançar
Por etapa, lista quais componentes do framework precisam estar preenchidos pra deal poder avançar. Vira regra obrigatória no HubSpot: deal não sai dessa etapa sem esses campos preenchidos.
| Etapa | Componentes obrigatórios pra avançar | O que se perde se skipar |
|---|---|---|
| 01 · Lead novo → 02 MQL | — | — |
| 02 · MQL → 03 Reunião agendada | Pain declarada · Cargo · Tamanho da empresa | SDR vai pra reunião sem contexto |
| 03 · Reunião agendada → 04 Reunião realizada | Reunião confirmada · Briefing pré-reunião lido | AE entra na reunião cego |
| 04 · Reunião realizada → 05 Proposta enviada | Pain real validada · Champion identificado · Decision Process mapeado · Metrics aprofundadas | Proposta vira chute · Cadência sem alvo · Risco de "frio" alto |
| 05 · Proposta enviada → 06 Cliente fechado | Decision Criteria atendido · Economic Buyer aprovou · Champion confirma fit | Deal "fecha" mas estoura no onboarding · Champion some · Renegociação |
| 06 · Cliente fechado → Onboarding (Parte 3) | Contrato + pagamento + acessos · Champion confirmado pra Discovery | Discovery atrasa · Champion vira ausente · Rescisão precoce |
| 07 · Etapa 07 → 08 | ||
| 08 · Etapa 08 → 09 | ||
| 09 · Etapa 09 → 10 | ||
| 10 · Etapa 10 → 11 | ||
| 11 · Etapa 11 → 12 | ||
| 12 · Etapa 12 → fim |
Como vira regra no HubSpot. Cada componente obrigatório do framework vira uma propriedade obrigatória no estágio correspondente do pipeline. Quando vendedor tenta mover deal pra próxima etapa sem o campo preenchido, HubSpot bloqueia (ou no mínimo alerta). Isso transforma o framework de "intenção" em regra operacional.
Trocar de framework é caro. Mudar de BANT pra MEDDIC no meio do projeto significa renomear propriedades, recapacitar o time, refazer dashboards. Definir o framework certo na Discovery (e validar com o cliente) economiza meses de retrabalho. Quando em dúvida, MEDDIC é robusto pra B2B SaaS com ticket > R$ 5k/mês.
Cadências de contato.
Catálogo de cadências do funil — não tem só uma. Cada cadência tem gatilho próprio, total de touchpoints, canal predominante, janela de duração e regras especiais. A operação manda em qual cadência inicia conforme o evento.
| Nome da cadência | Gatilho de início | Total touchpoints | Canal predominante | Janela (dias) | Regras especiais | |
|---|---|---|---|---|---|---|
| Pós-proposta (fechamento) | Proposta enviada (Etapa 05) | 10 | WhatsApp + ligação | 28 | Mix de canais — ligação a cada 3-4 toques de WhatsApp · Sem mensagem de despedida no T10 | |
| Pós-no-show | Lead faltou na reunião (Etapa 03 → 04 frustrada) | 5 | WhatsApp + e-mail | 7 | 1º toque imediato (até 2h após no-show) · Reagendar é foco · 2 reagendamentos máximo | |
| Pós-reunião sem proposta | Reunião realizada sem próximo passo claro | 4 | E-mail + WhatsApp | 7 | Foco em entender bloqueio (pergunta direta) · Não é reapresentar método | |
| Reativação de frio | Lead frio há 90+ dias | 3 | 14 | Conteúdo novo (não vendas) · Cita case ou métrica · Sem CTA agressivo | ||
| Check-in cliente ativo | Cliente em entrega · 30 dias após início | 1 | Ligação | 1 | Pulso de saúde — NPS informal · Identifica risco de churn cedo | |
| Pré-renovação | 60 dias antes do fim do contrato | 3 | Reunião + e-mail | 30 | Apresenta resultados consolidados · Discute renovação ou expansão · Confirma champion |
Por que separar cadências. Mesma cadência para todo lead frustra o time e o lead — pós-no-show é diferente de pós-proposta de pós-reativação. Cada uma tem objetivo, ritmo e tom próprios. Documentar no Discovery garante que time não improvisa "o que mandar agora".
Onde rodam. Cadências de e-mail podem ser automatizadas no HubSpot Sequences. Cadências de WhatsApp + ligação ficam manuais (executor do time). Marcar no HubSpot qual cadência um lead está protege contra disparos duplicados de cadências diferentes ao mesmo lead.
Ferramentas e liberação de acessos.
Checklist operacional do que o consultor precisa receber pra rodar a Discovery. Diferente do "stack técnico" do mapa-discovery (que mapeia o que existe na operação). Aqui é o que precisa ser liberado pelo cliente pra trabalho começar.
| Ferramenta | Tipo de acesso | Quem libera | Status | Observações | |
|---|---|---|---|---|---|
| HubSpot do cliente | Admin (read + write) | Champion | Pendente | Necessário pra audit completo + criar propriedades novas durante Build | |
| E-mail corporativo (auditoria) | Read-only · 1 caixa do time comercial | IT / Champion | Pendente | Verificar histórico de comunicação com leads · Geralmente pulado, mas revela muito | |
| Slack / Discord do time comercial | Convidado em canais relevantes | Champion | Pendente | Observar dinâmica do time · Não falar, só observar primeiros 3 dias | |
| Google Drive / Notion comercial | Read | Champion | Pendente | Acesso a templates atuais, scripts, propostas anteriores | |
| Dashboards externos (Looker / Metabase / Power BI) | Read | Data team | Pendente | Validar métricas reportadas pelo time vs. realidade dos dashboards | |
| Calendar do time comercial | Read | Champion | Pendente | Mapear cadência real de reuniões internas e com leads | |
| HubSpot Meetings / Calendly | Read | Champion | Pendente | Avaliar fluxo atual de agendamento · Janelas, restrições, follow-ups | |
| ERP / sistema financeiro | Read · relatórios de receita | Financeiro | Pendente | Cruzar deal won (HubSpot) × receita real · Detecta deals "fechados" que não viraram dinheiro |
Status sugeridos. Use valores consistentes na coluna Status: Pendente · Solicitado · Liberado · Bloqueado · N/A. Ajuda a montar dashboard de progresso do kick-off.
Sem acesso, sem Discovery completa. Cliente que demora pra liberar HubSpot trava 2-3 dias do cronograma de 2-3 semanas. Pedir tudo no kick-off é bom — mas é melhor pedir 2 semanas antes (junto com a assinatura do contrato), pra IT do cliente ter tempo de aprovar.
Canais de captação.
Mapa dos canais por onde o lead chega. Cada canal tem UTMs (source/medium/campaign) que identificam a origem no HubSpot, e um valor mapeado pra propriedade Origem do lead. Define também volume e custo pra calcular CAC depois.
| Canal | UTM source | UTM medium | UTM campaign | UTM content | UTM URL final | Origem mapeada | Volume mensal | Custo | Status | |
|---|---|---|---|---|---|---|---|---|---|---|
| LinkedIn orgânico | organic | — | post-organico | https://ruyspinola.com.br/?utm_source=linkedin&utm_medium=organic&utm_content=post-organico | ~50/mês | R$ 0 | Ativo | |||
| LinkedIn Ads | cpc | nome-da-campanha | criativo-A | https://ruyspinola.com.br/?utm_source=linkedin&utm_medium=cpc&utm_campaign=nome-da-campanha&utm_content=criativo-A | ~30/mês | CPC ~R$ 12 | Ativo | |||
| Google Ads | cpc | brand + nonbrand | anuncio-1 | https://ruyspinola.com.br/?utm_source=google&utm_medium=cpc&utm_campaign=brand&utm_content=anuncio-1 | Outro | ~20/mês | CPC ~R$ 8 | Ativo | ||
| Organic search (SEO) | organic | — | — | https://ruyspinola.com.br/?utm_source=google&utm_medium=organic | Outro | ~15/mês | R$ 0 | Ativo | ||
| Indicação | — | — | — | — | — | Indicação | ~5/mês | R$ 0 | Ativo | |
| Evento | evento-X | offline | nome-do-evento | materiais-stand | https://ruyspinola.com.br/?utm_source=evento-X&utm_medium=offline&utm_campaign=nome-do-evento&utm_content=materiais-stand | Evento | ~10 (sazonal) | R$ 5k+ por evento | Sazonal | |
| Parceria / co-marketing | parceiro-X | referral | — | landing-conjunta | https://ruyspinola.com.br/?utm_source=parceiro-X&utm_medium=referral&utm_content=landing-conjunta | Outro | ~3/mês | R$ 0 — rev share | Em teste |
UTMs no HubSpot. Os 3 valores (utm_source, utm_medium, utm_campaign) são capturados automaticamente pelo HubSpot quando o lead chega via link com UTM. Origem mapeada é o valor do dropdown Origem do lead (Contact property) que esse canal alimenta — define a regra de tradução entre UTM bruto e categoria de origem.
Status sugeridos. Ativo · Em teste · Pausado · Sazonal · Encerrado. Canais em teste devem ter critério de promoção pra ativo (ex: 5 leads qualificados em 30 dias). Sem critério, "teste" vira limbo eterno.
Oportunidades de AI no funil.
Catálogo de casos onde AI pode automatizar ou aumentar a operação. Cada caso vincula a etapas específicas, tem categoria, tipo de modelo, maturidade do mercado e status (mapeado / manual hoje / AI parcial / AI ativo / futuro). Vira pipeline natural de cross-sell pra fase AI Augment pós-Build.
| Caso de uso | Etapas (vírgula) | Categoria | Tipo de AI | Maturidade | Esforço | Impacto | Status | |
|---|---|---|---|---|---|---|---|---|
| Enriquecimento de lead via API | 01 | Captura | Workflow + APIs | Standard | Pequeno | Alto | Manual hoje | |
| Scoring ICP automático | 02 | Qualificação | Classificação | Standard | Médio | Alto | Mapeado | |
| Briefing pré-reunião automatizado | 03, 04 | Qualificação | LLM + RAG | Standard | Médio | Alto | Manual hoje | |
| Transcrição + estruturação no CRM | 04 | Análise | LLM + Speech-to-text | Standard | Pequeno | Alto | AI parcial | |
| Geração de proposta com variáveis | 05 | Conteúdo | LLM | Standard | Pequeno | Médio | Manual hoje | |
| Scoring de probabilidade de fechamento | 04, 05 | Análise | Classificação | Emerging | Médio | Médio | Mapeado | |
| Detecção de estagnação proativa | 01, 02, 03, 04, 05 | Orquestração | Agent autônomo | Standard | Pequeno | Alto | Mapeado | |
| Categorização de motivos de perda free-text | 01, 02, 03, 04, 05 | Análise | LLM + Embeddings | Standard | Pequeno | Médio | Mapeado | |
| Drafting de cadência personalizada | 05 | Cadência | LLM | Emerging | Médio | Médio | Futuro | |
| Health-check pós-onboarding | 06 | Análise | Agent autônomo | Emerging | Grande | Alto | Futuro |
Como vira cross-sell pós-Build. Cada caso de AI mapeado aqui — especialmente os com status Mapeado ou Futuro — alimenta a oferta AI Augment que pode ser vendida 3-6 meses depois do Build core. A Recomendação Build pode então oferecer 3 escopos:
· Build core — propriedades, automações, SLAs, motivos (operação rodando)
· Build + AI básico — inclui AI Standard com status "Manual hoje" (impacto alto, esforço pequeno-médio)
· Build + AI avançado — inclui AI Emerging + casos ambiciosos (Detecção proativa, Health-check)
Convenções sugeridas.
· Categoria: Captura · Qualificação · Conteúdo · Cadência · Análise · Orquestração
· Tipo de AI: LLM · Embeddings · Classificação · Agent autônomo · RAG · LLM + RAG · Workflow + APIs
· Maturidade: Standard (commodity, baixo risco) · Emerging (viável mas requer cuidado) · Experimental (pesquisa, alto risco)
· Esforço: Pequeno (<2 semanas) · Médio (2-6 semanas) · Grande (>6 semanas)
· Status: Mapeado · Manual hoje · AI parcial · AI ativo · Futuro
Métricas e dashboards.
Mapa de métricas que sustentam decisão na operação. Cada métrica tem etapa(s) onde aplica, frequência de leitura, dono e dashboard onde vive. Status diz se hoje é medida ou só "falada".
| Métrica | Tipo | Etapas (vírgula) | Frequência | Quem olha | Dashboard atual | Status | |
|---|---|---|---|---|---|---|---|
| Conversão Lead → MQL | Conversão | 01, 02 | Semanal | Gestor comercial | HubSpot dashboard funil | Medindo | |
| Conversão MQL → Reunião agendada | Conversão | 02, 03 | Semanal | SDR + Gestor | HubSpot dashboard funil | Medindo | |
| Taxa de no-show | Operacional | 03 | Semanal | SDR | — | Não medindo | |
| Conversão Reunião → Proposta | Conversão | 04, 05 | Semanal | AE + Gestor | HubSpot dashboard funil | Medindo | |
| Conversão Proposta → Cliente | Conversão | 05, 06 | Semanal | Closer + Gestor | HubSpot dashboard funil | Medindo | |
| Tempo médio em cada etapa | Ciclo | 01, 02, 03, 04, 05 | Mensal | Gestor | — | Não medindo | |
| Ciclo total Lead → Cliente | Ciclo | 01, 06 | Mensal | CEO + Gestor | HubSpot | Parcial | |
| Ticket médio | Receita | 06 | Mensal | CEO + Financeiro | ERP | Medindo | |
| Taxa de motivos de perda preenchidos | Qualidade do dado | 01, 02, 03, 04, 05 | Semanal | Gestor | — | Não medindo | |
| Aderência ao framework de qualificação | Qualidade do processo | 02, 04, 05 | Mensal | Gestor | — | Não medindo |
Status sugeridos. Use valores consistentes na coluna Status: Medindo · Parcial · Não medindo · Inconfiável. Métricas com status "Não medindo" são candidatas P1 do Build (instrumentar a medição vem antes de melhorar).
Sem métrica, sem otimização. Se o cliente fala "queremos aumentar X" mas X não é medido com confiabilidade, primeira entrega do Build é instrumentar a medição. Sem dado, otimização vira achismo. Métricas de qualidade do processo (aderência ao framework, taxa de motivos preenchidos) são as mais negligenciadas — são as que mais explicam queda de conversão.
RACI por etapa do funil.
Quem faz o quê em cada etapa. Responsible (executa) · Accountable (responde por) · Consulted (consultado) · Informed (informado). Identificar gaps de responsabilidade revela perda invisível — geralmente o pior gargalo do funil é "ninguém é dono".
| Etapa | R · Responsável (executa) | A · Aprovador (responde por) | C · Consultado | I · Informado | Gap identificado | |
|---|---|---|---|---|---|---|
| 01 · Lead novo | SDR | Gestor comercial | Marketing (origem) | — | — | |
| 02 · MQL qualificado | SDR | Gestor comercial | AE (decide se aceita) | Marketing | Critério MQL muda por SDR — falta dono claro do critério | |
| 03 · Reunião agendada | SDR | Gestor comercial | — | AE (vai conduzir) | — | |
| 04 · Reunião realizada | AE / Closer | Gestor comercial | SDR (briefing) | Marketing (qualidade lead) | Quem registra a reunião? Quem garante próximo passo? Falta dono | |
| 05 · Proposta enviada | AE / Closer | Gestor comercial | CEO (escopo / preço) | Financeiro (cobrança) | Cadência de follow-up sem dono — vendedor "lembra" sozinho | |
| 06 · Cliente fechado | AE / Closer | CEO | CS / Onboarding | Financeiro · Operações | Handoff Closer → CS sem ritual — info se perde | |
| 07 · Etapa 07 | ||||||
| 08 · Etapa 08 | ||||||
| 09 · Etapa 09 | ||||||
| 10 · Etapa 10 |
Como ler RACI. Cada etapa deve ter 1 só Accountable — quem responde se der errado. Pode ter múltiplos Responsibles (executores). Se mais de 1 pessoa for Accountable na mesma etapa, isso é gap (ninguém vai ser dono na prática). Coluna "Gap identificado" é onde você anota essa fricção pra atacar no Build.
Gaps típicos detectados em Discovery. Cadência de follow-up sem dono · Handoff entre roles sem ritual · Escala de qualificação subjetiva · Decisão de "quando descartar" não documentada · Atualizações no CRM sem responsável. Cada gap detectado vira candidato a regra/automação no Build.
Treinamentos a construir.
Build não é só código — é também capacitar o time pra usar a operação nova. Cada novo workflow, propriedade, cadência ou framework precisa de treinamento dedicado. Sem isso, o time volta ao improviso e o investimento se perde.
| Tema | Audiência | Etapas relacionadas | Formato | Duração | Frequência | URL dos materiais | Status | |
|---|---|---|---|---|---|---|---|---|
| Novo funil — etapas, gatilhos e regras | Todos (SDR, Closer, Gestor) | 01-06 | Vídeo gravado + Q&A live | 30 min | One-shot (kick-off) | — | A construir | |
| Como preencher motivos de perda corretamente | SDR + Closer | 02, 04, 05 | Doc + 1 página de exemplos | 15 min leitura | Recorrente trimestral | — | A construir | |
| Cadência manual de 10 toques | Closer / AE | 05 | Live + roleplay | 1h | One-shot | — | A construir | |
| Framework de qualificação (MEDDIC ou outro) | SDR + Closer | 02, 04, 05 | Vídeo + roleplay live | 1h30 | One-shot + reforço 30d | — | A construir | |
| Dashboards: como interpretar e agir | Gestor comercial | 01-06 | Live com dados reais | 30 min | One-shot + revisão 60d | — | A construir | |
| Propriedades obrigatórias por etapa | Todos | 01-06 | Doc + checklist | 15 min | Recorrente quando criar prop nova | — | A construir |
Status sugeridos: A construir · Em produção · Gravado · Entregue · Atualizar.
URL dos materiais: link público (Drive, Notion, Loom, YouTube unlisted) com slide/vídeo/doc. Esse campo é entrada pra IA gerar o entregável final do treinamento pro cliente — quanto mais explícita a URL, mais limpa a transformação.
Treinamento sem roleplay raramente sobrevive. Vídeo + doc cobrem o "o quê" e o "como". O "quando aplicar" só vem com prática observada — daí roleplay live ou shadowing nas primeiras semanas.
Modelo de apresentação mensal de resultados.
Define o que mostrar pro cliente nas reuniões mensais — KPIs, formato visual, comparações. Vira artefato recorrente que justifica continuidade do projeto e mantém valor visível pro decisor.
Configuração geral da reunião
Quem vê
- CEO / Founder
- Gestor comercial
- Diretor (quando aplicável)
Quando acontece
- Mensal — última terça do mês
- Duração: 45 min
- Formato: live com dashboard + slides
Roteiro padrão
- 5 min — recap do mês
- 20 min — KPIs e tendências
- 10 min — destaques + alertas
- 10 min — prioridades do próximo mês
KPIs a apresentar
Cada linha define uma métrica + como visualizar + comparação + origem do dado. Tabela vira input direto pra construir o dashboard.
| KPI / Métrica | Tipo de gráfico | Comparação | Origem do dado | Status | |
|---|---|---|---|---|---|
| Conversão por etapa do funil | Linha (mês a mês) | vs mês anterior · vs meta | HubSpot funnel report | A instrumentar | |
| Tempo médio em cada etapa | Barras horizontais | vs benchmark interno | HubSpot custom report | A instrumentar | |
| Ticket médio | Scorecard + sparkline | vs meta · vs ano anterior | HubSpot deal value | Já medindo | |
| Volume de leads por canal | Donut + ranking | vs distribuição esperada | HubSpot por UTM source | Parcial (origem ausente) | |
| Top 5 motivos de perda | Barras horizontais ranking | vs mês anterior | HubSpot perdidos com motivo | A instrumentar | |
| Saúde do pipeline (deals × estagio × valor) | Heatmap ou gauge composto | vs meta de pipeline coverage | HubSpot pipeline view | Parcial | |
| Taxa de aderência ao framework de qualificação | Scorecard % | vs meta 80% | HubSpot — campos preenchidos | Não medindo | |
| Receita gerada no mês | Linha + meta projetada | vs meta · vs mês anterior | HubSpot won deals + ERP | Já medindo |
Status sugeridos: Já medindo · Parcial · A instrumentar · Não medindo. Métricas "Não medindo" e "A instrumentar" viram tarefas Build automaticamente.
3 KPIs vencem 10 KPIs. Cliente decisor não decide com 10 gráficos — decide com 3 que ele entende. Os outros são contexto pra perguntas. Se a apresentação tiver mais de 6-8 KPIs, repensar — provavelmente está virando relatório, não conversa.
Roadmap de Discovery.
Status consolidado de cada seção da Discovery, agrupado por prioridade. Em construção (foco atual) → Para fazer (pendentes) → Concluídas (arquivo). Tabelas auto-populadas a partir das configs e timers de cada seção. Quando o modo Build for ativado, terá seu próprio Roadmap de Build paralelo.
Em construção (0)
| Seção | Estimativa Discovery | Real (timer) | Diferença | % do estimado | Build est. |
|---|
Para fazer (0)
| Seção | Estimativa Discovery | Real (timer) | Diferença | % do estimado | Build est. |
|---|
Concluídas (0)
| Seção | Estimativa Discovery | Real (timer) | Diferença | % do estimado | Build est. |
|---|
Como ler. Diferença negativa = sob orçamento (positivo). Positiva = passou da estimativa. % do estimado mostra quanto da estimativa já foi consumido (acima de 100% indica estouro).
Build dashboard.
Status agregado de todas as atividades de Build — vindas das tabelas Discovery + extras adicionados aqui. Atualiza ao vivo conforme você marca atividades como Em construção / Concluída.
Distribuição por categoria
| Categoria | Total | A fazer | WIP | Concluídas | Estimativa |
|---|
Como usar. Atividades vêm das tabelas Discovery (Motivos, SLA, Automações, Propriedades, Cadências, Canais, AI, Treinamentos, Apresentação) — cada linha é uma atividade Build. Marque o status Build em cada linha (toggle "A fazer / WIP / Concluída"). Para atividades não previstas no Discovery, use a aba Atividades extras.
Atividades compiladas.
Lista read-only de todas as atividades vindas das tabelas Discovery. Para alterar nome, etapas, estimativa ou status — vá na origem (na seção correspondente do Discovery).
| Categoria | Atividade | Etapas | Executor | Prev. fim | Est. (h) | Real (h) | Status | Risco |
|---|
Source-of-truth. Esta tabela espelha 9 tabelas do Discovery. Editar aqui não vai funcionar (read-only). Para mudar status Build de uma atividade, navegue até ela na origem.
Gantt das entregas.
Visualização temporal de todas as atividades Build com data prevista de fim. Barras coloridas por status. Linha vermelha indica hoje. Atividades sem data prevista não aparecem aqui.
Como funciona. O range temporal é calculado automaticamente pela menor e maior data prevista entre as atividades. Cada barra começa na data de start do projeto (ou hoje, se não houver start) e termina na previsão. Status: cinza = a fazer · amarelo = WIP · verde = concluída · borda vermelha = atrasada.
Atividades extras de Build.
Coisas que surgem durante o Build e não estavam no Discovery. Mesmas métricas e status — entram no dashboard automaticamente.
| Atividade | Categoria | Etapas relacionadas | Notas | |
|---|---|---|---|---|
| Exemplo: ajuste de webhook não previsto | Integração | 05 | Surgiu na semana 2 — depende do parceiro X |
Convenção sugerida. Use Categoria com valores que ajudem a entender impacto: Integração / Workflow / Property / Treinamento / Refactor / Bug fix / Migration. Quando essa lista cresce muito, é sinal de Discovery incompleto — input pra calibrar próximos projetos.
Documentos entregues.
Centraliza os artefatos produzidos durante o Build — vídeos de treinamento, docs, dashboards, planilhas, slides. Cada linha aponta pra uma URL hospedada (Drive, Notion, Loom, YouTube). Vira referência pro cliente e input pra IA gerar entregáveis derivados.
| Categoria | Documento | URL | Notas | |
|---|---|---|---|---|
| Treinamento | Vídeo: novo funil, etapas e gatilhos | — | Audiência: time comercial. Duração ~30min. | |
| Documentação | Guia de motivos de perda | — | 1 página + exemplos. Notion ou Drive. | |
| Dashboard | Painel de KPIs comerciais (HubSpot) | — | Compartilhado com gestor + diretoria. | |
| Planilha | Cadência manual de 10 toques | — | Sheets · template editável por cliente. |
Categorias sugeridas: Treinamento · Documentação · Dashboard · Planilha · Slide · Vídeo · Workflow · Outro. Em modo de edição, clica na URL pra colar o link; em modo somente-leitura, vira um link clicável que abre em nova aba.
Optimize backlog.
Lista de iniciativas que pertencem à fase Optimize (pós-Build). Não fazem parte do escopo Discovery nem Build — ficam aqui registradas pra serem priorizadas quando o cliente migrar pro contrato Optimize recorrente.
| Iniciativa | Descrição | Pré-requisito | Prioridade | |
|---|---|---|---|---|
| Planejamento de crescimento | Definir trajetória de receita/leads/conversão por trimestre, com cenários (base/otimista/conservador) e gatilhos de revisão. | Discovery + Build entregues; baseline de métricas estabilizado. | Alta | |
| Desenvolvimento de metas | Cascata de metas operacionais (por papel · por etapa · por canal) que conectam ao planejamento de crescimento. Inclui método de definição, frequência de revisão e tratamento de desvios. | Planejamento de crescimento aprovado. | Alta |
Como usar. Sempre que durante Discovery ou Build aparecer uma demanda que não cabe no escopo atual mas faz sentido pra fase de otimização contínua, registre aqui. Vira input direto pra proposta Optimize quando o cliente migrar.
Horas contratadas vs utilizadas.
Você lança duas coisas: o pacote contratado por mês (do contrato) e cada atividade Optimize com data de conclusão e esforço em horas. O sistema agrupa as atividades por semana automaticamente, soma horas por semana/mês e mostra o saldo do mês corrente. Reset zera o saldo no início de cada mês.
Pacote contratado
Histórico de contratos. Cada linha = um evento (assinatura, renegociação, upgrade, downgrade). O sistema usa o contrato mais recente cuja Data contratação seja ≤ mês corrente — então você só precisa registrar quando algo muda.
| Data contratação | Horas/mês | Link do contrato | Notas | |
|---|---|---|---|---|
| 2026-04-01 | 20 | — | Pacote padrão · contrato em vigor |
Cada linha = uma alteração de contrato (assinatura, renegociação, upgrade). O sistema usa sempre o contrato mais recente cuja Data contratação seja anterior ou igual ao mês corrente.
Atividades
Cada linha = uma tarefa Optimize com data de conclusão e esforço estimado/real. Sistema agrupa abaixo por semana baseado na data de conclusão.
| Tarefa | Categoria | Data conclusão | Esforço (h) | Real (h) | Status | Notas | |
|---|---|---|---|---|---|---|---|
| Discovery com Ana Escher | Vendas | Reunião 1h + 1h follow-up. | |||||
| Recuperação de negócios ciclo passado | Vendas | — | |||||
| Validar relatórios HubSpot | Squad Scient | — | |||||
| Alinhar roadmap sales ops | Vendas | — |
Visão por semana
Agrupado automaticamente pela data de conclusão. Cada semana mostra total de horas e lista de tarefas. Calculado em tempo real.
Como funciona. Pacote contratado = capacidade reservada por mês (input do contrato). Atividades = tarefas reais executadas/planejadas, cada uma com data de conclusão e esforço. Sistema soma esforço por semana (agrupado pela data de conclusão) e por mês. Saldo = pacote − real do mês corrente.
Política completa documentada em apps/funil/docs/optimize-horas-policy.md — referência pra cláusula contratual e copy de proposta.
Aviso de saldo expirando. A partir do dia 25, se o saldo do mês corrente for > 30% do pacote, exibimos alerta. Reset zera o saldo no novo mês — programe demandas pendentes na RBM.
Optimize dashboard.
Status agregado das iniciativas Optimize cadastradas no backlog. Atualiza em tempo real conforme você marca status (A fazer · WIP · Concluída) nas linhas do backlog.
Como usar. O dashboard só conta iniciativas do Optimize Backlog. Build tem dashboard próprio com agregação separada. Cada iniciativa Optimize ganha as mesmas colunas das atividades Build (Prev. fim · Executor · Notas · Real · Est · Status) — preencha pra ver dados aqui.
Atividades compiladas.
Lista read-only das iniciativas do backlog Optimize com colunas executoras (Prev. fim · Executor · Real · Status · Risco). Pra alterar, vá em Backlog.
| Iniciativa | Pré-requisito | Prioridade | Executor | Prev. fim | Est. (h) | Real (h) | Status | Risco |
|---|
Source-of-truth. Esta tabela espelha o Optimize Backlog. Read-only.
Gantt das iniciativas Optimize.
Visualização temporal das iniciativas Optimize com data prevista de fim. Mesma lógica do Gantt de Build.
Documentos entregues — Optimize.
Centraliza artefatos produzidos durante Optimize (planos de crescimento, cascatas de metas, dashboards de KPIs estratégicos, atas de RBM).
| Categoria | Documento | URL | Notas | |
|---|---|---|---|---|
| Plano | Plano de crescimento — trimestre Q1 | — | Cenários base/otimista/conservador. Aprovado em RBM. | |
| Cascata de metas | Metas por papel — comercial | — | SDR · Closer · AE. Revisão mensal. | |
| Dashboard estratégico | KPIs Optimize — visão diretoria | — | Frequência mensal. Acessado por C-level. |
Categorias sugeridas: Plano · Cascata de metas · Dashboard estratégico · Ata de RBM · Apresentação · Outro.
Como usar este template.
Este arquivo é um modelo. Cada projeto Discovery clona e preenche com os dados do cliente real.
Passo a passo
Duplicar o arquivo
- Copiar pra
discovery/[cliente]/funil-as-is.html - Trocar
[CLIENTE]no h1 da Visão geral - Atualizar título da página e meta
Mapear as etapas reais
- Algumas operações têm 5, outras 8 etapas — ajustar quantidade
- Renomear cada etapa pro nome usado pelo cliente
- Atualizar sidebar pra refletir as etapas reais
Preencher diagnóstico por etapa
- 5 cards por etapa: definição, gatilhos, campos, problemas, métricas
- Card de problema usa classe
.problem(borda âmbar) - Quando não há problema, omitir o card e marcar etapa como
healthyno pipeline
Atualizar pipeline-viz
- Cada
.pipeline-stagereflete a etapa - Adicionar classe
.has-painou.healthyconforme diagnóstico - Atualizar contador de dores no
.stage-pain
Consolidar na síntese
- Toda dor mapeada vira linha na
.matrix-table - Atribuir severidade (Alta/Média/Baixa) por impacto
- Sugerir ação proposta pra cada — input do TO-BE/Build
Apresentar ao cliente
- Doc é entregável formal da Discovery
- Apresentar primeiro a Visão geral, depois Síntese, depois detalhes por etapa
- Cliente sai com o doc + recomendação Build sim/não
Convenção de classes. Use .has-pain + número de dores no pipeline pra etapas com problema. Use .healthy pra etapas saudáveis. .diagnostic-card.problem destaca cards de dor com borda âmbar e fundo amber-bg.