Un mensaje repetido de un comprador no siempre es una nueva solicitud. Para el informe, asigne un número de caso estable y vincule a él las aclaraciones, conservando los registros originales. La coincidencia de nombre o tema por sí sola no da motivo para fusionar a dos personas.
Definir la unidad de registro
Elija qué significa una solicitud en su proceso: por ejemplo, un caso sobre una tarea concreta que el equipo aceptó para trabajar. Mensaje, persona, tarea y pedido son entidades distintas. Un comprador puede estar discutiendo dos pedidos independientes a la vez; dos miembros del equipo del cliente pueden escribir sobre una misma tarea.
Para la vinculación, utilice un número de caso confirmado u otro identificador operativo. Deje los datos de contacto en un sistema protegido con el acceso necesario y traslade a un ejemplo analítico designaciones anonimizadas.
Cinco registros: dos solicitudes y una consulta
Registro didáctico: registro A — nueva solicitud L1; B — aclaración confirmada L1; C — nueva solicitud L2; D — aclaración confirmada L2; E — mensaje con un nombre similar, vínculo no establecido. Resultan dos solicitudes confirmadas y un mensaje sin resolver, y no automáticamente cinco o tres solicitudes.
Conserve para A–E las filas originales y un campo de vínculo aparte. Para B y D indique el motivo de la fusión. Para E plantee una pregunta aclaratoria en el flujo de trabajo habitual; hasta la respuesta, no una el registro por suposición. Tras la confirmación, actualice el resultado dejando rastro del cambio.
No trasladar la regla de compra a cualquier señal
Por ejemplo, Google Analytics describe la eliminación de purchase repetidos en el flujo web por transaction_id con salvedades sobre un solo usuario. Es una mecánica concreta de compras, no una fusión automática de conversaciones en todas las CRM. Para las solicitudes, su regla debe definirse y verificarse por separado.
Antes del informe, muestre el número de mensajes originales, solicitudes confirmadas y casos sin resolver. Así la reducción de duplicados no parecerá una caída inexplicable de la demanda, y el equipo podrá reproducir el recuento.
Esquema: 1 — conservar los mensajes originales; 2 — vincular solo las coincidencias confirmadas; 3 — contar por separado las solicitudes y los casos indeterminados.
Otras instrucciones prácticas — en el blog de Boosted.
Fuentes
Google Analytics: identificadores de transacciones. Verificado el 21 de septiembre de 2026. Los ejemplos prácticos y los esquemas son metodología editorial; las cifras hipotéticas no son datos de clientes.
Para una publicación pública concreta ya preparada, puede consultar las condiciones de las vistas. Este servicio no realiza el trabajo descrito ni garantiza interés orgánico, solicitudes o ventas.