Conteúdo detalhado
🍕 A pizza: regras & ganchos pesam mais
A distribuição do Consulting OS é razoavelmente equilibrada, com contexto puxando na frente (a informação dos clientes está espalhada e precisa ser agregada). A diferença marcante: regras & ganchos pesam mais do que o normal. Em consultoria, o que sai do seu OS vai para um cliente pagante — então as cercas (voz da marca, o que é selado, formato por cliente) ganham peso.
Como ler: a fatia de Regras & Ganchos está em destaque (brilho) porque cresce aqui. Compare com o Content OS, onde ela vinha por último: o domínio muda a forma da pizza.
💡 Por que as regras pesam
Cada entregável carrega a sua reputação e a relação com um cliente específico. O relatório do cliente A não pode ter o tom do cliente C; o que foi marcado como selado nunca pode vazar. Regras moles não dão conta disso — por isso a camada engorda.
Por que aprender
Porque te ensina a ler a forma da pizza por domínio. Ao ver que consultoria exige cercas fortes, você prioriza certo: não adianta um agente brilhante se ele manda ao cliente A o relatório no formato do cliente B. A distribuição é o seu mapa de prioridade.
Conceitos-chave
🗄️ Contexto: 1 pasta por cliente
A informação dos seus clientes vive espalhada por todo lugar. O primeiro movimento é agregar e dar sentido — o equivalente, em pastas, a montar armários e prateleiras. Cada cliente vira uma pasta; no CLAUDE.md você deixa a referência: "quando eu menciono este cliente, estou falando desta pasta". O OS passa a saber exatamente onde olhar.
🌱 Novo aqui?
A pasta raw/ guarda o material bruto (transcrições de reunião, e-mails); a synthesized/ guarda o destilado (o resumo que o OS de fato lê). O CLAUDE.md é o arquivo-alma, lido primeiro — é onde você cria os apelidos: "Cliente A = clientes/cliente-a/".
Como ler: a estrutura é o "armário". Cada cliente tem sua gaveta (com bruto e destilado), os playbooks ficam à mão, e a wiki guarda o que vale para todos. Os agentes (em ciano) leem essa estrutura.
Por que aprender
Porque sem o armário organizado, todo o resto desmorona. Se o OS não sabe qual pasta é qual cliente, ele mistura contextos — e misturar clientes em consultoria é falha grave. A pasta por cliente + a referência no CLAUDE.md é o que dá ao OS uma memória confiável de cada conta.
Conceitos-chave
📚 Playbooks por cliente + wiki global
Em cima das pastas vêm os playbooks: como você roda a consultoria de forma geral e como roda para cada cliente específico. Esses playbooks agregam para um playbook global, uma wiki que triagem todas as reuniões de todos os clientes. Toda empresa tem padrões; a wiki é onde você os captura para enriquecer a próxima reunião e a preparação.
Como um playbook ganha vida
Reuniões brutas
O raw/ de cada cliente acumula transcrições e notas — o material cru de toda conta.
Triagem & destilação
A wiki cruza as reuniões de todos os clientes e isola os padrões — o que se repete vira nugget.
Playbook vivo
Específico por cliente + global (a wiki), prontos para enriquecer a prep da próxima reunião.
🔎 Dois níveis de playbook
- Por cliente — o jeito específico de servir o Cliente A: o que ele valoriza, o ritmo, as manias.
- Global (wiki) — os padrões que valem para todos: "negócios assim costumam objetar X", o seu método de prep de reunião.
- A ponte — a wiki triagem as reuniões de todos os clientes e encontra os padrões que enriquecem cada conta.
✓ Playbooks que rendem
- ✓Específico por cliente + um global que destila padrões.
- ✓Alimentado pela triagem das reuniões reais.
- ✓Melhora a prep da próxima reunião de cada conta.
✗ Wiki morta
- ✗Um doc gigante que ninguém atualiza.
- ✗Mesmo playbook genérico para todo cliente.
- ✗Nunca destilar as reuniões em padrões.
Por que aprender
Porque é o que transforma experiência em ativo. Sem playbooks, cada reunião recomeça do zero e o conhecimento mora só na sua cabeça. Com a dupla por-cliente + wiki global, o OS lembra como você atende cada conta e ainda cruza padrões entre elas — você fica melhor a cada cliente.
Conceitos-chave
🛡️ Review gate adversarial na voz do cliente
A peça-assinatura do Consulting OS: antes de um entregável chegar ao cliente, ele passa por um revisor adversarial que veste a voz daquele cliente. É um agente que você nomeia com o contato principal da conta, primado por todas as reuniões sintetizadas — ele conhece as objeções recorrentes, o que a pessoa valoriza e o tom dela. Quando o stack pede, vale ter vários revisores adversariais, não só um.
🌱 Novo aqui?
Um review gate (portão de revisão) é um ponto obrigatório por onde algo passa antes de sair. Adversarial significa que o revisor joga contra: o trabalho dele é achar o problema, não elogiar. Primado = pré-carregado com o contexto. SOW (statement of work) é o documento que fixa o escopo combinado com o cliente.
🎯 Objetivo do copy-run
Rodar um revisor que pensa como o cliente sobre um entregável, ancorado no resumo real das reuniões, e sair com as objeções dele + um veredito de "enviaria" ou "devolveria".
Aja como <Nome do contato principal>, principal contato da conta <Cliente>. Você é o revisor adversarial deste entregável — não eu. Antes de responder, leia o contexto desta conta: - clientes/<cliente>/synthesized/resumo-reunioes.md (o destilado das reuniões: objeções recorrentes, o que ele valoriza, o tom dele) - clientes/<cliente>/playbook.md (como tratamos esta conta especificamente) Entregável em revisão: <cole aqui a proposta / o relatório / o e-mail> Revise NA VOZ do <Nome do contato>, sem suavizar: 1. Liste as 3 objeções que ELE levantaria primeiro, na ordem em que doem. 2. Aponte 1 ponto onde prometemos além do escopo (SOW) ou do que foi acordado. 3. Diga onde o tom soa genérico / "de agência" e não fala com ELE. 4. Termine com um veredito: "enviaria" ou "devolveria" + a correção nº 1. Cite trechos do resumo de reuniões para sustentar cada objeção. Se faltar base no synthesized/, escreva "sem lastro" em vez de inventar.
As partes em <...> você troca pelos seus dados. Promova para agents/review-gate.md e dispare antes de todo envio ao cliente.
✅ Como verificar
- ✓A resposta vem na 1ª pessoa do cliente (não "ele acharia que…").
- ✓Cita reuniões reais do synthesized/ — objeções concretas, não genéricas.
- ✓Entrega um veredito acionável: "enviaria/devolveria" + a correção nº 1.
- ✓Teste de ancoragem: apague o resumo de reuniões e rode de novo — ele responde "sem lastro", prova de que não chuta.
Por que aprender
Porque é o que pega o erro antes do cliente pegar. Um revisor primado na voz da pessoa antecipa a objeção que você só ouviria na reunião — quando já seria tarde. É o review gate adversarial em ação: o entregável só sai depois de sobreviver ao crítico mais difícil, que é o próprio cliente simulado.
Conceitos-chave
👔 Agente: portfolio lead
O segundo agente é o portfolio lead: um gerente de relacionamento (CRM) por cliente. Cada um é totalmente primado e tem, injetado no seu contexto, todas as reuniões que você já teve com aquela conta. Quando você pergunta "onde paramos com o Cliente A?", o portfolio lead daquele cliente responde com a memória completa do relacionamento.
🌱 Novo aqui?
Um CRM (customer relationship management) é o sistema que guarda o histórico do relacionamento com um cliente. Aqui o "CRM" não é um app externo: é um agente primado com as reuniões daquele cliente — a memória viva da conta, dentro do seu OS.
Um CRM-agente por cliente, com todas as reuniões injetadas. Lembra o status, os próximos passos, o histórico.
O par dele: enquanto o portfolio lead lembra, o review gate critica na voz do cliente antes do envio.
💡 Dois agentes, papéis opostos
O portfolio lead está do seu lado (lembra tudo, prepara a reunião). O review gate joga contra (ataca o entregável na voz do cliente). Os dois leem o mesmo synthesized/ — a mesma memória, usada de duas formas.
Por que aprender
Porque consultoria é relacionamento, e relacionamento é memória. Um portfolio lead por cliente significa que você nunca chega numa reunião "frio": o agente já te lembrou do combinado, das pendências e das sensibilidades daquela conta. Escala o atendimento sem perder o toque pessoal.
Conceitos-chave
🧰 Skills & ferramentas da conta
As skills do Consulting OS são as tarefas que você mais repete por conta: pré-call prep (preparar a reunião), proposta/SOW e auditoria de IA. Detalhe importante: nunca uma "skill de auditoria genérica" — toda auditoria é nuançada ao objetivo do cliente. As ferramentas conectam ao mundo real: QuickBooks e ledgers, links do Stripe dentro das propostas (em vez de PandaDoc) e checagem de buffer na agenda (Calendly/iCal).
🌱 Novo aqui?
SOW (statement of work) fixa o escopo do trabalho. Ledger é o livro-razão das transações. Stripe gera links de pagamento; PandaDoc é uma alternativa de documentos que aqui se dispensa. Buffer na agenda é o respiro entre reuniões — a ferramenta checa se há folga antes de marcar.
As skills da conta — repetíveis, nunca genéricas
skills/ ├── pre-call-prep # junta histórico + pendências da conta ├── proposta-sow # gera proposta com link Stripe embutido └── auditoria # SEMPRE nuançada ao objetivo do cliente
✓ Intencional
- ✓Auditoria sempre ancorada no objetivo da conta.
- ✓Stripe direto na proposta — menos ferramenta, menos manutenção.
- ✓Checagem de buffer antes de marcar reunião.
✗ Genérico
- ✗Uma skill de "auditoria" que serve para qualquer um.
- ✗Empilhar 5 ferramentas que viram peso morto.
- ✗Proposta sem caminho de pagamento claro.
Por que aprender
Porque é onde o "nunca seja genérico" do curso fica concreto. A mesma palavra — auditoria — vale ouro quando ancorada no objetivo do cliente e nada quando é template. E ser intencional com ferramentas (Stripe sim, PandaDoc não) evita que cada integração vire uma dívida de manutenção.
Conceitos-chave
🚧 Regras & o que é selado
Voltamos à camada que pesa mais aqui. As regras do Consulting OS cobrem a voz da marca, as coisas a evitar e o formato de relatório — que pode ser diferente entre o Cliente A e o Cliente C. E há a identidade: quem você serve, o que é selado (confidencial, nunca vaza) e os seus valores. Em consultoria, vazar entre clientes é o erro que encerra contratos.
✓ Cercas de consultoria
- ✓Voz da marca consistente por entregável.
- ✓Formato de relatório por cliente (A ≠ C).
- ✓O selado de um cliente nunca aparece para outro.
✗ Quebra de confiança
- ✗Dado do Cliente A vazando no doc do Cliente B.
- ✗Mesmo formato genérico para contas diferentes.
- ✗Tom inconsistente que não parece você.
⚠️ O erro a evitar
Tratar a confidencialidade entre clientes como "regra mole". O cruzamento de dados sensíveis entre contas deve ser um gancho determinístico: um reflexo que impede o material selado do Cliente A de entrar em qualquer artefato de outro cliente. Determinístico onde dói — e em consultoria, vazar dói para sempre.
Por que aprender
Porque é o que protege o seu negócio. A inteligência do OS não vale nada se ele cruzar dados entre clientes ou falar com a voz errada. Fechar as regras — voz, formato por cliente, selado como gancho — é o que deixa você escalar atendimento sem risco à reputação que sustenta a consultoria.
Conceitos-chave
✅ Resumo do módulo
Próximo módulo:
5.6 — Freedom OS & padrões de produção 🗽