Doble reserva a las 6 de la mañana
Dos equipos reservaron la misma sala de ensayo. Ambos se presentan. El ingeniero mueve los micros. El equipo los vuelve a mover. El ponente llega al caos.
Reservas
Salas, escenarios, recursos. Cero reservas duplicadas.
Un único motor de reservas para todos los tipos de recurso, con una restricción de exclusión GIST en la base de datos que hace imposible el solapamiento bajo escrituras concurrentes. Flujos de aprobación donde los quieres y una API limpia donde no.
En vivo
Las reservas duplicadas no son un problema de planificación. Son un problema de datos.
Si tu calendario permite que dos reservas se solapen, lo hará — ninguna disciplina de tu equipo lo impedirá. Espacios hace imposible el solapamiento en la base de datos, donde la disciplina no importa.
Un calendario distinto por cada tipo de recurso
Las salas de ensayo viven en una herramienta. Los escenarios en una hoja de cálculo. Los camiones en la cabeza de alguien. No existe una vista entre recursos porque tampoco existen los datos.
Aprobación por captura de pantalla
Los recursos de alto valor requieren aprobación. El flujo es "haz captura del calendario, escribe al responsable por Slack, espera respuesta". Sin registro, sin auditoría, sin reintento.
Bloqueos que no se aplican
Mantenimiento, retenciones VIP, descansos sindicales — los bloqueos viven en la cabeza de alguien. Cuando una reserva se cuela, nadie se entera hasta el día.
Un motor de reservas que sobrevive a la concurrencia.
Protección contra solapamientos que aguanta bajo escrituras concurrentes, recursos polimórficos para que un módulo pueda reservar los de otro y un flujo de aprobación que no vive en Slack.
Protección contra solapamientos a nivel de base de datos
Una restricción de exclusión GIST sobre el rango de tiempo hace imposibles las reservas duplicadas a nivel de base de datos. Sin conjeturas en la capa de aplicación — una garantía real, segura ante concurrencia.
Registro polimórfico de recursos
Salas de ensayo, planos de producción, recursos independientes — todos se resuelven a través de una única tabla de recursos. Un calendario, todos los tipos de recurso.
Flujo de aprobación donde importa
Una marca requires_approval por recurso enruta las reservas a través de una máquina de estados pendiente → confirmada | rechazada. Los recursos de alto valor quedan filtrados; las reservas del día a día fluyen.
RPC de conflicto previo a la inserción
El RPC check_reservation_conflict() devuelve un 409 amigable antes de que el conflicto llegue a la base de datos, así que la UX es informativa. La restricción GIST es la garantía última.
Bloqueos como registros de primer nivel
Ventanas de mantenimiento, retenciones, descansos — los bloqueos son filas reales con actores, motivos y ciclos de vida. Las reservas contra bloqueos fallan limpiamente, con el motivo visible.
Sincronización bidireccional con Ensayos
Crear una sesión de ensayo reserva la sala automáticamente. Cancelarla la libera. Acoplamiento entre módulos sin la deriva — ambos sistemas leen el mismo registro.
Eventos de reserva en el bus
Cada creación, aprobación, rechazo y cancelación emite un evento de plataforma. Command Center, notificaciones y módulos posteriores se suscriben — el calendario es reactivo, no se refresca por lotes.
Reservas recurrentes, de primer nivel
Ventanas de montaje de rig, franjas diarias de ensayo, reuniones semanales de producción — las reservas recurrentes se expanden en filas discretas con la misma protección contra conflictos que las puntuales.
Connected by Design
One reservation engine, many callers.
Spaces doesn't own calendars — it owns the authoritative reservation record. Rehearse, Produce, and any future module all book through Spaces, so there is exactly one truth for what resource is committed when.
Inbound — data flowing into Spaces
RehearseSpaces
Creating a rehearse session reserves the room automatically via the session → reservation link. Cancelling the session releases the room in the same transaction.
rehearse.session.createdOutbound — events Spaces publishes
SpacesRehearse
When a reservation is cancelled on the Spaces side (maintenance, blackout), the linked session is flagged for the rehearse team — no stale bookings.
spaces.reservation.cancelledInteligencia en los márgenes, no en el centro.
El motor de reservas no necesita IA. Pero la planificación de capacidad, el seguimiento de aprobaciones y la detección de riesgos sí — así que los especialistas viven en los bordes, nunca en la ruta de reserva.
Detección de riesgo de conflicto
Las reservas propuestas cerca del límite de capacidad o de bloqueos se marcan antes de enviarse — no con un rechazo tajante, sino con contexto, para que quien reserva decida.
Informes de utilización
El % de utilización por recurso saca a la luz salas sobrerreservadas e infrautilizadas. La planificación de capacidad pasa a ser una vista, no una hoja de cálculo.
Detección de aprobaciones estancadas
Las reservas que llevan en aprobación pendiente más allá de un umbral salen a la luz junto al aprobador y al recurso. Nada se pudre esperando una respuesta.
Empieza ya
Un calendario. Todos los recursos. Cero conflictos.
La plataforma está activa. Solicita una demo para ver Spaces en acción.
Parte de una plataforma de 13 módulos que se adapta a tu operación. Sin compromiso.