Quién cuenta como huésped en tu CRM

Cada reserva que entra en tu CRM trae al menos una cadena con forma de persona: una dirección de correo electrónico, un número de teléfono, un nombre, a veces una fecha de nacimiento. La suposición natural es que cualquier cadena con esa forma es un huésped y debería convertirse en un registro de contacto sobre el que puedas construir un perfil, enviar correos electrónicos y fusionar con todo lo demás que sabes de esa persona.

Esa suposición falla lo bastante a menudo como para importar, y lo hace de una forma estructural muy concreta que una simple pasada de deduplicación nunca detecta, porque la deduplicación solo se ejecuta sobre contactos que ya existen. La CDP de GuestMaker tiene una capa colocada delante de eso: la Capa de Identidad. Su trabajo es más acotado de lo que parece. No intenta averiguar quién es un huésped. Decide, para cada identificador que llega con una reserva, si ese identificador puede convertirse en contacto desde el principio.

Dos preguntas, no una

El error que motivó esta capa es fácil de describir, porque lo hemos visto cometer. Un enfoque anterior hacía una sola pregunta a cada identificador: si era válido o inválido. Una bandera, un veredicto. Es un impulso razonable hasta que miras lo que «válido» tiene que cubrir en realidad, porque bajo esa etiqueta hay dos preguntas distintas.

La primera es la identidad. ¿Puede usarse este valor para reconocer a una persona real, con la fiabilidad suficiente para que sea seguro inferir que «estas dos reservas pertenecen al mismo huésped»? La dirección de correo electrónico propia de un huésped suele pasar la prueba. Un buzón compartido que un mayorista utiliza en las reservas de cientos de huéspedes distintos no la pasa, por legítima que sea la reserva que hay detrás.

La segunda es la capacidad de contacto. ¿Puedes escribir de verdad a ese valor, y hasta dónde? A nada en absoluto. Solo a mensajes transaccionales, como una confirmación o un enlace de check-in. O a marketing completo, el tipo de dirección que te sentirías cómodo incluyendo en un segmento de newsletter seis meses después del checkout.

Estas dos preguntas no siempre coinciden, y un sistema que las reduce a un único veredicto se equivoca en una dirección concreta y previsible: trata un fallo en la comprobación de identidad como permiso para eliminar también la capacidad de contacto. Ese es el error. Un alias de reenvío generado por una OTA falla de lleno en identidad. No es una forma estable de reconocer a una persona en reservas separadas. Pero detrás hay un huésped real, y ese huésped sigue necesitando recibir un correo electrónico de confirmación, aunque el alias no pueda vincularse nunca de forma segura con ninguna otra reserva suya. Si bloqueas por identidad, la capacidad de contacto muere con ella y el huésped nunca recibe su confirmación.

La solución es mantener los dos ejes independientes durante todo el sistema, y exigir que cada regla emita su veredicto sobre ambos, no sobre uno solo.

Cuatro formas, y qué pasa si te equivocas

Ordena lo que llega realmente en un feed de reservas según estos dos ejes, y aparecen una y otra vez unas pocas formas reconocibles.

La inmensa mayoría, en torno al 97% de todos los identificadores que observa el sistema, es el caso aburrido: una dirección o un número real y propio del huésped, válido para identidad, válido para contacto, sin necesidad de tratamiento especial. Conviene decirlo con claridad, porque es fácil diseñar todo un sistema alrededor de las excepciones y perder de vista que son excepciones. La mayor parte de lo que hay en tu CRM es exactamente lo que parece.

El resto, aproximadamente el 3%, es donde esta capa demuestra su valor. Cuatro formas lo cubren.

Un buzón de agencia o turoperador aparece en las reservas de cientos de huéspedes distintos a través de una misma bandeja compartida. Falla en identidad, porque no puedes distinguir a un huésped de otro detrás de él, y falla en capacidad de contacto, porque no es una persona a la que debas escribir directamente. La reserva y el huésped se siguen guardando completos. No se crea ningún registro de contacto a partir de esa dirección, y nunca se usa para fusionar huéspedes entre sí.

Un alias de reenvío de una OTA, del tipo que Booking.com genera nuevo para cada reserva, parece basura y no lo es. Falla en identidad por la misma razón estructural, no puede rastrearse entre reservas separadas, pero pasa la prueba de contacto, al menos durante la estancia. Debe recibir la confirmación de la reserva, la información previa a la estancia y el mensaje de check-in. Deja de recibir cualquier cosa después, porque el propio alias caduca en el checkout.

Un marcador de posición, el tipo de valor que el personal de recepción escribe cuando un huésped no facilita un correo electrónico real (algo con la forma de «noemail@gmail.com»), falla en ambos ejes. Sin una regla que lo detecte específicamente, todos los huéspedes de un hotel que rechazan dar un correo electrónico acaban colapsados en un único contacto ficticio que, supuestamente, se ha alojado cientos de veces.

Y luego está el caso normal, que es la mayor parte de lo que queda una vez filtrados los otros tres.

Dentro de ese 3% filtrado, el alias de reenvío de OTA es, con diferencia, la parte más grande, en torno al 79%. Le siguen los buzones de agencias y turoperadores, alrededor del 8%. Las cuentas de rol, las direcciones tipo info@ y reservas@ que corresponden a un mostrador y no a una persona, tienen una magnitud similar, alrededor del 6%. Lo que queda, direcciones institucionales, números de teléfono mal formados, el dominio propio de un hotel apareciendo como si fuera un huésped, un campo de documento que trae el valor equivocado, supone una pequeña fracción por separado.

Seis piezas, en orden

La Capa de Identidad no es una sola regla. Es una canalización, y cada pieza existe porque la anterior no basta por sí sola.

Las observaciones van primero. Cada reserva, contacto o registro de huésped que afirma algo sobre una persona queda registrado. Esta es la base de evidencias sobre la que razona todo lo que viene después. Todavía no es un juicio, solo el registro de que alguien afirmó algo.

El juicio sobre identificadores convierte observaciones en un veredicto. Cada correo electrónico, número de teléfono, documento o nombre se puntúa en función de la evidencia: cuántas veces se ha visto, cuántos nombres distintos lleva asociados, si el patrón parece exclusivo de una persona o compartido y promiscuo entre muchas.

Las reglas de identificadores convierten los juicios en un libro de registro duradero de dos niveles. Las reglas de plataforma capturan los casos obvios y comunes, las formas descritas antes, aplicadas a todos los grupos hoteleros. Las reglas específicas de cada grupo hotelero recogen lo particular de cada grupo: sus propias agencias contratadas, sus propios dominios, sus propios hábitos de recepción.

La puerta es donde se aplican las reglas, en el momento en que entran los datos. Aquí merece la pena ser preciso, porque es la parte que más preocupa. La reserva siempre se guarda completa. El registro de huésped siempre se guarda completo. Lo único que la puerta puede retener es el registro de contacto, aquello que permitiría buscar, segmentar y enviar correos a este identificador como si perteneciera a una persona conocida. Nunca se pierde ningún dato de reserva. El sistema simplemente rechaza inventarse una persona que probablemente no existe.

La fusión de contactos es el motor posterior que unifica duplicados una vez que ya existen contactos reales. Se explica con más detalle en el registro dorado que unifica el historial de un huésped en todos los hoteles; descrito de forma general, los casos claros se fusionan automáticamente, los ambiguos pasan a una cola para que los revise una persona, y toda fusión es reversible.

La fusión de huéspedes y huéspedes de reserva gestiona a los acompañantes, las personas incluidas en una reserva que no son quienes la hicieron. Se vinculan a sus propios registros de contacto cuando la evidencia lo respalda, con una salvaguarda que conviene nombrar directamente: dos personas que comparten una misma dirección de correo electrónico en la misma reserva, una pareja que reserva junta es el caso evidente, no se colapsan en una sola persona solo porque compartan una bandeja de entrada. Compartir una dirección en una reserva no afirma lo mismo que ser la misma persona.

La parte difícil de enseñar a un grupo hotelero

Hay una propiedad de este sistema que lo convierte en algo verdaderamente incómodo de demostrar, y merece la pena nombrarla en vez de pasar por encima: una regla que funciona destruye la evidencia que justificó construirla.

Antes de que exista una regla para detectar, por ejemplo, el buzón compartido de un mayorista concreto, cada reserva que llega por ese canal crea un nuevo contacto ficticio. Eso se ve. Aparece como un pico en el número de contactos, como un «huésped» que supuestamente se ha alojado en tu hotel docenas de veces, como un segmento silenciosamente equivocado. Es un problema que puedes señalar y enseñar a alguien.

Una vez que la regla está activa, ese canal deja de crear contactos. El pico no se produce. El huésped ficticio nunca se crea. Y como nunca se crea, no hay nada nuevo que enseñar como prueba de que la regla esté haciendo algo. El valor está por completo en lo que no llegó a ensuciarse desde el principio, y los datos que nunca se ensuciaron no aparecen en ningún informe que ejecutarías para comprobarlo.

Eso no es un motivo para desconfiar del sistema. Es un motivo para medirlo de forma distinta a la mayoría de las funciones de CRM. No verás la salida de esta capa en un panel, porque su salida, por diseño, es la ausencia de una categoría de fila mala. Si quieres verla funcionando, la forma honesta es mirar lo que detectaba antes de que existiera la regla y confiar en que esa misma forma de cosa sigue llegando y ya no aterriza donde no debe.

Dónde encaja

Esta capa se ejecuta antes de que cualquier otra parte de tu CRM toque a un huésped. No resuelve la identidad entre hoteles (de eso se encarga el registro dorado más adelante), ni te dice si un huésped ya ha llegado, ni resume lo que sabes de él. Esas tareas corresponden a todo lo demás que hace una plataforma de datos de clientes. Son preguntas posteriores, y solo reciben buenas respuestas si la población de contactos que las alimenta era sólida desde el principio.

Trátala como la puerta que es. Lo que pasa por ella es aquello en lo que el resto de tu CRM está construido para confiar.