Cómo redactar un RFP de software que atraiga al proveedor adecuado

Una request for proposal (RFP) de software es un documento que da a los proveedores los detalles para cotizar con precisión y para autoexcluirse cuando no encajan. Bien escrito, reduce la shortlist de veinte respuestas ruidosas a cuatro serias. Mal escrito, hace perder seis semanas y produce propuestas que no se pueden comparar.

La parte difícil no es el formato. Es hacer explícitas las restricciones. El 73% de las descalificaciones en RFP se debe a un alcance mal alineado o a respuestas de alcance incompletas. No es un problema de los proveedores. Es el brief que deja margen para interpretar.

Esta es la estructura en 8 secciones que usamos cuando un cliente pregunta cómo escribir un RFP que filtre pronto, evalúe de forma justa y termine en un contrato en lugar de en otra ronda de llamadas de aclaración.

Para qué sirve realmente el RFP

Un RFP sirve a tres destinatarios a la vez: tú, los stakeholders internos y los proveedores. A ti te obliga a alinear producto, ingeniería, finanzas y legal antes de que ningún proveedor lo lea. A los stakeholders les da una comparación homogénea. A los proveedores les dice si pujar con atención plena, declinar con educación o cuestionar las suposiciones.

Si basta una página para hacer esas tres cosas, no necesitas un RFP. Mándala a cuatro estudios y reserva las llamadas. El RFP existe porque la mayoría de proyectos de software implican compliance, integraciones, soporte plurianual o presupuestos que requieren procurement, y el documento es el artefacto que sobrevive a los cambios de equipo durante el ciclo de compra.

Las 8 secciones que filtran

1. El problema, no la solución

Abre con el problema de negocio en lenguaje llano: a quién afecta, con qué frecuencia, cuánto te cuesta hoy. Resiste la tentación de especificar la solución. Los proveedores capaces de proponer un enfoque mejor solo lo mostrarán si les dejas espacio. Los proveedores que copian tu solución prescrita en la propuesta se autoseñalan como mal encaje.

Una frase concreta por problema. "El equipo de finanzas concilia 40.000 transacciones al mes entre tres procesadores de pago a mano, tarda 12 días laborables y produce un 3% de errores" es útil. "Necesitamos agilizar la conciliación" no.

2. Dentro y fuera del alcance

Lista los entregables in-scope como sustantivos. Luego lista los puntos explícitamente fuera de alcance: migración de datos legacy más allá de una fecha límite, apps nativas móviles, reporting custom, integraciones de terceros no nombradas. La lista fuera de alcance filtra más que la de dentro de alcance, porque mata las propuestas "sí a todo" que parecen generosas hasta que lees la cláusula de change order.

El scope creep es el principal reto de proyecto para el 59% de los proveedores según datos sectoriales de DesignRush, y la brecha suele abrirse en la tercera semana. Cerrarla en el RFP cuesta diez líneas más y te salva un cuarto de margen.

3. Restricciones: presupuesto, plazos, fecha de decisión

Indica un rango de presupuesto, no un techo. "180k-240k USD para la fase uno" dice a un proveedor serio si pujar; "competitivo" le dice que no has hecho los deberes. Los presupuestos ocultos se correlacionan con desvíos de coste y plazo: cuando presupuesto y timeline se ocultan, los proyectos salen tarde y caros casi a cara o cruz.

Indica una fecha de decisión. Los proveedores cotizan distinto una selección de 4 semanas que una de 10, porque la segunda devora horas de business development. Indica una fecha objetivo de inicio. Indica el sponsor del proyecto y quién firma.

4. Requisitos no funcionales

Aquí la mayoría de RFP pierden fuelle. Especifica lo que convierte el proyecto de "construirlo" en "construirlo para producción":

• Usuarios concurrentes, pico y media
• Tiempo de respuesta P95 por clase de endpoint
• Uptime objetivo y ventanas de mantenimiento que cuentan contra el uptime
• Residencia de datos, retención y plazos de borrado
• Expectativas sobre audit log y observabilidad
• Objetivos de recovery point y recovery time

Un proveedor que cotiza un número en contradicción con estas restricciones (por ejemplo regiones cloud compartidas cuando exigiste residencia UE) se autoexcluye en la primera revisión.

5. Integraciones y sistemas existentes

Nombra cada sistema que el nuevo software debe tocar: proveedor de identidad, billing, CRM, data warehouse, analytics, la base de datos legacy que nadie quiere tocar pero de la que todos dependen. Incluye números de versión y modelos de autenticación. Para cada integración, di si el conector lo construye el proveedor, tu equipo, o si os encontráis a medio camino en un contrato API.

Cuando esta sección es vaga, dos proveedores construyendo lo mismo lo cotizan a tres veces de distancia. Cuando es específica, comparas dos números que significan lo mismo.

6. Seguridad y compliance

Los no negociables en 2026: SOC 2 Type II de los últimos 12 meses, condiciones GDPR de tratamiento de datos, cifrado en reposo y en tránsito, plan de incident response, y un software bill of materials por cada dependencia que el proveedor introduzca. Los add-on sectoriales se suman: HIPAA para healthcare, PCI-DSS para datos de tarjeta, ISO 27001 para procurement enterprise.

Lista las certificaciones como líneas individuales, no en un párrafo. Los proveedores que no pueden marcarlas todas no te hacen perder el tiempo discutiendo el mérito.

7. Equipo y modelo de entrega

Pide los nombres de las personas que trabajarán en el proyecto: lead de ingeniería, diseñador, PM. Pide el porcentaje de su tiempo comprometido. Pide el banquillo por si alguien se va. Este requisito por sí solo filtra a los estudios que firman con seniors y entregan con juniors.

Pide el modelo de entrega: precio cerrado, time and materials, equipo dedicado o staff augmentation. Pide la cadencia: ceremonias, demos y el artefacto que recibes al final de cada sprint o milestone.

8. Criterios de evaluación con pesos

Publica la rúbrica de scoring dentro del RFP. Una ponderación típica para una build SaaS: fit funcional 30-35%, seguridad y compliance 20-25%, precio 20-25%, viabilidad y referencias del proveedor 15%, fit cultural y proceso de entrega 10%. Ajusta por tipo de proyecto, no por humor.

La rúbrica publicada hace dos trabajos. Obliga a los proveedores a invertir donde cuenta (un proveedor que sabe que el precio pesa el 25% no intenta ganar solo por precio). Y disciplina a tu equipo de evaluación a medir lo mismo de la misma forma. Los criterios de evaluación estandarizados se correlacionan con precios un 23-31% mejores y ciclos de procurement un 28-35% más cortos.

Qué dejar fuera

Tres categorías de contenido desperdician páginas y pierden la atención de los proveedores.

Marketing sobre tu empresa. Dos frases de contexto bastan. Los proveedores te investigan en 30 segundos si les interesa.

Dictar la solución. Todo lo que diga "el sistema debe usar React" o "debe correr en AWS" sin una razón de negocio. Escribe la restricción detrás de la restricción (skills del equipo interno, infraestructura existente, exigencia de compliance) y deja que el proveedor acepte o lo cuestione.

500 preguntas sí o no de compliance. Las checklists largas parecen rigurosas pero premian a los proveedores con los equipos de propuesta más grandes, no a los que mejor encajan. Elige 20 preguntas que importen. Puntúalas.

Qué longitud debe tener

El punto justo para una build SaaS de tamaño medio son 8-15 páginas de cuerpo, con apéndices para wireframes, esquemas de data model y fichas detalladas de compliance. Por debajo de 6 páginas estás mandando vibras. Por encima de 30 estás filtrando a proveedores especializados en escribir propuestas, no en entregar software.

Distribución y shortlist

Manda el RFP a una shortlist de 4-6 proveedores. Las pujas públicas atraen 20 o más respuestas y consumen dos semanas de evaluación antes de la primera llamada. Una pre-shortlist (llamada de descubrimiento pagada con 8 proveedores, RFP a 4) casi siempre produce un campo mejor que una puja abierta.

Da una ventana de respuesta de 3-4 semanas. Más corta señala que no respetas el proceso del proveedor. Más larga deja que el proyecto se desplace por tu lado.

Cuando llegan las propuestas

Evalúa de forma independiente antes de comparar notas. La puntuación en grupo en la mesa converge en la voz más alta, no en el mejor encaje. Cada evaluador puntúa contra la rúbrica publicada, luego el grupo reconcilia los outliers con una justificación escrita.

Haz las llamadas de referencias antes de la demo, no después. Las referencias al final del proceso son una formalidad; al inicio son un filtro. Pide una referencia que terminara mal y qué aprendieron. Los proveedores que saben responder a esa pregunta son los que tomar en serio.