​

Reporte semanal NPS

• Email de los lunes — Windmill cron 0 9 * * 1 → POST /surveys/reports/weekly-nps/send (autenticado con x-api-key). Renderiza el payload con la plantilla React Email y lo envía a WEEKLY_NPS_REPORT_TO (lista separada por comas/punto y coma).
• Vista in-app “Reporte semanal” — pestaña Reportes de Resultados de encuestas, GET /surveys/reports/weekly-nps (rol tool-chat viewer). Acepta ?week=<ISO> para navegar semanas.

apps/backend/src/surveys/reports/
  weekly-nps-report.service.ts   # computePayload(): orquesta ventanas y métricas
  weekly-nps-data.service.ts     # acceso a Supabase (queries por ventana + globales)
  weekly-nps-compute.ts          # helpers puros (ventanas, normalización, NPS Bain, filtros)
  weekly-nps.constants.ts        # slugs incluidos, targets
  templates/WeeklyNpsEmail.tsx   # plantilla del email

​

Ventanas de tiempo

• Todo se computa en UTC. El cron corre lunes 09:00 Madrid; el desfase de ~2h es irrelevante para el volumen de respuestas (misma aproximación que el reporte original).
• La semana reportada es la semana completa anterior: lunes → lunes (extremo derecho exclusivo).
• El frontend espeja esta aritmética en lib/surveys/week.ts (getWeekBounds) y envía ?week al backend.

​

Slugs incluidos y excluidos

• Incluidos: stay-review, arrival-review, onboarding-review.
• Excluidos: home-review, financial-review, book-review (no entran en ninguna métrica de este reporte).

​

Fuentes de datos

• Respuestas nuevas: la ventana se aplica por completed_at. Ratings 1-5 envueltos como { value: n } (desde mayo 2026; se aceptan ambas formas).
• Respuestas legacy: la ventana se aplica por responded_at. nps_score ya viene en 0-10; el stay-review legacy lleva response_data.experience.nps (Casa) y response_data.stay.nps (Equipo/CX).
• Estancias: la ventana se aplica por check_in_date (no por actual_check_in_date). Estados active/past/inprogress.

​

Normalización a 0-10 y NPS Bain

• Ratings 1-5 → 0-10: normFromFivePoint(v) = value × 2 (rechaza fuera de 0-5).
• Llegada (arrival-review nuevo): approvalRateTo010(answers) = aprobados / total × 10 (tasa de aprobación de los ítems swipe).
• Legacy NPS / arrival legacy: clamp010 (ya 0-10).

​

Pools NPS (NO filtrados por disfrutadas)

​

Estancias

​

% Respondidas (tasa de respuesta)

• Denominador = estancias disfrutadas+activas de la ventana × 2 + links de onboarding. Cada estancia disfrutada genera dos envíos (arrival-review tras el check-in + stay-review tras el check-out); cada link de onboarding es 1 envío.
• Numerador = respuestas stay/arrival (nuevas y legacy) cuyo booking enlazado está en el set global de reservas disfrutadas+activas, más todas las respuestas de onboarding (sin filtrar: el scope_id de onboarding es un user id, no un booking).
  • Enlace estricto: nuevas por scope_id, legacy por booking_id.
  • El set global (fetchEnjoyedActiveBookingIds) se calcula una vez fuera del bucle de ventanas. Se enlaza contra el set global (no contra los check-ins de la ventana) para evitar el artefacto cross-ventana: una respuesta se fecha por completed_at/responded_at y una reserva por check_in_date, así que pueden caer en ventanas distintas.

​

Frictionless (sin fricción)

• Denominador = estancias disfrutadas+activas de la ventana.
• Numerador = de esas, las frictionless:
  • estancias que respondieron con ambas notas > 7 (Casa > 7 y Equipo > 7), o
  • estancias que no respondieron el stay-review (silencio = sin problema reportado).

​

Filtro: reservas disfrutadas + casa activa

1. Casa activa — properties.status = 'active' y deleted_at IS NULL y name NOT ILIKE '%[Test]%'. El conjunto de hid activos lo provee fetchActiveHomes().
2. Reserva disfrutada — bookings_snapshot.flag_enjoyed = true (CX marca la estancia como disfrutada; se sincroniza desde Firestore bookFlags.enjoyed).
3. property_hid no nulo y dentro del set de casas activas.

​

Endpoints