Cómo escribir una propuesta para un CFP que el comité quiera aceptar

Una buena propuesta para un call for papers (CFP) le deja claro al comité, en menos de un minuto de lectura, qué problema aborda la charla, para quién es, qué se llevará el público y por qué tú eres la persona indicada para darla. Eso se logra con un título específico, un resumen centrado en el beneficio para la audiencia, un esquema concreto, el nivel correcto y una bio breve que respalde el tema. Abajo tienes cada parte explicada, una plantilla para copiar y los motivos más comunes de rechazo.

Cómo lee un comité tu propuesta

Antes de escribir, ponte del otro lado. Un comité de revisión suele tener muchas propuestas para pocos espacios, y quienes revisan lo hacen en su tiempo libre o entre otras tareas. En la práctica:

• Leen primero el título y el primer párrafo del resumen. Si no queda claro de qué trata, pasan a la siguiente.
• Buscan encaje con el público y la temática del evento.
• Cuidan el equilibrio del programa: temas, niveles, formatos y diversidad de speakers.
• Desconfían de las propuestas que parecen presentaciones comerciales.
• Valoran la experiencia propia y concreta por encima de lo genérico.

Si quieres entender el proceso desde el lado del organizador, mira cómo organizar un call for papers y cómo seleccionar speakers.

Antes de escribir: lee la convocatoria

Parece obvio, pero muchas propuestas se rechazan por no seguir las instrucciones. Revisa:

• Temas o tracks que busca el evento.
• Formatos aceptados (charla, taller, panel, charla relámpago) y duraciones.
• Idioma de las charlas.
• Público objetivo y nivel.
• Qué campos pide el formulario y sus límites de extensión.
• Fecha de cierre y zona horaria. En la región hay varios husos horarios; no dejes el envío para la última hora.
• Qué cubre el evento para speakers.

Mira también el programa de ediciones anteriores: te dice qué tipo de charlas eligen.

El título

El título es lo que el comité recuerda y lo que el público ve en la agenda. Debe ser específico y prometer algo concreto.

Débil	Mejor
Introducción a Kubernetes	Kubernetes para equipos chicos: lo que nos hubiera gustado saber el primer año
El futuro de los pagos	Integrar pagos locales en tres países: errores y decisiones
Diseño y accesibilidad	Auditar la accesibilidad de tu app en una tarde

Consejos:

• Usa palabras que tu público buscaría.
• Evita los juegos de palabras que esconden el tema.
• Si el título es creativo, agrega un subtítulo que explique.

El resumen (abstract)

El resumen es el texto público de la charla y suele ser lo que más pesa. Una estructura que funciona:

1. El problema o contexto (una o dos frases): qué situación conoce tu público.
2. Qué vas a mostrar (dos o tres frases): tu enfoque, caso o propuesta.
3. Qué se lleva el público (una frase o una lista corta): aprendizajes concretos.

Escríbelo para el asistente, no para el comité: en segunda persona y sin jerga innecesaria. Evita prometer más de lo que cabe en el tiempo asignado.

Ejemplo de resumen (hipotético)

Tu equipo tiene usuarios en varios países y cada uno paga de forma distinta. En esta charla cuento cómo integramos medios de pago locales en una app, qué decisiones de arquitectura tomamos y cuáles revertimos. Vas a salir con una lista de preguntas para hacer antes de elegir un proveedor de pagos y un esquema para manejar monedas y reintentos.

El esquema (outline)

Muchos CFPs piden un esquema o descripción detallada solo para el comité. Es donde demuestras que la charla ya existe en tu cabeza. Incluye:

• Bloques con tiempo aproximado.
• Qué ejemplos, demos o datos vas a mostrar.
• Cómo cierras.

Ejemplo de esquema para una charla de treinta minutos (hipotético):

• Contexto y problema (5 min).
• Primera decisión y qué aprendimos (8 min).
• Segunda decisión, el error y cómo lo corregimos (8 min).
• Lista de verificación para el público (5 min).
• Preguntas (4 min).

El nivel y el público

Indica el nivel con honestidad: principiante, intermedio o avanzado. Y dilo en términos prácticos: “para quienes ya usan X en producción” o “no se necesita experiencia previa”. Una charla avanzada marcada como introductoria decepciona al público, y una introductoria marcada como avanzada se rechaza por superficial.

Si el formulario lo permite, aclara los requisitos previos y si la charla sirve para perfiles no técnicos.

La bio

La bio responde: ¿por qué tú? Mantenla corta y en tercera persona:

• Rol actual y área.
• Experiencia directamente relacionada con la charla.
• Una o dos charlas, publicaciones o proyectos relevantes.
• Ciudad o país, si aporta al evento.

Evita listas largas de títulos que no tienen que ver con el tema. Si es tu primera conferencia, no lo escondas: menciona meetups donde hablaste o contenido que publicaste. Si todavía no diste charlas, revisa cómo ser speaker en conferencias.

Notas para el comité

Si hay un campo de notas privadas, úsalo para:

• Explicar por qué la charla encaja en este evento en particular.
• Mencionar si ya la diste y dónde, con enlace a grabación si existe.
• Indicar necesidades especiales (accesibilidad, equipos, horario por viaje).
• Aclarar si tu empresa patrocina o no, para transparencia.

Plantilla para copiar

Título:
[Promesa concreta] + [contexto o público]

Formato y duración:
[Charla / taller / panel] – [minutos]

Nivel:
[Principiante / intermedio / avanzado] – [requisitos previos]

Resumen (público):
[Problema o contexto que tu público reconoce.]
[Qué vas a mostrar: tu caso, enfoque o propuesta.]
[Qué se lleva el público: 2–3 aprendizajes concretos.]

Esquema (para el comité):
- [Bloque 1] – [min]
- [Bloque 2] – [min]
- [Bloque 3] – [min]
- [Cierre y preguntas] – [min]

Bio:
[Nombre] es [rol] en [empresa/proyecto]. [Experiencia relacionada con la charla.]
[Charlas o contenido anterior relevante.]

Notas para el comité:
[Por qué este evento. Dónde la diste antes. Necesidades especiales.]

Motivos comunes de rechazo

• No encaja con el evento: tema fuera de los tracks o público equivocado.
• Demasiado amplio: “todo sobre” algo, imposible de cubrir en el tiempo.
• Comercial: la charla parece una demo de producto.
• Vago: el resumen no dice qué aprenderá el público.
• Repetido: el tema ya está muy cubierto en el programa o en ediciones anteriores, sin un ángulo nuevo.
• Incompleto: campos vacíos, bio de una línea, sin esquema.
• Fuera de plazo o de formato: excede los límites o llega tarde.
• Equilibrio del programa: a veces una buena propuesta queda fuera porque hay otra similar. No es personal.

Revisión final antes de enviar

• ¿El título dice de qué trata la charla?
• ¿El primer párrafo del resumen explica el problema y el beneficio?
• ¿El nivel es honesto?
• ¿El esquema cabe en la duración?
• ¿La bio respalda el tema?
• ¿Seguiste las instrucciones y los límites del formulario?
• ¿Alguien más la leyó? Pide a un colega que te diga en una frase de qué trata. Si no puede, reescribe.

Cómo te ayuda BuildAConf

En BuildAConf postulas a charlas directamente desde el sitio de cada evento, y el equipo organizador revisa las propuestas con puntajes y te notifica por correo. También puedes tener tu perfil en el catálogo público de speakers, donde los organizadores pueden invitarte, y recibir un resumen semanal con los nuevos eventos.

Preguntas frecuentes

¿Cuántas propuestas puedo enviar al mismo CFP?

Depende del evento; muchos aceptan varias. Envía solo las que de verdad encajan y que puedas preparar bien. Dos propuestas distintas y cuidadas son mejores que cinco variaciones del mismo tema.

¿Puedo enviar la misma propuesta a varios eventos?

Sí, es habitual. Adapta el título, el resumen y las notas al público y a los temas de cada evento, y avisa si te aceptan en dos con fechas que chocan.

¿Qué hago si me rechazan?

Agradece, pide comentarios si el evento los da y mejora la propuesta. Un rechazo suele reflejar el equilibrio del programa tanto como la calidad de la charla.

¿Debo tener la charla terminada antes de postular?

No hace falta tener las slides, pero sí la estructura y el contenido claros. Si te aceptan, vas a necesitar tiempo para prepararla y ensayarla.