Le pipeline CRM reprise en main : étapes, motifs de gain et droits

Le CRM d'Odoo a un pipeline, et c'est à peu près tout : une probabilité calculée par un modèle prédictif qu'on ne contrôle pas, une étape par équipe, des motifs de perte mais aucun motif de gain, et des droits qui ouvrent les ventes entières dès qu'on ouvre le pipeline.

Treize modules communautaires reprennent chacun de ces points.

Résumé

Cinq modules traitent les étapes et les gains : une probabilité fixe par étape, en alternative au calcul prédictif ; une étape partagée entre plusieurs équipes là où le standard n'en autorise qu'une ; un modèle de courriel par étape, envoyé automatiquement au franchissement ; des motifs de gain symétriques des motifs de perte ; et la restriction du passage direct en gagné selon l'étape atteinte.

Deux modules traitent l'organisation : une hiérarchie d'équipes commerciales par équipe parente, et des groupes de sécurité propres au CRM, séparés de ceux des ventes.

Six modules traitent la qualification : le client rendu obligatoire sur une opportunité, la date d'échéance rendue obligatoire, un montant exprimé dans la devise du client avec conversion automatique du revenu attendu, un onglet produits détaillant ligne par ligne ce que le client envisage, un numéro de TVA synchronisé avec la fiche contact, et les champs de suivi marketing recopiés de la piste vers le contact créé.

L'essentiel

• Une probabilité fixe par étape, au lieu du calcul prédictif.
• Une étape partagée entre plusieurs équipes.
• Un modèle de courriel par étape, envoyé au franchissement.
• Des motifs de gain, pas seulement des motifs de perte.
• Le passage direct en gagné restreint selon l'étape atteinte.
• Des droits CRM qui n'ouvrent pas les ventes.
• Un montant dans la devise du client, converti automatiquement.
• Un onglet produits sur la piste, avec analyse du pipeline par produit.

Ce que ces modules ajoutent à l'instance

Les étapes : probabilité, équipes, courriels

Depuis Odoo 13, la probabilité de succès d'une opportunité est calculée par un modèle prédictif entraîné sur l'historique de l'instance. Sur une base jeune ou un cycle de vente long, ce modèle n'a rien appris — et il produit des prévisions que personne ne croit.

crm_stage_probability restaure le comportement historique : une probabilité fixe définie par étape, en alternative ou en complément du calcul automatique. Une organisation qui sait que « proposition envoyée » vaut 40 % n'a pas besoin d'un modèle pour le lui apprendre.

crm_stage_multi_team permet de partager une étape entre plusieurs équipes. Le standard n'autorise qu'une équipe par étape, ce qui oblige à dupliquer les étapes dès qu'une organisation a deux équipes suivant le même processus.

crm_stage_mail associe un modèle de courriel à chaque étape : le message part automatiquement au contact de la piste dès qu'elle atteint cette étape. L'accusé de réception d'une demande, l'envoi d'une documentation, la confirmation d'un rendez-vous cessent de dépendre d'un geste.

Les gains : les documenter, les encadrer

crm_won_reason étend la notion de motif de perte pour qualifier aussi les motifs de gain. C'est une asymétrie du standard rarement relevée : on documente systématiquement pourquoi on perd, jamais pourquoi on gagne.

Savoir pourquoi on gagne vaut mieux que savoir pourquoi on perd : les motifs de perte dressent la liste des concurrents et des objections, les motifs de gain disent quel argument porte — et c'est celui-là qu'on peut répéter.

crm_won_restrict_per_stage restreint étape par étape la possibilité de marquer une opportunité gagnée. Il empêche de sauter les étapes intermédiaires en passant directement au gagné depuis une étape amont.

Ce n'est pas de la bureaucratie : un pipeline dont les opportunités passent de « nouveau » à « gagné » ne mesure rien, et le taux de conversion par étape devient inexploitable.

Les équipes et les droits

crm_team_parent ajoute une équipe parente aux équipes commerciales, donc une hiérarchie : division, région, secteur. Les analyses par niveau deviennent possibles.

crm_security_group est le plus structurant des treize. Il crée des groupes de sécurité dédiés au CRM, indépendants des groupes Ventes.

Dans le standard, donner accès au pipeline revient à donner accès aux ventes : devis, commandes, tarifs, marges. Un apporteur d'affaires, un assistant commercial ou un chargé de prospection n'a aucune raison de voir tout cela — et la plupart des instances le lui montrent quand même.

Le détail des droits et des groupes est traité dans droits utilisateurs et sécurité d'accès.

Qualifier une piste

• crm_partner_required (LGPL-3) rend le client obligatoire sur une opportunité — dès que l'enregistrement est de type opportunité, et non piste. Une opportunité sans client n'est pas une affaire, c'est une note.
• crm_date_deadline_required (LGPL-3) rend la date d'échéance obligatoire, sur le formulaire complet et sur la création rapide depuis le kanban. Le second point est le plus utile : c'est là que les opportunités sans date naissent.
• crm_lead_currency permet de saisir un montant dans la devise propre du client et calcule automatiquement le revenu attendu dans la devise de la société. Indispensable dès qu'on vend à l'export.
• crm_lead_product (LGPL-3) ajoute un onglet Produits à la piste : les produits, catégories ou modèles envisagés par le client, ligne par ligne, avec calcul du revenu attendu global et une analyse CRM ▸ Analyse ▸ Pipeline by product.
• crm_lead_vat ajoute un numéro d'identification fiscale sur la piste, synchronisé dans les deux sens avec le champ TVA du contact lié.
• marketing_crm_partner recopie sur le contact les trois champs de suivi marketing de la piste — support, campagne, source — et les propage automatiquement.

L'analyse du pipeline par produit est la question que pose tout dirigeant au premier comité commercial : qu'est-ce qui se vend dans ce qu'on a en cours ? Sans détail produit sur les pistes, la réponse est un montant global, qui ne dit rien de l'atelier à charger ni du stock à prévoir.

Le dernier module compte pour la mesure de l'acquisition : sans lui, la campagne qui a généré un client est connue sur la piste et perdue sur le contact, donc impossible à rapprocher du chiffre d'affaires réalisé.

Limites connues

• La probabilité par étape et le calcul prédictif coexistent : choisir lequel pilote, sous peine de prévisions contradictoires.
• crm_stage_mail envoie des messages automatiques au client : vérifier chaque modèle avant activation, et prévoir les étapes qui ne doivent rien envoyer.
• Restreindre le passage en gagné ralentit les affaires courtes : prévoir une exception pour les ventes en un rendez-vous.
• crm_security_group remplace une logique de droits : son installation sur une instance en service demande de rejouer les affectations de groupes.
• Rendre le client obligatoire bloque les imports de pistes qui ne le fournissent pas.
• crm_lead_product n'est pas un devis : les lignes qualifient l'opportunité, elles ne se transforment pas en commande.
• La synchronisation du numéro de TVA est bidirectionnelle : une saisie erronée sur la piste modifie la fiche contact.
• crm_industry, crm_partner_capital et crm_partner_employee_quantity dépendent de modules de contacts du dépôt partner-contact.

Identité technique

Les treize modules viennent du dépôt OCA crm, branche 18.0 — 31 modules au total. Dix sont en AGPL-3, trois en LGPL-3. Les dépendances : crm pour la plupart, sales_team pour la hiérarchie d'équipes, sale_crm pour les groupes de sécurité, product pour l'onglet produits.

Voir aussi qualifier et traiter une affaire pour le reste du dépôt.

Questions fréquentes

Peut-on définir une probabilité fixe par étape du pipeline Odoo ?

Oui, avec crm_stage_probability, qui restaure le comportement d'Odoo ≤ 12. Depuis Odoo 13, la probabilité vient d'un modèle prédictif entraîné sur l'historique de l'instance : sur une base jeune ou un cycle de vente long, ce modèle n'a rien appris et produit des prévisions que personne ne croit.

Comment donner accès au pipeline CRM sans donner accès aux ventes ?

crm_security_group crée des groupes de sécurité dédiés au CRM, indépendants des groupes Ventes. Dans le standard, ouvrir le pipeline ouvre les devis, les commandes, les tarifs et les marges — ce qu'un chargé de prospection n'a aucune raison de voir.

Odoo gère-t-il les motifs de gain d'une opportunité ?

Pas en standard : il ne gère que les motifs de perte. crm_won_reason ajoute les motifs de gain. L'asymétrie est rarement relevée et pourtant décisive : les motifs de perte listent les objections, les motifs de gain disent quel argument porte — et c'est celui-là qu'on peut répéter.

Peut-on partager une étape de pipeline entre deux équipes commerciales ?

Oui, avec crm_stage_multi_team. Le standard n'autorise qu'une équipe par étape, ce qui oblige à dupliquer tout le pipeline dès qu'une organisation a deux équipes suivant le même processus.

Comment savoir quels produits sont dans le pipeline ?

crm_lead_product ajoute un onglet Produits sur la piste — produits, catégories ou modèles envisagés, ligne par ligne — et une analyse CRM ▸ Analyse ▸ Pipeline by product. Sans ce détail, la réponse au premier comité commercial est un montant global, qui ne dit rien de l'atelier à charger.

Se faire accompagner

Un pipeline CRM ne vaut que par ce qu'on peut en déduire. Des étapes sautées, une probabilité calculée par un modèle vide, aucun motif de gain, pas de détail produit : le tableau est joli et la prévision inexploitable.

Nous reprenons donc les étapes et leurs règles avant d'ouvrir le CRM aux équipes — probabilité, passage en gagné, champs obligatoires — et nous séparons les droits CRM des droits Ventes dès le départ. Voir les prestations d'Atalios Consulting ou demander un rappel.

Pour aller plus loin

• Qualifier et traiter une affaire : réclamations, appels, visites
• Droits utilisateurs et sécurité d'accès

En résumé

Le CRM d'Odoo a un pipeline, et c'est à peu près tout : probabilité calculée par un modèle vide, une étape par équipe, aucun motif de gain, et des droits qui ouvrent les ventes entières. Treize modules reprennent chacun de ces points. Parlons de votre pipeline.