Um nome, não uma função.
Cada frente tem uma pessoa responsável pela saída. Pode ser Caeru ou cliente; o nome, as dependências e o poder de decisão ficam registrados no plano de trabalho.
RACER é a macroarquitetura que organiza o trabalho da Caeru, da fundação inicial à operação. Em cada frente, definimos quem responde, o que fica entregue e como o avanço será medido.
Estratégia só vira capacidade quando aparece na rotina do time. Por isso, o projeto combina leitura e decisão; quando o escopo inclui execução, acrescenta implementação supervisionada e transferência. A Caeru constrói como parceiro, acelera nas primeiras curvas com o time que, por sua vez, assume progressivamente o volante.
Consultoria tradicional entrega apenas o Mapa: roadmap de implementação, MECE, playbook por vertical. E manda você correr. Agência entrega o Destino: X MQLs, Y reuniões; corre para onde você manda (mesmo que não seja o lugar certo). Se você puxa o plug, o time não faz a mínima ideia do que foi feito para chegar lá. O modelo de Revenue Partner da Caeru entrega o Mapa e o Território. Diferentes caminhos potenciais para chegar ao mesmo destino, executando e validando as hipóteses lado a lado com os times. Corremos junto com você.
RACER organiza cinco movimentos necessários para estruturar uma operação de receita. Eles dão direção ao projeto, mas não formam uma linha rígida: a fundação vem primeiro; depois, hipóteses, decisões e implementação avançam em ciclos, voltando à leitura sempre que a evidência ou o contexto exigem. A cobertura e a profundidade dependem do produto contratado.
Leitura inicial de clientes, processo, pessoas, dados e contexto. Estabelece o ponto zero antes de recomendar ou implementar mudanças.
Sai Fundação documentada, lacunas priorizadas e premissas explícitas.
Define o resultado perseguido e, quando o escopo pede, ICP, proposta de valor e critérios de prioridade.
Sai Objetivos, escolhas e métricas de saída acordados.
Traduz a direção em caminho de execução: prioridades, canais, motion, dependências e sequência de trabalho.
Sai Plano priorizado, responsabilidades e critérios de decisão.
Desenha processos, tecnologia, papéis e rituais e, quando contratado, acompanha a implementação. Cada frente ganha dono, artefato e métrica.
Sai Desenho operacional ou mudança implementada, conforme a cobertura contratada.
Coloca a mudança em rotina, acompanha sinais de adoção e resultado e transfere a condução para o time.
Sai Operação acompanhada, ajustes documentados e handoff definido.
Dois tipos de Read O Read inicial cria a fundação contratada. O Read contínuo acompanha mudanças de contexto e evidência durante a execução; ele recalibra o plano, mas não substitui a fundação.
Dentro da macroarquitetura, cada frente avança por um microciclo: formular a hipótese, testar no campo, observar a evidência, decidir o ajuste e registrar o aprendizado. A cadência é definida no plano do projeto; a revisão de contexto fecha um ciclo e abre o seguinte.
A transferência acontece dentro do trabalho: o time participa das decisões, executa partes combinadas, recebe supervisão e assume os rituais no handoff. O objetivo é deixar capacidade instalada, com responsabilidades explícitas entre Caeru e cliente.
Esse tripé transforma intenção em trabalho verificável. Antes de iniciar uma frente, registramos quem responde pela saída, qual evidência concreta ficará disponível e qual sinal será usado para avaliar avanço ou resultado.
Cada frente tem uma pessoa responsável pela saída. Pode ser Caeru ou cliente; o nome, as dependências e o poder de decisão ficam registrados no plano de trabalho.
Documento, processo, dashboard, configuração ou registro de decisão: algo que possa ser revisado, usado pelo time e atualizado quando o contexto mudar.
Fundação, indicador e janela de observação são acordados antes da implementação. Quando atribuição financeira não for possível, isso também fica explícito.
Em projetos continuados, uma revisão periódica reúne o responsável Caeru e o sponsor do cliente para confrontar plano, evidência e mudanças de contexto. A cadência exata e os participantes ficam definidos na proposta; o objetivo é ajustar prioridades sem apagar o histórico de decisões.
O que mudou no contexto do cliente desde a última revisão?
O que está funcionando melhor ou pior do que esperávamos?
O que precisa ser priorizado, despriorizado ou abandonado?
Que decisão, de qualquer lado, está travando o próximo avanço?
Os produtos compartilham controles de qualidade e governança. Eles não percorrem o RACER de forma idêntica: cada um começa de uma necessidade e termina em uma profundidade diferente.
Aprofunda Read, Aim e Course e desenha Engineer. Entrega fundação operacional e plano executável; a implementação ampla fica fora desse escopo.
Parte de pontos acionáveis descobertos e validados no Ignition e concentra Engineer e Run em até três frentes delimitadas, com adoção e handoff.
Pode ser a entrada direta de operações maduras. Percorre o RACER de forma ampla, com Discovery próprio e novos diagnósticos por fase, implantação progressiva e governança continuada.
A conversa inicial serve para entender o contexto e verificar se existe fit. A fundação e a aplicação detalhada do RACER começam somente dentro de um escopo contratado.