La huésped que parece diez personas: por qué el correo electrónico por sí solo no detecta tus duplicados

Una huésped ha reservado diez veces en el mismo grupo hotelero en tres años. Pregunta a la base de datos cuántas veces se ha alojado y te dirá: una. Después lo repetirá nueve veces más, sobre otras nueve mujeres a las que nunca ha conocido.

No son otras nueve mujeres. Es una sola huésped, y el canal de reserva que utiliza le entrega una dirección de correo electrónico nueva y desechable cada vez que hace el check-out. Parece una cadena de caracteres aleatorios seguida de un dominio genérico, inventada por una plataforma creada para proteger su privacidad, no para ayudar a un hotel a reconocerla. Ya explicamos por qué un grupo hotelero con decenas de recepciones separadas acaba con una misma huésped repartida entre otros tantos registros distintos. Esta es la versión más extrema de ese problema. No una huésped dividida entre propiedades, sino una huésped dividida dentro de su propia historia, diez veces, por el mismo canal que la sigue trayendo de vuelta.

El cruce basado solo en el correo electrónico no puede ver más allá de esto, porque nunca se diseñó para hacerlo. Un sistema que interpreta "mismo correo electrónico" como "misma huésped" conservará diez instantáneas perfectas y aisladas de una viajera fiel, y recibirá a cada una como a una desconocida que acaba de entrar por la puerta. Cada mensaje de bienvenida sonará como una primera cita. Cada cálculo de fidelización empezará desde cero. La huésped que más merece un trato personal es la que peor entiende el modelo de datos. Ese es exactamente el vacío que una plataforma de datos de clientes hoteleros viene a cerrar: reconocer a una misma huésped bajo cada disfraz que un canal de reserva le ponga delante.

La solución no consiste en esforzarse más con el correo electrónico

Crear un analizador de correos electrónicos más inteligente no resolverá esto, porque el correo electrónico nunca iba a bastar por sí solo. Un grupo hotelero necesita mirar todo lo que una huésped deja a lo largo de una estancia, no solo el campo que un canal de reserva haya generado esa semana.

Un número de teléfono, cuando la huésped lo facilita, suele ser más duradero que un alias desechable. Un número de pasaporte o de documento de identidad pertenece a una persona y no cambia entre visitas. E incluso sin ninguno de esos datos, un nombre combinado con una fecha de nacimiento, una nacionalidad y un género empieza a describir a un ser humano concreto, no a un formulario de reserva. Ninguna de esas señales es infalible por sí sola. Juntas, a lo largo de suficientes estancias de una huésped, permiten que un sistema reconozca a la misma persona cuando vuelve, incluso si el campo que "debería" coincidir, el correo electrónico, es distinto cada vez.

Cuando se agotan las señales fuertes, una capa adicional de revisión mira los nombres como lo haría una persona: no buscando una coincidencia exacta de caracteres, sino evaluando si dos nombres podrían pertenecer razonablemente a la misma huésped, escritos con pequeñas diferencias, transliterados desde otro alfabeto o abreviados de la forma natural en que un nombre se acorta a lo largo de años de reservas. Así es como diez desconocidas se convierten en una huésped con diez estancias, un historial de fidelización y un número al que de verdad merece la pena llamar.

Después está el error contrario, y es peor

Si resuelves el problema de los correos electrónicos desechables con demasiada agresividad, abres la puerta a un segundo fallo más peligroso. Un identificador compartido no aparece solo porque un canal lo haya fabricado. También aparece porque un recepcionista, al hacer el check-in de una familia de cuatro, escribió el mismo correo electrónico en el registro de cada huésped de la reserva porque era más rápido que preguntar a cada persona por separado.

Ese atajo coloca una única dirección de correo electrónico en la esposa, el marido, una hija adolescente y un compañero que viaja con ellos, todos dentro de una misma reserva. Si una dirección compartida así debería poder identificar alguna vez a alguien es una cuestión que se resuelve antes de que empiece el cruce, y esto es lo que falla cuando no se hace. Un sistema que trata un correo compartido como prueba de una identidad compartida mirará esa reserva y verá a una huésped haciendo el check-in cuatro veces. Fundirá a un marido y una mujer en un único perfil. Mezclará el historial de estancias de una hija con el de uno de sus padres. Una vez ocurre, el daño se acumula en silencio: un mensaje pensado para la hija llega al teléfono del padre, un saldo de fidelización ganado por una huésped lo gasta otra persona, y nadie se da cuenta hasta que un huésped llama a recepción confundido por una estancia que nunca hizo.

Este fallo debería preocupar a un grupo hotelero más que los correos electrónicos desechables, porque va en la dirección contraria y es más difícil de detectar. No encontrar una coincidencia solo deja a una huésped fiel con aspecto de desconocida. Equivocarse en una coincidencia significa que el registro dorado da por cierta, de forma activa y equivocada, la identidad de una persona, y que todos los sistemas posteriores, desde el CRM de contactos hasta el próximo envío de WhatsApp, heredan ese error sin saberlo.

Un identificador compartido es un motivo para mirar más de cerca, no para fusionar más deprisa

La respuesta a ambos tipos de fallo nace del mismo principio, aplicado en direcciones opuestas. Un identificador coincidente es una señal fuerte, pero no es una prueba, y en cuanto los nombres asociados dejan de sonar como los de la misma persona, el sistema debe ir más despacio, no más rápido.

Dos huéspedes que comparten un correo electrónico y cuyos nombres todavía podrían pertenecer a una sola persona, un nombre de pila abreviado, una grafía transliterada, una errata, se emparejan automáticamente. Ese es el caso sencillo, y cubre la inmensa mayoría de los duplicados reales. Pero dos huéspedes que comparten un correo electrónico y cuyos nombres divergen con claridad, un "Marco" y una "Elena" asociados a la misma dirección, se retienen para una revisión más atenta en lugar de fusionarse al instante. La misma cautela se aplica cuando dos huéspedes aparecen en la misma reserva: los acompañantes suelen compartir apellido, nacionalidad e incluso fechas de viaje, y nada de eso los convierte en la misma persona. Una reserva con dos nombres se trata como lo que casi siempre es: dos personas que viajan juntas, no una huésped haciendo el check-in dos veces.

Aun así, en estos casos más difíciles los perfiles de huéspedes se fusionan, a menudo correctamente. El sistema no se desentiende ni deja un probable duplicado sin resolver para siempre. Aplica una capa de criterio adicional y más deliberada a esa pareja concreta, igual que un buen responsable de recepción se detendría ante un registro extraño y lo leería de verdad antes de asumir nada.

Nada se fusiona en silencio, y nada permanece fusionado por error

La otra mitad de hacerlo de forma responsable consiste en negarse a tratar cualquier fusión como definitiva y no revisada. Cada decisión que toma el motor de coincidencias, fusionar, retener para revisión, mantener dos perfiles separados, queda registrada: qué campos coincidieron, qué confianza tenía la coincidencia y por qué. Cuando dos perfiles se combinan, el registro resultante conserva qué hotel y qué entrada original de huésped aportaron cada campo, de modo que un correo electrónico o un número de teléfono en el perfil de una huésped siempre puede rastrearse hasta la reserva de la que realmente salió.

Ese rastro existe por una razón. La coincidencia automática entre decenas de miles de huéspedes y decenas de propiedades se equivocará de vez en cuando en un caso difícil, y fingir lo contrario sería poco honesto. Lo que distingue a un sistema fiable de uno temerario no es prometer cero errores. Es si un error, una vez detectado, ya sea por una comprobación rutinaria o porque un huésped llama confundido, puede rastrearse hasta la decisión exacta que lo causó y deshacerse limpiamente, sin que nadie tenga que adivinar cómo era el registro antes.

Una suposición que resulta ser errónea desaparece en el momento en que se hace, indistinguible de una correcta hasta que algo se rompe. Una decisión razonada, incluso cuando se equivoca, deja detrás las pruebas necesarias para detectarla y corregirla.

Qué gana un grupo hotelero con esto

Cuando esto se hace bien, el efecto es casi aburrido de describir: una huésped que se ha alojado diez veces aparece en el CRM como exactamente lo que es, una persona con diez estancias, localizable a través del canal que realmente haya utilizado, con un historial que hace que el siguiente mensaje de bienvenida suene como si la recordara. Una familia que viaja junta aparece como cuatro personas separadas, cada una con sus propias preferencias y su propio historial de comunicación, no como una identidad con cuatro caras.

Nada de eso aparece como una gran métrica destacada. Aparece como un mensaje de cumpleaños que llega al teléfono correcto, un saldo de fidelización que refleja una relación real en lugar de un fragmento de ella, y un recepcionista que, en la siguiente visita de una huésped, no pregunta cosas que ya se respondieron nueve veces antes, o un conserje con IA capaz de saber si ella ya ha llegado de verdad en lugar de adivinarlo a partir de un perfil disperso. Para eso sirve una plataforma de datos de clientes construida para la forma en que los hoteles reciben reservas en la práctica: no solo para ver más sobre una huésped, sino para ser lo bastante cuidadosa en cómo llega hasta ahí como para que la imagen que construye sea fiable.