Saltar al contenido
Idioma: en

Menú

TurismoCliente

Ayum Elun · Recepción

Un complejo de cabañas, hostería y camping cambia la planilla de papel por un sistema de recepción con reservas, caja diaria y extracto mensual.

El problema

Registramos a cada huésped en una planilla de papel y al final del día no sabemos cuánto entró ni por qué medio.

La solución

Una app de recepción instalable que registra al huésped una sola vez, muestra solo los campos del tipo de alojamiento elegido, impide reservas superpuestas desde la base de datos y cierra la caja del día por sector y medio de pago.

Impacto

  • El huésped que vuelve se encuentra por DNI, apellido o teléfono y sus datos se autocompletan.
  • Extracto diario y mensual por sector (cabañas, apart, hostería, camping) y por medio de pago.
  • Dos reservas no se pueden pisar en la misma unidad, porque lo impide Postgres.
  • Backups nocturnos automáticos de toda la base.

Mi rol

Relevamiento, diseño, desarrollo e infraestructura

DiseñoFrontBackInfra y DevOpsDatos

Herramientas

ReactTailwindExpressPrismaPostgreSQLRailwayGitHub Actions
La tranquera de Tranquera: poste, travesaños y la tornapunta en ocre

De este caso nació

Tranquera

La recepción de tu complejo, en orden.

Ordena todo lo que pasa entre que alguien cruza la entrada y se va. Quién llegó, dónde duerme, cuánto pagó y qué queda en la caja. Si se corta internet, se sigue atendiendo.

El contexto

Ayum Elun es un complejo en Valle Grande, San Rafael, con cabañas, apart hotel, una hostería de 16 habitaciones y un camping con parcelas y zona libre. La recepción registraba a cada huésped en una planilla de papel y no había un resumen económico del día ni del mes.

Lo que dolía

  • Cada visita volvía a cargar los mismos datos a mano.
  • No había forma de saber qué estaba ocupado más adelante sin mirar papeles.
  • Al cerrar el día, la plata se contaba sin un extracto que la explicara por sector y por medio de pago.

Las decisiones

El formulario se adapta al tipo de alojamiento. Si es cabaña, solo cabañas disponibles con capacidad suficiente; si es camping, la modalidad y una parcela libre o "sin parcela".

La base de datos dice que no. Una restricción de exclusión de Postgres impide que dos estadías activas se pisen en la misma unidad, aunque dos recepcionistas carguen al mismo tiempo.

Caja con cierre. Con la caja cerrada no entran más cobros ese día; solo un administrador la reabre. El extracto se imprime desde el navegador.

Backups aunque el plan no los traiga. Un servicio programado exporta toda la base cada noche a un bucket y borra los de más de 30 días.

Lo que se construyó

  • Huéspedes con búsqueda sin importar tildes y con historial de estadías.
  • Reservas y estadías con grilla de ocupación, check-in, check-out y renovación.
  • Día de campo para la portería, desde una tablet en la entrada.
  • Caja diaria, extracto mensual y exportación a CSV.
  • Roles de portería, recepción y administración, controlados en la API.

Más casos

DistribuciónCliente

Roleo · Distribuidora

Los vendedores salen a la calle sin señal, el sistema que usamos es viejo y la mitad de lo que tiene no lo usamos.

Relevé qué se usaba de verdad del sistema anterior, migré sus datos y construí una PWA de preventa y reparto que trabaja sin conexión y se sincroniza sola, más un panel de administración y un catálogo público, todo en una infraestructura con deploys automáticos.

  • Los vendedores toman pedidos sin señal y la venta se sube sola al volver la conexión, sin duplicarse.
  • 2.236 clientes, 13 rutas y 963 artículos migrados desde el sistema anterior.
DiseñoFrontBackInfra y DevOpsDatos
Dio origen agalpón