Reconciliação v2 · V4 Quests
Maturidade: ● caminho pronto · ◑ esboço · ○ sem caminho.
Mensagem de atendimento pronta para o cliente, no tom certo, sem o gestor caçar o que escrever — comprador: gestor de projetos / AM.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-A6CCBF7A | Atendimento Diário Problema: atendimento sem padronização — cada account improvisa o que responder, alguns clientes recebem mensagem igual à de outro, falta personalização; o gestor gasta 10–20 min por atendimento só decidindo o que escrever. Resolve: primeiro protótipo já publicado (demo no ar); com o Nekt disponível como fonte de dado, fica mais fácil evoluir para gerar a mensagem automaticamente a partir do contexto real do cliente. Ver solicitação | fabiojose.aiello | ● |
| QS-2026-C038306D | SKILL para atendimento diário Problema: gestores perdem 20–40 min/dia redigindo do zero mensagens de status, pré-call, pós-reunião e resultado — cada um formata diferente, o tom varia com a pressa, e é fácil esquecer contexto ou repetir saudação automática; o retrabalho acontece no fim do expediente, quando o gestor está mais cansado. Resolve: skill via Claude Code que lê o dossiê do cliente (contexto, métricas, tom, histórico), escolhe o formato certo, puxa tarefa do Ekyte e número de mídia quando precisa, e entrega o texto pronto — redução de até 80% no tempo de redação, lógica documentada e versionada no GitHub. Ver solicitação | matheus.jordan | ● |
| QS-2026-23383B65 | Apresentação de resultados diários Problema: o cliente que não quer esperar a reunião quinzenal para saber como está indo — quer abrir um link e ver leads, MQL, SQL, vendas, custos e ROAS (ou acessos, cliques, carrinho abandonado e checkout, no caso de ecommerce) quase em tempo real. Resolve: skill que integra plataformas de mídia, CRM e marketplace do cliente numa visão só, reduzindo o tempo do GP em montar atualização — ainda em esboço, sem caminho técnico definido. Ver solicitação | Maria | ◑ |
Registro que fecha o ciclo — compromisso → tarefa → leitura de carteira — sem depender de memória. Comprador: AM / coordenação / gestão. Separada de M1 porque a saída aqui é rastreabilidade interna, não peça para o cliente.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-65904645 | Ata de check-in automatizada Problema: depois de cada check-in, o AM redige manualmente 3 comunicações diferentes (WhatsApp do cliente, e-mail, mensagem interna) com tom e detalhe distintos, extrai as demandas da call e checa duplicidade no Ekyte — toda semana, para cada cliente, dependendo 100% de memória; quando a rotina aperta, é o primeiro passo que se perde. Resolve: workflow que reduz a montagem pós-call de 40 minutos para poucos minutos, padroniza o tom entre AMs, faz checagem automática de duplicidade antes de criar task, e garante que o combinado em check-in vira execução rastreada. Ver solicitação | Gabriela | ● |
| QS-2026-1EE714A6 | Sistema automático de to-dos a partir de reuniões Problema: combinados, pendências e pontos de acompanhamento ficam espalhados em reuniões, transcrições e memória individual — sem rastreabilidade entre coordenação, gestão de projetos, tráfego, copy, design e social. Resolve: leitura automática das reuniões da agenda que consulta a transcrição completa, identifica tarefa assumida por pessoa ou grupo, organiza num dashboard operacional com origem/contexto/prioridade, e envia para o Ekyte com dono, prazo e tags quando necessário. Ver solicitação | jefferson.vieira | ● |
| QS-2026-C43D0737 | Monitor da operação: pulso diário, ata e newsletter da carteira renomeada, vinda de M1 Problema: a comunicação da operação é reativa e depende de memória — combinados de reunião evaporam, a coordenação só vê a carteira por planilha fria ou por interrupção, e o gestor começa o dia sem saber por onde olhar; a operação pode entregar bem e ainda parecer ausente, porque o cliente só percebe a esteira rodando se ela aparecer como mensagem. Resolve: motor único (fonte determinística → template por rito → canal → cadência) servindo três públicos — operador recebe o dia mastigado às 8h, cliente recebe pulso diário curto com número + fonte + próximo passo, e ata pós-reunião sai validada em minutos com dono e prazo por compromisso; a camada do operador já roda em produção via WhatsApp. Ver solicitação | robson.job | ● |
| QS-2026-80BCD9FB | Painel único de carteira vinda de Growth Review Problema: para saber a saúde da carteira é preciso abrir Cockpit, GrowthPack de cada cliente, Ekyte e planilha comercial separadamente — e ainda rodar skill de Sprint cliente por cliente toda semana para consolidar; cada Account reconstrói isso na mão, consumindo tempo que poderia ir para análise, e a visão de saúde fica defasada entre rodadas. Resolve: lugar único onde qualquer gestor ou a gerência visualiza pace, Health Score, funil e entregas de todos os clientes ao mesmo tempo — ainda sem caminho técnico definido; a leitura só faz sentido plena quando M3 estiver madura. Ver solicitação | Jucosta | ○ |
82363468, track interno) define o schema do item de trabalho que esta mãe deveria consumir.Número com proveniência + meta versionada + pacing + causa do desvio com evidência, orquestrados num plano 5W1H — comprador: gestão + gestor. Desbloqueia M2, M4, M7 e M8a.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-2D9DE0E5 | Esteira de dados do projeto Problema: todo relatório nasce de um caos de fontes — exports, planilha, CRM juntados na mão, de jeito diferente por pessoa; o mesmo indicador varia entre relatórios da mesma conta, join errado que ninguém audita, e quando o número diverge na frente do cliente a discussão vira sobre confiança, não performance. Resolve: padrão operacional versionado em 7 etapas com gates — diagnóstico → plano aprovado → contrato de métricas → transformação determinística → instância a partir de molde comum → QA → publicação; já roda em produção alimentando monitores e check-ins de clientes reais (Grupo Colina, Sigo ERP). Ver solicitação | robson.job | ● |
| QS-2026-E3527ABD | Metas derivadas dos economics Problema: meta nasce de ambição ou herança de contrato, não da matemática do projeto — ROAS calculado com custo diferente em cada conta, janela não declarada, pacing improvisado; a reunião trava em "qual número é o certo" em vez de "o que fazer". Resolve: meta derivada de margem → ROAS mínimo → ponto de equilíbrio → OKR do quarter, com réguas invariantes (pro-rata, pacing, faróis em 3 faixas) num contrato versionado por projeto — já sustenta os faróis e pacing usados em contas reais. Ver solicitação | robson.job | ● |
| QS-2026-97C25A13 | Análise causal de gap de meta Problema: quando o resultado cai, o diagnóstico vira achismo de reunião — cada um chega com uma teoria, vence o palpite dito com mais confiança, mata-se cedo demais o que nem teve amostra; o mesmo gap volta todo mês. Resolve: método MASP adaptado a funil de growth em 5 fases — nomear gap → estratificar em árvore MECE → achar agressor por contribuição absoluta → sustentar causa com evidência → plano 5W2H com dono e prazo; já roda nos ritos semanais e retrospectivas de quarter de contas reais. Ver solicitação | robson.job | ● |
| QS-2026-30837CA3 | Projeção de Growth novo Problema: projeção de crescimento depende de planilha e premissa manual, sem padrão entre operações. Resolve: calculadora de funil de 12 meses (verba→impressões→cliques→leads→MQL→SQL→vendas→receita) com camadas de prioridade entre override manual, histórico e benchmark por nicho; já entregue a um cliente real (RPS Revestimentos), roda no navegador — próximo passo é incorporar ao V4 OS com persistência. Ver solicitação | jean.reis | ● |
| QS-2026-EAAC487D | Sprint Growth — orquestrador vinda de Growth Review Problema: construir o Sprint Growth exige coletar e analisar manualmente dados de mídia, tracking, CRM e comercial em ferramentas diferentes — lento, e dificulta achar rápido o gargalo do funil. Resolve: orquestrador que consome as auditorias padronizadas (M4) e o número confiável desta mãe para gerar plano 5W1H priorizado — passa a viver dentro de M3 porque é o consumidor natural do número e da meta, não uma camada externa. Ver solicitação | jean.reis | ● |
Laudo com achados (evidência + severidade + ação) em schema único — comprador: gestor / GT, consumido pelo orquestrador dentro de M3. 9 solicitações, mesmo formato de entrega, superfícies diferentes.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-F814563F | Auditoria Meta Ads Problema: auditoria de Meta Ads hoje depende de checagem manual no Gerenciador de Anúncios e de Eventos — duplicidade de evento, falha de dedup, saturação de público, fadiga criativa e divergência entre conversão da plataforma e venda no CRM passam despercebidas, levando a otimizar só por CPL/CPA. Resolve: workflow que consome Nekt/Cockpit para auditar tracking, estrutura, público, criativo e sinais de saturação com evidência e severidade, alimentando depois o orquestrador (M3). Ver solicitação | jean.reis | ○ |
| QS-2026-90A323A0 | Auditoria Google Ads Problema: auditoria de Google Ads exige consulta manual a configuração, campanha, conversão e termo de pesquisa — processo demorado, limitado a métrica superficial (CPL, CPA), deixando passar falha de tracking e estrutura ineficiente. Resolve: workflow que audita tracking, estrutura, eficiência de mídia e termos a partir do Nekt/Cockpit, preparando chaves para cruzar com CRM. Ver solicitação | jean.reis | ● |
| QS-2026-3487B326 | Auditoria Google Analytics 4 Problema: validar se aquisição, conversão e receita no GA4 são confiáveis exige checagem manual de propriedade, stream e escopo, sem padrão para separar tráfego pago/orgânico/direto ou achar divergência de atribuição. Resolve: workflow que audita governança, evento, canal e funil do GA4 com evidência, criando base segura para cruzar com mídia e CRM. Ver solicitação | jean.reis | ● |
| QS-2026-D541BA7C | Auditoria Google Tag Manager leitura Problema: validar tracking exige checagem manual e fragmentada entre GTM Web, container Server e Stape — "publicado" não comprova que a tag disparou ou que o dado persistiu, podendo gerar perda/duplicidade de conversão. Resolve: workflow via MCP do GTM/Stape, só leitura, que diferencia configurado de observado/persistido, localizando a etapa exata da perda. Ver solicitação | jean.reis | ○ |
| QS-2026-BA40A84B | Auditoria CRM Problema: dado comercial no CRM raramente tem estrutura confiável — campo de origem, UTM e motivo de perda ausente ou duplicado, dificultando acompanhar Lead→MQL→SQL→Venda sem planilha manual. Resolve: workflow que audita campo, pipeline, SLA e origem do CRM contratado, permitindo analisar conversão e receita por vendedor/canal com evidência. Ver solicitação | jean.reis | ● |
| QS-2026-63AB8D29 | Auditoria n8n/Make Problema: dado de lead/UTM/conversão passa por automação no n8n/Make antes de chegar a planilha, CRM e mídia — quando uma etapa falha, é difícil achar onde o dado se perdeu ou duplicou. Resolve: workflow que reconstrói o caminho do dado e aponta a etapa exata da falha, sem alterar as automações — hoje mais forense do que rotina, escopo ainda em esboço. Ver solicitação | jean.reis | ◑ |
| QS-2026-CA51C86D | Auditor de Sites Problema: a operação herda muitos projetos com site ruim, sem ferramenta que audite contra padrão mínimo de SEO, desempenho e conversão já na entrada. Resolve: workflow conectado ao Nekt que puxa a lista de clientes do Flow e avalia o site contra padrões pré-definidos — demo no ar, ainda evoluindo robustez. Ver solicitação | gustavosmarito | ● |
| QS-2026-127FDBAA | Auditoria de frete curva A Problema: quando o gargalo é carrinho→checkout, frete é candidato óbvio, mas auditar manualmente por CEP em cada produto da curva A leva horas, atrasando a validação. Resolve: fluxo que audita 50+ CEPs para 20+ produtos em menos de 30 minutos com análise já gerada; pode estender para benchmark de frete de concorrentes. Ver solicitação | daniel.otto | ● |
| QS-2026-8FA1D909 | Auditoria E2E da jornada dual: M4 + gate de M5 Problema: operação liga investimento sobre jornada que ninguém verificou ponta a ponta — "configurado" é tratado como "funcionando", e a falha silenciosa só aparece semanas depois, como número que não bate na reunião. Resolve: protocolo de 4 etapas (plano de teste → execução com evidência no destino → matriz de severidade → parecer go/go-com-risco/corrige-antes), nascido das falhas reais do caso Aquatro — serve como contrato de auditoria e como gate de qualidade antes de uma jornada nova entrar em produção. Ver solicitação | robson.job | ● |
Jornada no ar que mede: LP → form → tracking → CRM com evidência no destino — comprador: gestor / GT. Consome a biblioteca HTML como enabler; verificada pela auditoria E2E de M4.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-73B01469 | LP de leadgen B2B como jornada Problema: quando LP, copy, form, tracking e CRM são tratados como entregas independentes, o resultado é conhecido — página bonita que não mede, evento sem destino, negócio duplicado; a entrega "termina" no HTML no ar, mas o cliente compra lead qualificado, não página. Resolve: workflow com gates (brief → mapa de conversão → contrato de dados → construção via biblioteca de padrões → QA end-to-end com evidência real) — já testado em caso real (Aquatro) com dedup browser+server. Ver solicitação | robson.job | ● |
| QS-2026-12619162 | Orquestração de leads (n8n) Problema: entre o formulário e o CRM existe zona cinzenta onde o lead se perde em silêncio — submissão que não chega, negócio duplicado, CAPI sem dedup; a falha só aparece dias depois, e a discussão vira sobre confiança no dado, não performance. Resolve: 6 workflows n8n em produção (caso Aquatro) — orquestrador de LP normaliza e qualifica, orquestrador de CAPI despacha para Meta/Google com hash de PII, usando event_id compartilhado como chave de dedup. Ver solicitação | robson.job | ● |
| QS-2026-0D2B5E6E | Trackeamento avançado One Click Problema: dado de origem e atribuição da conversão não chega completo e padronizado ao CRM, dificultando saber qual campanha/anúncio gerou cada oportunidade; sem solução interna confirmada, só o MCP do GTM (V1) e soluções de mercado. Resolve: configuração via API de Conversões que envia atribuição para campo personalizado do CRM. Ver solicitação | guilherme.duarte | ◑ |
| QS-2026-AFB0495B | Setup de Data Layer novo Problema: o V4 Pages não captura/persiste de forma padronizada GCLID, FBCLID, GBRAID e WBRAID — quando esses dados se perdem na entrada, não é possível recuperá-los depois que o lead chega ao CRM, comprometendo devolução de conversão a Google/Meta. Resolve: workflow que define captura na entrada, persistência first-party, disponibilização no Data Layer para o GTM e devolução do resultado à mídia — gate de conclusão só fecha com clique rastreável até o campo no CRM. Ver solicitação | jean.reis | ◑ |
| QS-2026-DC6AE4B4 | Setup GTM Web via MCP novo Problema: setup de tracking web exige ações manuais no GTM (revisar container, criar variável/trigger/tag, testar, documentar), dependendo da experiência de quem executa. Resolve: workflow que já roda em casos reais via MCP do GTM para ler o container, evitar duplicação, criar configuração com naming padrão e gerar evidência — com aprovação humana obrigatória antes de publicar algo sensível. Ver solicitação | jean.reis | ● |
| QS-2026-4D430BE1 | Setup GTM Server-Side via MCP novo Problema: tracking server-side exige configurar manualmente container Server, clients e integração com GA4/Ads/Meta — processo técnico que varia entre operadores e aumenta risco de evento duplicado. Resolve: workflow via MCP do GTM + Stape que testa a cadeia completa (browser→Web→Stape→Server→destino) e aponta o ponto exato de quebra quando falha. Ver solicitação | jean.reis | ● |
| QS-2026-99D25095 | Biblioteca de padrões HTML enabler, decisão D Problema: cada LP/dashboard reinventa a UI do zero — qualidade variando por executor, retrabalho de QA visual quando o resultado chega desalinhado. Resolve: acervo de 30 famílias e 307 padrões agnósticos de marca, com manifest legível por agentes de IA — já sustentou o Monitor de projetos e LPs entregues; fica como enabler consumido por esta mãe, amarrado a V4-155, não Quest própria. Ver solicitação | robson.job | ● |
Lead classificado (INVALID/NOICP/MQL + tier + valor esperado) e enriquecido, dentro do CRM — comprador: gestor + comercial do cliente.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-6CC3807A | Qualificação de leads por valor (MQL por tier) Problema: a operação gera lead ruim e não tem como argumentar isso — não existe critério objetivo de qualidade, o comercial atende por ordem de chegada e a mídia otimiza por volume/CPL, aprendendo a gerar o lead errado. Resolve: motor determinístico (JS, com testes) que calcula estágio (INVALID/NOICP/MQL), tier (S/A/B/C) e valor esperado por lead a partir de config por cliente — testado em projetos reais (EcoStorage, Aquatro, Colina Clin), com recalibração mensal projetado × realizado. Ver solicitação | robson.job | ● |
| QS-2026-93750455 | Enriquecimento de bases B2B Problema: base B2B chega incompleta ou desatualizada, sem dado de segmento, porte, faturamento ou decisor, dificultando priorizar lead com potencial. Resolve: enriquecimento automático via scraping/APIs que consulta múltiplas fontes e consolida antes de devolver ao CRM — hoje testado em pontos isolados; encaixe confirmado pelo autor como uso pré-CRM, mesmo ponto da esteira que a qualificação por valor. Ver solicitação | guilherme.duarte | ● |
Peça no ar com naming que permite fechar o debrief por atributo — comprador: gestor / criação.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-7457A7DB | Nomenclatura de mídia + debriefing Problema: naming de campanha é decorativo — cada gestor nomeia do seu jeito e renomeia no meio do voo, quebrando o histórico; responder "que ângulo funciona" exige reconstrução manual, então o debriefing vira opinião e a rodada seguinte não herda aprendizado. Resolve: contrato de naming com dicionário fechado e ID imutável, "guardião" que valida antes de subir, parser que desdobra em dimensões de análise, e biblioteca de debriefing cruzando atributo × público × funil periodicamente. Ver solicitação | robson.job | ● |
| QS-2026-92031B36 | Esteira de criativos título quebrado Problema: ciclo criativo roda no gosto e na memória — direção por intuição, briefing incompleto, drop bagunçado sem naming; a peça nova repete o erro da anterior porque nenhum aprendizado fecha o ciclo. Resolve: esteira com matriz público × ângulo ancorada em dado real, briefing dual-modo (conceito novo vs. iteração que herda) com validador estrutural, e performance por criativo retroalimentando a direção seguinte. Ver solicitação | robson.job | ● |
| QS-2026-83AFB96F | SKILL geração de COPY Problema: copy escrita sem olhar o que já funciona é chute — gestor "inova" ângulo que já teve CTR baixo, ou evita keyword que tem o menor custo por lead. Resolve: skill que acessa Meta/Google via Flow antes de escrever, identifica criativo/keyword com melhor performance, calibra o ângulo pelo que a audiência já respondeu, e passa por checklist anti-IA antes de entregar. Ver solicitação | matheus.jordan | ● |
| QS-2026-1B46C036 | SKILL revisor de COPY Problema: copy de IA tem padrão reconhecível (travessão, "transforme", claim sem dado) que passa quando o gestor entrega com pressa, minando a confiança do cliente. Resolve: camada de revisão com 6 checks sequenciais (travessão, padrão anti-IA, vocabulário do cliente, precisão de produto, proof point, ângulo já reprovado) que corrige e devolve o texto limpo. Ver solicitação | matheus.jordan | ● |
Verba alocada por maturidade de evidência, com rito de rebalanceamento — comprador: gestor / GT. Depende de M3.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-9B74E119 | Plano de mídia como portfólio Problema: plano de mídia é feito uma vez no onboarding e vira planilha morta — realocação decidida no calor (mata campanha com 4 dias de dado ruim, dobra aposta com 3 dias de dado bom, ruído tratado como sinal). Resolve: verba gerida como portfólio, com fatias por maturidade de evidência (comprovado/aposta/teste), forecast com premissa declarada, e rebalanceamento só depois de atingir amostra e tempo mínimos — cada movimento em log com evidência. Ver solicitação | robson.job | ● |
Estrutura de campanha nova, gerada a partir dos campeões históricos da conta — comprador: gestor / GT.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-BB548DF8 | Fábrica de campanhas Google Search Problema: toda conta com histórico de Google Ads tem "ouro enterrado" nos termos e anúncios que já converteram, mas isso quase nunca é reaproveitado — campanha nova nasce do zero, análise de termo é manual e rasa. Resolve: esteira de 5 etapas com gates que extrai relatório filtrado por conversão, identifica campeões e desperdício, monta estrutura executável e entrega CSV pronto para importar — testado em contas reais (EcoStorage, Aquatro, Grupo SA). Ver solicitação | robson.job | ● |
Conteúdo de check-in auditável, com deck renderizado só após validação humana — comprador: gestor de projetos, AM. Miolo distinto de Atendimento Diário (M1): aqui o objeto é a prestação de contas periódica, não a mensagem do dia a dia.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-B047043B | Check-in de performance padronizado (ROPRE) Problema: o check-in de cliente é remontado do zero toda semana ou mês — horas montando slide, número copiado à mão e divergindo da fonte, narrativa variando conforme quem monta; o momento mais sensível do relacionamento vira o de maior risco, porque número que não bate mina a confiança. Resolve: três modelos por cadência (semanal, mensal, quarter) com estrutura de telas fixa — o conteúdo nasce como documento auditável com todo número rastreável, e o deck só é renderizado depois de validação humana; já roda em produção no check-in semanal do Grupo Colina e mensal do Sigo ERP. Depende da esteira de dados (M3) para número com fonte determinística. Ver solicitação | robson.job | ● |
Não é Quest competitiva — comprador é a própria operação, não o cliente.
| Código | Solicitação | Autor |
|---|---|---|
| QS-2026-6FC78D35 | SKILL Contexto Refresh vinda de M1 Problema: o conhecimento de cada conta está espalhado em 4 sistemas que não conversam — decisão no WhatsApp, alinhamento na call, execução no Ekyte, resultado no Flow — e ninguém tem tempo de sincronizar isso manualmente toda semana; o gestor trabalha com informação velha ou perde tempo reconstruindo o que já existia. Resolve: skill que lê as 4 fontes desde o último sync, filtra decisão/resultado real, e atualiza cada arquivo do cliente com a origem marcada — infraestrutura transversal que alimenta o atendimento diário (M1) e o monitor de rotina (M2), não Quest própria. Ver solicitação | matheus.jordan |
| QS-2026-F3AE1685 | Cadência operacional (ritos) Problema: a operação vive em reunião-ruído — encontros que misturam o problema de hoje, o resultado do mês e a estratégia do trimestre na mesma pauta, sem pergunta definida; projeto crítico é descoberto tarde e decisão evapora. Resolve: grãos de tempo aninhados, cada um com uma pergunta e um rito só seu, com healthscore de 5 pilares roteando a atenção automaticamente; já roda como a cadência real da operação. Ver solicitação | robson.job |
| QS-2026-82363468 | Governança de trabalho Problema: decisão tomada em reunião evapora e é re-decidida do zero depois; aprendizado vira anotação morta em vez de mudar o processo; e quando parte da execução é feita por agente de IA falta gate claro entre sugerir e materializar. Resolve: ciclo de 7 passos (captura → backlog → curadoria gated por reversibilidade → despacho → execução → registro → incorporação) onde "feito" só conta quando o executor certo foi de fato alterado. Ver solicitação | robson.job |
| QS-2026-06A292DE | Doutrina de operação com agentes de IA Problema: agente com autonomia demais aplica mudança irreversível sem aprovação; com autonomia de menos, vira chatbot caro que trava em quem aprova; regra escrita em documento morre na prática porque o agente esquece sob pressão de contexto. Resolve: 24 regras com anatomia fixa em 5 famílias, autonomia calibrada por reversibilidade, e um ciclo onde toda regra migra de contexto para mecanismo quando possível — já testada na operação que produziu este pacote. Ver solicitação | robson.job |
| QS-2026-95622A79 | Timesheet assistido no Ekyte Problema: timesheet apontado atrasado, incompleto e de memória por todo mundo — o dado que sustenta decisão de alocação e precificação acaba sendo ficção. Resolve: assistente que cruza 3 fontes (tasks ativas, agenda, confirmação humana), cria tasks faltantes com dry-run e confirmação antes de escrever — já roda semanalmente via Ekyte + Google Calendar, com ledger que impede relançamento duplicado. Ver solicitação | robson.job |
| QS-2026-3D9E1A59 | V4 Labs Problema: a operação produz método e ferramenta que funcionam, mas eles não circulam — distribuição boca a boca, demanda real invisível para quem prioriza; vale também para o próprio V4 Quests, cuja solicitação ainda não priorizada esfria sem acumular evidência. Resolve: catálogo já no ar (v4-labs.pages.dev) com 22 produtos, votação de um clique definindo fila de acesso, e feedback com crédito nominal — resolve o mesmo problema de distribuição que motivou o próprio V4 Quests. Ver solicitação | robson.job |
QS-2026-9354E455 Auditoria de Execução Operacional da Gerência. Problema: em escala, a qualidade de execução não é gerenciada — os mesmos gaps se repetem em dezenas de projetos sem que ninguém saiba quais, em quantos, e por causa de quem; a gestão só vê o sintoma agregado (churn, resultado abaixo da meta). Resolve: auditoria que lê o sistema de dados direto, sem pedir preenchimento a ninguém, contra régua de 21 disciplinas em 5 domínios — já testada em 2 rodadas reais (AERO TD: achou critério de qualificação escrito e não implementado, 1.041 leads contra meta de 100; Aquatro: 8 aprovações e 8 reprovações em 17 marcadores, padrão de "documenta bem, aplica pela metade"). É a peça mais madura do bloco — candidata a graduar para iniciativa própria fora do fluxo Quest-cliente. Ver solicitaçãoDecisão G: cluster heterogêneo, não promovido a mãe. Unidade comum candidata: arquitetura versionada entregue.
| Código | Solicitação | Autor | |
|---|---|---|---|
| QS-2026-3CBA2868 | Arquitetura de CRM RevOps Problema: CRM raramente é implantado com arquitetura — pipeline que mistura processo com resultado, campo criado ad-hoc, motivo de perda em texto livre; o relatório de pipeline vira número que ninguém acredita. Resolve: workflow com gates que desenha pipeline, campo e SLA a partir de um modo consciente (simples/avançado), com auditoria de config por script — é o destino da orquestração de leads (M5) e o executor do roteamento por tier (M6). Ver solicitação | robson.job | ● |
| QS-2026-E8E1243C | Reestruturação de growth B2B Problema: existe um perfil de conta B2B que gera demanda mas não escala — ICP mal definido, qualificação inexistente, CRM quebrado; ajuste tático não resolve porque o problema é estrutural, e meses sem o resultado mudar colocam a conta em risco de churn. Resolve: workflow de 7 fases (contexto → diagnóstico → estratégia → fundação → instrumentação → ativação → aprendizagem) com ledger de evidências e ativação sempre em modo shadow — aplicado em 8 projetos nos últimos 2 meses, 7 com pelo menos 3x de crescimento. Ver solicitação | robson.job | ● |
| QS-2026-EE06C673 | NPS pós-implementação de CRM novo Problema: depois do CRM implantado, a gerência passa para outras entregas e só depois de um tempo chega a notícia de que o cliente não usa, não atualiza campo, ou quer cancelar por não ver valor — muitos nem sabem que a implantação tem início, meio e fim. Resolve: formulário simples que pergunta sobre uso e necessidade de treinamento — dado de utilização vai para a coordenação, sinal de interesse em nova implementação vira oportunidade de upsell para a gerência. Ver solicitação | Vinicius_santos | ◑ |
| QS-2026-E2D676B0 | Brand Strategy Setup Sprint Problema: a cada cliente novo, posicionamento, ICP, UCM e GTM nascem de call, Notion solto ou memória de poucas pessoas — o time de operação recebe brief inconsistente e o "jeito bom" fica na cabeça de quem já fez antes. Resolve: protocolo que padroniza a primeira base estratégica usável, com handoff claro pós-aprovação, tornando o método capacidade da operação (N3) em vez de dependência de indivíduo — sem material desenvolvido ainda. Ver solicitação | lucas.isaque | ◑ |
| QS-2026-949470DC | Setup Design Problema: todo designer novo (ou troca de responsável) perde dias montando contexto antes de produzir — brand kit, referência, Figma, histórico de peça — e isso muda de pessoa para pessoa, gerando retrabalho na primeira entrega. Resolve: padrão de ponto de partida de marca/contexto reutilizável entre clientes da carteira — sem material desenvolvido ainda. Ver solicitação | lucas.isaque | ◑ |
92031B36 no Flow — está com a URL do repo do timesheet.A972FA1C (só senha, sem responder à pergunta) foi engano.needs_refinement — sem output-exemplo, o schema de M4 não fecha.D13777B9) para a avaliação formal da Q-2026-002.Marcado para sua revisão — não são decisões que eu considero fechadas com o mesmo grau de confiança das demais.
9354E455): resolvida como "track interno com destaque", mas é escolha de enquadramento de produto que só você decide com certeza.EE06C673 no cluster de Setup: leitura minha, não testada com o autor — o NPS pode ser instrumento mais genérico (qualquer implantação), não só CRM.
Social — Q-2026-002 já aberta
Decisão D6 mantida: não há mãe nova. As solicitações competem pela Quest já aberta, avaliadas pelo DoD dela — não pela completude do pacote.