Para qué sirve realmente un pliego de condiciones
Un pliego de condiciones no es un documento administrativo destinado a obtener tres presupuestos comparables. Es la herramienta que transforma una intención difusa en un proyecto ejecutable, y sirve tanto a quien lo redacta como a quien lo recibe.
Por parte de la empresa, el ejercicio obliga a decidir sobre cuestiones que, si se dejan abiertas, resurgirán en el peor momento. Quién valida. Quién proporciona los textos. Qué pasa si los contenidos llegan con seis semanas de retraso. Estas decisiones cuestan media jornada de reflexión previa y varias semanas de deriva cuando se eluden.
Por parte del proveedor, un pliego de condiciones preciso permite presupuestar correctamente. Un brief vago produce o bien un presupuesto inflado por el margen de incertidumbre, o bien un presupuesto bajo seguido de una serie de anexos. En ambos casos, el cliente paga la imprecisión, simplemente en momentos diferentes.
Un pliego de condiciones útil tiene entre ocho y quince páginas. Más allá de eso, se convierte en un documento que nadie vuelve a leer y que pierde su función contractual. Por debajo de cinco, deja demasiadas zonas grises para servir de referencia en caso de desacuerdo.
El documento no necesita estar escrito por un técnico. Debe describir lo que la empresa quiere obtener, no cómo construirlo. Un cliente que impone una tecnología en su pliego de condiciones se priva del asesoramiento que viene a buscar, y a veces se encuentra con una solución inadecuada que el proveedor ha ejecutado al pie de la letra.
Las doce secciones de un pliego de condiciones completo
La estructura a continuación cubre tanto proyectos de web corporativa como de tienda online. No todas las secciones tienen el mismo peso, pero ninguna puede eliminarse sin crear una zona de incertidumbre.
- Presentación de la empresa. Actividad, mercado, cliente tipo, posicionamiento de precios, competidores identificados. Lo que el proveedor no puede adivinar.
- Objetivos del proyecto. Formulados como resultados esperados, no como funcionalidades. «Recibir solicitudes de presupuesto cualificadas» en lugar de «tener un formulario».
- Público objetivo. Quién visita la web, con qué nivel de conocimiento del tema, desde qué dispositivo, en qué momento del proceso de compra.
- Alcance funcional. La lista de funciones esperadas, clasificadas entre indispensables, deseables y fuera de alcance. Esta última columna es la más útil.
- Arquitectura de información provisional. La lista de páginas y su jerarquía. Evolucionará, pero fija el orden de magnitud.
- Contenidos. Quién proporciona los textos, las fotos, los vídeos. En qué fecha. Lo que ya existe y lo que queda por producir.
- Identidad visual. Identidad existente o por crear, elementos impuestos, webs de referencia que gustan y que no gustan, con los motivos.
- Limitaciones técnicas. Alojamiento impuesto, herramientas a conectar, software de gestión, normativas legales del sector.
- Requisitos de rendimiento y accesibilidad. Umbrales cuantificados y verificables en lugar de «la web debe ser rápida».
- Posicionamiento SEO. Palabras clave objetivo, zonas geográficas, idiomas, existencia de una web a migrar.
- Planificación e hitos. Fecha de lanzamiento deseada, limitaciones de calendario, plazos de validación por parte del cliente.
- Presupuesto y modalidades. Presupuesto total o rango de precios, calendario de pagos, qué se incluye tras la entrega.
Dos secciones merecen un desarrollo especial, porque casi siempre se descuidan y concentran la mayoría de los litigios.
El alcance funcional y su columna «fuera de alcance»
Listar lo que la web hará es natural. Listar lo que no hará lo es mucho menos y, sin embargo, es lo que protege a ambas partes. Escribir negro sobre blanco que el área de cliente, el multilingüismo o la conexión con el software de gestión no forman parte de la primera versión evita la conversación penosa del tercer mes.
La clasificación en tres niveles funciona mejor que una lista plana. Lo indispensable condiciona el lanzamiento. Lo deseable se trata si el presupuesto lo permite y se presupuesta por separado. Lo que está fuera de alcance se pospone explícitamente. Esta jerarquía permite decidir durante el proyecto sin renegociar todo el conjunto.
Los contenidos, primer factor de retraso
En los proyectos que descarrilan, la causa rara vez es técnica. Casi siempre es editorial: los textos no están listos. Una empresa subestima sistemáticamente el tiempo que representa la redacción de veinte páginas, porque esta tarea recae en personas que ya tienen un trabajo a tiempo completo.
El pliego de condiciones debe, por tanto, nombrar a un responsable de contenidos, fijar una fecha de entrega por lotes y especificar qué sucede en caso de retraso. Existen dos opciones: el proveedor entrega con contenido provisional y factura una intervención posterior, o el proyecto se suspende y se aplaza el calendario. Elegir de antemano evita debatirlo bajo tensión.
La identidad visual descrita con ejemplos en lugar de adjetivos
«Moderno», «minimalista», «profesional» no transmiten ninguna información útil. Estas palabras significan cosas opuestas según el interlocutor, y un proveedor que las recibe diseña lo que a él le gusta, lo que garantiza dos rondas de corrección improductivas.
El método que funciona consiste en citar tres webs que te gusten y tres que no, explicando por qué en una frase. «Me gusta la sobriedad de esta, pero las fotos son demasiado frías» transmite más información que diez adjetivos. Las webs citadas no tienen por qué ser del mismo sector; sirven de referencia estética y no de modelo a copiar.
También hay que especificar lo que es obligatorio: logotipo existente, colores de marca, tipografía con licencia, elementos de identidad impresa a respetar. Un proyecto donde el logotipo debe rediseñarse a mitad de camino cambia de naturaleza, y esta posibilidad merece estar abierta desde el principio si la marca es antigua.
Lo que hay que cuantificar en lugar de describir
La diferencia entre un pliego de condiciones vago y uno útil suele residir en la sustitución de adjetivos por números.
«La web debe ser rápida» no significa nada y no se puede verificar. «La web debe alcanzar una puntuación Lighthouse superior a 90 en ordenador y 85 en móvil, y superar los tres umbrales de los Core Web Vitals en las plantillas principales» se mide el día de la aceptación. Es el compromiso que asumimos en nuestras entregas, y solo tiene valor porque es verificable.
El mismo razonamiento se aplica al resto. Un plazo de respuesta máximo para las solicitudes de modificación. Un número de ciclos de corrección incluidos en los diseños, generalmente dos. Una duración de la garantía tras el lanzamiento. Un volumen de formación para el manejo. Cada una de estas líneas evita una discusión.
El apartado de SEO, el que todo el mundo olvida
Un pliego de condiciones que trata el SEO en una sola línea produce una web que habrá que rehacer. Deben figurar tres elementos, y estos determinan decisiones estructurales imposibles de corregir a posteriori.
La arquitectura y las palabras clave objetivo
La estructura de las URL, la profundidad de las páginas y la distribución de los temas se deciden antes del primer diseño. Una web diseñada en torno al organigrama de la empresa en lugar de las intenciones de búsqueda de sus clientes empieza con una desventaja que ninguna optimización posterior corrige por completo.
El pliego de condiciones debe, por tanto, listar las palabras clave principales y indicar qué página las trata. Es el punto de partida de la arquitectura descrita en nuestro artículo sobre el clúster semántico, y hacerlo en este momento cuesta unas pocas horas frente a varios días de correcciones más tarde.
La migración, si ya existe una web
Rehacer una web que tiene un historial requiere un plan de redirecciones. Cada URL de la web antigua debe redirigirse a su equivalente más cercano; de lo contrario, la nueva web empieza de cero en términos de autoridad. Esta tarea debe aparecer en el pliego de condiciones con un responsable identificado, porque se olvida regularmente y se descubre tres semanas después del lanzamiento, cuando el tráfico se ha desplomado.
El documento también debe especificar quién proporciona la lista de URL existentes y quién verifica las redirecciones tras el cambio. Es uno de los puntos que tratamos sistemáticamente en un rediseño de sitio web, y uno de los pocos donde un error produce una pérdida inmediata y medible.
El SEO local, cuando la zona importa
Una empresa cuyo público es geográfico debe decirlo en su pliego de condiciones, porque eso cambia la arquitectura, el etiquetado y el contenido esperado. Las páginas por zona, la declaración del establecimiento y la estrategia de reseñas se preparan desde el diseño, como se detalla en nuestra guía de SEO local.
Las obligaciones legales y la accesibilidad
Una web profesional conlleva obligaciones que el pliego de condiciones debe nombrar, porque se traducen en trabajo real. Aviso legal, política de privacidad, condiciones generales si la web vende, gestión del consentimiento de cookies conforme al reglamento europeo, registro de actividades de tratamiento si se recogen datos personales.
El banner de consentimiento merece especial atención. Una implementación descuidada bloquea las herramientas de medición o, por el contrario, instala cookies antes de la aceptación, lo que expone a la empresa. Además, degrada el CLS y, por tanto, el rendimiento medido, lo que lo convierte en un tema tanto jurídico como técnico.
La accesibilidad avanza en las obligaciones normativas según el tamaño de la empresa y su sector. Incluso fuera de cualquier limitación legal, respetar los contrastes mínimos, la navegación por teclado y los textos alternativos mejora la experiencia de todos los visitantes y se gestiona mucho más fácilmente en el diseño que como corrección posterior.
Las seis trampas que hacen descarrilar un proyecto
Nueve años de proyectos resaltan siempre las mismas causas de deriva. Ninguna es técnica.
El circuito de validación no definido
Cuando nadie tiene formalmente la última palabra, cada diseño vuelve con las opiniones contradictorias de cuatro personas. El proveedor decide a ciegas, el cliente no está satisfecho con nada y el proyecto se estanca. Nombrar a un único responsable de la toma de decisiones, aunque este consulte a otros, soluciona este problema por sí solo.
El alcance que se expande en silencio
Cada solicitud tomada por separado parece mínima. Sumadas, veinte solicitudes mínimas representan una semana de trabajo no prevista. La solución no es rechazar los cambios, sino registrarlos: cada solicitud fuera de alcance se presupuesta y se valida antes de ejecutarse, incluso cuando se ofrece de forma gratuita.
La confusión entre gusto personal y eficacia
«No me gusta el azul» es una opinión legítima. «Nuestros clientes no harán clic en este botón» es una hipótesis verificable. Un pliego de condiciones que expresa objetivos medibles permite centrar las discusiones sobre el diseño en el terreno de la eficacia en lugar del de la preferencia.
La ausencia de una aceptación formal
Sin un procedimiento de validación final, el proyecto nunca termina realmente. Una aceptación por escrito, listando los puntos a verificar y los criterios de aceptación, marca el fin de la fase de producción y el inicio de la garantía. Sin ella, la frontera entre corrección de errores y evolución de pago sigue siendo difusa para ambas partes.
La cuestión de la propiedad eludida
A quién pertenece el código, los diseños, el nombre de dominio, las cuentas de alojamiento y de analítica. La respuesta debe estar por escrito. Un cliente que descubre después de dos años que su dominio está registrado a nombre de su antiguo proveedor descubre también su nulo poder de negociación.
Los accesos no recopilados al inicio
Nombre de dominio, alojamiento, correo electrónico, cuentas de medición, redes sociales, plataformas de reseñas: un proyecto empieza necesitando de seis a diez accesos, y siempre faltan al menos dos. El titular es a veces un antiguo empleado, a veces un proveedor anterior con quien la relación terminó mal.
Recuperar un acceso perdido lleva entre dos días y tres semanas según el servicio, y esta búsqueda se activa casi siempre en el peor momento, el día antes del lanzamiento. Un anexo al pliego de condiciones listando cada acceso, su titular y su estado de disponibilidad evita este bloqueo. Es una página por rellenar que te hace ganar una semana.
El post-lanzamiento olvidado
Una web no está terminada el día de su entrega. Actualizaciones, copias de seguridad, monitorización, correcciones: estas tareas existen, alguien debe realizarlas y eso tiene un coste. El pliego de condiciones debe especificar si están incluidas, por cuánto tiempo y qué cubre exactamente un posible contrato de mantenimiento.
Lo que el pliego de condiciones debe decir sobre la planificación
Una fecha de lanzamiento deseada no es suficiente. Lo que realmente estructura el calendario son los plazos de validación por parte del cliente, casi siempre subestimados.
Un proyecto de web corporativa se produce en tres a cinco semanas de trabajo efectivo por parte de la agencia. Sin embargo, frecuentemente se alarga tres meses, porque entre cada etapa se intercala una fase de validación que depende de la disponibilidad de un directivo ocupado. Un diseño enviado un viernes y validado diez días después, repetido cuatro veces, añade seis semanas al calendario sin que el trabajo haya avanzado.
El pliego de condiciones debe, por tanto, comprometer al cliente tanto como al proveedor: un plazo máximo de respuesta para cada entrega, generalmente cinco días hábiles, y la consecuencia de un retraso. La mayoría de los contratos prevén un aplazamiento del calendario proporcional al retraso, lo cual es justo y, sobre todo, disuasorio.
Las limitaciones reales del calendario merecen ser nombradas: ferias profesionales, estacionalidad de la actividad, fin de un contrato de alojamiento, lanzamiento de producto. Una fecha arbitraria moviliza recursos innecesariamente; una fecha justificada permite organizar el trabajo en torno a ella. Una web turística que debe estar lista antes de la temporada no tiene el mismo margen que una web institucional sin fecha límite.
Pliego de condiciones y presupuesto, cómo articularlos
Dos escuelas se enfrentan. Anunciar el presupuesto ya en el pliego de condiciones, o guardárselo para comparar las propuestas. La segunda es intuitiva, la primera es más eficaz.
Un proveedor que conoce el presupuesto puede proponer la mejor solución para ese nivel de precio, decidir entre funciones y señalar francamente si el alcance solicitado es inalcanzable. Un proveedor que no lo conoce propone al azar, y el cliente compara ofertas que no cubren los mismos alcances, lo que hace que la comparación sea inútil.
Anunciar un rango de precios en lugar de una cifra exacta preserva el margen de negociación a la vez que encuadra la respuesta. Para situar los órdenes de magnitud antes de redactar, nuestro simulador de precios de sitios web ofrece una estimación en pocos minutos, y el artículo sobre cuánto cuesta una página web en 2026 detalla qué cubre cada partida.
Un último punto sobre la comparación de presupuestos. El precio por sí solo no dice nada si el alcance no es idéntico. Un presupuesto de dos mil euros que excluye la redacción, las fotos, la migración y el mantenimiento sale más caro que uno de tres mil quinientos que los incluye. Comparar supone llevar cada propuesta al mismo alcance, ejercicio que el pliego de condiciones hace posible.
Las especificidades de los proyectos de tienda online
Una web de venta añade una capa de complejidad que el pliego de condiciones debe anticipar; de lo contrario, el presupuesto inicial se superará en un cincuenta por ciento.
Primero, el catálogo. Cuántas referencias, cuántas variantes por referencia, de dónde vienen las fichas de producto y las imágenes, existe un archivo exportable desde el software de gestión. Una carga manual de ochocientos productos representa varias semanas de trabajo, una partida que nunca aparece en los presupuestos de desarrollo.
Después, las reglas comerciales. Gastos de envío por zona y peso, umbrales de envío gratuito, descuentos por cantidad, códigos promocionales, gestión de impuestos según el país de entrega. Cada una de estas reglas es sencilla por separado, pero su combinación representa la mayor parte de la carga de configuración.
Finalmente, las conexiones. Pasarela de pago, transportistas, software de gestión de stock, herramienta contable, plataforma de reseñas. Cada conexión supone una interfaz técnica disponible y documentada por parte del servicio externo, lo cual no siempre es el caso. El pliego de condiciones debe listar estas herramientas por su nombre, no por su función, y especificar quién proporciona los accesos. Estas decisiones también condicionan la elección de la plataforma, tema que tratamos en el apartado de creación de sitios e-commerce.
Una estructura directamente reutilizable
El documento puede construirse en cualquier procesador de textos. Su forma importa poco, su estructura es lo que cuenta.
Empieza con una página de contexto: quién eres, qué vendes, a quién. Continúa con una página de objetivos formulados como resultados, con un indicador por objetivo si es posible. Dedica después dos o tres páginas al alcance funcional en tres columnas: indispensable, deseable, excluido.
Reserva una página para la arquitectura, en forma de lista con sangría en lugar de un esquema. Una página para los contenidos, con la tabla de responsabilidades y fechas. Una página para la identidad visual, citando tres webs que te gusten y tres que no, con una frase de explicación para cada una: esta sección vale más que diez adjetivos.
Termina con las limitaciones técnicas, los requisitos cuantificados, el apartado de SEO, la planificación y el presupuesto. Añade un anexo listando los accesos existentes y sus titulares; te hará ganar una semana al empezar.
Un consejo sobre la difusión. Enviar el mismo documento a cinco proveedores es legítimo, pero lee las preguntas que te hagan. El que responda con un presupuesto sin hacer preguntas probablemente no ha leído el documento o no tiene intención de discutir el alcance. Las preguntas que hace un proveedor dicen más sobre su nivel que su folleto. Puedes juzgar el nuestro echando un vistazo a nuestros trabajos.
Una palabra final sobre en qué se convierte el documento tras la firma. Demasiados pliegos de condiciones desaparecen en una carpeta el día que empieza el proyecto, cuando deberían ser la referencia común en caso de desacuerdo. Mantenerlo abierto, anotarlo en cada decisión y hacerlo evolucionar mediante anexos en lugar de por correo electrónico preserva su valor hasta la aceptación final.
Lo que debes recordar
Un pliego de condiciones sirve para decidir antes de gastar. Las preguntas que plantea (circuito de validación, responsable de contenidos, alcance excluido, propiedad de los entregables) son exactamente las que hacen descarrilar los proyectos cuando se quedan sin respuesta.
Tres secciones marcan la diferencia entre un documento útil y uno de compromiso. El alcance con su columna de exclusiones, que protege a ambas partes. Los contenidos con su calendario y su responsable, porque ahí es donde nacen los retrasos. Los requisitos cuantificados, porque un compromiso que no se mide no se puede exigir.
El resto se escribe en unas pocas horas y se lee en veinte minutos. No es una inversión pesada; es el único momento del proyecto donde corregir un error no cuesta nada.
