MQL vs SQL : quelle différence et quand passer de l’un à l’autre ?

MQL vs SQL : quelle différence ?

MQL signifie Marketing Qualified Lead. SQL signifie Sales Qualified Lead.

La différence tient moins à un niveau d’intérêt théorique qu’à la nature de la qualification réalisée et à la décision qui en découle.

Cette frontière doit être adaptée à chaque entreprise.

L’enjeu n’est pas de trouver la définition universelle parfaite du MQL ou du SQL. Il faut surtout que Marketing, Sales et le CRM utilisent la même définition, avec des critères suffisamment précis pour savoir quoi faire lorsqu’un lead change de statut.

Qu’est-ce qu’un MQL ?

Un MQL est un prospect que le marketing considère comme suffisamment intéressant au regard de critères définis à l’avance.

Ces critères combinent généralement deux dimensions.

Le fit : ce prospect correspond-il à notre cible ?

Par exemple :

• son entreprise correspond à votre ICP ;

• sa taille est adaptée à votre offre ;

• son activité fait partie de vos marchés cibles ;

• son rôle est pertinent dans la décision ;

• son besoin potentiel correspond à ce que vous proposez.

L’intention : montre-t-il suffisamment d’intérêt ?

Selon votre activité, certains signaux peuvent être utiles :

• téléchargement d’une ressource ;

• inscription à un webinar ;

• consultation répétée de pages à forte intention ;

• réponse à un email ;

• demande d’informations ;

• demande de rendez-vous.

Aucun de ces signaux ne suffit nécessairement seul.

Un responsable des opérations appartenant parfaitement à votre cible peut télécharger plusieurs ressources sans avoir de projet actuel. À l’inverse, une personne qui consulte une page tarifaire n’est pas automatiquement un bon prospect.

Il est donc utile de distinguer fit et intention, plutôt que de transformer toute interaction marketing en MQL.

Lorsque le volume de leads le justifie, le lead scoring B2B peut aider à rendre cette priorisation plus systématique. Mais le score ne remplace pas nécessairement la qualification commerciale qui suit.

Qu’est-ce qu’un SQL ?

Un SQL est un lead que l’équipe commerciale considère suffisamment qualifié pour justifier un traitement commercial actif.

Cela ne signifie pas nécessairement qu’il est « prêt à acheter ».

Sur une vente B2B consultative, plusieurs semaines ou plusieurs mois peuvent encore séparer la qualification commerciale de la signature.

Le changement important est ailleurs : les Sales disposent désormais de suffisamment d’informations pour considérer que ce prospect mérite du temps commercial.

Selon l’entreprise, cela peut notamment signifier :

• qu’un problème réel a été identifié ;

• que l’offre peut raisonnablement y répondre ;

• que le sujet possède une certaine priorité ;

• qu’une temporalité existe ;

• qu’un interlocuteur pertinent est impliqué ;

• qu’une prochaine étape est envisageable.

Prenons une société de services qui cible des PME.

Un COO appartenant parfaitement à l’ICP télécharge un guide sur l’automatisation des opérations et consulte plusieurs contenus similaires.

Il peut devenir MQL.

Après un premier échange, l’équipe apprend qu’il souhaite remplacer plusieurs fichiers dispersés, que les équipes perdent du temps chaque semaine et qu’un changement est envisagé dans les prochains mois.

Le contexte commercial est maintenant suffisamment concret pour poursuivre activement : le lead peut devenir SQL.

Une nouvelle information a permis de prendre une nouvelle décision.

C’est cette logique qui doit guider le passage entre les deux statuts.

Quand un MQL doit-il devenir SQL ?

Il n’existe pas de seuil universel.

Un modèle du type « 70 points = MQL, 100 points = SQL » peut sembler pratique, mais il ne fonctionne que si les points correspondent réellement aux informations nécessaires pour prendre une décision commerciale.

Dans beaucoup d’organisations B2B, quatre éléments permettent de structurer le passage de MQL à SQL.

1. Le prospect possède un fit suffisant

L’entreprise et l’interlocuteur correspondent raisonnablement au type de client que vous souhaitez accompagner.

Cela ne signifie pas qu’ils doivent cocher parfaitement tous les critères de l’ICP.

L’objectif est surtout d’éviter de transmettre aux Sales des leads dont on sait déjà qu’ils sont hors cible.

2. Un signal justifie une attention commerciale

Le prospect ne se contente plus d’exister dans la base marketing.

Il peut avoir demandé une démonstration, répondu à une sollicitation, décrit un besoin, consulté des contenus à forte intention ou demandé directement à échanger.

Le bon signal dépend de votre cycle de vente.

3. Le contexte commercial est suffisamment crédible

C’est généralement ici que la qualification humaine apporte le plus de valeur.

Le commercial cherche notamment à comprendre :

• existe-t-il réellement un problème ?

• ce problème correspond-il à ce que nous pouvons résoudre ?

• le sujet est-il suffisamment important ?

• existe-t-il une priorité ou une temporalité ?

• sommes-nous en contact avec la bonne personne ?

Il n’est pas nécessaire de connaître immédiatement le budget exact, toutes les parties prenantes et l’intégralité du processus de décision.

La profondeur de qualification doit rester proportionnée à la complexité de la vente.

C’est ce que nous détaillons davantage dans notre article sur la qualification des leads B2B.

4. Le changement de statut déclenche une action différente

C’est probablement le critère le plus important.

Si passer de MQL à SQL ne change absolument rien dans votre organisation, la distinction apporte peu de valeur.

Un passage en SQL peut par exemple déclencher :

• l’attribution à un commercial ;

• une prochaine action obligatoire ;

• une tâche de suivi ;

• l’entrée dans un processus commercial défini ;

• la création d’une opportunité, si c’est la règle retenue ;

• une mesure du délai de traitement.

Le statut devient alors un véritable élément du processus, et pas simplement une information supplémentaire dans le CRM.

Le lead scoring suffit-il pour passer de MQL à SQL ?

Pas toujours.

Le lead scoring peut être très utile pour détecter ou prioriser les prospects qui méritent une attention humaine.

Par exemple :

Fit élevé + intention élevée → MQL → revue par les Sales

Cette revue peut ensuite aboutir à :

SQL, si le contexte mérite une poursuite commerciale ;

Nurturing, si le fit est bon mais que le timing ne l’est pas ;

Disqualifié, si les informations complémentaires montrent que le prospect ne correspond finalement pas au besoin.

Automatiser directement le passage en SQL à partir d’un score suppose que toutes les informations nécessaires à la qualification commerciale sont déjà disponibles dans les données.

Selon le processus de vente, ce n’est pas toujours le cas.

L’automatisation peut parfaitement identifier, prioriser, router et notifier sans nécessairement prendre seule la décision finale.

Faut-il ajouter une étape SAL entre MQL et SQL ?

Certaines organisations utilisent également le statut SAL — Sales Accepted Lead.

Le processus devient alors :

MQL → SAL → SQL

Le SAL indique que l’équipe commerciale a accepté de prendre en charge le lead, sans l’avoir encore complètement qualifié.

Cette étape peut être utile lorsque le handoff Marketing → Sales constitue une vraie transition opérationnelle, par exemple dans une organisation avec Marketing, SDR et Account Executives.

Elle permet notamment de distinguer les MQL transmis, acceptés, refusés puis réellement qualifiés.

À l’inverse, si quelques leads sont traités chaque semaine par la même personne, ajouter SAL risque surtout de créer un statut que personne n’utilisera réellement.

Un statut supplémentaire n’est utile que s’il matérialise une vraie décision ou un changement de responsabilité.

Comment structurer MQL et SQL dans son CRM ?

La première erreur consiste souvent à créer les statuts dans le CRM avant d’avoir défini le processus.

Il vaut mieux commencer par quatre questions :

Qu’est-ce qui fait entrer un prospect dans chaque statut ?

Qui en devient responsable ?

Quelle action doit avoir lieu ensuite ?

Qu’est-ce qui lui permet d’en sortir ?

Un processus simple peut par exemple fonctionner ainsi :

Nouveau lead

↓

Évaluation du fit et des signaux disponibles

↓

MQL

↓

Attribution ou revue par les Sales

↓

Qualification

↓

SQL
ou
Nurturing / Disqualifié

↓

Poursuite du processus commercial

Les automatisations viennent ensuite : attribution du propriétaire, création d’une tâche, notification, mise à jour d’un champ ou mesure du délai de prise en charge.

La règle métier doit être claire avant de l’automatiser.

Ne pas confondre MQL / SQL et étapes d’opportunité

C’est un point d’architecture important.

MQL et SQL décrivent généralement l’état de qualification d’un lead ou d’un contact.

Des étapes comme :

• Discovery ;

• Proposition ;

• Négociation ;

• Gagné ;

• Perdu ;

décrivent plutôt l’avancement d’une opportunité commerciale.

Mélanger les deux concepts dans un seul champ donne rapidement quelque chose comme :

MQL → SQL → Discovery → Proposition → Négociation → Gagné

Cela peut fonctionner sur un processus très simple, mais atteint vite ses limites.

Une même entreprise peut par exemple avoir plusieurs opportunités au fil du temps : un premier projet signé cette année, puis un second besoin six mois plus tard.

Le contact n’a pas besoin de redevenir « MQL » simplement parce qu’une nouvelle opportunité apparaît.

Lorsque le CRM et le processus le permettent, il est donc souvent plus propre de distinguer :

Lifecycle du lead ou du contact

et

Pipeline des opportunités

Le moment où l’opportunité est créée peut lui aussi varier. Certaines entreprises la créent au passage SQL, d’autres plus tôt ou plus tard.

Il n’existe pas une seule bonne convention.

L’important est de définir quel événement déclenche la création d’une opportunité, puis d’appliquer cette règle de manière cohérente.

Conserver uniquement les informations utiles au handoff

Quand un MQL est transmis aux Sales, le commercial ne devrait pas avoir à repartir de zéro.

Quelques informations peuvent suffire :

• source du lead ;

• entreprise et interlocuteur ;

• éléments ayant déclenché la qualification ;

• score éventuel ;

• besoin exprimé lorsqu’il est connu ;

• propriétaire ;

• date du handoff.

Les Sales peuvent ensuite compléter les informations qui nécessitent davantage de contexte : problème, priorité, temporalité, prochaine action ou motif de disqualification.

Le CRM doit aider les équipes à prendre la prochaine décision, pas transformer chaque changement de statut en formulaire administratif.

Avez-vous réellement besoin de MQL et SQL ?

Pas toujours.

Ces concepts sont particulièrement utiles lorsqu’il existe une vraie séparation entre génération de demande, qualification et traitement commercial.

Par exemple :

Marketing → SDR → Sales

Avec un volume important de leads, il devient utile de savoir ce que le marketing peut transmettre, ce que les Sales acceptent et ce qui mérite réellement du temps commercial.

Mais imaginons une société de conseil de quinze personnes recevant vingt demandes entrantes par mois.

Le dirigeant ou un commercial lit chaque demande, vérifie le fit puis organise éventuellement un rendez-vous.

Dans ce cas, un système comme :

Nouveau → À qualifier → Qualifié → Opportunité

peut être parfaitement suffisant.

Il n’y a aucun avantage à reproduire une architecture MQL / SAL / SQL uniquement parce qu’elle apparaît dans les modèles de grandes organisations Revenue.

C’est le même principe que pour le RevOps de manière générale : les données, les processus et les outils doivent servir le fonctionnement réel des équipes.

Le bon modèle n’est pas celui qui possède le plus d’étapes. C’est celui dans lequel chaque étape aide quelqu’un à prendre une décision.

Les erreurs qui rendent MQL et SQL inutiles

Considérer chaque interaction marketing comme un MQL

Un téléchargement ou une visite n’est pas une preuve suffisante de qualité. Le fit et la nature du signal doivent également entrer dans la décision.

Laisser Marketing et Sales utiliser deux définitions différentes

Si le marketing considère qu’un lead mérite d’être transmis mais que les Sales jugent systématiquement ces leads trop faibles, le problème n’est probablement pas le nombre de MQL.

La définition du handoff doit être retravaillée ensemble.

Utiliser le score comme seule validation commerciale

Un score peut prioriser ou déclencher une revue. Il ne remplace pas forcément les informations obtenues pendant la qualification.

Ajouter des statuts sans action associée

MQL, SAL et SQL ne devraient pas devenir trois cases supplémentaires dans le CRM.

Pour chaque transition, il devrait être possible d’identifier :

une condition → un responsable → une prochaine action.

Sinon, simplifier le processus est probablement préférable.

Questions fréquentes sur MQL et SQL