Deduplicar candidatos entre web, CRM, mensajería y teléfono

Deduplicar es dejar una sola ficha por candidato sin perder el historial

Deduplicar consiste en reconocer que un formulario web, una conversación de chat, un mensaje en una aplicación de mensajería y una llamada perdida pertenecen a la misma persona, y unirlos en una única ficha del CRM. El objetivo no es una base de datos ordenada por sí misma, sino que un solo asesor contacte al candidato, una sola vez, con todo el contexto.

Los duplicados cuestan más en admisiones porque el recorrido es largo. Quien pide información en septiembre, pregunta por las pruebas de acceso en octubre y llama en noviembre es un único candidato. Con tres fichas hay tres seguimientos, quizá de tres asesores, y un historial que nadie ve completo.

Este artículo explica dónde nacen los duplicados, qué claves de cruce usar, qué reglas de fusión conviene escribir y qué límites impone la protección de datos. Completa nuestra guía para limpiar la base de leads de estudiantes y la de enrutamiento con SLA.

Dónde nacen los duplicados: un identificador distinto por canal

Cada canal capta un identificador diferente, y ese desajuste fabrica duplicados. La tabla resume lo que se sabe de la persona en cada punto de entrada.

Dos casos exigen una regla explícita. El primero: los padres escriben en nombre de su hijo o hija, son dos personas y un solo expediente. El segundo: una persona usa dos correos. Ninguna herramienta lo resuelve sola; es una decisión de la universidad.

Elegir las claves de cruce, de la más segura a la más frágil

Una buena deduplicación aplica las claves en un orden fijo y se detiene en cuanto la coincidencia es segura. Tres niveles bastan para empezar.

1. Coincidencia exacta. Mismo correo normalizado (minúsculas, sin espacios) o mismo teléfono normalizado. El cruce puede ser automático.
2. Coincidencia probable. Mismo nombre y apellidos con el mismo grado de interés, o mismo teléfono con correos distintos. El sistema propone y una persona valida.
3. Coincidencia posible. Nombres parecidos u ortografía variable. Se señala, nunca se fusiona automáticamente.

Normalice los teléfonos al formato internacional de la recomendación E.164 de la UIT: prefijo del país y número, sin espacios. Un número guardado como 6… en el CRM y como +34 6… en la mensajería es el mismo; sin normalizar se convierte en dos fichas.

Una precaución: nunca fusione solo por el nombre. Los homónimos existen y una fusión errónea mezcla dos expedientes, algo peor que un duplicado.

Escribir las reglas de fusión antes de la primera fusión

Una fusión decide qué valor sobrevive cuando dos fichas se contradicen. Sin reglas escritas, cada asesor decide a su manera y la base vuelve a desordenarse en semanas.

Un conjunto sencillo de reglas para adaptar:

• Ficha maestra. Se conserva la más antigua y las demás se adjuntan. Mantiene el identificador que ya conocen sus otras herramientas.
• Datos de contacto. Gana el valor más reciente y verificado; el anterior pasa al historial en lugar de borrarse.
• Titulación y vía de acceso. Se guarda el último interés expresado y se conservan los anteriores: quien cambia de grado da una señal comercial, no comete un error.
• Responsable. Se queda con la ficha el asesor con el contacto humano más reciente; si no, se aplica su regla de enrutamiento.
• Consentimientos y oposiciones. Véase la sección siguiente: prevalece siempre el ajuste más restrictivo.
• Trazabilidad. Se registra quién fusionó qué, cuándo y por qué, para poder deshacerlo.

Mantenga posible la reversión. Una fusión precipitada por un teléfono compartido entre hermanos debe poder deshacerse sin pérdidas.

Protección de datos: una fusión nunca debe borrar una oposición

Fusionar fichas es tratar datos personales, y el Reglamento (UE) 2016/679 se aplica a la base resultante, junto con la ley orgánica española de protección de datos. Dos principios del artículo 5 sirven directamente: la exactitud justifica la deduplicación y la minimización impide conservarlo todo «por si acaso».

El riesgo principal son las oposiciones. Si una de las fichas fusionadas lleva una oposición a recibir publicidad o una solicitud de supresión, la ficha resultante debe heredarla. De lo contrario la fusión reactiva un contacto que la persona ya había rechazado. La AEPD publica guías sobre derechos de las personas y comunicaciones comerciales: haga validar sus reglas por el delegado de protección de datos de la universidad.

Tres hábitos reducen el riesgo:

• Guardar la fecha y el origen de cada consentimiento por canal: aceptar el correo no vale para la mensajería ni para el teléfono.
• Aplicar el ajuste más restrictivo cuando dos fichas se contradicen.
• Mantener aparte una lista de supresión, para que una importación posterior no vuelva a crear a quien se opuso.

Con candidatos menores, asocie a los tutores legales a las conversaciones que preparen una matrícula y no fusione su ficha con la del menor.

Poner el proceso en marcha en seis pasos

Una universidad puede empezar con las herramientas que ya tiene. El orden importa más que la sofisticación.

1. Inventariar los puntos de entrada: formularios, chat, mensajería, líneas telefónicas, ferias y listas de socios. Anote qué identificador capta cada uno.
2. Normalizar al entrar: correo en minúsculas, teléfono en formato internacional, nombres limpios. Evitar un duplicado cuesta menos que fusionarlo.
3. Activar la detección en el CRM: la mayoría ofrece reglas; configúrelas con sus claves, primero en modo sugerencia y después en automático.
4. Tratar el stock existente por lotes, empezando por coincidencias exactas.
5. Escribir la regla de propiedad: quién asume la ficha fusionada y cómo se informa al otro asesor.
6. Revisar cada mes las sugerencias rechazadas y las fusiones revertidas para afinar las claves.

Si varios centros o marcas comparten base de datos, decida primero si un candidato puede cruzarse entre ellos. Es una cuestión de finalidad del tratamiento que debe resolver con el delegado de protección de datos antes de cualquier fusión entre marcas.

Medir sin inventar una referencia

Ninguna fuente pública indica qué tasa de duplicados es «normal» en una universidad; mida la suya antes y después. Estos indicadores se calculan desde el CRM.

No presente la reducción de duplicados como más matrículas. Un proceso de admisión tiene muchas causas y el efecto sobre la conversión debe establecerse con sus propios periodos de comparación.

Qué aporta Skolbot y qué sigue en manos de la universidad

Skolbot Chat es un agente instalado en la web de la universidad. Responde a partir de los contenidos que el centro ha publicado, cualifica la consulta, propone una cita o una jornada de puertas abiertas y traslada la conversación al equipo y al CRM. Captar un correo o un teléfono pronto en la conversación aporta una clave de cruce que al visitante anónimo suele faltarle. La lógica completa está en nuestro artículo sobre agentes de IA del contacto al CRM.

Las reglas de cruce y fusión siguen siendo las de la universidad y su CRM. El comportamiento exacto del conector con su CRM se confirma en la fase de definición, no en un artículo. Para situar sus herramientas, consulte la comparativa de CRM para educación superior y, para la visión general, nuestra guía para reclutar más estudiantes.