Qué cuenta como MQL y qué pasa cuando un lead vuelve a cualificar

Separa el primer MQL de los episodios de recualificación.

Define qué convierte a un contacto en MQL

Un MQL es un contacto que cumple los criterios acordados para que marketing lo derive a ventas. Para que la definición funcione en el CRM, tiene que poder evaluarse sobre un registro concreto. «Tiene interés» es una interpretación. «Ha solicitado una demo y su empresa encaja en el segmento que atendemos» es una regla que se puede comprobar.

Nexo considera MQL a un contacto de una empresa que encaja en su segmento cuando solicita una demo o cuando combina asistencia a un webinar con una segunda señal explícita, como pedir información sobre precios. Un registro en el webinar, por sí solo, entra en nutrición. Una solicitud de demo con información insuficiente entra en una cola de revisión. Esto permite distinguir la falta de datos de una descalificación confirmada.

Documenta también las excepciones. Una solicitud de soporte de un cliente, un formulario interno de prueba y una demo duplicada pueden activar el mismo formulario que una oportunidad real. Decide qué ruta sigue cada uno antes de contar el evento.

Guarda el primer MQL y la última cualificación

Dato	Cómo se guarda	Qué permite medir
Primera fecha de MQL	Se escribe al cumplirse la regla por primera vez. Las nuevas cualificaciones conservan el valor original.	Conversión de la base de contactos y cohortes de captación
Última fecha de cualificación	Se actualiza con cada nuevo episodio válido.	Seguimiento de demanda reciente
Historial de cualificaciones	Un registro por episodio con contacto, fecha, señal, fuente y versión de la regla.	Reactivaciones, auditoría y análisis de campañas

El historial importa porque un campo con la última fecha responde a una pregunta sobre el estado actual. Si un contacto vuelve a cualificar en diciembre, ese campo cambia y ya no sirve para reconstruir cuántas veces cualificó en noviembre. Guarda también un identificador del evento de origen para que un reintento de integración no genere dos episodios.

GitLab documenta esta distinción en su handbook. Para determinados informes utiliza una fecha reciente de cualificación que puede cambiar, y distingue entre la primera y la última cualificación en sus campos de primer pedido. La elección de fecha depende de la pregunta que responde el informe. GitLab Handbook

Decide cuándo volver a avisar a ventas

Con una oportunidad abierta, la misma solicitud se deriva al responsable de esa oportunidad. Si Paula envía dos veces el mismo formulario, ambos envíos se consolidan según la regla de deduplicación acordada. Y si estaba descalificada porque su empresa queda fuera del mercado objetivo, una nueva señal por sí sola no debería revertir esa decisión.

Situación	Acción operativa
Primera señal válida	Registrar primer MQL y asignar seguimiento
Señal nueva tras cerrar un seguimiento por falta de momento	Registrar recualificación y volver a asignar
Señal nueva con oportunidad abierta	Avisar al responsable y adjuntar el contexto
Reenvío del mismo evento	Conservar un episodio
Descalificación por criterio estructural	Revisar solo si cambia el criterio que motivó la descalificación

En el ejemplo inicial, las 140 cualificaciones incluyen 100 primeros MQL y 40 episodios de recualificación. Si esas 40 recualificaciones corresponden a 35 personas, el equipo puede reportar tanto episodios como personas reactivadas. Para el seguimiento comercial, la cola muestra únicamente los casos que requieren una acción pendiente.

Cómo trasladarlo al CRM

Empieza con las propiedades de primera y última cualificación y un registro histórico en el sistema que utilices para analítica o automatización. Conserva la fecha real de la señal y la fecha de procesamiento cuando intervengan integraciones. Así puedes explicar qué ocurre si una demo del domingo se procesa el lunes, o si el CRM y el dashboard cierran el mes en horas distintas.

Antes de publicar la métrica, valida una muestra de primeros MQL, recualificaciones, duplicados y exclusiones. Si el equipo puede seguir cada uno desde la señal original hasta el informe, podrá explicar los cambios de volumen sin revisar manualmente todos los contactos.

Diseña la automatización alrededor del evento de cualificación

Si el MQL de Nexo se activa con una solicitud de demo, el formulario es el punto de entrada. Antes de actualizar el contacto, la automatización tiene que resolver quién hizo la solicitud, comprobar la elegibilidad y decidir qué actuación comercial corresponde. Si cada formulario implementa esas reglas por separado, un cambio en la definición puede acabar aplicándose solo a parte del tráfico.

1. Identifica el contacto y la señal. Guarda un identificador estable de la solicitud, la hora del evento y el formulario de origen. Si la empresa aún no está identificada, conserva la señal pendiente de revisión.
2. Evalúa encaje e intención. Registra qué condición se cumplió y qué versión de la regla se utilizó. Una decisión de exclusión debe dejar un motivo visible para que el equipo pueda revisarla.
3. Crea el episodio y actualiza el contacto. Usa la clave de la señal para evitar duplicados por reintentos. Si el episodio válido es el primero, escribe la fecha inicial. Si ya existe una primera cualificación, actualiza solo la última cuando el episodio sea posterior.
4. Resuelve la acción comercial. Si existe una oportunidad abierta, deriva la señal al responsable actual. Si se trata de demanda nueva o reactivada, aplica las reglas de asignación y registra el resultado para detectar entregas que fallaron.

Comprueba que la métrica y la cola comercial se comportan como esperas

En Nexo, una integración vuelve a enviar el mismo formulario después de perder la confirmación del CRM. La segunda entrega debería devolver el episodio ya registrado. Si además se crea una tarea de ventas, conviene usar el identificador del episodio para que el reintento tampoco duplique la tarea.

• Dos señales distintas en la misma conversación. Define cuándo representan un único episodio de intención. Una solicitud de precios seguida minutos después de una reserva de demo puede enriquecer el episodio abierto.
• Un evento antiguo que llega tarde. Si su fecha efectiva es anterior a la primera registrada, revisa si el histórico admite correcciones y cómo se refleja el cambio en informes ya cerrados.
• Dos contactos que se fusionan. Vincula los episodios al contacto canónico y recalcula sus fechas a partir del histórico. Comprueba también que la fusión conserve la trazabilidad de las tareas.
• Un cambio en los criterios de encaje. Prueba la regla nueva sobre una muestra histórica y compara qué contactos cambiarían de clasificación antes de decidir si el cambio será retroactivo.

En la revisión mensual, compara primeros MQL por canal, personas reactivadas y episodios entregados. Si las recualificaciones suben pero las conversaciones comerciales no, revisa una muestra de las señales y su ruta de asignación. Puede que el problema esté en la calidad de la señal o en la capacidad de seguimiento.

Preguntas frecuentes

Checklist del capítulo

• Acordar los criterios de encaje e intención
• Guardar la primera fecha y el historial
• Probar reenvíos y casos con una oportunidad abierta