Resumen

  • Fuera de la beta de conservación del ID principal, ambos contactos salen de sus flujos activos al fusionarse. Dentro de ella, el principal continúa y el secundario sale.
  • La selección masiva por última actualización contempla propiedades internas ocultas. Ese orden cronológico puede elegir qué trabajo sobrevive sin medir su importancia comercial.
  • Volver a inscribir un contacto reinicia el flujo desde el principio. La fusión no se puede deshacer; conservar el historial y completar lo pendiente requieren controles distintos.

Una empresa puede felicitarse por haber borrado un duplicado mientras alguien espera una respuesta. La base de datos mejora su aspecto. El cliente sigue mirando la bandeja de entrada. El mérito administrativo y el resultado comercial caben en la misma operación, pero no siempre van juntos.

Imaginemos dos registros que pertenecen de verdad a una misma persona. Uno espera el siguiente paso después de una demostración; el otro tiene pendiente un seguimiento de la prueba del producto. Al unirlos, el equipo resuelve una identidad repetida. Todavía le quedan dos compromisos que ordenar. Esa escena hipotética basta para entender por qué la fusión de HubSpot merece algo más que una revisión de campos.

El historial tiene mejor suerte que lo pendiente

La documentación de fusión explica cómo se reúnen actividades, asociaciones e historial de propiedades. El contacto resultante puede ofrecer una visión más completa de lo ocurrido. Precisamente por eso resulta fácil dar el siguiente salto mental: si se ha reunido el pasado, también estará encarrilado el futuro.

La regla de ejecución rompe esa intuición. En las cuentas Professional o Enterprise con los flujos correspondientes, hay que distinguir si participan en Primary ID Preservation for Merged Records, una beta pública. Fuera de ella, los dos registros salen de sus flujos activos al fusionarse. Dentro, el principal mantiene retrasos, ramas y acciones pendientes; el secundario abandona todos los flujos en los que estaba activo.

En el ejemplo, eso obliga a elegir. Bajo la beta, uno de los recorridos puede conservar su marcha; el trabajo pendiente del otro necesita un destino. Que una actividad antigua aparezca en la ficha unificada no traslada por sí solo la acción que debía venir después.

Aquí hay una pequeña trampa organizativa. Quien administra los datos puede comprobar que ya no hay duplicado. Quien atiende al cliente puede ver las conversaciones anteriores. Ambos encuentran pruebas tranquilizadoras. Falta la prueba que interesa al cliente: que el próximo paso siga programado y llegue a ejecutarse.

El registro ganador no siempre es el que más trabajo debe

En una fusión individual se puede discutir qué ficha conservar. En un lote, la discusión suele convertirse en una regla. El gestor de duplicados permite elegir mediante fechas de interacción, creación o actualización. El criterio de actualización más reciente incluye todas las propiedades, también las internas que permanecen ocultas.

Es una manera reproducible de ordenar registros. No es una valoración del compromiso que guarda cada uno. La ficha recién modificada puede tener menos trabajo urgente que la otra. Cuando la continuidad del flujo depende de conservar el registro principal, ordenar por actualidad también reparte continuidad operativa.

El reloj acaba haciendo de jefe de ventas, sin haber leído la conversación con el cliente.

No hace falta atribuir una intención a HubSpot para ver el problema. Basta con seguir la autoridad que el equipo entrega al criterio de selección. Un campo temporal responde a «qué cambió después»; una persona responsable del proceso debe responder a «qué acción debemos mantener». Son preguntas diferentes, aunque el mismo botón las resuelva de una vez.

La selección empieza, además, por confirmar que se trata del mismo contacto. Una sugerencia de duplicado no sustituye esa comprobación. Después conviene separar las fichas sin trabajo activo de las que tienen acciones esperando: meterlas en el mismo saco ahorra clasificación a costa de ocultar consecuencias distintas.

Volver a entrar puede devolver al cliente a la primera casilla

HubSpot permite configurar la inscripción de contactos fusionados. Por defecto, los cambios de datos causados por la fusión no los incorporan automáticamente a nuevos flujos, aunque cumplan las condiciones. Activar esa posibilidad facilita una entrada; no devuelve la posición anterior.

Las reglas de reinscripción sitúan al registro otra vez al principio. Las acciones iniciales vuelven a formar parte del recorrido, con la ejecución sujeta a sus condiciones. Intentar recuperar un seguimiento perdido puede volver a poner sobre la mesa tareas que ya se habían hecho.

La inscripción manual tampoco salta al punto interrumpido. Para ejecutar únicamente pasos posteriores, HubSpot propone crear o clonar un flujo separado que empiece en la acción deseada. Recuperar bien exige conocer la frontera entre lo cumplido y lo pendiente.

Ese trabajo cuesta. Alguien tiene que revisar el recorrido, seleccionar las acciones y decidir si el cliente necesita otra comunicación. Una limpieza que se mide solo por clics ahorrados puede terminar financiándose con horas de otra persona. El formulario quedó más ordenado; la cuenta de trabajo, menos.

La prueba está después de la fusión

La página de detalles de los flujos muestra eventos, acciones y horas. Es posible contrastar el momento de la fusión con la salida, la nueva entrada y la ejecución efectiva. Para calcular un perjuicio comercial concreto hacen falta las posiciones anteriores y los registros posteriores de esa cuenta.

La marcha atrás tampoco es un botón disponible: HubSpot no permite deshacer la fusión. Quitar una dirección secundaria y crear un nuevo contacto con ella produce otro registro. Recuperar la referencia de los antiguos ID ayuda a explicar el origen, pero no devuelve dos procesos a su estado previo.

Por eso el cierre de la tarea debería mencionar el siguiente compromiso, no solo el duplicado eliminado. La empresa puede decidir continuar una acción, reasignarla o cancelarla con criterio. Lo caro es que desaparezca de la atención de todos mientras cada equipo tiene un pequeño éxito que enseñar.

Un CRM sirve para recordar relaciones. Si su limpieza hace olvidar qué se debía hacer después, alguien habrá ordenado muy bien el problema.