Demostraciones de sistemas PMS para hoteles: prueba el sistema, no el discurso comercial

Todas las demostraciones de sistemas de gestión hotelera (PMS) que veas están ensayadas. Se ejecutan con datos ficticios, en un establecimiento sin historial, y las lleva a cabo alguien que utiliza el software todos los días laborables y sabe exactamente qué camino seguir para evitar las pantallas más complicadas. Nada de eso es deshonesto. Se trata simplemente de una presentación comercial, y una presentación comercial es prácticamente inútil a la hora de decidir con qué sistema PMS seguirá pudiendo trabajar tu equipo a las once de la noche de un sábado dentro de dieciocho meses.

La solución no es adoptar una actitud conflictiva. Es tomar el control de la agenda. Trae tus propios escenarios, tus propios datos desordenados y a tu propio personal, y esos mismos cuarenta y cinco minutos que te habrían mostrado un recorrido pulido te mostrarán, en cambio, cómo se comporta el producto cuando llega la realidad. Este artículo aborda la evaluación en sí misma: qué preparar, qué situaciones ponen de manifiesto los puntos débiles, qué preguntar, qué ignorar y cómo puntuarlo después sin engañarte a ti mismo. Se detiene donde comienzan las condiciones comerciales, porque lo que hay que comprobar en un contrato de PMS para hoteles es un trabajo aparte, al igual que la cuestión de si un motor de reservas incluido forma parte realmente de la licencia.

Lo que sigue a continuación se basa en el supuesto de un establecimiento independiente o de un pequeño grupo que no cuenta con departamento de compras. Si dispones de uno, la mayor parte de esto sigue siendo aplicable; simplemente habrá más personas presentes en la reunión.

Por qué todas las demostraciones parecen buenas

Entender por qué las demostraciones presentan el software de forma más favorable es la base fundamental para evaluarlo adecuadamente. Hay cuatro factores que juegan en tu contra, y ninguno de ellos implica que nadie se comporte mal.

Los datos son perfectos. Los establecimientos de las demostraciones tienen perfiles de huéspedes ordenados, sin duplicados, con códigos de tarifas coherentes y sin una acumulación de quince años de registros a medio migrar. Casi todas las dificultades reales de un sistema hotelero provienen de datos erróneos, ambiguos o históricos. No puedes ver cómo gestiona un producto esas situaciones observándolo manejar datos que no presentan ninguno de esos problemas.

Nada de lo relacionado con el segundo punto es exclusivo del software. El presentador es un usuario experto, y los usuarios expertos hacen que cualquier interfaz parezca coherente. Saben que lo que no puedes encontrar está tras un clic con el botón derecho, que el informe se encuentra en un menú diferente al que esperarías y que es mejor evitar cierta pantalla. Tu auditor nocturno no sabrá nada de esto durante la primera semana, y la brecha entre el experto y el novato es precisamente lo que oculta una demostración.

El recorrido está ensayado. Una demostración sigue una ruta elegida porque funciona. Todo producto tiene áreas más antiguas, más torpes o inacabadas, y ningún presentador se adentra en ellas voluntariamente. La ausencia de un tema es información, y se necesita un esfuerzo deliberado para darse cuenta de lo que no te han mostrado.

Estás predispuesto a que te guste. Para cuando llegas a una demostración, normalmente llevas semanas elaborando una lista de finalistas y quieres que la búsqueda termine. Ver a un presentador competente resolver problemas con fluidez resulta genuinamente persuasivo. Esa sensación no es una prueba.

Qué hacer antes de concertar una cita

La parte más valiosa de una evaluación tiene lugar antes de hablar con un solo proveedor, y es la que más a menudo se omite porque parece un retraso.

Anota qué es lo que realmente falla hoy. No las funciones que te gustaría tener, sino las cosas concretas que te han costado tiempo o dinero este mes. Una lista útil podría ser algo así: nos lleva dos horas introducir a mano la lista de habitaciones del grupo; el panel de limpieza es una hoja impresa que queda desactualizada en diez minutos; no podemos ver los ingresos netos por canal sin una hoja de cálculo; y la auditoría nocturna falla cada vez que se deja abierto un folio. Esa lista vale más que cualquier matriz de características, porque es lo único que te dirá después si un sistema ha resuelto tus problemas o si simplemente tenía muchas características.

A continuación, divide la lista en tres grupos. Cosas que deben funcionar o, de lo contrario, el establecimiento no podrá operar. Cosas que ahorrarían tiempo real y cuantificable. Y cosas que serían un plus. Sé estricto, porque todo tiende a subir en la lista si lo permites, y una lista de requisitos en la que todo sea esencial no ofrece ninguna base para elegir entre dos productos que cubren la mayor parte de esas necesidades.

Hay otros dos pasos de preparación que merecen la pena. Anota las integraciones con el PMS del hotel de las que realmente no puedas prescindir, indicando los productos y versiones específicos, ya que el logotipo de un socio en una página web no es lo mismo que una conexión certificada y operativa. Y decide quién tomará la decisión antes de empezar, porque una evaluación que termina en un comité sin un responsable tiende a acabar sin ninguna decisión, o con la opción que prefiera la persona que más grite.

Toma el control de la agenda

Cuando reserves la demostración, envía al proveedor un breve resumen por escrito con varios días de antelación. Entre cuatro y seis escenarios extraídos de tu propia actividad, una frase por cada uno, además de tu lista de requisitos imprescindibles y tu lista de integraciones. Si puedes proporcionar una muestra anonimizada de tus propios datos, envíala también.

Explica claramente cómo quieres que se desarrolle la sesión. Algo así como: veinte minutos para la presentación general estándar, después repasamos nuestros escenarios y nos gustaría que uno de los miembros de nuestro equipo tomara las riendas en la última parte. La mayoría de los proveedores lo aceptan de buen grado, y los que se resisten ya te han dado una pista útil antes de que empiece la reunión.

Esto no tiene por objeto tender una emboscada a nadie. Se hace porque una demostración preparada de tus escenarios es mucho más informativa que una improvisada, y porque la forma en que un proveedor aborda el briefing es en sí misma una señal. La respuesta adecuada es una llamada previa para preguntar qué entiendes por dos de los escenarios. Así es como se percibirá la implementación: alguien que intenta comprender tu funcionamiento en lugar de adaptarlo a su plantilla.

Una nota práctica sobre la grabación. Pregunta si puedes grabar la sesión y, si la respuesta es afirmativa, hazlo. Tres demostraciones se confunden entre sí en quince días, y la respuesta concreta a una pregunta concreta es precisamente lo que querrás comprobar más adelante, sobre todo si resulta haber sido optimista.

Los escenarios que realmente revelan un sistema

Los buenos escenarios comparten una característica: son habituales en un hotel, pero complicados en el ámbito del software. Cualquier sistema puede gestionar una reserva sencilla. Lo que distingue a los sistemas es lo que ocurre cuando la situación es complicada, que es lo habitual.

La llegada que no coincide con la reserva

Un huésped llega un día antes, para quedarse tres noches en lugar de dos, quiere un tipo de habitación diferente y la reserva se realizó a través de una agencia con una tarifa que no se aplica a las nuevas fechas. Pídeles que se encarguen de ello de principio a fin.

Fíjate en si la reserva se modifica o se cancela y se vuelve a crear, ya que al volver a crearla se pierde el historial y el registro de la tarifa original. Fíjate en qué ocurre con la comisión de la agencia, si la tarifa se recalcula o hay que modificarla manualmente, y si para esa modificación se necesita la intervención de un responsable. Después, haz la pregunta que realmente importa: ¿podrás ver mañana cuál era la reserva original y quién la modificó? Los sistemas que gestionan las modificaciones descartando el historial hacen que las disputas sean irresolubles.

La factura que nadie quiere dividir

Dos compañeros de trabajo comparten una habitación doble. La empresa paga la habitación y el desayuno de ambos, ellos pagan sus propios extras y uno de ellos ya ha abonado un depósito por internet. A la hora de salir del hotel, uno quiere una factura única para su empresa y el otro quiere un recibo personal.

Esto es habitual en cualquier hotel que trabaje con empresas, donde el saldo suele recaer en el «city ledger», y es ahí donde las deficiencias contables se ponen de manifiesto de inmediato. ¿Se pueden distribuir los cargos por tipo antes de la llegada, en lugar de tener que desenredarlos al hacer el check-out? ¿Se puede dividir un folio entre los distintos pagadores sin tener que volver a introducir los datos? ¿Se aplica el depósito a la cuenta correcta? ¿Se pueden generar dos documentos con el tratamiento fiscal correcto en ambos? Si esto le lleva al usuario experto varios minutos y requiere una solución alternativa, recuerde que su recepcionista tendrá que hacerlo con una cola de clientes a sus espaldas.

El grupo que cambia dos veces

Un bloque de quince habitaciones se reduce a once antes de la fecha límite; luego, cambian dos nombres y una se convierte en una habitación doble. Pide ver todo el proceso: la configuración del bloque, la lista de habitaciones, la reducción, la liberación del inventario y cómo queda la factura del grupo al final.

Los aspectos concretos a tener en cuenta son si las habitaciones liberadas vuelven a ponerse a la venta automáticamente, si la lista de asignación de habitaciones se puede importar o hay que introducirla manualmente, y si las bajas se registran según el contrato o dependen de la memoria de alguien. La gestión de bloques de grupos en los hoteles es una de las mayores diferencias de calidad entre los sistemas hoteleros y uno de los temas que menos suele aparecer en una demostración estándar.

La auditoría nocturna y la mañana siguiente

Pide que te muestren cómo se realiza una auditoría nocturna del hotel con algún error: un folio abierto, un cargo no contabilizado, una autorización de tarjeta fallida. A continuación, pregunta cómo es el informe de la mañana.

Las preguntas útiles son si la auditoría se bloquea ante el error o lo pasa por alto sin avisar, si se puede volver a ejecutar en caso de que se haya pasado algo por alto y quién debe corregir lo que detecte. Pregunta también qué ocurre si no se ejecuta en absoluto, algo que sucede con más frecuencia de lo que nadie admite. Un sistema que trata la auditoría nocturna como una ceremonia irreversible resulta más difícil de gestionar que uno que la considera un proceso repetible.

Merece la pena añadir dos escenarios más si tienes tiempo: un cambio de tarifa que debe llegar a todos los canales, para que puedas ver la ruta de distribución de principio a fin y cuánto tarda en propagarse, que es donde surgen los problemas de sincronización entre el gestor de canales y el PMS; y una cancelación el mismo día con un cargo en la tarjeta, un reembolso parcial y una queja del huésped, lo que te muestra conjuntamente la ruta de pago y el registro de auditoría.

Cuenta los clics, no las pantallas

Incorpora una forma de registrar dos cifras para cada escenario: cuántos pasos se han dado y cuánto tiempo han tardado. No para que nadie tenga que estar pendiente del cronómetro, sino porque esas cifras son la única parte de una demostración que se puede comparar entre tres proveedores quince días después, cuando todo lo demás se ha convertido en una simple impresión.

Pon en perspectiva el resultado en función de la frecuencia. El registro se realiza cientos de veces al mes. Si un sistema requiere cuatro clics y otro nueve, esa diferencia supone trabajo real, repetido por personas cansadas, una y otra vez. Un informe mensual que lleva dos minutos más importa mucho menos. Ponderar por frecuencia es lo que evita que un ejercicio de puntuación se vea dominado por la característica que se haya demostrado de forma más impresionante.

Presta atención a tres aspectos concretos mientras cuentas. Cuánto del trabajo se realiza en una sola pantalla en lugar de en varias, ya que el cambio de contexto es donde se producen los errores. Si el sistema previene los errores o simplemente los notifica a posteriori, ya que una advertencia antes de una doble reserva vale mucho más que un informe que la recoja. Y cómo se comporta el producto cuando algo sale mal: un mensaje claro que explique qué ha pasado y qué hay que hacer a continuación es señal de un producto maduro, mientras que un aviso genérico de fallo es señal de lo contrario.

Quién debería estar presente

El error más común en la evaluación es que la realice la persona que menos va a utilizar el sistema. Los directivos eligen, y los recepcionistas tienen que vivir con ello.

Incluye a las personas que lo utilizarán a diario. Un supervisor de recepción, quien se encargue del servicio de limpieza, quien gestione el dinero y, si lo hay, quien se ocupe de los ingresos y la distribución. Cada uno de ellos planteará una pregunta en la que tú no habrías pensado y se dará cuenta de cosas que a ti se te escapan: tu auditor nocturno detectará en noventa segundos que la rutina de cierre tiene un paso que no se puede deshacer.

Dales instrucciones concretas en lugar de una simple invitación a asistir. Pide a cada persona que evalúe un aspecto concreto, que lo anote durante la sesión y que lo comparta inmediatamente después. De lo contrario, la reunión generará una impresión general, y las impresiones generales suelen estar dominadas por quien habla primero.

Hay un segundo beneficio, más sutil. Las personas a las que se ha consultado durante la selección se comportan de manera diferente durante la puesta en marcha. La resistencia al cambio en los hoteles a menudo no tiene nada que ver con el software; se debe a que la decisión se ha tomado en otro lugar y se ha impuesto desde arriba. Dedicar una hora a una demostración genera una cantidad sorprendente de buena voluntad más adelante.

Preguntas que obtienen respuestas sinceras

Las preguntas abiertas obtienen respuestas de marketing. Las preguntas específicas obtienen información. La diferencia radica exclusivamente en la forma de formularlas.

Hay dos preguntas que vale la pena plantear a cualquier proveedor, ya que las respuestas son muy reveladoras. ¿En qué no destacáis, o qué es lo que los clientes suelen pedir con más frecuencia y que vosotros no ofrecéis? Un proveedor que mencione algo concreto te está diciendo la verdad y suele ser el socio más fiable. Un proveedor al que no se le ocurra nada o bien no está escuchando a sus clientes o bien no te lo está contando.

Y además: ¿qué tipo de hotel no es adecuado para vosotros? Cada producto tiene su perfil. Un sistema diseñado para hoteles de negocios en el centro de la ciudad no funcionará bien en un complejo turístico con actividades, tratamientos de spa y media pensión, y los buenos proveedores lo saben y os lo dirán, en lugar de venderos un primer año complicado.

Señales de alerta durante una demostración

Hay señales que merecen más atención que la lista de características, y la mayoría de ellas tienen que ver con el comportamiento más que con el software.

Desviar un escenario a una sesión posterior. Una vez está bien, ya que puede que realmente haya que configurar algo. Aplazar repetidamente los escenarios complicados significa que esos escenarios son complicados para el producto.

Responder a una pregunta sobre una funcionalidad con una fecha de la hoja de ruta. Trata todo lo que aún no se haya lanzado como si no existiera. Puede que llegue; mientras tanto, no puedes gestionar un hotel con ello.

Diapositivas donde se esperaba ver una pantalla. Si un módulo se presenta como un diagrama en lugar de como una pantalla en funcionamiento, pide que te lo muestren en acción. A veces la respuesta es que está en fase beta, lo cual está bien saberlo, pero es arriesgado darlo por hecho.

Presión vinculada a un plazo. Los descuentos que caducan esta semana son una técnica de venta, no una realidad comercial. Un proveedor que confía en su producto no necesita que te decidas antes de que hayas terminado de evaluarlo, y vale la pena recordar esto cuando llegues a la fase de contratación.

Imprecisión sobre quién realiza el trabajo. Pregunta quién se encargará de tu implementación, si son empleados del proveedor o de un socio, y cuántas propiedades gestionan a la vez. La calidad de la implementación varía más entre personas que entre productos.

Falta de disposición a concederte acceso. Un proveedor que no te permita acceder a un entorno de pruebas te está pidiendo que compres un sistema que tu equipo nunca ha probado.

El entorno de pruebas es donde reside la verdad

Si te quedas con una sola cosa de este artículo, que sea esta: una demostración guiada te muestra lo que el software puede hacer; un entorno de prueba te muestra lo que tu equipo puede hacer por sí mismo, y solo este último permite predecir si la implementación tendrá éxito.

Solicita un entorno de prueba para tus dos finalistas, a ser posible cargado con una muestra de tus propios datos, durante una o dos semanas. Cargar esa muestra también es una primera indicación de cómo se desarrollaría realmente una migración del PMS. A continuación, asigna a tu equipo tareas reales en ese entorno en lugar de dejar que simplemente exploren. Explorar no es una tarea y no produce nada comparable.

Establece la misma lista reducida de tareas en ambos sistemas: crear y registrar una reserva, dividir un folio, modificar un grupo, realizar una auditoría nocturna, elaborar el informe que el propietario solicita cada mes. Pide a cada persona que anote en qué se ha atascado y sobre qué ha tenido que preguntar. A continuación, compara las notas en lugar de las opiniones.

Presta especial atención a quién tiene dificultades. Si a tu recepcionista con más experiencia le resulta confuso algo, se trata de un problema del producto. Si el miembro del personal con menos confianza tiene dificultades con todo, se trata de una cuestión de formación y de un tipo diferente de coste, que, aun así, conviene conocer antes de comprometerte.

Ten cuidado con una trampa. Un sistema que resulta familiar no es lo mismo que un sistema que es bueno, y los equipos suelen preferir aquello que más se parece a lo que ya utilizan. Pregúntate si algo es realmente peor o simplemente diferente, y sé sincero con la respuesta, porque la familiaridad se desvanece en unas pocas semanas y un mal diseño no.

Llamadas de referencia y cómo ir más allá de la «lista de clientes satisfechos»

Todos los proveedores tienen una lista de clientes que dirán cosas positivas. No es ningún escándalo; tú harías lo mismo. La tarea consiste en obtener información útil de una conversación organizada por el proveedor.

Pide referencias que se parezcan a tu caso: tamaño similar, segmento similar, integraciones similares y, a ser posible, una que se haya puesto en marcha en los últimos doce meses, para que el recuerdo de la implementación esté fresco. A continuación, haz preguntas que no se puedan responder con un simple «sí» o «no».

¿Qué te sorprendió tras la puesta en marcha? ¿Cuánto tiempo llevó realmente la implementación en comparación con la estimación? ¿A qué has renunciado al intentar hacer en el sistema? Cuéntame una ocasión en la que el servicio de asistencia fuera realmente importante y qué ocurrió. ¿Qué comprobarías si tuvieras que volver a elegir? Cada una de estas preguntas genera una historia en lugar de una valoración, y las historias contienen detalles que las valoraciones no ofrecen.

A continuación, ve un poco más allá de la lista. Pregunta directamente al proveedor si algún cliente se ha dado de baja en el último año y por qué; es una pregunta que da lugar a una respuesta sincera o a un silencio revelador. También merece la pena preguntar a comunidades hoteleras independientes y asociaciones regionales, y una sola conversación con alguien que utilice exactamente la misma combinación de sistemas que tú vale más que cualquier cantidad de material publicado.

Cómo abordar una promesa de hoja de ruta

En algún momento de toda evaluación, se responderá a una carencia con un plan. La respuesta adecuada no es ni descartarla ni confiar en ella.

Compra el producto tal y como está hoy. Si la carencia es realmente fundamental, la conclusión honesta es que este sistema aún no se adapta a tus necesidades, por muy creíble que sea el plan. Los plazos de desarrollo de software se retrasan en todos los sectores y una fecha de entrega indicada durante el proceso de venta es una intención, no un compromiso.

Si decides seguir adelante de todos modos, haz que la promesa sea real. Consíguelo por escrito con una fecha, adjúntalo al contrato como anexo y pregunta qué pasará si no se cumple. Un proveedor verdaderamente comprometido a lanzar algo en los próximos dos trimestres suele incluirlo en un documento. El que no lo haga te habrá dejado claro cuán firme es su plan.

Una pregunta útil para evaluar la situación no cuesta nada: ¿qué habéis entregado en los últimos doce meses y qué figuraba en la hoja de ruta hace un año que aún no se ha materializado? Un proveedor que responda a eso con naturalidad es una apuesta más segura que uno que solo hable de lo que está por venir.

Puntuación sin engañarse a uno mismo

Las matrices de puntuación son útiles por una razón y peligrosas por otra. Obligan al equipo a registrar sus valoraciones mientras la memoria está fresca, lo cual es realmente valioso. También arrojan una cifra que parece objetiva y no lo es, porque las ponderaciones las han elegido personas con sus propias preferencias.

No te compliques. Puntúa según la lista de requisitos imprescindibles que redactaste antes de hablar con nadie, ponderando en función de la frecuencia con la que ocurre cada cosa, y que cada asistente puntúe su propia área en lugar de todo. Anota el número de clics y las notas de la prueba junto a las puntuaciones, en lugar de incluirlas en ellas.

A continuación, considera el total como una indicación, no como un veredicto. Si el ganador por puntos no es el que tu equipo quiere utilizar, no te limites a pasar por encima de la opinión del equipo; averigua por qué existe esa diferencia. Normalmente se debe a una de estas tres cosas: se ha omitido algo importante en la matriz, una ponderación es errónea o la preferencia se basa en la familiaridad en lugar de en la calidad. Vale la pena conocer las tres y ninguna se resuelve con simples cálculos aritméticos.

Hay una disciplina que conviene imponer. Escribe un breve párrafo explicando la decisión antes de firmar nada, indicando a qué estás renunciando al no elegir las demás opciones. Si te cuesta escribir ese párrafo, la evaluación no está terminada. Si te resulta fácil, te alegrarás de tenerlo dentro de dieciocho meses, cuando alguien pregunte por qué el hotel ofrece lo que ofrece.

Convertir una evaluación en una decisión

Las evaluaciones no suelen fracasar porque haya ganado el sistema equivocado. Fracasan porque nunca terminan: la lista de finalistas crece, aparece una nueva opción, la persona que la impulsa se ve ocupada y, un año después, el hotel sigue utilizando lo mismo que antes, con los mismos problemas en la misma lista.

Establece el calendario desde el principio y cúmplelo. Para un establecimiento independiente, de una a dos semanas de preparación, dos o tres semanas de demostraciones con guion, de una a dos semanas de pruebas en entorno de pruebas con llamadas de referencia realizadas en paralelo, y luego una semana para decidir. Eso supone aproximadamente entre seis y ocho semanas, y es suficiente. Acortarlo suele significar prescindir de la fase de pruebas, que es la parte que realmente predice el resultado. Alargarlo más allá de un trimestre significa empezar de nuevo.

Hay dos cosas que conviene decidir antes de la reunión final. Qué te haría descartar al favorito, acordado de antemano para que no se pueda justificar a posteriori. Y quién firma, para que la decisión tenga un responsable en lugar de recaer en un comité. El precio también debe formar parte de esa conversación, pero como coste total de propiedad a lo largo del plazo, en lugar de como cuota mensual.

A continuación, pasa a la fase comercial con la evaluación aún en la mano. Todo lo que hayas aprendido sobre tiempos de respuesta, alcance de la implementación, certificación de integración y compromisos de la hoja de ruta debe quedar plasmado en la documentación, y no solo en el recuerdo de una buena reunión. La brecha entre lo que se dijo en una demostración y lo que figura en un acuerdo es, en realidad, el origen de la mayor parte de la decepción tras la compra, y cerrarla es la última tarea que la evaluación te debe.