El pipeline de notas de reunión a brief: los pasos reales y dónde se rompe

El peor brief que le envié a un cliente fue escrito con una grabación completa, una transcripción completa, y un modelo de IA capaz. También era el brief equivocado: coherente en la superficie, equivocado sobre lo que el cliente realmente necesitaba, lo bastante fluido como para que no lo detectara antes de enviarlo.

La falla no fueron las herramientas. Fue el pipeline. Había automatizado demasiado en la dirección equivocada y me había saltado el único paso que hace la diferencia entre un brief que ayuda al cliente a pensar y uno que solo prueba que estuviste en la sala.

Esta es la disección del pipeline que ahora corro: los pasos reales, en orden, con los tres lugares donde se rompe y lo que hago en cada uno. Sin marco aspiracional. Esto es lo que realmente corre en trabajo real con clientes.

Lo que el pipeline no es

Antes de los pasos: seamos honestos sobre lo que la IA no puede hacer en este flujo, porque todo tutorial se salta esta parte.

La IA no puede decirte cuál momento de la reunión fue el que importó. No puede distinguir entre lo que un cliente dijo y lo que un cliente quiso decir. No puede oír la pausa antes de una respuesta, ni la forma en que se desvió una pregunta. Esas señales son tuyas. Viven en las notas que tomas durante la reunión, no en la transcripción después de ella.

Así que la primera restricción de este pipeline es arquitectónica: la IA opera sobre lo que le llevas, y lo que le llevas es el resultado de tu propia percepción en la sala. Automatiza la transformación de un buen input, y obtienes un buen output. Usa IA para rescatar un mal input (notas delgadas, sin contexto, una transcripción cruda sin anotación humana) y obtienes un brief plausible que tergiversa la reunión. He generado ambos. Solo uno es útil.

El pipeline, paso a paso

Paso uno: anotar en la sala, no después

Durante la reunión tomo notas tipeadas escasas. No un intento de transcripción; no viñetas de todo lo dicho. Busco tres cosas específicas, y las etiqueto en línea:

• [D]: una decisión, incluso una tentativa
• [T]: una tensión que no se resolvió (“quieren X pero también dijeron Y”)
• [Q]: una pregunta que hicieron que nadie contestó, o que quedó enterrada

Nada más se etiqueta. La disciplina es deliberada. Si intento capturar todo, estoy transcribiendo, y transcribir en la sala cambia atención por cobertura, un mal negocio. Estas tres etiquetas toman quince segundos cada una y no me cuestan nada en la sala. Al final de una reunión de noventa minutos tengo, típicamente, de cuatro a ocho de ellas. Ese es el input real a todo lo que sigue.

Paso dos: comprimir a la forma, no a la sustancia

Después de la reunión, transfiero las notas anotadas a Obsidian y las paso por un único paso de compresión. La instrucción que uso:

Here are annotated notes from a client meeting. Tags: [D] = decision, [T] = tension, [Q] = unanswered question.

Produce a structured outline only: no prose. Three sections:
1. Decisions taken or effectively taken (list the decision and the confidence level: firm / provisional / tacit)
2. Tensions still open (list each tension as a genuine either/or)
3. Questions nobody answered (verbatim or close to it)

Do not interpret. Do not add context I haven't provided. If you are uncertain whether something is a decision or a tension, put it in both.

La instrucción “no interpretes” es la que sostiene todo. La interpretación es mi trabajo, por razones que el tercer paso hace obvias. Lo que necesito de la etapa de compresión es forma: una estructura limpia que hace que el contenido de la reunión sea escaneable y esté listo para argumentar. No necesito la lectura del modelo sobre lo que el cliente realmente estaba diciendo. Eso es lo único que consistentemente hace mal.

Paso tres: llenar el marco

Ahora escribo el brief. A mano. Desde el outline comprimido.

El brief tiene tres secciones que se mapean a los tres tipos de etiqueta. Esto no es una coincidencia; diseñé las etiquetas para producir las secciones. Las decisiones se convierten en la sección “Dónde quedamos”. Las tensiones se convierten en la sección “Preguntas abiertas”, reformuladas como preguntas reales, no como declaraciones diplomáticas generadas por IA. Las preguntas sin responder se convierten en “Disparadores para la próxima conversación”.

La escritura en esta etapa es genuinamente mía, por la misma razón por la que el primer borrador de una recomendación tiene que ser mío: el brief es un documento de cara al cliente, y cualquier cosa en él representa mi entendimiento de lo que pasó. Si dejo que el modelo escriba la prosa, termino editando una versión plausible de los eventos que puede o no ser lo que realmente pienso. Se ve terminado. El cliente puede notar cuando no captura del todo la sala, incluso cuando no puede explicar por qué. Ellos también estuvieron en la sala.

El brief no es una transcripción en forma de párrafo. Es un registro de lo que entendiste, y lo que entendiste es tuyo para escribir.

Tiempo total desde que termina la reunión hasta que se envía el brief: típicamente de treinta a cuarenta y cinco minutos para una reunión de noventa minutos. El paso de notas de reunión a brief solía tomar dos horas y requería volver a escuchar las grabaciones. Eso, el volver a escuchar, es lo que corté, no la escritura.

Los tres lugares donde se rompe

Cada versión de este pipeline que he corrido se ha roto en los mismos tres lugares. Conocerlos de antemano es lo único que evita que me sorprendan.

Ruptura uno: la trampa de la transcripción. La falla más común es empezar desde una transcripción completa en vez de notas anotadas. Las transcripciones son exhaustivas e inútiles de la misma manera en que los inputs scrapeados eran inútiles en el flujo de investigación: son un registro completo de ruido junto con señal, sin manera de distinguir cuál es cuál. Cuando le doy una transcripción al paso de compresión, el modelo tiene que adivinar qué momentos importaron. Adivina encontrando lo que se dijo más, o más enfáticamente, o más claramente, nada de lo cual es un proxy confiable de lo que al cliente realmente le importó. Mi anotación de tres etiquetas es precisamente la capa de señal que una transcripción no puede proveer. La transcripción no es un sustituto de las notas; es una alternativa a haber prestado atención.

Ruptura dos: el problema del blanqueo de confianza. El paso de compresión tiene un modo de falla contra el que ahora me protejo explícitamente: el modelo va a producir prosa confiada y limpia sobre decisiones que, en la sala, fueron provisionales, tentativas o disputadas. Un cliente que dijo “creo que nos estamos inclinando hacia la opción B” se convierte, en un brief generado por IA, en “el cliente eligió la opción B”. La palabra “creo” desaparece en el resumen. La etiqueta “provisional” nunca aparece porque el modelo no sabe cómo se ven, desde adentro de una conversación de negocios en vivo, lo confiado y lo provisional.

Por eso la instrucción de compresión pide niveles de confianza explícitamente (“firme / provisional / tácito”) y por eso leo el resultado contra mi propia memoria de la sala antes de que el brief vaya a alguna parte. El modelo no puede saber la diferencia. Tú puedes. Úsalo.

Ruptura tres: el problema de la prosa limpia. El modo de falla final es el más sutil. Un brief bien escrito suaviza todo, incluyendo las tensiones que deberían quedar afiladas. Una tensión que se leía como “quieren granularidad semanal pero se resisten al gobierno de datos requerido para producirla” se convierte, en prosa generada por el modelo, en algo como “el equipo está trabajando para alinear la cadencia de reportes”. Esa oración no está mal. Tampoco es útil. El cliente no puede actuar sobre ella. La tensión es con lo que necesitan sentarse, y la prosa suave la disuelve.

Mi regla: si una tensión en la sección “Preguntas abiertas” no se siente ligeramente incómoda de leer, la escribí mal. La incomodidad es la señal de que el brief es honesto sobre el problema real, que es la única razón para enviarlo.

Lo que uso

Obsidian para las notas y el paso de compresión. Un modelo de IA capaz para la compresión. Una plantilla en Obsidian con las tres secciones pre-construidas para que el paso de llenado tenga un marco consistente en el que trabajar. Sin herramientas de grabación, sin auto-transcripción, sin bots de notas de reunión: optimizan para la captura, y la captura no es el cuello de botella. La anotación en la sala lo es. Solo listo lo que está en mi stack real.

Si quieres la plantilla exacta (las convenciones de etiquetas, el prompt de compresión, y el marco de brief de tres secciones con el andamiaje de nivel de confianza incorporado) está empaquetada:

→ La plantilla Meeting-to-Deliverable: $49. Ponla en Obsidian y corre tu próxima reunión con cliente a través de ella. (Se envía primero a la lista del newsletter; suscríbete abajo.)

Disclosure: Algunos enlaces en este sitio son enlaces de afiliado, si compras a través de ellos puedo ganar una comisión, sin costo para ti. Solo recomiendo herramientas que realmente uso. Mira el brief que acabas de leer: las fallas también están aquí, porque eso es lo que significa “realmente uso”.

El brief que mencioné al principio (el equivocado, enviado con una grabación completa y una transcripción) estaba equivocado por una razón específica. Tenía un registro preciso de todo lo que se dijo. No tenía ningún registro de lo que había notado. La diferencia entre esas dos cosas es el paso de anotación, que toma quince segundos por etiqueta en la sala y no se puede recuperar después del hecho. Esa es toda la lección, si la necesitas en una sola oración.

Siguiente en Workflows → Mi stack completo de IA para consultoría, y cuánto cuesta cada herramienta realmente.