Cómo redactar una propuesta técnica que gana licitaciones — lo que nadie le enseña
Este artículo prolonga La revolución informacional, donde se planteaba el marco teórico de la relación señal/ruido aplicada a las licitaciones, y El mito del executive summary, donde se mostraba que el primer documento leído por el evaluador es también el que todo el mundo descuida. Aquí, pasamos a la propuesta técnica en sí — el documento que determina la nota.
La propuesta técnica es el documento más redactado, más reciclado y menos comprendido del proceso de licitación. Cada año, miles de bid managers dedican cientos de horas a producir documentos de 100, 200, 300 páginas — y la mayoría obtiene notas entre 11 y 13 sobre 20.
No porque carezcan de competencias. No porque su solución sea mala. Porque redactan un documento. Y una propuesta técnica ganadora no es un documento redactado — es un sistema de codificación optimizado para la grilla de evaluación.
La diferencia entre 12/20 y 17/20 casi nunca es una cuestión de fondo. Es una cuestión de estructura, de densidad informacional, y de comprensión de lo que realmente hace el evaluador cuando abre su archivo.
Lo que el evaluador realmente hace con su propuesta técnica
Olvide la imagen del lector atento que devora cada página. El evaluador de una licitación pública tiene cinco expedientes que evaluar en dos días. A veces siete. Cada expediente tiene entre 80 y 300 páginas. Frecuentemente está solo, a veces acompañado de un colega técnico que solo ha leído "su" parte. Tiene una grilla de evaluación impresa junto a la pantalla.
Esto es lo que sucede concretamente.
Los primeros 30 segundos: abre el archivo, mira el índice, verifica que el documento está estructurado. Si no ve inmediatamente las grandes secciones esperadas, se ancla una señal negativa. No la olvidará.
Los primeros 5 minutos: lee el executive summary — si existe. Es ahí donde se juega la primera impresión. Si lee "Nuestro equipo pluridisciplinario se compromete a acompañar su transformación con un enfoque probado", ya sabe que tiene entre manos la misma propuesta que las otras cuatro. Su concentración baja un grado.
La evaluación propiamente dicha: no lee en orden. Toma su grilla de evaluación, criterio por criterio, y busca en la propuesta la sección que responde a cada uno. Escanea los títulos, los primeros párrafos, las tablas. Busca contenido direccionable — una información que pueda vincular a una línea de su grilla y a la que pueda asignar una nota.
El comportamiento de escaneo: en una sección de 15 páginas, el evaluador realmente lee 3 o 4 páginas. El título, el primer párrafo, los subtítulos, las tablas, los recuadros, la conclusión de sección. El resto, lo recorre por encima. No es pereza — es una restricción de capacidad del canal. Físicamente no puede absorber 1 500 páginas en dos días.
La calificación: evalúa cada criterio de forma independiente. Si su mejor argumento para el criterio "metodología" está enterrado en la sección "organización del equipo", no lo encontrará. Calificará según lo que haya encontrado en la sección "metodología" — aunque sea más débil.
A recordar: El evaluador no lee su propuesta. La escanea con una grilla. Cada información que no está en el lugar correcto, en el formato correcto, asociada al criterio correcto — es una información perdida. No porque sea mala, sino porque es invisible.
La estructura que marca la diferencia: responder al baremo, no al pliego de condiciones
Es el error más extendido, y es responsable de más puntos perdidos que cualquier defecto de contenido.
La mayoría de los bid managers estructuran su propuesta técnica calcando el plan del pliego de condiciones técnicas. ¿El pliego tiene 8 capítulos técnicos? La propuesta tendrá 8 capítulos técnicos, en el mismo orden. Es lógico. Es tranquilizador. Es erróneo.
El pliego de condiciones describe la necesidad. El baremo de evaluación describe lo que el evaluador va a calificar. No son lo mismo, y no siguen el mismo plan.
Tomemos un ejemplo. Una licitación de servicios informáticos con este baremo:
| Criterio | Ponderación | Lo que busca el evaluador |
|---|---|---|
| Comprensión de la necesidad | 30% | Reformulación, análisis de los desafíos, riesgos identificados |
| Metodología de implementación | 25% | Procesos, herramientas, gobernanza, indicadores |
| Recursos humanos | 25% | Perfiles, competencias, organización, escalamiento |
| Gestión de riesgos y calidad | 20% | Identificación de riesgos, plan de mitigación, SLA |
El pliego, por su parte, está estructurado por perímetro funcional: gestión de incidentes, gestión de cambios, gestión de puestas en producción, supervisión, reporting. Cinco capítulos técnicos.
La propuesta calcada del pliego produce cinco grandes secciones (incidentes, cambios, puestas en producción, supervisión, reporting). Para cada sección, el bid manager mezcla comprensión, metodología, equipo y riesgos. El evaluador que califica el criterio "metodología" (25% de la nota) debe buscar en cinco secciones diferentes para encontrar los fragmentos dispersos. Encuentra tres de cinco. Nota: 13/20.
La propuesta calcada del baremo produce cuatro grandes secciones (comprensión, metodología, recursos, riesgos). En cada sección, los perímetros funcionales se tratan como subsecciones. El evaluador que califica el criterio "metodología" abre la sección 2, encuentra todo lo que busca, en orden. Nota: 16/20.
Mismo contenido. Estructura diferente. Tres puntos de diferencia.
| Enfoque | Estructura | Comportamiento del evaluador | Nota típica |
|---|---|---|---|
| Calcada del pliego | Por perímetro funcional | Debe reconstruir cada criterio cruzando las secciones | 11-13/20 |
| Calcada del baremo | Por criterio de evaluación | Encuentra cada criterio en una sección dedicada | 15-17/20 |
El pliego le dice qué cubrir. El baremo le dice cómo será evaluado. Estructurar en torno al qué en lugar del cómo, es como preparar un examen leyendo el curso en lugar de mirar los exámenes anteriores. Aprende la materia. No prepara la prueba.
A recordar: El plan de su propuesta técnica no debe ser el espejo del pliego de condiciones. Debe ser el espejo de la grilla de evaluación. Cada criterio del baremo = una sección. Cada subcriterio = una subsección. El evaluador nunca debe tener que buscar.
Los tres errores que limitan su nota a 12/20
Después de haber revisado cientos de propuestas técnicas — como redactor, como revisor, como evaluador — tres patrones aparecen sistemáticamente en los expedientes que se estancan entre 11 y 13.
Error 1: la respuesta genérica
"Nuestro equipo de proyecto asegurará un seguimiento riguroso de los incidentes conforme a las buenas prácticas ITIL."
Esta frase podría figurar en cualquier propuesta, para cualquier licitación. Es el test del competidor: sustituya el nombre de su empresa por el de un competidor. Si la frase sigue funcionando, no transmite ninguna señal diferenciadora. El evaluador la lee, no aprende nada, y pasa a la siguiente. Acaba de desperdiciar un párrafo.
La respuesta genérica es el síntoma de una propuesta redactada a partir de una plantilla en lugar del pliego de condiciones. El bid manager tomó la propuesta de la última licitación, cambió el nombre del cliente, ajustó los volúmenes, y envió. Es el sesgo de recencia materializado en un documento Word.
La corrección: cada párrafo debe contener al menos un elemento específico de la licitación en curso. Un nombre de tecnología mencionado en el pliego. Un volumen. Una restricción. Un riesgo identificado en el contexto del cliente. Si no puede señalar el elemento del expediente que justifica ese párrafo — elimínelo.
Error 2: el párrafo reciclado
Más insidioso que la respuesta genérica: el párrafo que era excelente en el expediente anterior, y que está fuera de tema en este.
Un párrafo sobre la gestión del cambio en entorno SAP, perfectamente calibrado para un cliente industrial — reciclado tal cual en una licitación de una entidad territorial que no tiene SAP. El evaluador detecta inmediatamente el desfase. Y la señal que recibe no es "este candidato es generalista" — es "este candidato no ha leído nuestro pliego de condiciones".
El reciclaje es la fuente más frecuente de ruido destructivo en una propuesta técnica. Cada párrafo reciclado degrada la relación señal/ruido del conjunto del documento, porque ocupa espacio sin aportar información pertinente.
Error 3: la ausencia de pruebas
"Nuestra experiencia en gestión de proyectos complejos nos permite asegurar una implementación controlada."
Afirmación gratuita. Ninguna prueba. Ningún dato. Ninguna referencia. El evaluador no tiene razón alguna para creerle a usted más que al competidor que escribe exactamente lo mismo.
La nota técnica no es un ejercicio de persuasión retórica. Es un ejercicio de demostración. Cada afirmación debe estar respaldada por:
- Un dato: "Tiempo medio de resolución de incidentes P1 en nuestros 3 últimos contratos de TMA: 2h14, frente a un SLA de 4h."
- Una referencia contextualizada: "En la licitación [X] (entorno comparable: 12 000 puestos, SI heterogéneo), redujimos la tasa de incidentes recurrentes en un 34% en 18 meses." — No un catálogo de logotipos, sino un hecho verificable vinculado a un contexto similar.
- Un entregable concreto: "La metodología de transferencia de conocimientos se apoya en un kit documental de 47 fichas operativas, cuyo extracto se proporciona en el anexo 3."
| Nivel de prueba | Ejemplo | Impacto en la nota |
|---|---|---|
| Ninguna prueba | "Nuestra experiencia nos permite..." | El evaluador ignora — +0 puntos |
| Prueba débil | "Tenemos la costumbre de..." | Señal vaga — +0,5 puntos |
| Prueba contextual | "En un contexto similar (12 000 puestos), resultado: -34% incidentes" | Señal fuerte — +2 puntos |
| Prueba documentada | Dato + referencia + entregable en anexo | Señal máxima — +3 puntos |
A recordar: Genérico + reciclado + sin pruebas = 12/20 garantizado. No es un juicio de valor — es un mecanismo. El evaluador califica lo que ve. Si solo ve ruido, pone la nota media y pasa al siguiente expediente.
Cómo codificar la señal en cada sección
El marco teórico señal/ruido da el "por qué". Aquí viene el "cómo".
La codificación de la señal en una propuesta técnica se basa en un principio: la señal debe sobrevivir a una lectura en diagonal. Porque así es como el evaluador va a leerla. No porque sea negligente, sino porque la restricción temporal le obliga.
Técnica 1: la primera frase de cada sección transmite el mensaje
El evaluador lee sistemáticamente la primera frase de cada sección y subsección. Si su primera frase es "Esta sección presenta nuestro enfoque metodológico" — acaba de desperdiciar el único espacio con lectura garantizada.
Malo: "Esta sección presenta nuestra metodología de gestión de incidentes."
Bueno: "El riesgo principal de su gestión de incidentes no es el volumen — es el plazo de calificación. Nuestra metodología apunta específicamente a esta etapa con un prediagnóstico automatizado que reduce el tiempo de calificación en un 45%."
La primera frase debe ser un concentrado de señal: anuncia su comprensión del problema Y el valor de su respuesta. El resto de la sección desarrolla. Pero si el evaluador solo lee las primeras frases — ya tiene lo esencial.
Técnica 2: las tablas transmiten las pruebas
El ojo del evaluador se siente atraído por las rupturas visuales: títulos, tablas, recuadros, esquemas. Una tabla se lee incluso en modo escaneo. Un párrafo de prosa puede saltarse.
Concentre sus pruebas en tablas. No tablas decorativas — tablas informativas.
| Proceso | SLA contractual | Rendimiento medio (3 últimos contratos) | Herramienta |
|---|---|---|---|
| Calificación incidente P1 | 30 min | 18 min | ServiceNow + prediagnóstico IA |
| Resolución incidente P1 | 4h | 2h14 | Equipo dedicado N2 (3 ingenieros) |
| Resolución incidente P2 | 8h | 5h30 | Rotación N2/N3 |
| Informe mensual | M+5 días hábiles | M+3 días hábiles | Cuadro de mando Power BI |
Esta tabla transmite más señal que dos páginas de prosa. Se lee en 15 segundos. Demuestra en lugar de afirmar. Y sobrevive a la lectura en diagonal.
Técnica 3: la redundancia estratégica de los win themes
Un win theme es un argumento diferenciador que usted quiere anclar en la mente del evaluador. No debe aparecer una sola vez en la propuesta — debe ser declinado en cada sección pertinente, bajo ángulos diferentes.
Si su win theme es "prediagnóstico automatizado", aparece:
- En la comprensión de la necesidad: "El volumen de incidentes no es el problema. El plazo de calificación lo es. El prediagnóstico automatizado reduce este plazo en un 45%."
- En la metodología: descripción técnica del proceso de prediagnóstico, integración con la herramienta ITSM del cliente.
- En los recursos: perfil del ingeniero que configura y mantiene el prediagnóstico, formación del equipo del cliente.
- En los riesgos: "Riesgo identificado: resistencia al cambio del equipo N1 frente al prediagnóstico. Mitigación: acompañamiento durante 3 meses con métricas de rendimiento visibles."
No es repetición. Es redundancia en el sentido de Shannon: un código corrector de errores. Aunque el evaluador solo lea una sección de cuatro, se encuentra con el win theme. La señal pasa a pesar del ruido del canal.
Técnica 4: nombrar los riesgos que nadie nombra
El evaluador ha leído cuatro expedientes. Los cuatro dicen "nuestra metodología probada garantiza una implementación controlada". Ninguno nombra los riesgos específicos de la licitación. El quinto expediente escribe:
"El riesgo principal de esta licitación no es técnico — es la cohabitación entre el antiguo SI (cuyo desmantelamiento está previsto pero no fechado) y el nuevo durante un período de transición que podría durar de 18 a 24 meses. Nuestro plan de mitigación trata específicamente las dependencias aplicativas identificadas en el párrafo 4.3 del pliego de condiciones."
El evaluador posa su bolígrafo. Este candidato ha comprendido algo que los otros no vieron — o no se atrevieron a escribir. Es la misma señal que la de las buenas preguntas en la fase de consultas: demuestra una comprensión que va más allá de la lectura superficial.
A recordar: Codificar la señal no es escribir mejor. Es colocar la información donde el evaluador la busca, en el formato que absorbe, con la prueba que transforma la afirmación en hecho. Primera frase = mensaje. Tabla = prueba. Redundancia = robustez. Riesgo nombrado = diferenciación.
El caso concreto: dos propuestas técnicas para la misma licitación
Licitación de Mantenimiento Correctivo y Evolutivo de Aplicaciones para una metrópoli. Perímetro: 14 aplicaciones de negocio, 8 000 usuarios, entorno Java/Oracle. Presupuesto estimado: 2,5 millones de euros en 4 años. Baremo técnico: 60% de la nota global.
Criterios de evaluación:
- Comprensión del contexto y de los desafíos: 30 puntos
- Metodología y organización: 40 puntos
- Recursos humanos: 30 puntos
Dos licitadores. Mismo tamaño de empresa. Competencias comparables. Referencias similares. La diferencia está en la propuesta.
Licitador A — la propuesta estándar
Estructura: calcada del pliego de condiciones. Cinco grandes partes correspondientes a los cinco dominios funcionales (urbanismo, finanzas, RRHH, GRC, SIG).
Executive summary: "Gracias a nuestra reconocida experiencia en mantenimiento de aplicaciones de negocio para el sector público, nuestro equipo pluridisciplinario se compromete a acompañar a la Metrópoli en la gestión y evolución de su patrimonio aplicativo, con un enfoque estructurado y probado." — 42 palabras, cero información.
Comprensión del contexto: reformulación del pliego. Dos páginas que resumen lo que el cliente escribió, sin análisis, sin identificación de riesgo, sin desafío explicitado. El evaluador lee su propio texto en versión condensada.
Metodología: descripción general del proceso ITIL. Ninguna adaptación al contexto de la metrópoli. El mismo capítulo aparece en las 15 últimas propuestas de la empresa. Algunos esquemas genéricos de procesos.
Recursos humanos: lista de CV. Una tabla de perfiles con años de experiencia y certificaciones. Ninguna explicación de la organización operativa, de la gestión de ausencias, del escalamiento.
Referencias: cuatro logotipos de entidades públicas. Ningún detalle sobre los contextos, los resultados, las dificultades encontradas.
Resultado: 12/20 — Nota detallada: Comprensión 16/30, Metodología 26/40, Recursos 18/30.
Licitador B — la propuesta estratégica
Estructura: calcada del baremo. Tres partes: Comprensión, Metodología, Recursos. Cada dominio funcional se trata como subsección dentro de cada parte.
Executive summary: "Su desafío principal no es el mantenimiento corriente de 14 aplicaciones — es la gestión de la deuda técnica acumulada en los módulos Finanzas y RRHH (Java 8, Oracle 11g) durante el período de transición hacia su futuro SI, cuyo calendario de despliegue aún está por estabilizar. Nuestra respuesta se construye en torno a tres ejes: la aseguración de la continuidad de servicio en los módulos críticos (apartado 2), un plan de reabsorción de la deuda técnica calibrado en 18 meses (apartado 3), y un equipo dimensionado para absorber los picos de carga vinculados a las migraciones aplicativas (apartado 4)." — Específico. Factual. Estructurante.
Comprensión del contexto:
| Desafío identificado | Fuente (apartado del pliego) | Impacto | Nuestra respuesta (apartado de la propuesta) |
|---|---|---|---|
| Deuda técnica Java 8 / Oracle 11g | apartado 3.2.1, apartado 4.1 | Riesgo de fin de soporte del editor Q3 2027 | Plan de migración apartado 3.2 |
| Cohabitación antiguo/nuevo SI | apartado 4.3.2 | Dependencias no documentadas entre 6 módulos | Cartografía apartado 2.3 + hipótesis H-04 |
| Pico de carga en despliegues | apartado 5.1 | 3 períodos críticos identificados (presupuesto, elecciones, inicio de curso) | Dimensionamiento elástico apartado 4.2 |
| Rotación del equipo actual del proveedor | Consulta Q&R #7 | Pérdida de conocimiento de negocio en 3 módulos | Plan de transferencia apartado 4.3 |
Cuatro desafíos. Cuatro fuentes. Cuatro respuestas trazables. El evaluador ve inmediatamente que este candidato ha leído, comprendido y estructurado.
Metodología: proceso ITIL adaptado al contexto. Cada proceso se describe con las especificidades de la licitación: "La calificación de los incidentes en el módulo Finanzas será completada con un prediagnóstico automatizado (reglas de negocio extraídas de la documentación funcional existente) para compensar la falta de documentación técnica identificada en el apartado 3.2.1 del pliego de condiciones." Sin descripción genérica — cada párrafo ancla la metodología en la necesidad.
Recursos humanos: organigrama operativo. Matriz RACI por dominio funcional. Plan de respaldo nominativo (quién sustituye a quién, en qué plazo). Curva de escalamiento durante los 6 primeros meses con los hitos de transferencia de conocimientos. No una lista de CV — un sistema organizativo.
Referencias: dos referencias detalladas. Para cada una: contexto (tamaño, perímetro, tecnologías), dificultad principal encontrada, solución implementada, resultado cuantificado. "Contexto comparable (metrópoli, 11 000 usuarios, Java/Oracle): reducción del 28% del stock de bugs críticos en 12 meses, paso de la tasa de resolución dentro de los SLA del 73% al 94%."
Resultado: 17/20 — Nota detallada: Comprensión 26/30, Metodología 34/40, Recursos 25/30.
Cinco puntos de diferencia. Misma licitación. Mismo perímetro funcional. La diferencia: una propuesta habla del cliente, la otra habla de sí misma.
A recordar: La propuesta a 12/20 no es mala. Es invisible. No le da al evaluador los elementos para poner una buena nota — aunque la solución detrás sea sólida. La propuesta a 17/20 codifica la señal para que sobreviva al escaneo. Cada punto del baremo tiene su sección. Cada afirmación tiene su prueba. Cada riesgo está nombrado.
Lo que hace TenderGraph
TenderGraph no escribe su propuesta técnica. Hace el trabajo que nadie tiene tiempo de hacer — y del que, sin embargo, depende la totalidad de la nota.
Extracción y cartografía de requisitos
El sistema analiza el expediente de licitación completo — pliego de condiciones técnicas, reglamento de consulta, cláusulas administrativas, cuadro de precios, anexos — y extrae cada requisito, cada restricción, cada criterio de evaluación. No por orden de página. Por capa semántica: requisitos funcionales, restricciones técnicas, criterios de evaluación, hipótesis implícitas, zonas de ambigüedad.
El resultado es una cartografía estructurada de la necesidad. El equivalente de dos semanas de trabajo de un bid manager senior — producido en unos minutos, con el rigor de un sistema que no salta párrafos y no sufre de sesgo de recencia.
Alineación baremo-contenido
TenderGraph cruza los criterios de evaluación con los requisitos extraídos y produce una matriz de alineación: para cada criterio del baremo, qué requisitos del pliego están en juego, qué ponderación tienen, y qué densidad de señal debe alcanzar cada sección de la propuesta.
Es la diferencia entre el licitador A (que estructura por intuición) y el licitador B (que estructura por el baremo). El sistema formaliza lo que los mejores bid managers hacen intuitivamente — pero que la presión del calendario impide hacer sistemáticamente.
Concentración de la señal
Para cada sección de la propuesta, TenderGraph identifica los elementos de fuerte señal: las pruebas cuantificadas, las referencias contextuales, los riesgos específicos, los compromisos medibles. Señala las zonas de ruido: los párrafos genéricos, las formulaciones recicladas, las afirmaciones sin prueba.
El bid manager mantiene el control del contenido. El sistema le muestra dónde la señal está concentrada y dónde está diluida — para que pueda asignar su tiempo donde tiene mayor impacto, en lugar de pulir secciones que no pesan nada en el baremo.
Trazabilidad requisito-respuesta
Cada sección de la propuesta está vinculada a los requisitos del pliego que aborda. Si un requisito no está cubierto por ninguna sección, el sistema lo señala. Si una sección no responde a ningún requisito, el sistema también lo señala — probablemente es ruido.
Esta trazabilidad es exactamente lo que el evaluador hace mentalmente cuando califica: busca, para cada criterio, si la respuesta lo aborda. TenderGraph realiza este trabajo antes que él — para que la respuesta ya esté estructurada en el sentido de su lectura.
A recordar: TenderGraph no redacta la propuesta técnica. Construye la armadura sobre la que la propuesta debe construirse: cartografía de requisitos, alineación al baremo, concentración de la señal, trazabilidad. El fondo sigue siendo del experto. La estructura se convierte en la que maximiza la nota. Nuestra visión es que la propuesta técnica no es un ejercicio literario — es un ejercicio de codificación.
Lo que debe recordar
Una propuesta técnica a 17/20 y una propuesta técnica a 12/20 contienen a menudo las mismas ideas, las mismas competencias, la misma solución. La diferencia no está en el fondo — está en la manera en que el fondo está estructurado, codificado y presentado a un evaluador que tiene cinco expedientes que leer en dos días.
Tres principios separan las propuestas que ganan licitaciones de las que "participan":
-
Estructurar en torno al baremo, no al pliego de condiciones. Cada criterio de evaluación = una sección. El evaluador nunca debe tener que buscar.
-
Codificar la señal para que sobreviva al escaneo. Primera frase = mensaje. Tabla = prueba. Redundancia estratégica = robustez. Riesgo nombrado = diferenciación.
-
Demostrar en lugar de afirmar. Cada párrafo contiene un dato, una referencia o un entregable concreto. Las afirmaciones gratuitas no suman puntos — generan ruido.
La propuesta técnica no es un documento que se redacta. Es un sistema que se construye.
Para ir más lejos: descubrir TenderGraph · hablar con nuestro equipo.
Lea también:
- El mito del executive summary — El executive summary es la puerta de entrada de la propuesta técnica. Si es genérico, el resto se lee con un prejuicio negativo.
- Por qué sus referencias de clientes no convencen a nadie — Las referencias en una propuesta técnica no son logotipos. Son pruebas contextuales que validan sus afirmaciones.
- Lo que el pliego de condiciones no dice — La propuesta técnica que solo aborda lo que está escrito en el pliego deja de lado lo que hace ganar la licitación.
- La revolución informacional: señal y ruido — El marco teórico detrás de la codificación de la señal: Shannon aplicado al bid management.
- El peor enemigo del bid manager: él mismo — Los sesgos cognitivos que producen propuestas técnicas genéricas: recencia, anclaje, completitud.
- La aceleración de los ciclos de preventa — El tiempo liberado por la automatización debe reinvertirse en la construcción de la señal, no en la producción de volumen.