Contenido detallado
🍕 La pizza: las reglas y los ganchos pesan más
La distribución del Consulting OS está razonablemente equilibrada, con el contexto a la cabeza (la información de los clientes está dispersa y debe agregarse). La diferencia más marcada: las reglas y los ganchos pesan más de lo normal. En consultoría, lo que sale de tu OS va a un cliente que paga; por eso, los límites (voz de marca, qué está sellado, formato para cada cliente) cobran más importancia.
Cómo leer: la porción de Reglas y ganchos está destacado (brillo) porque crece aquí. Compáralo con el Content OS, donde aparecía al final: el dominio cambia la forma del gráfico circular.
💡 Por qué pesan las reglas
Cada entregable lleva tu reputación y la relación con un cliente específico. El informe del cliente A no puede tener el tono del cliente C; lo que se marcó como sellado nunca puede filtrarse. Las reglas flexibles no bastan para eso; por eso la capa crece.
Por qué aprender
Porque te enseña a leer la forma de la pizza por dominio. Al ver que la consultoría exige barreras fuertes, priorizas correctamente: no sirve de nada un agente brillante si le envía al cliente A el informe con el formato del cliente B. La distribución es tu mapa de prioridades.
Conceptos clave
🗄️ Contexto: 1 carpeta por cliente
La información de tus clientes está dispersa por todas partes. El primer paso es agregarla y darle sentido: el equivalente, en carpetas, a armar armarios y estantes. Cada cliente se convierte en una carpeta; en el CLAUDE.md tú dejas la referencia: "cuando menciono a este cliente, me refiero a esta carpeta". El OS pasa a saber exactamente dónde buscar.
🌱 ¿Nuevo aquí?
La carpeta raw/ guarda el material sin procesar (transcripciones de reuniones, correos); la synthesized/ guarda lo destilado (el resumen que realmente lee el OS). El CLAUDE.md es el archivo-alma, que se lee primero; ahí creas los apodos: «Cliente A = clientes/cliente-a/».
Cómo leer: la estructura es el «armario». Cada cliente tiene su cajón (con material bruto y destilado), los playbooks están a mano y la wiki guarda lo que sirve para todos. Los agentes (en cian) leen esta estructura.
Por qué aprender
Porque sin un armario organizado, todo lo demás se derrumba. Si el OS no sabe qué carpeta corresponde a cada cliente, mezcla contextos, y mezclar clientes en una consultoría es una falla grave. La carpeta por cliente y la referencia en el CLAUDE.md son lo que le dan al OS una memoria confiable de cada cuenta.
Conceptos clave
📚 Playbooks por cliente + wiki global
Sobre las carpetas vienen los playbooks: cómo llevas la consultoría en general y cómo la llevas para cada cliente específico. Estos playbooks se agregan a un playbook global, una wiki que clasifica todas las reuniones de todos los clientes. Toda empresa tiene patrones; la wiki es donde los registras para enriquecer la próxima reunión y su preparación.
Cómo cobra vida un playbook
Reuniones en bruto
O raw/ de cada cliente acumula transcripciones y notas: el material sin procesar de cada cuenta.
Clasificación y destilación
La wiki cruza las reuniones de todos los clientes y aísla los patrones — lo que se repite se convierte en nugget.
Playbook vivo
Específico por cliente + global (la wiki), listos para enriquecer la preparación de la próxima reunión.
🔎 Dos niveles de playbook
- Por cliente — la forma específica de atender al Cliente A: lo que valora, el ritmo, sus manías.
- Global (wiki) — los patrones que aplican a todos: "los negocios de este tipo suelen objetar X", tu método de preparación de reuniones.
- El puente — la wiki clasifica las reuniones de todos los clientes y encuentra los patrones que enriquecen cada cuenta.
✓ Playbooks que dan resultados
- ✓Específico por cliente + uno global que destila patrones.
- ✓Alimentado por la clasificación de reuniones reales.
- ✓Mejora la preparación de la próxima reunión de cada cuenta.
✗ Wiki muerta
- ✗Un documento gigante que nadie actualiza.
- ✗El mismo playbook genérico para todos los clientes.
- ✗Nunca destilar las reuniones en patrones.
Por qué aprender
Porque es lo que convierte la experiencia en un activo. Sin playbooks, cada reunión vuelve a empezar desde cero y el conocimiento vive solo en tu cabeza. Con el dúo por cliente + wiki global, el OS recuerda cómo atiendes cada cuenta y además cruza patrones entre ellas: mejoras con cada cliente.
Conceptos clave
🛡️ Review gate adversarial con la voz del cliente
La pieza distintiva del Consulting OS: antes de que un entregable llegue al cliente, pasa por un revisor adversarial que adopta la voz de ese cliente. Es un agente al que le pones el nombre del contacto principal de la cuenta, priorizado por todas las reuniones sintetizadas — conoce las objeciones recurrentes, lo que la persona valora y su tono. Cuando el stack lo requiere, conviene tener varios revisores adversariales, no solo uno.
🌱 ¿Nuevo aquí?
Un review gate (puerta de revisión) es un punto obligatorio por el que algo pasa antes de salir. Adversarial significa que el revisor juega en contra: su trabajo es encontrar el problema, no elogiar. Primacía = precargado con el contexto. SOW (statement of work) es el documento que fija el alcance acordado con el cliente.
🎯 Objetivo de la copy-run
Ejecutar un revisor que piense como el cliente sobre un entregable, basado en el resumen real de las reuniones, y obtener sus objeciones + un veredicto de «lo enviaría» o «lo devolvería».
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.
Las partes en <...> tú los reemplazas por tus datos. Promueve a agents/review-gate.md y actívalo antes de cada envío al cliente.
✅ Cómo verificar
- ✓La respuesta viene en la 1.ª persona del cliente (no «creería que…»).
- ✓Cita reuniones reales de synthesized/ — objeciones concretas, no genéricas.
- ✓Entrega un veredicto accionable: «enviaría/devolvería» + la corrección n.º 1.
- ✓Prueba de anclaje: borra el resumen de reuniones y ejecútalo de nuevo — responde "sin respaldo", prueba de que no inventa.
Por qué aprender
Porque es lo que detecta el error antes de que lo detecte el cliente. Un revisor preparado con la voz de la persona anticipa la objeción que solo escucharías en la reunión, cuando ya sería tarde. Es el review gate adversarial en acción: el entregable solo sale después de superar la revisión del crítico más exigente, que es el propio cliente simulado.
Conceptos clave
👔 Agente: responsable de portafolio
El segundo agente es el portfolio lead: un gerente de relaciones con clientes (CRM) por cliente. Cada uno está completamente preparado y tiene inyectado en su contexto, todas las reuniones que ya tuviste con esa cuenta. Cuando preguntas «¿dónde nos quedamos con el Cliente A?», el portfolio lead de ese cliente responde con la memoria completa de la relación.
🌱 ¿Nuevo aquí?
Un CRM (gestión de relaciones con clientes) es el sistema que guarda el historial de la relación con un cliente. Aquí, el «CRM» no es una app externa: es un agente con las reuniones de ese cliente como contexto inicial: la memoria viva de la cuenta, dentro de tu OS.
Un agente CRM por cliente, con todas las reuniones incorporadas. Recuerda el estado, los próximos pasos y el historial.
Su contraparte: mientras el portfolio lead recuerda, el review gate critica con la voz del cliente antes del envío.
💡 Dos agentes, roles opuestos
O portfolio lead está de tu lado (lo recuerda todo, prepara la reunión). El review gate juega en contra (ataca el entregable con la voz del cliente). Ambos leen lo mismo synthesized/ — la misma memoria, usada de dos maneras.
Por qué aprender
Porque la consultoría se basa en las relaciones, y las relaciones requieren memoria. Tener un portfolio lead por cliente significa que nunca llegas «sin contexto» a una reunión: el agente ya te recordó lo acordado, los pendientes y las sensibilidades de esa cuenta. Permite ampliar la atención sin perder el toque personal.
Conceptos clave
🧰 Skills y herramientas de la cuenta
Las skills del Consulting OS son las tareas que más repites por cuenta: preparación antes de la llamada (preparar la reunión), propuesta/SOW e auditoría de IA. Detalle importante: nunca una «skill de auditoría genérica»; toda auditoría tiene matices según el objetivo del cliente. Las herramientas se conectan con el mundo real: QuickBooks y libros contables, enlaces de Stripe dentro de las propuestas (en lugar de PandaDoc) y verificación de disponibilidad en el calendario (Calendly/iCal).
🌱 ¿Nuevo aquí?
SOW (statement of work) fija el alcance del trabajo. Ledger es el libro mayor de las transacciones. Stripe genera enlaces de pago; PandaDoc es una alternativa de documentos que aquí se puede omitir. Margen en la agenda es el espacio entre reuniones: la herramienta comprueba si hay tiempo libre antes de agendar.
Las skills de la cuenta — repetibles, 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
- ✓Auditoría siempre anclada en el objetivo de la cuenta.
- ✓Stripe directo en la propuesta — menos herramientas, menos mantenimiento.
- ✓Verificación del buffer antes de programar una reunión.
✗ Genérico
- ✗Una skill de «auditoría» que sirve para cualquiera.
- ✗Apilar 5 herramientas que terminan siendo un peso muerto.
- ✗Propuesta sin una forma clara de pago.
Por qué aprender
Porque es donde el "nunca seas genérico" del curso se vuelve concreto. La misma palabra —auditoría— vale oro cuando se basa en el objetivo del cliente y no vale nada cuando es una plantilla. Y ser intencional con las herramientas (Stripe sí, PandaDoc no) evita que cada integración se convierta en una deuda de mantenimiento.
Conceptos clave
🚧 Reglas y lo que está sellado
Volvemos a la capa que más pesa aquí. Las reglas del Consulting OS cubren la voz de marca, las cosas que hay que evitar y el formato del informe, que puede variar entre el Cliente A y el Cliente C. Y está la identidad: a quién sirves, lo que está sellado (confidencial, nunca se filtra) y sus valores. En consultoría, filtrar información entre clientes es el error que termina los contratos.
✓ Límites de consultoría
- ✓Voz de marca coherente en cada entregable.
- ✓Formato de informe por cliente (A ≠ C).
- ✓Lo sellado de un cliente nunca aparece para otro.
✗ Pérdida de confianza
- ✗Dato del Cliente A filtrado en el doc del Cliente B.
- ✗El mismo formato genérico para distintas cuentas.
- ✗Tono inconsistente que no suena como tú.
⚠️ El error que debes evitar
Tratar la confidencialidad entre clientes como una «regla flexible». El cruce de datos sensibles entre cuentas debe ser un gancho determinista: un reflejo que impide que el material sellado del Cliente A entre en cualquier artefacto de otro cliente. Determinista donde más importa; y en consultoría, una filtración duele para siempre.
Por qué aprender
Porque es lo que protege tu negocio. La inteligencia del OS no vale nada si mezcla datos entre clientes o habla con la voz equivocada. Definir las reglas —voz, formato por cliente, sellado como gancho— es lo que te permite escalar la atención al cliente sin arriesgar la reputación que sostiene la consultoría.
Conceptos clave
✅ Resumen del módulo
Siguiente módulo:
5.6 — Freedom OS y patrones de producción 🗽