Extraer tareas de una reunión con IA en un fin de semana

Extraer tareas de una reunión con IA es un proyecto real de fin de semana, no una fantasía. Si a las 11 de la noche estás mirando una terminal en blanco preguntándote qué construir, esta idea de negocio te interesa. Dale al extractor una transcripción de llamada o notas dispersas y devuelve una lista limpia: quién es responsable, para cuándo. La construcción en sí son pocas horas de integración. La pregunta más difícil es si encuentras veinte personas dispuestas a usar tu versión en lugar de las cinco herramientas pagadas que ya están compitiendo por ese trabajo.

Qué significa "acción pendiente" como objetivo de construcción

Sin el tecnicismo: la tarea es específica. Toma texto no estructurado (una transcripción, una nota de voz convertida en texto, un hilo de Slack) y devuelve {tarea, responsable, fecha_límite, confianza}. Nada más. No se requiere resumen, no hay análisis de sentimiento, no hay panel. Solo extracción en una forma que una app de tareas pueda consumir.

Esto importa porque cambia el estimado de alcance. Un "asistente de reuniones" general es un producto de seis meses con infraestructura de transcripción, sincronización con calendario y un equipo de UI que pelearía sobre cada detalle. Un extractor de actiónítems es un prompt, un schema, y un lugar donde guardar la salida. Puedes ship una versión funcional antes de que se enfríe tu café.

La entrada no tiene que ser una reunión. El mismo enfoque basado en esquema extrae compromisos de un hilo de standup en Slack, una cola de tickets de soporte, o una nota de voz de un cliente. Las reuniones son el objetivo obvio porque las transcripciones ya existen. No son el único mercado.

El stack que te lleva de transcripción a lista de tareas en un fin de semana

Aquí está todo el pipeline para una primera versión:

1. Entrada: pega transcripción o sube .txt / .vtt (sin audio en vivo aún)
2. Llamada a LLM: salida estructurada, schema JSON forzado
3. Almacenamiento: tabla Supabase o incluso un archivo JSON para v0
4. Salida: checklist markdown + opcional webhook a Linear/Notion

El prompt de extracción es la única parte que necesita iteración real. Algo como esto te lleva al 80% del camino:

Extrae actiónítems de la transcripción de abajo.
Devuelve array JSON: [{tarea, responsable, fecha_límite, confianza}]
Reglas:
- responsable = nombre mencionado, o "sin asignar"
- fecha_límite = solo fecha explícita, si no null
- salta declaraciones vagas ("deberíamos pensar en X")
- confianza: 0-1, basado en cuán explícito fue el compromiso

Wei-Chen Liao, que trabaja en sistemas de recomendación en Appier en Taipei, lo dijo después de un proyecto similar: "la calidad de extracción se limita por la calidad de la transcripción, no por la calidad del modelo. Gasta tu primer fin de semana limpiando entrada, no cambiando modelos".

El costo a escala indie es casi nada. Una transcripción de reunión de una hora consume 8.000 a 12.000 tokens en una llamada con salida estructurada. Con los precios actuales de API es una fracción de centavo por reunión. El costo real es la transcripción si no partes de texto que alguien ya exportó.

No alcances el modelo más grande disponible. Un modelo pequeño y económico con un schema JSON forzado y algunos ejemplos de few-shot logra precisión de extracción cercana a la de un modelo de punta, a una fracción de latencia y costo. Guarda el presupuesto del modelo grande para los casos donde confianza regresa baja y quieres un segundo análisis, no para cada llamada.

Dónde ya existe el mercado, y no está vacío

Antes de construir, sabe contra qué compites. Un análisis reciente de herramientas de extracción automática de actiónítems sitúa el precio por usuario para la categoría entre $4 y aproximadamente $40 al mes, dividido en dos campos: herramientas solo de extracción que dejan tareas en un documento, y herramientas de ciclo completo que envían tickets directamente a Jira, Linear o Asana antes de que termine la llamada.

Esa división es la parte útil. La mayoría del medio abarrotado es solo extracción: notas limpias, sin enrutamiento. Las herramientas que automatizan la última milla, creando realmente el ticket, son menos y cobran más por ello. Si estás delimitando v1, ese es tu wedge: nadie quiere otro resumen. Quieren que la tarea ya exista en algún lugar cuando termine la llamada.

TicNote es un punto de referencia útil aquí, no porque deberías recomendarlo en lugar de construir, sino porque muestra qué se ve "suficientemente bueno para cobrar" en el extremo pequeño: genera archivos reales, no solo un resumen volcado en una ventana de chat. Ese es el estándar.

Valida antes de perfeccionar el prompt de extracción más allá de lo que alguien pidió. Publica tu v0 en dos o tres comunidades de freelancers o builders independientes, ofrécete a ejecutarlo en una llamada real de alguien de forma gratuita, y observa qué hacen con la salida. Si nadie te envía una transcripción dentro de una semana de pedir, esa es la señal para cambiar el nicho, no el modelo.

Salta el bot de reunión en tiempo real. Construye primero la versión asincrónica

Cada tutorial que encuentres asume que estás construyendo un bot que se une a la llamada en vivo, escucha, y publica en Slack en medio de la reunión. Salta eso. Tiempo real significa streaming de audio, diarización (distinguir hablantes), y un bot que tiene que sentarse en la llamada sin retraso. Eso no es un fin de semana. Es la versión que mata proyectos secundarios en la semana tres.

La versión asincrónica es la misma lógica central sin las partes difíciles: alguien pega una transcripción (de la exportación incorporada de Zoom, de Otter, de una ejecución de Whisper en una grabación) y obtiene una lista de tareas treinta segundos después. Es menos impresionante en un video de demostración. También es la versión que realmente puedes terminar.

Ya existe un template público de n8n encadenando AssemblyAI y GPT-4 en Google Sheets para exactamente esto. Vale la pena estudiarlo antes de escribir una línea de código, y vale la pena ignorarlo como producto final: vuelca todo en una hoja de cálculo, que se rompe pasado un puñado de usuarios y no te da nada por lo que cobrar.

Lo que un freelancer en Bangkok necesita que un plugin de Jira no da

La versión genérica de esta herramienta se construyó para equipos ya dentro de Jira o Linear. Es un carril abarrotado y bien financiado. La porción desatendida son consultores solo y freelancers, el tipo de persona sobre la que Napat Charoenwong escribe ejecutando su estudio en Bangkok, que toma cinco llamadas de clientes a la semana y no tiene ni quiere una herramienta de gestión de proyectos.

Para esa persona, la ganancia no es enrutamiento de tickets. Es una lista de tareas que aparece en WhatsApp o correo después de la llamada, etiquetada por cliente, sin nada que configurar. Tres llamadas de cliente sin procesar a la semana vence mil asientos empresariales que nunca cerrarás como un constructor solo sin equipo de ventas.

Esa es una decisión real de alcance, no un buen tener: elige un canal de entrega (resumen por correo es el más barato de construir) y un persona estrecho (freelancers, terapeutas, consultores, cualquiera que facture por llamada) antes de tocar una segunda integración.

La economía también funciona diferente entre mercados. Una herramienta de $9/mes se ve trivial desde una perspectiva estadounidense y parece una factura de utilidad real en Manila o Bangkok, donde la misma tarifa de freelancer cubre más horas facturables perdidas en administración. Precio por el valor de la hora que ahorras, no por lo que cobra un SaaS de Silicon Valley.

Por qué la versión sin código se rompe antes de la versión pagada

La ruta de n8n y hoja de cálculo es el punto de partida honesto, pero tiene un techo: límites de tasa en la API de transcripción, una hoja de cálculo que se vuelve ilegible pasada una docena de filas, y cero lugar para poner un login o una suscripción. Es un prototipo, no un producto.

El movimiento una vez que validas demanda: reemplaza la hoja de cálculo con una tabla real (Supabase funciona bien en esta escala), añade un login, y pon un precio. No necesitas reconstruir la lógica de extracción. Necesitas dejar de almacenar estado en un lugar donde nadie puede pagarte.

Vale la pena notar antes de profundizar en el pipeline: audio basura produce transcripciones basura, y transcripciones basura producen actiónítems basura sin importar cuán bueno sea tu prompt. Si tus usuarios objetivo están en llamadas desordenadas (wifi lento, ruido de fondo, inglés con acento en un equipo distribuido), un paso de limpieza de ruido como Krisp antes de la transcripción te ahorrará más tiempo de depuración que afinar el prompt de extracción.

¿Deberías cobrar por ello, o plegarlo en algo más grande

Salta si esperas que se convierta en un SaaS independiente con números de escala de capital de riesgo. La categoría tiene precio bajo ($4 a $10 por usuario es el piso realista una vez que compites por precio) y los gigantes ya tienen integraciones de calendario, apps móviles, y equipos de ventas. Un dev solo no gana esa pelea de frente.

Vale la pena construir si lo tratas como una característica, no una empresa: enchúfalo a una práctica de consultoría como un valor agregado, envíalo como una herramienta de $9/mes para un nicho estrecho que ya entiendes, o úsalo como la pieza técnica central de una pieza de portafolio que te consigue trabajo de integración LLM de freelance. Los tres son resultados realistas para una construcción de fin de semana. "Vencer Otter.ai" no lo es.

Si la herramienta de extracción es una pieza de un kit más grande que estás armando para clientes, algo como Skywork vale la pena mirar para los entregables circundantes: el documento o una página dirigido al cliente que de otro modo construirías a mano alrededor de la lista de tareas sin procesar.

Lo que realmente enviaríamos primero

Una aplicación de una sola página: pega una transcripción, obtén un checklist, exporta a correo o copia como markdown. Sin login para v0. Sin integraciones. Pruébalo en tus propias llamadas durante dos semanas antes de mostrarlo a cualquier otra persona, porque el prompt de extracción necesita transcripciones reales en las que fallar, no datos de prueba sintéticos que escribiste tú mismo.

Si sobrevive a tus propias llamadas sin perder un compromiso obvio, ponlo delante de cinco freelancers o consultores que realmente conoces. No un post de Reddit, no un lanzamiento de Product Hunt. Cinco personas cuyas llamadas puedas ver cuando la salida sea incorrecta. Ese es el primer mes completo.

¿Qué necesitarían realmente tus primeras diez transcripciones que esto no cubre aún?