SNAP es una cadena de estudios de autofoto en seis ciudades de Indonesia. El sitio anterior era un folleto estático — las reservas se gestionaban por DMs de WhatsApp, cada sucursal llevaba su propio cuaderno y aproximadamente una de cada doce sesiones terminaba en un conflicto a la puerta. Reconstruimos el flujo del cliente como una PWA y entregamos un panel de administración único que ve las seis sucursales a la vez.
Una PWA mobile-first para el cliente, una SPA de escritorio para la administración, una sola API y una sola base de datos por debajo. Seis módulos sostienen toda la cadena — desde el splash de ciudad que el cliente ve en Instagram hasta el cierre de caja diario que el responsable de sucursal confirma al cerrar.
Seis ciudades, doce sucursales, dos arquetipos físicos de estudio. El flujo del cliente omite automáticamente el paso de sucursal en ciudades con un solo estudio y enruta el modelo de capacidad correcto según el local.
Los estudios box operan con una matriz de fondo×horario — cada sala se reserva de forma independiente. Los estudios roll-down manejan un horario compartido con selección de fondo puramente estética. Misma interfaz, dos reglas de capacidad distintas por debajo.
El cliente escanea un código QRIS dinámico, el callback del comercio libera el turno y el cliente ve una confirmación. Sin personal mirando la app del banco. Sin el mensaje manual de "¿ya pagó?".
Un panel para el fundador. Reservas del día en las seis sucursales, ventas vs. ayer, gastos por categoría, ocupación por sala. Desde cualquier tile se puede ir a los registros detallados.
Los responsables de sucursal solo ven su sucursal — calendario del día, activación de turno para walk-ins, registro de gastos, cierre de caja al final del día. Basado en roles, bloqueado por defecto.
Reserva confirmada → mensaje de WhatsApp con plantilla que incluye el turno, la dirección de la sucursal y un enlace al calendario. Recordatorio automático 2 horas antes. El hilo de DMs ya no es donde viven las reservas, pero sigue siendo donde los clientes esperan recibir respuesta.
Cada sucursal tenía su propio número de administración. Los clientes enviaban mensajes del tipo "¿mañana 3pm Kemang?" y alguien respondía si estaba despierto. Dos empleados a veces confirmaban el mismo turno a dos clientes distintos porque la bandeja era la única fuente de verdad.
Los fines de semana con más actividad, aproximadamente una sesión de cada doce terminaba en un conflicto a la puerta — una parte quedaba sin lugar, recibía un reembolso y se enojaba en Instagram.
El cliente elige una ciudad, una sucursal, una fecha, un horario y un fondo — cada paso escribe un bloqueo en una fila real. Dos teléfonos tocando el mismo turno en el mismo segundo: uno gana, el otro ve "recién tomado" y recibe el siguiente bloque de 30 minutos disponible.
La confirmación se envía luego por WhatsApp, así los clientes siguen recibiendo respuesta donde lo esperan. El DM ahora es el comprobante — no la reserva.
La mitad de las sucursales son estudios box — cada fondo tiene su propia sala, así que dos fondos implican dos sesiones en paralelo. La otra mitad son estudios roll-down — múltiples fondos colgados en una sola sala, pero solo puede realizarse una sesión a la vez.
El sitio anterior los trataba de forma idéntica. Los clientes reservaban cuatro fondos al mismo tiempo en una sucursal roll-down y llegaban para descubrir que no era posible realizarlos todos.
Cada sucursal está etiquetada como multi o single en la base de datos. Los estudios box tienen una cuadrícula de fondo×horario — elegir una celda es elegir una sala y un horario en un solo movimiento. Los estudios roll-down tienen un horario compartido y una selección de fondo separada que es puramente estética.
Mismo shell en React, mismos componentes, diferente forma de datos desde un único endpoint. El cliente nunca tiene que saber la diferencia.
○ libre × ocupado ● seleccionado
El cliente transfería, capturaba el comprobante, lo enviaba por WhatsApp. El administrador de la sucursal abría la app del banco, buscaba el monto correspondiente, respondía "ok confirmado" y anotaba el turno en el cuaderno. Cinco minutos por reserva un día tranquilo, mucho más un sábado.
Si el administrador estaba en el almuerzo, el cliente esperaba. Si el cliente esperaba demasiado, cancelaba.
Confirma automáticamente.
No se necesita captura de pantalla.
Para un administrador de sucursal un sábado, desde la apertura hasta el mediodía — el tramo más ocupado. La misma persona, el mismo trabajo, antes y después de la reconstrucción.
Pasamos un sábado completo con dos administradores de sucursal. Observamos cómo se llenaba el cuaderno, se gestionaban los chats, se actualizaba la app del banco. Anotamos cada paso. Eliminamos todo lo que no tenía que existir si hubiera una base de datos.
PWA en React + Vite, Express + MySQL en el backend. Dos modelos de reserva detrás de un único shape de endpoint para que la interfaz no se bifurcara. Integración QRIS con fallback de webhook para que una red inestable nunca dejara a un cliente atrapado a mitad del pago.
SPA de administración: resumen general, calendario de reservas, gastos, ventas, reportes, configuración. Desplegamos primero en una sucursal (Kemang), la monitoreamos una semana, luego incorporamos el resto de a dos. Los cuadernos se retiraron sucursal por sucursal.
Las cifras a continuación provienen de la base de datos en vivo de la sucursal piloto (Kemang) más las dos sucursales que se incorporaron después. Las cifras de toda la cadena se publicarán aquí solo cuando haya suficientes meses de datos reales detrás.
Seis sucursales en seis ciudades, un fundador que tiene que poder leer el panel de control desde el teléfono mientras espera en la fila de un café. Cada decisión respondía a: ¿qué pasa si el wi-fi de una sucursal se cae en el pico del sábado?
Instalable desde la pantalla de inicio. Transiciones de página con Framer Motion. CSS Modules y una paleta estricta en blanco y negro — las fotos aportan el color, la interfaz no interfiere.
Una base de datos, sucursales como filas, modelo de capacidad como enum. Las escrituras de turnos pasan por un único endpoint que bloquea la fila para evitar que dos reservas simultáneas ganen la misma celda.
Código QRIS dinámico por reserva con TTL de 15 minutos. El webhook de liquidación libera el turno; si el webhook falla, un poller reconcilia en un minuto. De cualquier forma, el cliente ve la misma confirmación.
Sin codebase de administración separado. El login del fundador lleva al layout de barra lateral de escritorio; el login de sucursal lleva a la vista de una sola sucursal. RBAC en la API, no en la interfaz — navegar por la UI nunca puede otorgar permisos que el servidor no haya aprobado previamente.
Llamada de diagnóstico sin costo. Le decimos qué es lo más sencillo que lo soluciona.
Builds como este funcionan sobre la Plataforma Core + módulos a medida — la mayoría de los sistemas de reservas queda entre $2.500 y $4.500. Precios completos →