El «Control de duplicados» nativo de Bitrix24 busca coincidencias en prospectos, contactos y empresas, pero no revisa las negociaciones. Dos negociaciones abiertas del mismo cliente no se consideran un duplicado: una negociación no tiene teléfono ni correo propios, así que el mecanismo nativo no tiene nada que comparar. Por eso las negociaciones duplicadas se cazan de otra forma: un proceso de negocio busca la negociación abierta del contacto antes de crear una nueva, una condición decide qué hacer con el hallazgo y la comprobación bloqueante en las etapas la añade la aplicación «Control de duplicados».

¿Por qué la búsqueda nativa de duplicados no ve las negociaciones?

El mecanismo nativo compara nombre completo, teléfono y email, es decir, los datos del cliente. Esos campos los tienen el prospecto, el contacto y la empresa, por eso para ellos funcionan tanto el aviso al crear la ficha como la «Búsqueda de duplicados» masiva desde la lista. Una negociación no tiene datos de contacto: hace referencia al contacto y a la empresa, y sus propios campos —nombre, importe, etapa— coinciden constantemente entre distintas negociaciones y no pueden servir de clave de comparación. Dos negociaciones «Suministro de equipos» del mismo contacto son, para el sistema, simplemente dos registros distintos. Cómo funciona el mecanismo nativo para prospectos y contactos está en el análisis de los duplicados en Bitrix24.

¿De dónde salen las negociaciones duplicadas?

La fuente principal son las interacciones repetidas. El cliente dejó una solicitud en el sitio y al día siguiente llamó: cada canal creó su negociación, aunque ya había una abierta. Las integraciones amplifican el efecto: la telefonía, los formularios y los mensajeros crean negociaciones según sus propias reglas y no comprueban las existentes. La tercera fuente son los gestores: no encontró la negociación en una lista larga y creó una nueva. La cuarta, una importación sin cotejo. El resultado es el mismo: el historial de las conversaciones queda repartido entre dos fichas, dos gestores llaman al mismo cliente y el embudo muestra una conversión que no existe; una parte notable de las negociaciones «perdidas» en realidad están duplicadas. Cuantos más canales de recepción de solicitudes haya, más rápido se acumulan estos pares.

¿Cómo no crear un duplicado ante una interacción repetida?

La regla: antes de crear una negociación, el proceso busca una existente. Primer paso, el robot «Buscar contacto por teléfono/email»: por el número de teléfono de la solicitud devuelve el ID del contacto y el indicador «Encontrado» (Y/N). Segundo paso, el robot «Buscar negociación según condición»: por el ID del contacto y el filtro {"CLOSED":"N"} busca las negociaciones abiertas del cliente y devuelve el ID de la primera encontrada, la lista de todos los ID, la cantidad y el indicador Y/N. Después, una bifurcación por condición: si es Y, la solicitud se añade a la negociación existente como comentario o actividad; si es N, el proceso crea una nueva. El duplicado se intercepta antes de que aparezca.

¿Cómo comprobar si una negociación ya creada es un duplicado?

La misma búsqueda funciona también después de la creación, por ejemplo en la primera etapa del embudo. El proceso sobre la negociación lanza «Buscar negociación según condición» con el ID del contacto de esa negociación y el filtro de abiertas: la cantidad devuelta mostrará cuántas negociaciones abiertas tiene el cliente. El robot «Condición compuesta (AND / OR / NOT)» comprueba varias condiciones a la vez —por ejemplo, que la cantidad sea mayor que uno Y que el importe de la nueva negociación no esté rellenado— y devuelve un único indicador Y/N. Si es Y, el proceso le crea al responsable una tarea para revisar el duplicado y avisa al jefe. No conviene fusionar negociaciones automáticamente: cuál es la principal lo decide una persona.

¿Cuándo no bastan los procesos?

El proceso de negocio caza duplicados en los puntos que has previsto: la creación, la primera etapa, la interacción repetida. Todo lo que llega al margen de esos puntos —creación manual saltándose el proceso, registros duplicados antiguos, prospectos y contactos duplicados de los que crecen negociaciones duplicadas— se queda en la base. La solución sistémica es la aplicación «Control de duplicados»: comprueba la ficha en cada movimiento por el embudo y no la deja avanzar hasta que el duplicado se fusiona, además de escanear masivamente la base existente. La combinación resulta de tres capas: los procesos impiden crear duplicados, la comprobación en las etapas caza lo que se ha escapado y el escaneo resuelve lo acumulado.

Lista de comprobación

Pon la búsqueda del contacto y de la negociación abierta antes de crear una nueva; en la primera etapa comprueba la cantidad de negociaciones abiertas del cliente mediante una condición compuesta; entrega los duplicados encontrados al gestor como tarea, en lugar de fusionarlos a ciegas; para la comprobación bloqueante en las etapas y el escaneo masivo, instala «Control de duplicados». Los robots de búsqueda y comprobación están en el catálogo de robots de CRM. Si falta el robot que necesitas, describe la tarea: lo haremos gratis y lo añadiremos a la biblioteca común.