~/case-studies
Reservas · Plano de venue
Plataforma de reservas con plano interactivo del recinto
Sustituir hojas de cálculo que se rompían cada noche por un sistema visual con asignación automática y control en puerta.
duración · 8 semanas para MVP usable en salaequipo · 1 persona + co-diseño con jefes de sala
El reto
- ▸Sistema de reservas en Google Sheets compartido entre varios usuarios concurrentemente. Una edición mal hecha borraba reservas confirmadas.
- ▸Aforo y fusión de mesas calculados manualmente con riesgo de overbooking en eventos con varias salas.
- ▸Control en puerta el día del evento dependía de una lista impresa que quedaba obsoleta en cuanto entraba una reserva nueva.
- ▸No había sincronización con la ticketera externa que vendía entradas con mesa incluida.
La solución
- ▸Editor visual del plano del recinto con drag-and-snap y configuración decorativa por sala.
- ▸Reglas de aforo y fusión codificadas (mesa simple = pax + 2 sillas extra; fusión = suma - 2, etc).
- ▸Sincronización bidireccional con la ticketera del cliente, en modo configurable (off / shadow / on).
- ▸App móvil para control en puerta con lista en vivo, escaneo de QR y check-in incremental.
Stack
Next.jsTypeScriptNestJSPostgreSQLWebSocketPWASVG
Impacto
- ▸Cero pérdidas de reservas por edición concurrente.
- ▸Asignación automática respeta aforo real y reglas de fusión sin intervención manual.
- ▸Control en puerta en vivo, con visibilidad de quién ha llegado y quién falta en cualquier momento.
- ▸Sincronización con ticketera sin duplicados ni discrepancias.
Aprendizajes
- ▸Las hojas de cálculo aguantan más de lo que pensamos, pero el día que se rompen cuestan más que el desarrollo del software que las sustituye.
- ▸Sincronización bidireccional siempre se hace en modo "shadow" antes de ponerla en "on". Probarlo en producción sin red de seguridad es buscar problemas.
- ▸El plano visual no es decoración, es parte de la UX. La sala lo entiende mejor que cualquier formulario tabular.