PRODUCT_STRATEGY.md — KAI CLUB

Principio rector del brief: ser crítico, no ejecutar ideas ciegamente. Cada función se evaluó contra: ¿aporta reservas? ¿sube ticket? ¿ayuda a vender eventos? ¿la usará el personal? ¿daña el móvil? Este documento es el resultado: qué SÍ, qué NO, y por qué.

1. Los 10 objetivos → dónde se juegan de verdad

2. Decisiones SÍ / NO por idea del brief

✅ SÍ — v1 (P0)

• Motor de reservas propio para experiencias + reservados (4 pasos: fecha+pax → experiencia → extras+datos → confirmación). El mayor hueco: productos de 60–900 € sin canal online. Mesa de restaurante sigue en CoverManager (operativa intacta, riesgo cero) integrado como opción del flujo.
• Carta y bebidas en HTML (TASTE KAI / DRINK KAI). Hoy son PNG: invisibles para Google, ilegibles para lectores de pantalla, intraducibles. Seed con la carta real extraída [CONFIRMAR con cliente]. PDF como secundario.
• Eventos privados /celebrar (CELEBRATE AT KAI): wizard ¿qué celebras? → tipo/invitados/fecha/servicios → contacto. Lead al CRM + aviso al equipo. Sin presupuestador automático: los reservados de 600–900 € y bodas requieren valoración humana (el brief lo permite y la operativa lo exige).
• WhatsApp contextual: CTAs con mensaje precargado distinto en reservas/eventos/grupos/contacto. Ya es SU canal real (687 600 153) — se potencia, no se sustituye.
• Localización/NAP completo: hoy no hay dirección, email ni tel: clicable. Básico brutal que falta.
• ES/EN/DE con hreflang. DE es P0 por mercado turístico del sur de GC; arquitectura lista para NO/SV/DA/FI (colonia noruega de Arguineguín) sin construirlos aún.
• Legal RGPD/LSSI: aviso legal, privacidad, cookies + consentimiento. Hoy hay formulario SIN política de privacidad → riesgo legal activo.
• Admin 10 secciones: Dashboard, Reservas, Productos (experiencias/reservados/cupos), Carta, Bebidas, Eventos, Leads privados, Clientes, Galería/Contenido (incl. KAI TODAY), Ajustes. Nada más.
• Transversales P0: mobile-first 375–430 px, presupuesto de performance (LCP<2,5 s), accesibilidad AA, seguridad (ARCHITECTURE §6).

✅ SÍ — v1 (P1)

• KAI TODAY recortado a lo fiable: mensaje del día + DJ/música + estado piscina (admin, 30 s de trabajo) · clima (Open-Meteo) + sunset (cálculo astronómico) automáticos · «quedan X reservados hoy» SOLO desde bookings reales. Si un dato no existe, la franja lo omite — jamás inventa. Coste bajo, diferenciación alta.
• Agenda de eventos públicos (NEXT AT KAI): admin los crea; sección solo visible si hay eventos futuros. Sin eventos inventados.
• Galería premium por categorías (masonry, AVIF/WebP, lightbox swipe). Depende de recibir fotografía real de Kai; placeholders TODO_KAI_REAL_IMAGE hasta entonces.
• Reseñas curadas: selección manual en admin con fuente y enlace (Google/TripAdvisor). Sin API frágil, sin inventar.
• Automatizaciones (4): confirmación inmediata · recordatorio T-1 · gracias+reseña T+1 · aviso interno de lead privado. Vía mail_outbox (funciona sin SMTP desde el día 1, despacha cuando haya credenciales).
• Stripe depósitos para reservados, detrás de flag (NONE al lanzar; se activa cuando el cliente tenga cuenta Stripe y política de cancelación definida).
• GA4 + Consent Mode: 8 eventos de conversión definidos (SEO_STRATEGY §10).
• Dashboard honesto: reservas hoy/futuras, ocupación por producto, leads nuevos. Ingresos/ticket medio SOLO cuando Stripe esté activo. Sin números decorativos.

🟡 PREPARADO PERO NO CONSTRUIDO (P2)

• Pool map visual: NO se dibuja un plano falso (el brief lo prohíbe y hoy se vende por tier, no por hamaca numerada). El modelo de datos ya soporta unidades con map_shape_id; cuando Kai facilite plano real → SVG interactivo de ZONAS en v2. Mientras: selector de tier con fotos reales, que es como venden hoy.
• #KAIMOMENTS: categoría PEOPLE de la galería, curada desde admin. Sin API de Instagram (frágil, requiere tokens que caducan). Embeds autorizados puntuales si el cliente los pide.
• Página por tipo de evento (bodas/empresa): se independizan de /celebrar solo cuando existan fotos y casos reales que las llenen.
• Noruego/sueco/danés/finés: al añadir la 4ª lengua solo hay que crear messages/no.json + traducir contenido de BD.

❌ NO — con motivo

• Chatbot/concierge IA: prohibido por brief. La claridad de la web + FAQ + WhatsApp lo sustituyen.
• KAI ORDER (pedido desde hamaca): NO en v1. Requiere integración TPV/cocina, flujo de camareros, pagos en tumbona y disciplina operativa que no está validada. Un sistema de pedidos que el personal ignora es peor que ninguno (experiencia directa en otros locales: la impresora/operativa es el 80% del problema). Camino incremental sin riesgo: v1.5 = QR por zona → carta con contexto (/carta?zona=A17) + analytics; v2 = si el cliente lo pide con operativa comprometida, pedido real con estado y aviso a barra.
• KAI PASS (fidelización): no hay estrategia de fidelización definida por el negocio → construir un sistema de puntos sería inventarse el modelo comercial del cliente. customers + consentimientos + segmentación básica dejan la puerta abierta. Revisar con datos reales de recurrencia en temporada 1.
• Presupuestador automático de eventos: valoración humana; el wizard captura, el equipo cotiza.
• Bottom navigation de 5 iconos: pierde 64 px permanentes y duplica el header. Gana: BookBar contextual de 2 acciones (Reservar + WhatsApp) que aparece tras el hero.
• Sync automática de reseñas, popups de entrada, autoplay con sonido, cursor custom, música, doorway pages SEO, dashboard decorativo: descartados (brief §44 + criterio).

3. Riesgos y dependencias del cliente (bloqueos honestos)

4. Métrica de éxito (temporada 1)

• ≥30% de reservas de experiencias/reservados entrando por la web (hoy 0%).
• ≥5 leads de eventos privados/mes con respuesta <24 h.
• LCP móvil real <2,5 s (hoy 19,8 s) · peso home <3 MB (hoy 199 MB).
• Indexadas las 3 versiones de idioma con carta en HTML (hoy 0 palabras de carta indexables).