Auditoría: el estado actual

Panavisión es un operador con 40 años, catálogo en 6 continentes y una huella digital que no refleja nada de eso. El producto existe; la autoridad digital, no.

01 Los 4 datos demoledores

02 Problemas técnicos del sitio actual

Crawl completo de mayo 2026 — 1.995 páginas rastreadas.

03 Estructura del sitio actual

04 Análisis competitivo

El mercado español de circuitos organizados es competitivo pero no está saturado para operadores de calidad. Catai es el benchmark premium; Pepetours, el referente en facetado y conversión.

Competidores ciegos = sitio en primera línea

• Mapatours bloquea sus URLs en robots.txt
• Catai no usa schema.org
• Ningún operador español defiende Pinterest ni el turismo religioso en SEO

05 Redes sociales: warm but starved

06 Las 3 ventanas que se cierran en 2026

De una web a un ecosistema digital

No es solo un sitio mejor: es un punto único de contacto B2B y B2C que acompaña al viajero en todo su ciclo de vida — descubrir, decidir, reservar, viajar y volver.

01 Las cinco oportunidades

Cada interacción del viajero es una oportunidad. El proyecto las ordena en cinco frentes:

02 Tres patas

03 Transformación digital

• Automatización de procesos: más trabajo, más rápido, menos errores.
• Monitorización de la competencia: auto-análisis de newsletters, precios y contenidos.
• Centralita virtual con IA: al entrar la llamada, reservas ya sabe quién llama — presupuestos abiertos, visitas web, antigüedad y margen del producto.
• Reserva multicanal: web, WhatsApp y ChatGPT.
• Asistencia IA: cotizaciones de grupo, reclamaciones, documentación, seguros y visados.
• Motor de entrevistas por IA: ayuda a los especialistas de producto a descubrir factores diferenciadores.
• Voice of Customer: NPS por email con síntesis por IA, viaje a viaje.

04 La capa digitalizadora

Una capa común que conecta y da inteligencia a todos los sistemas de negocio — no solo la web:

La Fase 1 entrega la Web y el CMS; el resto de la capa se incorpora por módulos en el horizonte 2027.

05 Palancas de negocio

El proyecto propuesto

No es un rediseño. No es repintar 599 páginas. Es construir un grafo semántico de descubrimiento de viajes, generado combinatoriamente desde el catálogo que ya existe.

01 La tesis: de catálogo a autoridad de categoría

• Modelo entitario: cada destino, experiencia, estilo y temporada es un nodo enlazado
• Páginas SEO generadas combinatoriamente desde el catálogo que ya tienes
• Schema.org en cada producto, destino y FAQ → rich results en Google
• Datos limpios y estructurados → tu marca cita-able por ChatGPT, Perplexity y Gemini

02 El grafo de 9 ejes

Hoy: 1 eje (geografía). El viajero que busca "15 días easy-going en otoño" no encuentra nada. Mañana: 9 ejes que se cruzan, y cada cruce es una landing.

03 Inventario Fase 1: ~407 páginas profundas

04 3 monopolios SERP casi vacíos

05 Land grab: ganar el SERP esta temporada

06 El próximo Google ya se está indexando

ChatGPT, Perplexity, Google AI Overviews y Gemini citan páginas que entienden: con entidades claras, datos estructurados y FAQ explícitos.

07 Resumen: lo que cambia y lo que no

Análisis basado en 4.878 páginas (1.995 .es + 1.994 .com + 889 .com.br), 35 ficheros JavaScript auditados y 1.741 ficheros HTML analizados.

Plan de proyecto

10 sprints de 15 días, del 16 de junio al 15 de noviembre de 2026 (~5 meses). Cada sprint cierra con un entregable concreto; cada fase, con una puerta de aprobación del cliente.

01 Los 10 sprints

· Cronograma (Gantt)

02 Gates y puertas de aprobación

Cada fase termina con un gate de aprobación del cliente. Sin sorpresas a final de proyecto. La producción de contenido corre en paralelo y continúa post-launch.

03 Dependencias clave

04 Riesgos y mitigación

05 El middleware adelanta a Fase 1

Construir la capa middleware desde el principio desacopla el frontend del backend Java: las fases 2–6 se desarrollan contra respuestas mock sin depender del equipo Java de Panavisión.

06 Reunión obligatoria · Sprint 1, Semana 1

Para arrancar el middleware necesitamos alinear con el equipo técnico de Panavisión. Agenda mínima:

1. ¿Puede el middleware hacer peticiones al servidor hornet.panavision.es?
2. ¿Hay allowlist de IPs necesaria (WAF / Cloudflare en su lado)?
3. ¿Cuál es el charset real de las respuestas? (sospechamos ISO-8859-1)
4. ¿Existe documentación de los 14 endpoints /rol2/?
5. ¿El servidor de producción es distinto de hornet?
6. ¿Hay un staging Java donde probar sin tocar producción?

Stack técnico

Simple, propio, sin candados. Todo self-hosted en tu servidor, sin licencias, sin Issuu, sin SaaS creep. Coste de infraestructura por debajo de 300€/mes.

01 Infraestructura

02 Componentes

03 Renderizado híbrido

04 Por qué no…

05 Modelo de datos (CMS headless)

Entitario, no por categorías. Todas las colecciones soportan relaciones muchos-a-muchos.

Una misma base de conocimiento alimenta dos formatos: la guía de viaje (/viajes/, editorial) y la ficha de producto (/circuitos/, venta). El destino es la fuente única; cada formato compone desde ella.

06 Plantillas del sitio actual

El sitio actual son ~12 plantillas visuales que generan 1.871 páginas data-driven. El espejo a Astro reconstruye estas plantillas como componentes.

07 La capa middleware (motor de reservas)

El backend de reservas es Java (servlets) con sesión JSESSIONID. No se reescribe: se mantiene el backend Java y se expone una capa de API REST (middleware Node) que el frontend Astro consume. El flujo de reserva /rol2/ es multi-paso.

08 Multi-dominio y geo-routing

Hoy: 3 dominios sobre el mismo código Java, diferenciados por parámetros de URL. Mañana: dominio único con geo-detección y hreflang.

• Geo-detección server-side (Cloudflare Workers) → sirve el contenido del mercado correcto con hreflang
• Mapeo de URLs antiguas .com → rutas /latam/ y .com.br → /br/ con 301
• DNS cutover: los dominios antiguos redirigen al canónico nuevo

09 Responsabilidades del middleware

El middleware no es solo un proxy: aísla, traduce, cachea y observa. Seis responsabilidades:

10 Componentes React (Islands Architecture)

Páginas Astro estáticas (HTML rápido, SEO perfecto) con islas React solo donde hace falta interactividad. Lo estático es la base; lo interactivo, una isla.

11 Entornos y CI/CD

Arquitectura SEO

La estructura de URLs refleja los 9 ejes de navegación. URLs limpias y descriptivas, schema.org en cada superficie y un mapa de redirects 301 que protege la equity acumulada.

01 Estructura de URLs nueva

02 Mapa de redirects 301

03 Schema.org — el moat

Primer operador español con TouristTrip + Offer + FAQPage en rich results.

04 Clusters de keywords prioritarias

05 Core Web Vitals

El jQuery de 2014 bloquea el render. El nuevo stack elimina ese cuello de botella: rendimiento es ranking.

Validado en cada deploy con Lighthouse CI (gate: LCP < 2,5 s, CLS < 0,1).

Inventario & Datos

El trabajo de base: todos los catálogos PDF parseados a datos estructurados, los destinos deduplicados y priorizados, y la competencia analizada circuito a circuito. Esto es lo que alimenta el grafo SEO.

01 Inventario de circuitos por catálogo

Generado desde los PDF de Panavisión. PA6/EG6/SE6 comparten una base común de 164 circuitos (variantes Premium / Easy Going / Senior) → ~212 únicos.

02 Mapa visual de circuitos

Visualización interactiva de toda la red de circuitos sobre el mapamundi — generada desde los datos del catálogo.

03 Páginas de destino: priorización por tiers

330 destinos limpios, clasificados por número de circuitos que los incluyen. Esto decide qué merece una página editorial completa y qué evita el riesgo de contenido fino.

Tier 1 — ciudades prioritarias (10+ circuitos)

El análisis competitivo completo — solapamiento de circuitos, productos similares, posicionamiento de precio y plataformas — está en la pestaña Competencia →

Análisis de competencia

El mercado español de circuitos organizados, operador a operador: perfiles, solapamiento de catálogo, productos espejo, posicionamiento de precio y cómo entrega cada uno su contenido a Google.

01 Panorama de mercado

02 Perfiles de competidores

Otros competidores

03 Gap analysis

04 Solapamiento de catálogo

Análisis circuito a circuito. 114 ciudades están cubiertas por los tres operadores.

Ciudades cubiertas por los 3 operadores (nº de circuitos)

05 Productos similares (espejo)

Pares donde ambos operadores visitan las mismas ciudades clave (índice Jaccard de solapamiento de ciudades).

Panavisión vs. Catai

Panavisión vs. Mapatours

06 Posicionamiento de precio con caveats

Caveats de calidad de dato

• Triplicación Panavisión: EG6/PA6/SE6 son 3 variantes de marca de los mismos ~158 circuitos → "546" es 3× el producto real (~210 únicos)
• Mapatours incompleto: solo 30 de 178 PDFs (17%) con precio extraído — muestra pequeña y posiblemente sesgada
• Vuelos incluidos ambiguos: Mapatours y Catai incluyen vuelos en su "desde X€"; el crucero CR6 de Panavisión a €65 no puede incluir vuelos → comparación de peras con manzanas hasta verificar qué incluye cada "desde"
• 44 fragmentos filtrados: nombres mal parseados (frases a medias) eliminados del análisis de precio

07 Análisis de plataformas (tech & SEO)

Cómo entregan técnicamente su contenido — y por qué la estrategia Astro + schema deja a ambos atrás.

08 Posicionamiento recomendado

Lo que verá el viajero

De fichero geográfico a revista de viaje. Mobile-first, aspiracional, editorial. El viajero descubre por intención, no por mapa.

01 Anatomía de la nueva ficha de circuito

10 secciones, en orden, con campos que hoy no existen en el catálogo:

02 Lo que la competencia muestra y Panavisión no

La mayoría de esta información ya existe en los PDF de origen, pero no está extraída al modelo de datos.

03 Los catálogos dejan Issuu

La arquitectura correcta del visor de catálogos

Google no indexa bien los flipbooks. El ranking no viene del visor, sino de la página HTML que lo envuelve. La arquitectura ganadora separa las tres capas:

04 Palancas de conversión

05 Spin-offs: el ecosistema

Módulos opcionales — roadmap, no requisito de Fase 1.

Más ideas que extienden la marca

• Diario de Viaje: PDF auto-generado al volver — itinerario + fotos + sellos del pasaporte
• Programa Embajadores: trae un amigo, gana crédito (el CAC más barato del mercado)
• Quiz "Tu próximo viaje": IA recomendadora + captura de email
• Expansión multilingüe: ES → EN (mes 6) → PT (mes 9) → FR (mes 12)

06 Asistente conversacional dedicado

Un chatbot propio integrado en la web, con una base de conocimiento de producto que se mantiene actualizada por API (catálogo de circuitos + guías de destino). Responde con producto real, no con respuestas genéricas.

Módulo opcional, integrable sobre la web del proyecto.

07 Búsqueda — indexa todo el sitio

Un solo buscador sobre todo el contenido: circuitos, cruceros fluviales, combinados, guías de viaje y destinos. La misma base de conocimiento que alimenta guías y fichas alimenta también el índice — se busca el catálogo y el contenido editorial a la vez, no solo los listados.

08 Controles de búsqueda — pantalla A12

Una pantalla de gestión para que su equipo controle el buscador sin depender de un programador.

Estado en vivo

El progreso real del proyecto, sprint a sprint. Esta sección se conectará en vivo con ClickUp para reflejar el estado actual de cada tarea y entregable.

· Estado por sprint

· Tareas por épica

Las 100 tareas del proyecto, traídas de ClickUp y agrupadas por épica (sprint). Clic en una épica para desplegar sus tareas.

· Galería de variaciones de diseño

Modernizamos lo que se ve, conservamos lo que funciona

Consolidamos sus tres dominios en una sola plataforma rápida, medible y editable por su propio equipo, sin tocar el motor de reservas Java que hoy sostiene su negocio. Cada objetivo es medible y se verifica en demostraciones cada 15 días.

· Cómo se estructura el encargo

El proyecto se entrega en dos bloques complementarios, para que lo visible quede cerrado y garantizado y la integración con su sistema de reservas avance sin sorpresas en el precio del bloque principal.

01 Punto de partida

El proyecto parte de un diagnóstico técnico completo. Tres datos lo resumen.

02 Cinco objetivos medibles

03 Objetivo 1 al detalle: salud técnica y SEO

04 Un solo dominio, tres mercados

05 Lo que NO cambia

Tan importante como lo que construimos es lo que deliberadamente no tocamos.

• El motor de reservas Java: es el corazón operativo del negocio y funciona. La nueva web se comunica con él mediante una capa intermedia (middleware) que traduce sus 14 puntos de integración sin modificar una sola línea del sistema existente.
• La operación interna: gestión de cupos, precios, disponibilidad y administración siguen exactamente igual. Su equipo no cambia de herramientas ni de procesos.
• Las URLs ante Google: cada dirección actual responde con su redirección 301 correspondiente; ningún enlace externo ni resultado de búsqueda se pierde.

06 Criterios de éxito del proyecto completo

El proyecto se considera concluido con éxito cuando se cumplen, de forma verificable, estas siete condiciones.

Qué páginas reciben exactamente

Entregamos 24 tipos de vista pública en este proyecto —cada una disponible en los tres idiomas, es decir 26 vistas en total contando las 2 de destino que proponemos como fase 2 post-lanzamiento— y 11 pantallas de administración, todas nuevas. Ninguna URL actual se pierde: las 3.878 redirecciones de la migración conservan el posicionamiento acumulado. Cada vista tiene sprint asignado y criterio de aceptación demostrable en staging.

01 De dónde partimos: el sitio actual en cifras

Hoy operan tres dominios servidos por una única aplicación Java, con 1.336 rutas de URL únicas construidas sobre 12 plantillas de página. Este capítulo responde a una pregunta concreta: qué páginas reciben ustedes y dónde vive cada contenido en el nuevo sitio.

02 Los volúmenes que migramos

El contenido del sitio actual se reconstruye, no se reescribe a mano: importamos cada bloque a su plantilla nueva. Estos son los volúmenes que reciben ustedes.

A esto se suman las 19 landings temáticas (hoy programadas a mano) que pasan al constructor de landings, y ~30 páginas estáticas y corporativas. El motor de reservas Java se mantiene tal cual: el nuevo sitio se comunica con él a través de una capa intermedia, sin tocar su lógica de precios ni de disponibilidad.

03 Las 24 vistas públicas, en los tres idiomas

Cada tipo de vista se publica para España (/es/), LATAM (/latam/) y Brasil (/br/). La columna Estado distingue lo que se reconstruye mejorado de lo que hoy no existe y se crea de cero.

Particularidades por mercado: /br/ sirve el subconjunto del catálogo disponible en portugués (~45 %) con precios en reales; /latam/ sirve precios y catálogo es-419. Las etiquetas hreflang (es-ES / es-419 / pt-BR) en todas las páginas indican a los buscadores qué versión mostrar en cada país.

04 Dos vistas diferidas a fase 2 (fuera de este presupuesto)

Las páginas de destino son la fase 2 propuesta tras el lanzamiento. Suman las vistas 25 y 26 del recuento total, pero no forman parte de este presupuesto.

Las 66 ciudades corresponden a 13 de nivel 1 (página completa) más 53 de nivel 2 (profundidad media); las 264 ciudades de niveles 3 y 4 no reciben página propia.

05 Sistema de gestión: 11 pantallas, todas nuevas

El sitio actual no dispone de ningún panel de edición. El nuevo sistema de gestión —con interfaz en español y en los tres idiomas de contenido— pone el sitio en manos de su equipo.

Quedan en el sistema Java —y no se tocan— el catálogo de circuitos, los precios, la disponibilidad y la transacción de reserva.

06 De tres dominios a uno: 3.878 redirecciones sin pérdida

La migración consolida los tres dominios en uno solo con carpetas por mercado. Las 3.878 redirecciones permanentes (301) conservan el posicionamiento acumulado y se gestionan desde la pantalla A8. La detección geográfica en el borde de la red (Cloudflare Workers) dirige a cada visitante a su versión, y una cookie de preferencia respeta siempre la elección manual.

Su equipo publica sin programadores

Un sistema web completo para editar, crear y publicar desde una interfaz en español: editor visual, constructor de landings por bloques, Centro de importación, gestión de imágenes, espacios publicitarios, roles y vista previa, en los tres idiomas del proyecto. Operativo en el sprint 2, con las 535 guías ya cargadas.

01 Qué gestiona su equipo

El sistema de gestión se ocupa del contenido editorial. El catálogo comercial —circuitos, precios, disponibilidad y reservas— sigue viviendo en su sistema de reservas actual, que se mantiene sin cambios.

Las páginas mixtas (por ejemplo, una landing con tarjetas de circuitos) combinan bloques editoriales con datos comerciales que se leen en vivo de su sistema: el editor coloca el bloque y los precios se actualizan solos.

02 Editor visual: se edita viendo la página real

El editor trabaja sobre una vista previa de la página real, no sobre un formulario abstracto: lo que ve es lo que se publica.

03 Constructor de landings por bloques

Las 19 landings actuales están escritas a mano en código: cada cambio exige un desarrollador. Las sustituye un constructor por bloques: marketing compone una landing nueva combinando piezas de un catálogo cerrado y coherente con el diseño aprobado.

04 Centro de importación: las cargas masivas, desde la interfaz

Las operaciones de volumen no dependen de scripts ni de técnicos. El Centro de importación las resuelve desde el propio panel.

05 Gestión de imágenes (mediateca / DAM)

Una biblioteca central de imágenes y documentos, servida desde la red de distribución de contenidos. No es un simple almacén: ofrece la organización que su equipo necesita para reutilizar material sin duplicarlo.

06 Espacios publicitarios (gestor de anuncios)

El sitio incorpora espacios publicitarios gestionados desde el panel, sin intervención de desarrollo. Su equipo crea campañas, las programa y las activa o pausa al momento. Admite dos tipos de creatividad.

07 Tres idiomas con reglas claras

El editor cambia de idioma dentro de la misma página y ve qué versiones existen y cuáles faltan. La regla de Brasil es deliberada: el catálogo brasileño (889 páginas, ~45% del total) prefiere ser más corto antes que mezclar idiomas, que penaliza la experiencia y el SEO. Cada idioma tiene su propia URL y campos SEO, con hreflang generado automáticamente.

08 Roles, revisión y vista previa

• Todos los cambios quedan registrados: quién cambió qué y cuándo.
• Cada borrador genera un enlace de vista previa en staging: se comprueba la página exacta antes de publicarla y puede compartirse internamente.
• Al publicar, la web pública se regenera de forma automática. La web servida a sus clientes no depende del panel en tiempo real: aunque estuviera en mantenimiento, la web sigue funcionando a plena velocidad.

09 El beneficio, medido en autonomía

10 Entrega y criterio de aceptación

El sistema de gestión se entrega en el sprint 2 y su aceptación es demostrable, como todos los hitos del proyecto: los editores de Panavisión acceden con sus usuarios y las 535 guías se muestran correctamente en staging. La entrega incluye la interfaz en español, los roles definidos y una sesión de formación para su equipo, de modo que la autonomía empiece ese mismo día.

La calidad no se inspecciona al final: se construye

Tres entornos de trabajo, controles automáticos en cada entrega y gates verificables por ustedes cada 15 días. El Sprint 8 concentra la verificación final y culmina en un corte de DNS planificado, monitorizado durante 24 horas y con un plan de marcha atrás ensayado.

01 Tres entornos: nada llega a producción sin pasar dos filtros

Trabajamos con tres entornos separados desde la primera semana. Cada uno tiene una función distinta y un nivel de exigencia creciente.

02 Gates verificables por ustedes durante el proyecto

Cada sprint cierra con una demo sobre staging y un checklist de criterios binarios: se cumplen o no se cumplen.

El motor de reservas se somete además a una prueba de carga con usuarios concurrentes dentro del Sprint 6, antes de llegar a la fase final.

03 QA final — Sprint 8 (31 oct. a 15 nov.)

El último sprint dedica un equipo de QA a tiempo completo a una batería de verificación exhaustiva. Nada de lo que sigue es opcional: cada punto es condición para el lanzamiento.

04 Línea base SEO: medir antes de lanzar

Para que el resultado de la migración sea medible —y no opinable—, fijamos una fotografía objetiva antes del corte.

• Posiciones de las 100 palabras clave principales: registradas con fecha previa al lanzamiento.
• Search Console y Bing Webmaster Tools: exportación completa de datos y alta verificada para el dominio definitivo.
• Sitemap.xml y robots.txt: publicados y enviados (el sitio actual no dispone de sitemap operativo).
• GA4: recibiendo tráfico real desde el primer día, con el embudo de reserva instrumentado.

05 Plan de corte de DNS

El cambio de DNS es el único momento en que el sitio nuevo sustituye al actual. Lo tratamos como una operación planificada, no como un acto de fe.

06 Runbook de marcha atrás (rollback)

Documentamos y entregamos antes del corte un procedimiento de reversión paso a paso. Volver atrás es una operación técnica preacordada, no una negociación bajo presión.

• Criterios pactados de antemano: alerta de disponibilidad, fallo en el flujo de reserva o pico anómalo de errores 404. Si se cumple cualquiera, se ejecuta el runbook sin debate.
• Mecanismo: con el TTL en 60 segundos, restaurar el DNS al sitio actual tarda minutos. La reversión devuelve el servicio exactamente al estado previo.
• Responsables y comunicación: el runbook asigna por nombre quién decide, quién ejecuta y a quién se informa, con tiempos máximos para cada paso.
• Caducidad de la ventana: superadas las primeras 24 horas sin incidencias, el lanzamiento se da por consolidado y se restablecen los TTL normales.

07 Checklist de lanzamiento (firmable)

El go-live solo se ejecuta cuando este checklist está completo y firmado por ambas partes en la demo del Sprint 8.

• Regresión funcional superada: 50 páginas por plantilla, 12 plantillas, sin defectos bloqueantes
• 3.878 redirecciones 301 validadas automáticamente: 0 errores 404
• Core Web Vitals en objetivo: LCP < 2,5 s · CLS < 0,1 · INP < 200 ms
• Lighthouse móvil ≥ 85 en home, listado y ficha de producto
• Multi-navegador y móvil verificados, incluido el flujo de reserva completo
• Prueba de carga superada sin degradación
• Schema validado en el 100 % de las plantillas; sitemap y robots publicados
• hreflang es-ES / es-419 / pt-BR validado en los tres locales
• Línea base SEO registrada: top 100 keywords + exportación de Search Console
• GA4 recibiendo tráfico y eventos del embudo de reserva
• Reserva de extremo a extremo en producción con refPresupuesto verificado
• Runbook de rollback entregado, con criterios de reversión y responsables firmados
• TTL de DNS reducido a 60 segundos con 48 horas de antelación
• Equipo de guardia confirmado para las primeras 24 horas

El 15 de noviembre no termina el proyecto: empieza a producir resultados

Con el go-live, Panavisión Tours dispone de una plataforma que su propio equipo opera sin programadores. Sobre esa base proponemos tres líneas de evolución: garantía y soporte, la Fase 2 de destinos y un programa de mejora continua guiado, por primera vez en años, por datos reales.

01 Garantía incluida en el proyecto

Durante los 30 días posteriores al go-live corregimos sin coste cualquier defecto sobre el alcance aceptado en los gates del proyecto. La garantía cubre errores de funcionamiento; no cubre nuevas funcionalidades ni creación de contenido, que se canalizan por las vías de soporte.

02 Soporte y mantenimiento: modelo propuesto

Para la operación posterior a la garantía proponemos un acuerdo de soporte con tres líneas de servicio, con informe mensual de consumo: el trabajo se ve, se justifica y se prioriza con ustedes.

03 Acuerdo de nivel de servicio (SLA)

Las incidencias se clasifican por severidad. Los tiempos de respuesta y resolución, el horario de cobertura y el dimensionado del soporte se fijan en el acuerdo que presentamos antes del go-live, cuando ya conocemos el comportamiento real de la plataforma en staging.

04 Fase 2: las páginas de destino

La nueva arquitectura deja preparado el espacio /destinos/, el estándar de navegación que ya utiliza la competencia directa y que hoy no existe en la web actual. Proponemos como Fase 2 la creación de 32 páginas de país y 66 páginas de ciudad, derivadas del análisis de los 330 destinos únicos del catálogo.

Páginas de país (32)

Cada país con 3 o más circuitos recibe una página editorial que agrupa toda su oferta. Los seis primeros por volumen:

Páginas de ciudad (66), por niveles

No todas las ciudades merecen el mismo tratamiento. El análisis del catálogo define cuatro niveles para evitar contenido pobre que penalizaría el SEO.

Entre las 13 ciudades del nivel 1: Madrid (20 circuitos), Viena (19), Ámsterdam (17), Estrasburgo (17) y Delhi (16).

05 Contenido editorial asociado

La Fase 2 incluye la ampliación del contenido editorial sobre la base ya construida: nuevas guías y landings temáticas creadas por su equipo con el constructor visual, y la apertura de una taxonomía experiencial (estilo de viaje, temporada, motivación) complementaria a la geográfica.

06 Mejora continua guiada por datos

A partir del lanzamiento, las decisiones dejan de basarse en intuición. GA4 mide desde el primer día el comportamiento real, incluido cada paso del embudo de reserva, y el proyecto entrega una línea base SEO de las 100 palabras clave principales tomada antes del corte de dominio.

Este ciclo es también el mecanismo natural para ordenar la Fase 2: los datos de búsqueda y navegación indican qué países y ciudades priorizar primero.

Roles definidos, citas fijas y reglas escritas antes de empezar

Un proyecto de 1.995 páginas, 12 plantillas y un motor de reservas que se mantiene intacto no se gobierna con buenas intenciones. Un equipo NovumBC de cinco perfiles trabaja en sprints de 15 días con demo y firma al final de cada uno; Panavisión participa con cuatro roles claros y tiempos de respuesta pactados. Así las decisiones nunca frenan el calendario.

01 El equipo NovumBC

Cinco perfiles cubren todo el ciclo. La especialidad SEO la ejercen de forma transversal el responsable del proyecto y el equipo de desarrollo, con auditoría dedicada en el Sprint 8.

El pico de dedicación se produce en el Sprint 6 (Motor de Reservas), el tramo de mayor exigencia técnica. Lo planificamos así deliberadamente: el middleware llega ensayado desde el Sprint 5 y con simuladores funcionando desde el Sprint 1.

02 Los roles del lado Panavisión

El proyecto necesita cuatro roles de su lado. Una misma persona puede asumir más de uno; lo importante es que cada rol tenga nombre y apellidos en el kickoff.

03 Matriz de decisión (RACI)

R realiza el trabajo · A aprueba y es responsable final · C consultado · I informado.

04 Ceremonias: tres citas, ninguna reunión innecesaria

• La demo de gate se realiza por videollamada sobre el entorno de staging, accesible para ustedes desde el primer día de cada sprint —no solo el día de la demo—. Recorremos juntos el checklist de aceptación punto por punto, marcando cada ítem en directo. Todos los criterios son verificables y binarios: "el PDF descarga", "el precio coincide", "el evento se registra en GA4".
• La weekly sirve para avance, próximos hitos y desbloqueos. Si no hay nada que decidir, dura diez minutos.
• El canal directo (correo o canal compartido, a elección de ustedes) evita que las dudas esperen a la siguiente reunión.

05 Tiempos de respuesta pactados

La cadencia de 15 días funciona si ambas partes respondemos rápido. Estos son los compromisos, en ambas direcciones.

06 Calendario de citas que requieren a Panavisión

Fuera de estas citas, el proyecto no necesita tiempo de ustedes: el equipo NovumBC avanza, el staging muestra el progreso en todo momento y la weekly mantiene la foto al día.

Gestión del proyecto

Usuarios y accesos, tarifas por rol y presupuesto. Esta sección es interna y nunca se sirve al rol cliente — el cortafuegos de pricing se aplica en la capa de datos, no solo en la interfaz.

01 Usuarios y accesos

02 Tarifas por rol INTERNO

Editar una tarifa recalcula el presupuesto. En producción, persistido en Directus (nunca en ClickUp, nunca visible al cliente).

03 Presupuesto por sprint INTERNO

01 Modelo de facturación INTERNO

Un sprint = 15 días = una entrega demostrada = una factura. Panavisión solo paga trabajo que ha visto funcionar en staging y ha aceptado por escrito: diez facturas, de F1 a F10. Ninguna factura se emite sin demostración previa. Los importes concretos de cada factura se autocalculan en el panel de admin (rate-card) a partir de las horas por perfil × tarifa.

El ciclo gate → demo → checklist → firma → factura

El mecanismo es idéntico en los diez sprints. Cada gate es un conjunto de criterios de aceptación demostrables, pactados de antemano en el documento de análisis (entregable F1, alcance congelado).

1. Gate — criterios de aceptación demostrables, desglosados en un checklist de 5–12 ítems binarios y verificables (sin ítems subjetivos: lo subjetivo, el diseño, se resuelve una sola vez en el hito F2).
2. Construcción (días 1–12) — el entorno de staging es accesible para Panavisión desde el primer día, no solo el día de la demo.
3. Demo en vivo (día 13) — videollamada de 60–90 min: se recorre el checklist punto por punto, marcando cada ítem OK/KO en directo.
4. Ventana de aceptación (días 13–15) — 3 días hábiles para que el equipo de Panavisión ejecute sus propias pruebas.
5. Firma — acta de aceptación de una página (sprint, checklist, fecha, firmante) o confirmación por correo. La firma dispara la factura ese mismo día.
6. Factura — vencimiento de 30 días netos desde la fecha de factura (F8: 15 días netos). El importe se autocalcula en el panel de admin (rate-card).

Aceptación tácita (deemed-acceptance)

Cláusula contractual para proteger la cadencia de ambas partes.

• Si transcurren 5 días hábiles desde la demo sin firma y sin lista escrita de defectos bloqueantes referidos al checklist, el sprint se considera aceptado de pleno derecho y la factura se emite automáticamente.
• Si la demo no puede celebrarse y no se reagenda dentro de esos 5 días hábiles, el efecto es el mismo.
• En los sprints 5 y 6 (pruebas del propio equipo de Panavisión: 10 cuadros de precios pactados; 5 reservas de prueba), si esas pruebas no se ejecutan en la ventana, la aceptación tácita opera sobre la evidencia documentada que entregamos: capturas, vídeos y referencias de presupuesto (refPresupuesto) verificables en su sistema.
• Una aprobación pendiente (p. ej. la del diseño en el sprint 0b) pausa el calendario completo: cada día de espera desplaza día a día todas las fechas posteriores y sus facturas. El desplazamiento se notifica por escrito, sin penalización para ninguna parte.

¿Y si un gate no se supera?

• El sprint no se factura. Corregimos a nuestro coste y convocamos una re-demo en un máximo de 5 días hábiles, limitada a los ítems en KO — lo ya aceptado no se reabre.
• Sin doble cobro: cada sprint se factura una sola vez, cuando supera su gate. La corrección no genera importe adicional.
• La primera re-demo está incluida. Si el mismo gate vuelve a fallar, se convoca un comité (dirección de proyecto Novum BC + sponsor de Panavisión) con plan de remediación fechado, y los sprints posteriores se desplazan en consecuencia.
• Una dependencia del cliente no es un KO: contenido pendiente, aprobaciones en curso o accesos no concedidos no impiden la factura si el resto del checklist se supera con datos de muestra.
• Motor de reservas (sprint 6): si el ítem pendiente se debe al entorno o al equipo Java de Panavisión, el gate se da por superado en la parte que nos corresponde (demostrable de forma aislada con los simuladores de integración), y la integración pendiente se replanifica como anexo con cargo a la bolsa de contingencia, siempre con aprobación escrita.

Control de cambios sin romper la cadencia

Regla de oro: dentro del sprint en curso no entra nada nuevo. El alcance de cada sprint se cierra el día 1. Todo lo demás es una petición de cambio: se registra (descripción, estimación en horas × tarifa de perfil, impacto en fechas) y se valora en un máximo de 3 días hábiles. Las facturas F1–F10 no se modifican por estas vías; ampliaciones y readmisiones se numeran aparte (F-AMP-n / F-CR-n).

• Las peticiones de 2 horas o menos se absorben sin trámite (máximo 3 por sprint).
• Cambios de diseño tras la aprobación del hito F2: una ronda de ajustes menores está incluida; un rediseño completo se planifica como sprint de diseño adicional con presupuesto propio.
• Ningún cambio se ejecuta sin aprobación escrita de Panavisión sobre la estimación entregada.

Calendario de facturas (F1–F10)

Cada fecha es la del cierre de sprint previsto; si una aprobación se retrasa, la tabla completa se desplaza día a día según la cláusula de aceptación tácita. Los importes no se hardcodean aquí: el panel de admin los autocalcula desde la rate-card y los muestra en el bloque «Presupuesto por sprint».

02 Estructura de entrega: básico + bolsa de APIs INTERNO

Esfuerzo de entrega real (lo que se construye), separado en el bloque cerrado y la bolsa abierta. No es el precio de contrato; es el esfuerzo. La bolsa se factura por horas reales.

03 Configurador de alcance y presupuesto INTERNO

Desglose por sprint y por entregable. Cada línea se asigna a quién la ejecuta — Novum, una tercera compañía, o se deja fuera / diferida. El panel separa lo que factura Novum de lo que ejecuta un tercero. Reasignar cambia el importe de la factura del sprint, nunca su fecha (16 jun → 15 nov 2026).