PLANO DE EXECUÇÃO — BidQualifier (go/no-go de RFQ para estimator de sub)

PLANO DE EXECUÇÃO — BidQualifier (go/no-go de RFQ para estimator de sub)

May (Marty) · Missão 1 · Estágio 3 (PLANEJADA) · M1-006 · 2026-09-02

Status: rascunho completo → auto-revisão QA N1 (seção final) → pronto para 🔔 do Felipe (1 APROVAR = começa GATE 0 · 2 PEDIR AJUSTES · 3 ARQUIVAR). Fonte: dossiê marty/dossies/ideia-b1-bidqualifier.md (seções citadas como §N) · decisão Felipe 02/09 = aprofundar (revertido do MATAR a pedido, 20:24) · dedup NOVO-ADJACENTE A M1-004 (hash fa1e6504133de9a0) · NÃO alterou CSVs. ⚠️ PONTO CRÍTICO (do QA do dossiê §15): BidQualifier é possível irmã/módulo do M1-004 AddendaWatch (mesmo ICP — estimator de specialty sub — e mesma fase de bid). Este plano trata isso explicitamente: (a) a decisão produto isolado × módulo do AddendaWatch é parte do Gate 0 (pergunta ao Felipe com recomendação, §5.2); (b) se isolado, o que justifica (decisões e inputs diferentes — §5.2a); (c) o risco de "planilha cara" se o produto virar tracking-only é critério de morte explícito (§5.2, G1, anti-reciclagem M1-R18). O M1-004 segue validada sem decisão do Felipe (ops/ideias.csv 02/09 20:24) — o 🔔 do Gate 0 deste plano pede a decisão da família na mesma mensagem. Regra de ouro deste plano: NADA de construção, gasto ou publicação acontece antes do GATE 0 passar (teste-48h do dossiê §14 — ver seção 5.2). A ressalva M13 do dossiê (prova de uso pendente: nenhum trial testado) vira critério explícito de passagem do Gate 0, e a ressalva de redundância com M1-004 vira a decisão de família dentro do próprio Gate 0. Nota operacional: o vínculo link_plano em ops/ideias.csv é gravado pelo OPS/agente pai (este documento não toca CSV).

---

0. RESUMO EXECUTIVO (3 linhas)

O estimator de specialty sub recebe 100-200 RFQs/ano de 10 GCs diferentes com a equipe de estimativa como gargalo — e a empresa cota "tudo" por medo de perder obra: quem cotava tudo tinha 1% de aproveitamento, quem escolhia bem tinha 40%, faturando o mesmo (hit rate típico do setor: 10-20%), e o único registro é uma planilha de bid list que ninguém alimenta (dossiê §1-3). O produto é um motor de go/no-go que lê a RFQ que chegou (PDF/e-mail/portal), cruza com o histórico de win/loss do próprio sub (por GC, trade, tamanho, região) e responde em minutos "vale a pena cotar?" (fit, requisitos, capacidade, win-rate por tipo) — e depois do bid day captura o resultado com 2 cliques e aprende com cada vitória/derrota — self-serve, US$ 549/mês ou US$ 4.200/ano (qualifica os dois pisos M4). Antes de construir qualquer coisa: GATE 0 executa o teste-48h do dossiê (15 entrevistas go/no-go + trials de Contractor Foreman/STACK/ProEst + pré-venda), valida a NÃO-REDUNDÂNCIA com o M1-004 AddendaWatch (irmã de mesmo ICP/fase) e traz a decisão de família (isolado vs módulo) no mesmo 🔔 — mata barato se o gut for o padrão-ouro, se o barato já cobrir a decisão, ou se for duplicata do M1-004.

---

1. ESPECIFICAÇÃO DA SOLUÇÃO

1.1 Necessidade (do dossiê — §1, §2, §3)

"Eu recebo 100-200 pedidos de cotação por ano de 10 GCs diferentes e minha equipe de estimativa é o gargalo — mas a gente cota 'tudo' porque o dono tem medo de perder obra. Resultado: estimator que cotava tudo tinha 1% de aproveitamento e o que escolhia bem tinha 40%, faturando o mesmo. Não existe ferramenta que me diga antes de eu gastar 10 horas se esta RFQ vale a pena — o único registro é uma planilha Excel de bid list que ninguém alimenta."

• Quem sente: estimator sênior / chief estimator e o dono/VP de estimativa de sub especializada (elétrica, mecânica, hidráulica, chapa, concreto, fundações, divisão 9), US$ 3-20M de receita, que licita ≥30 obras/ano contra múltiplos GCs (dossiê §4); o dono decide "cotamos tudo?" na base do medo (dossiê §6, prova 6) e o estimator é o usuário e o "comprador moral".
• Custo atual: hit rate típico 10-20% = 80-90% das horas de estimativa vão para bids perdidos (dossiê §2 provas 1-2); anedota declarada de 1% vs 40% faturando igual (prova 1 — anedota, sinal qualitativo, não estatística, §15); US$ 10-25k/ano de horas de estimator em bids sem chance (150 bids × 10 h × US$ 60 = US$ 90k de esforço; fração atacável 10-25% ≈ US$ 13k/ano — ESTIMATIVA rotulada com método, §3). Custo do erro oposto: go/no-go agressivo corta a obra boa (relação com GC, reputação) — por isso o debrief pós-bid calibra, não só corta volume (§3, §13.2).
• Por que existe o espaço: o barato (Excel US$ 0, Contractor Foreman US$ 49/mês) já ganhou a camada registro; os incumbentes têm o lead (ConstructConnect/PlanHub), o canal (portais do GC) ou o estimar (STACK/ProEst/Bluebeam) — nenhum tem a decisão com os dados do próprio pipeline do sub: score go/no-go por RFQ + win/loss analytics calibrado + debrief de perda (matriz §7c: 5 fatias vazias). Veredito do dossiê: GAP PROVÁVEL — NÃO COMPROVADO POR USO (M13: trials pendentes).

1.2 Forma concierge → self-serve

O produto nasce concierge (semanas 6-8) e vira self-serve (semanas 8-12), mesmo padrão do CostSense e dos planos M1-001/M1-002:

1. Fase concierge (prova de valor): 3 subs piloto encaminham as RFQs que recebem (forward do e-mail ou upload do PDF) e importam a bid list do ano (CSV do Excel deles); o agente CONCIERGE roda o motor, revisa 100%, entrega o go/no-go com as razões + o registro de decisão, e assiste o debrief de cada resultado (ganhou/perdeu, por quê). Cada correção do estimator vira caso de aprendizado e teste automatizado. É a isca de prova (seção 2.1) e a fábrica de regras — ninguém paga ainda.
2. Fase self-serve (produto): o mesmo motor, atrás de um onboarding guiado (importar histórico → conectar o forward de RFQs → wizard de confirmação do que o motor não leu com certeza → score sob demanda → debrief de 2 cliques → painel). A decisão final é sempre humana (o estimator/dono clica COTAR/NÃO COTAR; o score é insumo rotulado — ver contrato de saída).

1.3 Motor etapa por etapa (entrada → saída)

Pipeline único, reutilizado pelo concierge e pelo self-serve. Ordem deliberada: a base win/loss e o debrief vêm ANTES do score (sem histórico não há score calibrado — e a captura de resultado é o ponto de falha que mata o produto, §13.4):

1.4 Contrato de saída (o que o cliente recebe — e o que NÃO recebe)

• Por RFQ recebida: score go/no-go com as razões ("o que esta RFQ exige que você não tem", "este GC você nunca ganhou em X tentativas", "sua equipe está com Y bids em aberto") + recomendação COTAR/COTAR COM RESSALVAS/NÃO COTAR. Pronto para o estimator decidir em 1 clique.
• Pós-bid day: debrief de 2 cliques gerado automaticamente para cada bid encerrado (sem digitação de parágrafo); base win/loss atualizada e consultável por GC/trade/tamanho/região.
• Dados: 100% do cliente. Export total (CSV/PDF) a qualquer momento; cancelamento sem multa (mensal) / pró-rata no anual. O histórico win/loss é o ativo do cliente (dossiê §9) — portabilidade garantida.
• Prazo: RFQ encaminhada até as 17:00 → score na manhã seguinte (concierge); self-serve = em minutos. Correção apontada em até 24h se o erro for nosso (regra vira teste).
• O que NÃO entra no contrato (limite de responsabilidade explícito): o software não decide (a decisão de cotar é humana — score é heurística rotulada, nunca "probabilidade de vitória" prometida, §12), não cotar (takeoff/preço continuam em Bluebeam/STACK/ProEst/Excel), não envia proposta (a resposta ao GC segue pelo canal de sempre do sub), não é CRM de leads (ConstructConnect/PlanHub continuam sendo a fonte de convites) e não é assessoria de bid strategy (o debrief aponta o padrão; a estratégia é do dono).

1.5 MVP — o que entra e o que fica de fora (explícito)

ENTRA (v1, até a semana 12):

• Captura de RFQ por upload de PDF e forward de e-mail (sem integração API com portais no MVP).
• Importador da bid list histórica (CSV/Excel) para semear a base win/loss + começo vazio para quem não tem registro.
• Score go/no-go com 4 fatores (fit, requisitos, capacidade, win-rate histórico por tipo), pesos calibrados por sub, saída COTAR / COTAR COM RESSALVAS / NÃO COTAR + razões + "o que mudaria o veredito". Score rotulado como heurística.
• Registro de decisão (1 clique) + debrief de 2 cliques com captura semiautomática (e-mail do GC/status do portal).
• Painel: win rate por GC/trade/tamanho/região + custo de horas em bids sem chance.
• 1 conta = 1 sub; até 3 usuários (estimator + office manager + dono); até 100 RFQs avaliadas/mês (cobre o volume do ICP de 100-200/ano com folga — limite de produto, não de negócio).
• Histórico consultável + export total.

FICA DE FORA (explícito — não é escopo do MVP):

• ❌ Não é registro puro (tracking-only): a camada de registro só existe como insumo do score/debrief — o produto que vira "bid list bonita" é exatamente o M1-R18 BidFunnel que já morreu (arquivada: tracking-only sem WTP) e a "planilha de US$ 549" do caso contra do QA (§15) → critério de morte G1.
• ❌ Sem takeoff/estimativa de preço (Bluebeam/STACK/ProEst seguem donos do "estimar"); margem entra como input do estimator, não é calculada.
• ❌ Sem integração API com portais do GC (Procore/ACC/STACK rooms) no MVP (só forward/upload); extensão de navegador = pivô P4 se a captura não segurar volume.
• ❌ Sem envio de proposta/resposta ao GC; sem CRM de leads; sem previsão de vitória como promessa (heurística rotulada).
• ❌ Fora do ICP: GCs/primes (recebem bids, não decidem cotar contra GCs maiores); sub com <30 bids/ano (ticket não fecha — dossiê §9); conta que quer só o registro (Excel/CF US$ 49 já cobrem); o estimator que decide 100% por relacionamento e não quer dado (não é lead, é o risco do produto — §13.1).
• ❌ Multi-idioma, app mobile, white-label, integração com estimating software (pós-MVP).

---

2. ESTRATÉGIA DE ENTRADA

2.1 Isca de prova antes do pitch

"Score de 3 RFQs atuais, grátis" — o prospect encaminha 3 RFQs que recebeu (reais, em aberto) e, se tiver, a bid list do ano; recebe em 24-48h o go/no-go de cada uma com as razões: "esta RFQ exige bond de US$ 2M — vocês têm?", "deste GC vocês ganharam 1 de 9 nos últimos 2 anos", "a equipe já está com 8 bids em aberto". Quem vê o próprio histórico falando (ou o requisito que ninguém tinha notado) sente a dor em números e vira lead quente (o concierge do piloto usa a mesma oferta). Custo: ~15-30 min de agente por prospect. Segundo estágio da isca no self-serve: lista de espera da página (seção 6) com "3 RFQs grátis no lançamento".

2.2 Canais (todos gratuitos; ordem de prioridade — mesmo ICP/canais do M1-004, família)

1. Resposta orgânica onde a dor fala: r/Estimators (as threads citadas no dossiê §2 são a prova social pronta: "Bid win rate for all divisions", "How to deal with losing bids", "Total Bid Volume Per Year", "How many bids have you sent this year?", "Trapped in Perpetual Bidding", "What % of bids do you win?") + grupos de specialty trade (elétrica, mecânica, hidráulica — Facebook/LinkedIn) + r/Construction. Responder com ajuda real (May redige o texto; Felipe posta na conta dele — May não posta). É inbound com prova social.
2. E-mail direto/DM para o gatilho de compra: empresas recém-contratando estimator/bid coordinator (vaga ativa = volume subiu e o estimator virou gargalo — o gatilho (a) do dossiê §4). A vaga data o momento de dor, mesma mecânica do canal 2 do M1-001.
3. GCs como fonte de inbound, não ICP: conteúdo "como os melhores subs decidem o que cotar (e por que 'cotar tudo' custa caro)" + GCs que conhecem os subs parceiros afogados indicam (sem comissão no MVP). O GC não paga; ele aponta o sub.
4. LinkedIn do Felipe (post/manual: a anedota 1% vs 40% é o gancho) + lista de espera da página Orbitask.
5. SEO (categoria go/no-go): páginas "bid/no-bid decision for subcontractors", "should I bid this project", "win rate by trade / by GC" — a categoria tem nome estabelecido no setor (bid/no-bid) e os incumbentes não disputam esse vocabulário (vendem leads/takeoff).
6. Irmã M1-004: se a decisão de família for módulo (Gate 0), a distribuição é única — mesma lista de espera e mesmo canal do AddendaWatch (um bid desk); os dois planos não dividem o mesmo orçamento de aquisição duas vezes (§13.5).

• Canal que NÃO existe no MVP: anúncio pago (gasto 🔔) e marketplace (produto cedo demais).

2.3 ICP (do dossiê §4, §5, §9 — idêntico ao do M1-004)

2.4 Template de outreach (rascunho — 5 linhas, EN; envio só após 🔔 do texto, protocolo May/Marty)

Subject: Before you spend 10 hours on that next RFQ

>

Hi [First name],

>

I help specialty subs decide which RFQs are actually worth bidding — most estimators spend 80-90% of their hours on bids they lose, and the subs who pick selectively win 2-3x more with the same revenue.

>

We read the RFQ that just landed (PDF or email), match it against your own win/loss history by GC, trade and job size, and tell you in minutes: bid, bid with caution, or pass — and why.

>

Want me to score 3 of your current RFQs free so you can check us against your gut? Just forward them — 48h, no strings.

>

[Nome] — Orbitask · BidQualifier

---

3. ARQUITETURA DE AGENTES (construir e operar — padrão CostSense/Marty)

A ideia é do May (Missão 1); construir é decisão humana do Felipe (guardrail 9). Aprovado o Gate 0 (🔔 AVANÇAR), a construção roda como linha de produto da Orbitask: sub-agentes efêmeros (sessões OpenClaw) com sub-planos próprios no padrão do CostSense, sob supervisão do Felipe. O May (fábrica) segue rodando em paralelo, sem conflito. Nota de família: se a decisão do Gate 0 for módulo do M1-004, o DEV compartilha o modelo de dados do bid desk com o AddendaWatch (um sub-dev, dois módulos — o registro versionado do watch é insumo do score, dossiê §7c) — o re-planejamento é o pivô P2 (§5.3).

3.1 Sub-agentes de produto

QA de dois níveis: N1 = revisão leve de produção (quem produz revisa — ex.: a auto-revisão na seção final deste arquivo); N2 = adversarial, sessão nova, sempre antes do que toca o mundo externo (cliente, GC, página, release). N2 nunca revisa o próprio trabalho e nunca recebe o raciocínio de quem produziu.

3.2 Crons (operação, após o Bloco 3)

• Diário 18:00 ET — DEV/OPS: processa as RFQs do dia (upload/forward), roda o score, enfileira recomendações e lembretes de debrief pendente.
• Seg 09:00 ET — DEV: varre resultados de bids encerrados (e-mail do GC/portal/status) → gera debriefs de 2 cliques para o estimator confirmar.
• 1ª seg do mês — DEV: retro de calibração do score vs resultados reais (acurácia por GC/trade/tamanho; onde o score discordou do humano e quem acertou) → ajuste de pesos + changelog.
• Sex 17:00 ET — digest semanal (já existente): entra o placar do produto (RFQs avaliadas, decisões mudadas/confirmadas pelo score, taxa de debrief preenchido, pilotos pagantes).
• QA-N2 — amostra semanal de decisões/debriefs no 1º mês, depois mensal; taxa de erro → retro.
• Diário — OPS: lembrete de aprovações pendentes ≥24h (mesmo ritual do May).

3.3 Sub-planos

Criados no Bloco 1, passo 12, em planos/sub-*.md no padrão CostSense: sub-dev-motor.md, sub-concierge.md, sub-conteudo.md (VALIDAÇÃO/COMPETIÇÃO/QA/OPS reutilizam os sub-planos existentes + ops/). Critério: cada sub-agente com plano vivo antes de atuar. Se família com M1-004: um único sub-dev-bid-desk.md cobre os dois módulos (watch + go/no-go).

---

4. PASSO A PASSO (responsável · 🔔 aprovação · ✅ critério de pronto)

BLOCO 0 — GATE 0 · teste-48h do dossiê (pesquisa; custo US$ 0-10; proíbe construção/gasto/publicação)

Critérios de passagem/morte na seção 5.2, incluindo o teste de não-redundância com M1-004 e a decisão de família no 🔔 final. Nenhuma etapa deste bloco constrói produto.

1. [PLANEJADOR] Montar lista de ≥30 candidatos a entrevista (meta 15): autores das threads Reddit citadas no dossiê (§2: bid win rate, deal with losing bids, total bid volume, how many bids, trapped in perpetual bidding, small GC, what % do you win), empresas com vaga ativa de estimator/bid coordinator (gatilho gargalo), 29 alvos do Gate 0 do M1-001 (mesmo ICP); colunas: nome, empresa, papel, canal, link. → ✅ ≥30 contatos com canal identificado e fonte.
2. [PLANEJADOR → 🔔 Felipe] Redigir (a) convite de entrevista (DM/e-mail, 4 linhas), (b) roteiro de entrevista de go/no-go (~12 perguntas: volume anual de RFQs; como decide o que cotar hoje; confiança no gut/relacionamento vs dado; % de win por tipo de obra/GC/trade; já tentou planilha de win/loss e abandonou? quem alimenta o registro hoje; WTP em 2 pontos — US$ 200 vs US$ 549/mês + anual US$ 4.200 — com o mostruário da 1 página; teste de redundância: apresentar as duas dores — "vigiar addenda/versões de bids em andamento" × "decidir o que cotar e aprender com o resultado" — "para você é um problema só ou dois? compraria em 1 ferramenta ou 2?") e (c) e-mail de solicitação das 3 demos (CF Opportunities/STACK/ProEst). → 🔔 Felipe aprova os 3 textos (e-mail em nome do Felipe só após aprovação — protocolo May). ✅ Textos aprovados (ou ajustados).
3. [VALIDAÇÃO + Felipe] Executar 15 entrevistas: Felipe envia DMs (LinkedIn/Reddit, manual); VALIDAÇÃO envia e-mails aprovados e coleta respostas assíncronas; até 5 chamadas de 15 min com roteiro (Felipe na linha, VALIDAÇÃO registra). → ✅ ≥15 entrevistas concluídas, cada uma com resposta de WTP e do teste de redundância (fonte + data).
4. [COMPETIÇÃO] Executar os 3 trials/demos (Contractor Foreman "Opportunities", STACK, Autodesk ProEst): preferir vídeo/gravação + pricing por escrito; se live, Felipe entra 15-20 min. Foco da prova M13: o que eles entregam de go/no-go, win/loss analytics e debrief — e a que preço. → ✅ Prova de uso M13 fechada: por concorrente, o que entrega self-serve, preço real, sobreposição com a nossa camada. ⚠️ Se após 5 dias úteis alguma demo não ocorreu nem por vídeo/escrito → Gate 0 NÃO passa (bloqueado, não morto) até M13 fechar.
5. [CONTEÚDO] Pré-venda de 1 página com pricing (US$ 549/mês e US$ 4.200/ano, o que resolve — score + debrief + base win/loss, CTA lista de espera) — usada como mostruário nas entrevistas; não publicada (publicação é M19, só no Bloco 3). → ✅ 1 página rascunhada e usada nas entrevistas.
6. [QA-N2] Revisão adversarial do relatório do Gate 0 (sessão nova: só relatório + critérios de morte da seção 5.2). → ✅ Veredito em ops/qa-verdicts.md.
7. [OPS → 🔔 Felipe] Alerta com resultado consolidado: WTP (X/15), achados das 3 demos, respostas "Excel resolve", teste de redundância (Y/15 "é um problema só") + pedido de decisão do M1-004 se ainda pendente (mesma mensagem) + recomendação de família (§5.2a). → 🔔 1 AVANÇAR ISOLADO · 2 AVANÇAR COMO MÓDULO DO M1-004 (família) · 3 AJUSTAR (preço/escopo/posição) · 4 ARQUIVAR (morte com motivo em ops/rejeitadas.csv — OPS/agente pai grava; PLANEJADOR não toca CSV). ✅ Decisão registrada.

BLOCO 1 — BASE WIN/LOSS + DEBRIEF (semanas 1-3 · após Gate 0 ✅ + 🔔 AVANÇAR)

A fundação na ordem certa: sem captura de resultado viva, o score nasce cego e o produto vira planilha (M1-R18).

1. [DEV] Modelo de dados do bid desk (RFQ, GC, trade, porte, região, status, resultado, motivo, decisão) + importador CSV da bid list (Excel padrão do setor, dossiê §2 prova 3) com mapeamento assistido. → ✅ 2 CSVs reais de pilotos importados sem erro.
2. [DEV] Captura de resultado quase automática: parser de e-mail do GC (award/regret), status manual de 2 cliques (ganhou/perdeu + motivo: preço/relacionamento/escopo/bond/prazo), import de status do portal. → ✅ 1 resultado real capturado sem digitação de parágrafo.
3. [DEV] Painel base: win rate por GC/trade/tamanho/região + volume de horas estimadas em bids perdidos. → ✅ Painel bate com o CSV de origem (auditoria de totais).
4. [QA-N2] Release da base (sessão adversarial, casos-teste com CSV real). → ✅ Veredito; 0 divergência de totais nos casos.
5. [OPS] Sub-planos dos papéis de produto criados (seção 3.3). → ✅ Sub-planos vivos no padrão CostSense.

BLOCO 2 — SCORE GO/NO-GO + PILOTO CONCIERGE (semanas 4-8 · 3 subs reais · ninguém paga ainda)

1. [DEV] Parser de RFQ (upload PDF/forward de e-mail): extrai GC, obra, local, escopo (Divisões/trade), prazo do bid, bond/licença/insurance exigidos. → ✅ ≥80% de extração correta em 10 RFQs-teste reais; campo ambíguo nunca silencioso (pede confirmação).
2. [DEV] Scorer go/no-go: fit (escopo × trades do sub), requisitos (bond/licença ausente = trava), capacidade (bids em aberto × equipe), win-rate histórico do sub por GC/trade/tamanho; pesos calibrados; saída COTAR / COTAR COM RESSALVAS / NÃO COTAR + razões + "o que mudaria o veredito"; score rotulado como heurística. → ✅ Score bate com o veredito do estimator sênior em ≥70% dos 10 casos históricos (retro) — ou pesos ajustados até bater (calibração do G1, seção 5.3).
3. [PLANEJADOR → 🔔 Felipe] Texto do convite do piloto gratuito ("3 RFQs atuais com score grátis" — isca, seção 2.1). → 🔔 Aprovação do texto. ✅ Aprovado.
4. [VALIDAÇÃO/Felipe] Recrutar 3 subs do ICP (prioridade: os de WTP do Gate 0 com gatilho recente — estimator recém-contratado ou dono pedindo "menos bids, melhores"). → ✅ 3 subs ativos com aceite por e-mail (sem NDA formal no piloto; se surgir termo → 🔔 Felipe assina).
5. [CONCIERGE] Operar o serviço 3-4 semanas: RFQ do piloto → score → estimator decide (registra se o score mudou ou confirmou a decisão) → debrief capturado; revisão humana 100% no início. → ✅ ≥2 pilotos com ≥10 RFQs avaliadas cada; em cada um, ≥1 decisão mudada pelo score OU ≥3 confirmadas com dado ("concordância útil").
6. [DEV] Feedback loop: cada correção do estimator vira teste/regra de extração e calibração de pesos. → ✅ 100% das correções da semana viram teste automatizado.
7. [CONCIERGE] Medir WTP pós-uso ("se custasse US$ 549/mês, continua?") e confiança ("o score acertou quando discordou do seu gut?"). → ✅ WTP registrado por piloto (fonte + data).
8. [QA-N2] Retro do piloto (o que o estimator rejeitou do score, o que mudou decisões, taxa de adesão). → ✅ Relatório com taxa de adesão + lista de gaps.

BLOCO 3 — SELF-SERVE + LANÇAMENTO (semanas 8-12 · 🔔 em cada passo externo)

1. [DEV] Self-serve: onboarding (import histórico → conexão do forward de RFQ → wizard de confirmação), score sob demanda, debrief de 2 cliques, painel, export total. → ✅ Jornada ponta a ponta testada pelo QA-N2 com 2 subs do piloto sem assistência.
2. [PLANEJADOR/CONTEÚDO → 🔔 Felipe] Pricing final (US$ 549/mês / US$ 4.200/ano; qualquer ajuste não pode descer abaixo do piso M4 — abaixo disso = arquivar a ideia com motivo) + página Orbitask versão final. → 🔔 Aprovação (M19). ✅ Aprovado.
3. [OPS → 🔔 Felipe] Converter 2-3 pilotos em 1ºs pagantes (preço de lançamento, carta simples) + ativar cobrança (Stripe/Felipe; May não move dinheiro — guardrail 1). → 🔔 Felipe autoriza cobrança. ✅ ≥2 pilotos pagantes OU ≥3 pré-vendas na lista de espera.
4. [CONTEÚDO → 🔔 Felipe] Publicar a página na Orbitask (em breve → disponível) + anúncio de lançamento. → 🔔 Aprovação do texto E da publicação (M19 — ver seção 6). ✅ Página no ar + anúncio enviado.
5. [OPS] Ligar crons de operação (seção 3.2) + ledger de gastos. → ✅ Operação rodando 2 semanas sem intervenção manual crítica.

Fim do passo a passo → 1º cliente pagante em ~12 semanas (SOLO: SIM, dossiê §10: 1-3 registro+debrief, 4-6 score, 6-8 concierge, 8-12 self-serve+pricing). A partir daqui o produto vive em regime de operação contínua com retro semanal (QA + OPS + calibração mensal do score) e a Missão 1 do May segue em paralelo rumo às 100 ideias.

---

5. ORÇAMENTO MÍNIMO + GATES/PIVÔS PRÉ-DESENHADOS

5.1 Orçamento mínimo

Padrão = grátis. Cérebro (DeepSeek/OpenClaw) e infra base já existem; canais e fontes (Reddit, LinkedIn, e-mail, portais dos GCs nos trials) são gratuitos; libs PDF/CSV open-source; página em free tier (Netlify/Cloudflare, padrão CostSense). Stripe só entra quando houver 1ª receita (custo ~2,9%/transação — 🔔 na ativação).

5.2 GATE 0 — OBRIGATÓRIO, ANTES DE QUALQUER CONSTRUÇÃO (teste-48h do dossiê §14)

O dossiê já definiu o teste; este plano o torna portão de entrada — e acrescenta o teste de não-redundância com M1-004 e a decisão de família (ponto crítico do QA §15). O plano NÃO avança para construção sem o Gate 0 passar. Silêncio ≠ aprovação (lembrete 24h pelo cron).

5.2a A DECISÃO DE FAMÍLIA (isolado × módulo do M1-004 AddendaWatch) — perguntar ao Felipe no 🔔 do Gate 0, com recomendação

• (a) A pergunta: BidQualifier e AddendaWatch compartilham ICP (estimator de specialty sub), fase (bid) e até o bid register (matriz §7c do dossiê). São dois produtos (cada um US$ 549/mês no mesmo comprador = canibalização e confusão de mercado interno, §13.5) ou um bid desk com dois módulos (ticket único)? O QA pai recomendou: se o M1-004 for aprovada, tratar este como módulo/fase 2 da família. Recomendação do PLANEJADOR: se o Felipe aprofundar o M1-004 → FAMÍLIA (módulo do mesmo bid desk; BidQualifier como o motor de decisão + debrief, AddendaWatch como a vigia de escopo); se o M1-004 for arquivada/morta → BidQualifier ISOLADO. O 🔔 do Gate 0 (passo 7) decide com os dados do teste de redundância na mão.
• (b) O que justifica o isolado (se a decisão for essa): são decisões e inputs diferentes — AddendaWatch responde "o escopo/desenho do meu bid em andamento mudou?" (entrada: addenda/versões; momento: durante o bid; ativo: trilha versionada por bid); BidQualifier responde "esta RFQ vale a pena cotar? e por que ganhei/perdi?" (entrada: RFQ + histórico win/loss; momento: antes de entrar no funil e depois do resultado; ativo: win rate calibrado por GC/trade/tamanho/preço). O watch não decide entrada e o go/no-go não vigia versões — complementares, não sobrepostos (dossiê §7c). Isolado faz sentido se o M1-004 não avançar (o score não depende do watch para viver; depende da base win/loss, que é deste produto).
• (c) O risco de planilha cara se tracking-only: o BidQualifier só se sustenta como camada de decisão+debrief com dados — a camada registro já está ganha pelo barato (Excel US$ 0, CF US$ 49). Se as entrevistas/piloto mostrarem que o sub quer "só organizar os bids", o produto é o M1-R18 BidFunnel (já arquivado: tracking-only sem WTP) e morre no Gate 0 (critério c/e) ou no G1 (ninguém alimenta). Este risco é critério de morte explícito, não ressalva.

5.3 Gates seguintes e pivôs pré-desenhados

Pivôs pré-desenhados (baratos, decididos no gate, nunca em pânico):

• P1 · score genérico → score calibrado/explicável: se o score não mudar/confirmar decisões no piloto, ajustar pesos às regras do próprio sub e forçar o "porquê" em linguagem de estimator ("você nunca ganhou obra > US$ 2M deste GC", "esta RFQ pede licença que vence em 30 dias") — o estimator precisa ver o próprio histórico falando, não um número mágico (§13.1).
• P2 · isolado → módulo do M1-004 (família): se o Gate 0 decidir família (Felipe aprova o M1-004 e o teste de redundância indicar um bid desk só), este plano é re-planejado como fase 2 do AddendaWatch — mesmo modelo de dados, ticket único, watch primeiro (dor fresca 31/08/2026 do M1-004) e go/no-go como segundo módulo. O B0 deste plano já produziu os dados do re-planejamento.
• P3 · self-serve → serviço gerenciado: se o sub pequeno não quer operar software, entregar o mesmo motor como serviço (score + debrief operados pelo concierge permanente) no mesmo ticket US$ 549.
• P4 · forward/upload → extensão de navegador/hook de e-mail: se o piloto mostrar que ninguém encaminha RFQ (captura morta = produto morto), a captura vira extensão de navegador sobre os portais/inbox do estimator.

---

6. PÁGINA DO SERVIÇO NA ORBITASK — rascunho "EM BREVE"

Marca guarda-chuva Orbitask, produto filho. Rascunho de 3-5 linhas + CTA (M19). PUBLICAÇÃO SÓ COM 🔔 APROVAÇÃO DO FELIPE (passo 24, Bloco 3; nada de "em breve" no ar antes do Gate 0 ✅ — página externa é publicação). Versão final deriva deste rascunho após pricing validado no piloto. Se a decisão de família for módulo do M1-004, esta página nasce como seção do bid desk do AddendaWatch (uma página, dois módulos) — ajuste no Bloco 3.

BidQualifier — em breve, by Orbitask

>

Estimator: cansado de gastar 10 horas numa RFQ que nunca ia vencer? O BidQualifier lê a RFQ que chegou (PDF ou e-mail), cruza com o seu histórico de win/loss por GC, trade e tamanho de obra e responde em minutos: cotar, cotar com ressalvas ou não cotar — e por quê. Depois do bid day, registra o resultado com 2 cliques e aprende com cada vitória e derrota.

>

Feito para specialty subs que recebem mais pedidos de cotação do que a equipe de estimativa consegue avaliar — quem cota tudo fatura igual a quem escolhe bem, só que com 40x mais trabalho.

>

CTA: "Quero o score grátis de 3 RFQs atuais → [lista de espera]"

---

QA N1 — AUTO-REVISÃO ADVERSARIAL DO PLANO (2026-09-02, pelo PLANEJADOR)

Sessão de auto-verificação antes do envio ao Felipe; QA-N2 externo segue obrigatório no Gate 0 (passo 6) e em toda entrega externa. Checklist Missão 1 aplicado ao PLANO (não re-julga a ideia — o dossiê já foi aprovado com ressalva pelo Felipe, revertido do MATAR a pedido dele).

• [x] Executável solo? Sim — todo o trabalho pesado é de agente (motor, parser, scorer, concierge, textos). Dependências humanas explícitas e mínimas: Felipe envia DMs, participa de demos/chamadas, clica 🔔 (R1/R2 abaixo).
• [x] Gates matam cedo? Sim — Gate 0 é 100% pesquisa, US$ 0-10, antes de qualquer linha de código/gasto/publicação; critérios de morte do dossiê §14 reproduzidos sem drift (a-d) + (e) derivado do §13.1/§15 ("gut é padrão-ouro") + (f) teste de redundância com M1-004 + (g) veto do pai; M13 vira critério de passagem explícito. G1 mata o risco tracking-only (anti-reciclagem M1-R18) antes do score nascer.
• [x] Números batem com o dossiê? Conferido campo a campo: ticket 549/4.200 (qualifica os dois pisos M4) · mercado 839.609 specialty (fato naics.com) / fatia ICP 25-50k (estimativa herdada do M1-004, rotulada) · hit rate típico 10-20% · anedota 1% vs 40% rotulada qualitativa (não estatística) · 100-200 RFQs/ano · US$ 10-25k/ano de horas (ESTIMATIVA com método) · ≥30 bids/ano (piso do ICP) · 8 concorrentes · MOAT: DADO parcial · SOLO: SIM 8-12 semanas · hash dedup fa1e6504133de9a0 · morte §14 intacta. Zero drift.
• [x] Orçamento: US$ 0 padrão; todo gasto ≠ 0 com 🔔 (guardrail 1). Conforme.
• [x] Regras do May: M3 (plano só pós-Portão 2 ✅ — Felipe aprofundou 20:24), M4, M12/M13 (trials no Gate 0), M19 (publicação 🔔), guardrails 1/5/6/9 respeitados; anti-reciclagem tratado em 3 camadas: dedup NOVO-ADJACENTE (não é a mesma solução do M1-004 — M12 não aplica — mas duplicata em potencial aos olhos do Felipe, decidida no Gate 0), M1-R18 BidFunnel (tracking-only) vivo como critério de morte G1, sem colisão com M1-001/002/003.
• [x] O caso contra continua vivo no plano? Sim — seção 5.2 preserva as mortes do dossiê e acrescenta a explícita do "gut padrão-ouro" (e) e a da redundância (f); 5.3 acrescenta a morte pós-piloto (score que não muda nem confirma decisão = enfeite).

Ressalvas (4 registradas):

1. R1 — a decisão de família depende de um M1-004 ainda sem decisão do Felipe. O M1-004 segue validada, sem decisao_felipe (ops/ideias.csv 02/09 20:24) — se o Felipe aprofundar o M1-004 depois deste plano, a resposta de "isolado vs módulo" muda com o dado novo. Mitigação: o teste de redundância roda DENTRO do Gate 0 deste plano (pergunta 12 do roteiro), o 🔔 do passo 7 pede a decisão da família na mesma mensagem com recomendação explícita (§5.2a), e o pivô P2 re-planeja como fase 2 sem retrabalho (o B0 já produziu os dados).
2. R2 — dependência humana comprime o "48h". O Gate 0 depende de Felipe para DMs/chamadas e das agendas de vendedor para os trials; na prática pode levar 5-7 dias úteis. Mitigação já no plano: entrevistas assíncronas por e-mail aprovado, trials por vídeo/escrito, e atraso = bloqueio relembrado pelo cron de aprovações (nunca morte silenciosa).
3. R3 — amostra de 15 viesada + anedota é anedota. Quem responde DM/Reddit tende a ser early adopter, e a história 1% vs 40% é qualitativa (relacionamento, não score — é exatamente o risco do produto). Mitigação: exigir resposta de WTP com valor concreto e o que paga hoje; os critérios (a) e (e) medem o risco "gut padrão-ouro" de dois ângulos (dor fraca × rejeição ao dado); anedota usada como gancho de venda e hipótese, nunca como número de mercado.
4. R4 — fronteira fina com o que já morreu (M1-R18 BidFunnel, tracking-only). O registro vivo é necessário (sem base win/loss não há score) mas nunca pode virar o produto — o barato já ganhou o registro (Excel US$ 0, CF US$ 49). Mitigação: a captura de resultado é quase automática por desenho (e-mail/portal/2 cliques, §13.4), o G1 mata se ninguém alimenta, e o critério (c)/(f) do Gate 0 pega o comprador "só quero organizar".

Veredito QA N1: APROVADO COM RESSALVA — executável solo com as ressalvas acima; gates matam antes de qualquer gasto/construção; a relação com o M1-004 é tratada como decisão de produto explícita no Gate 0, não como acidente; nada impede o envio ao Felipe.

---

ALERTA 🔔 PRONTO PARA O FELIPE (cópia para o OPS disparar; este subagente não enviou nada)

`` 💡 PLANO M1-006 — BidQualifier (go/no-go de RFQ de sub) Contém: especificação completa (RFQ → extrair escopo/trade/local/GC → score go/no-go com fit/margem/capacidade/win-rate histórico → recomendação + debrief win/loss pós-bid → base win/loss própria do sub; concierge → self-serve; MVP explícito, sem tracking-only) + estratégia de entrada (3 RFQs atuais grátis de isca; canais do ICP do M1-004) + arquitetura de agentes + passo a passo com 🔔 e ✅ + página Orbitask rascunhada. GATE 0 obrigatório ANTES de construir: teste-48h do dossiê (15 entrevistas go/no-go com WTP 2 pontos + trials CF/STACK/ProEst + pré-venda 1 página) + teste de NÃO-REDUNDÂNCIA com o M1-004 (irmã de mesmo ICP/fase) e a DECISÃO DE FAMÍLIA no mesmo 🔔: produto isolado vs módulo do AddendaWatch (recomendação: família se o M1-004 for aprovada; isolado se não). Critérios de morte incluem 'gut é padrão-ouro' e tracking-only. Orçamento: US$ 0-10; qualquer gasto 🔔. QA N1: APROVADO COM RESSALVA (4 ressalvas no arquivo, seção final). → 1 APROVAR (começa Gate 0) · 2 PEDIR AJUSTES · 3 ARQUIVAR ``