Cómo preparar una web para un cliente: guía para agencias

Por qué conviene preparar la información antes de presupuestar

Cuando un cliente dice que quiere una web nueva, normalmente todavía no está describiendo un proyecto. Puede necesitar captar contactos, explicar una propuesta compleja, vender, publicar contenidos, integrar un CRM o reemplazar un sitio que ya posiciona. Cada caso exige decisiones y esfuerzo distintos.

Una web puede parecer una landing sin misterio hasta que aparecen tres idiomas, un CRM, una campaña con fecha cerrada y la condición de no perder lo que ya funcionaba en Google. No es un drama: solo conviene saberlo antes de dar un precio.

La agencia suele tener muy claro el posicionamiento, la marca y la relación con el cliente. Preparar esa información permite trasladar el contexto al equipo de desarrollo sin convertir a nadie en técnico. Así se puede decidir qué hay que construir, qué conviene validar primero y qué preguntas siguen abiertas.

El objetivo no es cerrar todos los detalles antes de hablar con desarrollo. Es evitar presupuestar a ciegas una lista de páginas y descubrir después que faltaban idiomas, contenido, integraciones, migración, permisos o un proceso de aprobación.

Qué información necesita desarrollo para presupuestar una web

No hace falta un documento interminable. Estas son las piezas que más cambian el alcance de una web y que conviene recoger antes de pedir una propuesta:

Plantilla para preparar un proyecto web con el cliente

Puedes copiar esta estructura en Notion, Google Docs o en el documento que uses con tus clientes. No rellenes huecos con suposiciones: marca lo que aún debe decidirse y quién lo decide.

1. Proyecto en una frase: qué empresa es, qué cambia y por qué se hace ahora.
2. Objetivo principal: una acción concreta que debe completar la persona usuaria, por ejemplo solicitar una demo, reservar, comprar o contactar.
3. Público: a quién habla la web, qué problema tiene y qué información necesita antes de actuar.
4. Oferta y mensajes: servicios o productos prioritarios, diferenciadores demostrables y afirmaciones que no se deben hacer.
5. Estructura: secciones, tipos de página y contenidos imprescindibles. No hace falta cerrar el mapa del sitio si aún se va a trabajar.
6. Diseño: enlace a Figma, guía de marca, referentes y qué se quiere tomar de cada referencia. Indica qué pantallas no están diseñadas.
7. Funcionalidad: formularios y su destino, CRM, newsletter, analítica, pagos, reservas, áreas privadas, idiomas o cualquier sistema existente.
8. SEO y web actual: dominio, CMS, URLs que deben mantenerse, redirecciones necesarias, contenido que se reutiliza y accesos disponibles.
9. Personas y proceso: quién aprueba diseño, contenido y desarrollo; cómo se recoge feedback y qué canal se usa para el día a día.
10. Plazo, presupuesto y fases: fecha relevante, presupuesto orientativo, dependencias y qué se puede dejar fuera de la primera entrega.
11. Criterios de aceptación: qué tiene que ocurrir para considerar que cada parte está lista, incluido el lanzamiento y la entrega de accesos.

Lo que no hace falta definir para pedir una buena propuesta

No necesitas decidir el framework, escribir una especificación técnica completa ni dibujar cada estado de cada pantalla. Tampoco hace falta jugar a adivinar si algo va en React, WordPress o una servilleta. Son decisiones que conviene tomar junto a quien va a construir el proyecto, con el problema y las restricciones delante.

Tampoco ayuda poner una fecha fija y pedir después que se descubra qué cabe dentro. Si hay una campaña, un evento o un lanzamiento que no se puede mover, inclúyelo como condición. El equipo técnico podrá proponer qué debe entrar en la primera fase y qué conviene aplazar.

Un buen partner no debería usar la información que falta para facturar sorpresas. Debería señalarla, separar lo confirmado de lo pendiente y explicar qué cambio de alcance supondría cada decisión.

Cuatro errores que encarecen un proyecto web

• Confundir una referencia visual con una definición funcional. Una web puede parecer sencilla y tener flujos complejos detrás.
• Dejar el contenido y los idiomas para el final. Deciden navegación, componentes, espacio, SEO y calendario.
• Tratar el formulario como un detalle. No es decoración al final de la página: hay que saber qué datos pide, a dónde llegan, quién los atiende y qué ocurre si falla.
• Hablar de SEO solo al final. Si se sustituye una web existente, las URLs, los contenidos y las redirecciones se revisan antes de publicar.

Si el cliente ya tiene una web que genera tráfico, el desarrollo debe contemplar la migración desde el principio. Google recomienda planificar los cambios de URL y mantener redirecciones para ayudar a trasladar las señales de la web anterior.

Cuándo incorporar al partner técnico

El mejor momento es antes de presentar una propuesta cerrada al cliente. Con la información suficiente, la agencia puede contrastar viabilidad, riesgos y fases; después presenta una solución que puede cumplir sin diluir su papel estratégico.

NodraLabs trabaja como equipo de desarrollo externo para agencias de marketing y como partner técnico para agencias. La agencia mantiene su relación, estrategia y marca; nosotros ayudamos a convertir esa información en una web que se pueda diseñar, construir, medir y mantener.

Si tu agencia trabaja especialmente con identidad y diseño, también puedes contar con desarrollo que respete esa parte en proyectos para estudios de branding y diseño.