ÉTUDE DE CAS · SALESFORCE
Refonte de Salesforce pour structurer les données, adapter le CRM aux besoins de 4 Business Units et faciliter le travail quotidien des équipes sales.
POSTE
Sales Ops / Growth
PÉRIODE
09/2023 – 09/2024
CRM
Salesforce
4
Business Units
~30
utilisateurs CRM
~50 000
leads dans le CRM
Chiffres de périmètre : ils décrivent l’environnement de travail, pas un résultat généré personnellement.
CONTEXTE ET PROBLÈME
Extracadabra utilisait Salesforce pour quatre Business Units : environ 30 utilisateurs et une base d’environ 50 000 leads. Chaque équipe avait sa façon de vendre, mais toutes travaillaient dans le même CRM.
Le sujet était double. Côté données : des champs à rationaliser, des doublons à détecter et des leads à segmenter par BU. Côté usage : des fiches et des interfaces à adapter pour que chaque commercial retrouve vite l’information utile, sans saisie inutile.
Le pilotage commercial en dépendait : sans base propre et statuts cohérents, difficile de suivre l’activité et le pipeline de chaque BU.
Ce dont les Sales avaient besoin
CE QUI A ÉTÉ MIS EN PLACE
Chaque chantier explique ce qui a été fait et à quoi cela servait. Les schémas sont des illustrations ; le scoring et le Flow sont des exemples de démonstration, pas ceux utilisés en production chez Extracadabra.
01
Rationalisation des champs, création de l’objet Lead lors du déploiement initial de Salesforce, personnalisation des fiches et des opportunités. Les Record Types et les Page Layouts adaptent chaque interface à une Business Unit.
À quoi ça servait : rendre le CRM lisible et limiter la saisie inutile.
02
Structuration du suivi des leads, détection des doublons à la création, segmentation par Business Unit et scoring selon des critères de qualification. Les Sales disposent d’une liste de leads avec priorité et prochaine étape.
À quoi ça servait : aider les commerciaux à décider quel lead traiter en premier.
Colonnes de la liste de leads
03
Exemple sur un lead fictif, Thomas Leroy chez Novalink : chaque critère de qualification ajoute des points, jusqu’à un score de 81/100.
Exemple de démonstration. Ce n’est pas la formule historique exacte d’Extracadabra.
04
Création et mise à jour de tâches, notifications, progression du cycle de vente, mise à jour d’informations selon les actions des commerciaux.
Exemple de démonstration de ma compréhension des Flows. Ce n’est pas le Flow utilisé en production chez Extracadabra.
05
Dashboards de suivi de l’activité commerciale et du pipeline, construits à partir de rapports Salesforce.
À quoi ça servait : donner aux managers et aux Sales une lecture commune du pipeline.
• Leads par Business Unit et par statut
• Activité commerciale
• Opportunités par étape
• Pipeline par Business Unit
• Opportunités ouvertes et clôturées
06
Documentation des objets et des workflows, tutoriels d’utilisation, ateliers de formation avec les équipes commerciales et accompagnement à la prise en main du CRM.
À quoi ça servait : que la configuration soit comprise et utilisée par les Sales, pas seulement livrée.
• Documentation des objets et workflows
• Tutoriels d’utilisation
• Ateliers de formation avec les Sales
• Accompagnement à la prise en main
RÉSULTATS ET SYNTHÈSE
4
Business Units
Un modèle CRM commun, avec des interfaces adaptées à chaque équipe.
~30
utilisateurs CRM
Des commerciaux à accompagner : documentation, tutoriels et ateliers.
~50 000
leads dans le CRM
La base sur laquelle ont porté la déduplication, la segmentation et le scoring.
Ces chiffres décrivent le périmètre du projet, pas un résultat généré personnellement.
Ce que j’en retiens
Un CRM utilisable commence par un modèle de données lisible : champs utiles, objets cohérents, statuts clairs.
Les interfaces doivent suivre le travail réel de chaque équipe, d’où les Record Types et les Page Layouts par BU.
Scoring, automatisations et dashboards ne valent que si les données sont propres.
Sans documentation ni formation, la configuration reste une démo : l’adoption fait partie du projet.