Programa para recepción de hotel: lo que el mostrador necesita (y lo que sobra)

Un programa para recepción de hotel no es un ERP ni un CRM de marketing. Es la herramienta del turno: ver habitaciones, crear estancias sin drama, hacer check-in y check-out, cobrar, y no vender la misma noche dos veces. Si el software se siente como “oficina” y no como “mostrador”, el personal inventará atajos.

Qué hace la recepción en un día real

En un hotel independiente típico (12–60 habitaciones), el día no es un flujo de proceso de manual corporativo. Es:

1. Cola de llegadas a las 15:00.
2. Walk-in a las 21:30 con una sola habitación libre del tipo que piden.
3. Teléfono que corta a mitad de reserva.
4. Huésped que “reservó en la web” y no aparece.
5. Salida con saldo extra de minibar y discusión de tarifa.
6. Housekeeping que marca limpia en un chat mientras el calendario sigue en sucia.

El programa gana o pierde en esos momentos, no en el módulo de “insights con IA” del día del demo.

El núcleo del programa de recepción

1. Calendario de ocupación legible

Filas de habitaciones, columnas de fechas, colores de estado. Es el tablero mental del hotel. Si el calendario es lento o confuso, todo lo demás se usa menos.

2. Dos formas de crear estancia (no cuatro)

• Walk-in: huésped en la puerta, hoy, habitación libre.
• Nueva reserva: teléfono, correo, empresa, fechas futuras; con origen honesto (phone, staff, walk-in, OTA si aplica).

Las reservas de la web del hotel no las “elige” el staff: el motor las crea con origen website. Mezclar “crear web a mano” con walk-in destruye reportes y genera reescritura.

3. Check-in / check-out que cambia estados

Check-in no es un sello de goma: cambia estancia y habitación. Check-out deja la habitación en flujo de limpieza y cierra (o deja claro) el saldo.

4. Saldos y pagos visibles

El personal debe ver lo cobrado, lo pendiente y registrar un pago sin magia de contabilidad. Si el saldo es “pregunta al gerente y al Excel”, el programa falló.

5. Tablero del día (visibilidad)

Llegadas, salidas, in-house, alertas. “Hoy” sirve para ver, no para inventar un segundo camino de alta de reservas. La creación vive en el calendario.

6. Housekeeping operativo

Sucia / limpia / fuera de servicio. Idealmente ligado al checkout. La recepción no debería asignar una “limpia” que housekeeping aún no liberó.

Lo que no es el trabajo de recepción (aunque el software lo ofrezca)

• Diseñar campañas de email masivo.
• Configurar 300 canales el primer día.
• Contabilidad multi-empresa de grupo.
• “CRM 360” con 40 campos obligatorios antes de entregar llaves.

Esas cosas pueden existir más tarde. El día uno de un boutique es: no sobrevender, atender bien, cobrar bien.

Walk-in: la prueba de fuego del software

Un walk-in bien diseñado:

1. Se abre desde el calendario.
2. Por defecto es hoy.
3. Muestra habitaciones realmente disponibles.
4. Pide datos mínimos (nombre, teléfono o documento según política).
5. Bloquea inventario al guardar.
6. Permite check-in inmediato si el huésped se queda.
7. Marca origen walk-in — no website.

Un walk-in mal diseñado: te manda a “nueva reserva corporativa”, te pide 20 campos, o te dice “ve a Front Desk” y luego a “Quick Book” y luego al calendario. Eso no es “opciones”: es sobreingeniería.

Teléfono ≠ walk-in

El teléfono suele ser fechas futuras. Vive en Nueva reserva con origen phone. Forzar “walk-in de mañana” confunde reportes y estados. Un buen programa de recepción enseña esa distinción en el UI, no en un PDF de training de 80 páginas.

La web y la recepción: una sola verdad

El peor momento de recepción: “reservé en su página y no me tienen”. Causas típicas:

• Formulario web que solo manda email.
• Channel/engine desconectado.
• Alguien digitó mal el apellido.
• El hotel vive en Excel y “sube” de noche.

El programa correcto hace que la reserva web ya esté en llegadas. La recepción ejecuta; no reescribe.

Sobreventa: el programa debe oponerse

Si dos usuarios pueden grabar la misma habitación-noche sin aviso, no tienes control. El sistema debe rechazar el conflicto (salvo política explícita de overbooking, que casi ningún boutique debería improvisar sin reglas).

Controles prácticos:

• Un solo inventario.
• Creación con validación de solapamiento.
• Web y OTAs leyendo el mismo pool (cuando hay channel).
• Prohibido el segundo cuaderno de “llaves sin fila”.

Turnos, roles y “la persona que sabe”

Muchos hoteles dependen de una persona que “conoce el Excel”. Un programa de recepción debe ser usable por el turno de noche sin esa persona. Criterios:

• Login por usuario (no una sola contraseña compartida en un post-it).
• Flujos cortos.
• Idioma real en español (no menús a medias).
• Permisos sensatos (quien cobra vs quien solo ve).

Checklist de evaluación en una tarde

• Walk-in < 2 minutos con personal nuevo
• Reserva telefónica bloquea habitación al instante
• Reserva web de prueba aparece sin redigitar
• Check-in y check-out cambian estados
• Saldo visible; pago registrable
• Housekeeping ve sucias post-checkout
• Orígenes creíbles
• Precio y soporte entendibles
• El equipo diría “lo usamos mañana”

Preguntas al proveedor

1. ¿Dónde se crea el walk-in en el producto real?
2. ¿La web crea la estancia o solo notifica?
3. ¿Hay bloqueo de doble reserva?
4. ¿Exporto mis datos si me voy?
5. ¿Qué fees no están en la mensualidad?
6. ¿Trial real o solo demo?
7. ¿Cuánto tarda un hotel de 20 habitaciones en operar el día a día?

Errores al “digitalizar la recepción”

1. Comprar módulos de moda antes del calendario confiable.
2. Mantener Excel “por si acaso”.
3. Reescribir web como walk-in.
4. Entrenar solo al gerente.
5. Medir éxito por contrato firmado, no por uso a 30 días.
6. Tres pantallas para crear la misma estancia.
7. Digitar de noche en vez de en vivo.

Dónde encaja FluxPMS

FluxPMS está orientado a hoteles independientes con operación de recepción clara, reservas web automáticas y evaluación self-serve. Pruébalo contra el checklist junto a dos alternativas; una mención de producto basta.

Conclusión

El programa para recepción útil es el que protege inventario, acelera walk-in y teléfono, muestra la web sin reescritura, y se usa en el turno de noche. Todo lo demás puede esperar. El futuro del PMS no es un Salesforce hotelero: es un mostrador que confía en su pantalla.

Siguiente paso: fluxpms.com/es/pricing.

Escenarios de recepción (y cómo el software debe responder)

Escenario A: Walk-in a las 22:00

Huésped llega sin reserva. Solo queda una doble. El programa debe mostrar disponibilidad real, crear la estancia en segundos, y opcionalmente hacer check-in. Si el sistema tarda o pide un “proyecto de cliente corporativo”, el personal abrirá el cuaderno.

Escenario B: Teléfono durante el check-in

Mientras haces una llegada, suena el teléfono para el próximo fin de semana. Debes poder abrir Nueva reserva, bloquear habitación, colgar, y volver a la llegada sin perder estado. Multitarea real de mostrador.

Escenario C: “Reservé en su web”

El apellido no coincide con lo que el huésped dice. Buscas por fecha, email o código de reserva. Si la web no creó la fila, el hotel improvisa y pierde confianza.

Escenario D: Salida con disputa de cargos

El saldo debe ser legible: noches, extras, impuestos si aplican, pagos parciales. Un programa de recepción no resuelve el conflicto humano, pero no debe ocultar la aritmética.

Métricas internas que importan al gerente

• Tiempo medio de walk-in.
• % de estancias creadas en vivo vs “subidas de noche”.
• Incidencias de “no aparece en el sistema”.
• Sobreventas o casi-sobreventas por mes.
• Adopción por turno (¿el de noche usa el mismo software?).

Si no mides adopción, mides marketing de software, no operación.

Formación mínima (2 horas, no 2 semanas)

1. Calendario: leer colores y filtros.
2. Walk-in y nueva reserva.
3. Buscar reserva web/OTA.
4. Check-in, pago, checkout.
5. Marcar housekeeping.
6. Qué no hacer (Excel paralelo, origen falso).

Documenta en una hoja, no en un LMS de 40 cursos.