![[DATA]BLE](https://datable.fr/wp-content/uploads/2026/05/Logo-datable.webp){kind=logo}
Partir du réel, pas d’un cahier des charges idéal
Chaque mission commence par une structure déjà en place : son historique, ses habitudes, ses contraintes budgétaires et ses propres règles — un financement impossible ici, un besoin de tout centraliser en un seul outil là. Le travail de Datable consiste à partir de cette réalité, souvent chaotique, pour construire une architecture qui tient dans la durée. Deux missions récentes, anonymisées, illustrent cette méthode.
Structurer l’opérationnel et automatiser le suivi client avec un budget logiciel quasi nul
Un coworking multisite, une dizaine de stagiaires et un budget outils quasi nul.
La structure accueillait en permanence une dizaine de stagiaires répartis sur plusieurs sites. Le système devait fonctionner avec les versions gratuites de HubSpot, Notion, Zapier et des applications développées en interne avec Claude, Node.js, Netlify et GitHub.
Des informations dispersées, des outils limités et aucun suivi automatisé après réservation.
Il n’existait pas de référentiel commun permettant aux stagiaires de retrouver les procédures, les plannings, les projets ou les informations nécessaires au fonctionnement des sites et au service client.
HubSpot gratuit imposait des limites en matière de dashboards et de reporting.
Enfin, après chaque réservation d’un espace de coworking, aucune séquence automatisée ne prenait le relais pour assurer la confirmation et la fidélisation client.
Un écosystème opérationnel construit autour de Notion, HubSpot, d’outils maison et de Zapier.
1. Centralisation dans Notion
Création d’un espace commun regroupant les fiches stagiaires, les plannings, les projets, les procédures et les informations essentielles sur le fonctionnement de la structure.
Les accès étaient différenciés selon les rôles : stagiaire ou manager.
2. Reporting et applications internes
Optimisation de HubSpot gratuit et création d’applications légères avec Claude, Node.js, Netlify et GitHub pour compléter les fonctionnalités insuffisantes de l’offre gratuite.
Ces outils permettaient le suivi des projets stagiaires, la visualisation de dashboards et le pilotage opérationnel des sites : nettoyage, stocks et fournitures.
L’ensemble était accessible depuis un téléphone.
3. Automatisation post-booking avec Zapier
Création d’une séquence de communication déclenchée après chaque réservation :
- J0 : envoi automatisé de la confirmation de réservation.
- J7 : distribution d’un premier code de réduction unique, attribué individuellement au client.
- J14 : vérification de l’utilisation du premier code. S’il n’avait pas été utilisé, attribution d’un nouveau code de réduction unique.
Les codes étant individuels et à usage unique, leur utilisation pouvait être suivie par client, permettant de conditionner le second envoi.
Des confirmations automatisées, des stagiaires plus autonomes et un pilotage opérationnel centralisé.
Les confirmations ne dépendaient plus d’un envoi manuel systématique, réduisant le risque d’oubli.
Les stagiaires disposaient d’un point d’accès commun aux informations et d’applications mobiles pour assurer le suivi de leurs activités et du fonctionnement des sites.
Le système a permis d’améliorer l’organisation quotidienne sans investissement significatif en licences logicielles.
Les outils gratuits réduisent les coûts financiers, mais déplacent une partie du coût vers le temps humain.
La stabilisation du routing Zapier a nécessité deux semaines de travail.
Ce projet montre qu’une architecture low-cost peut répondre à de vrais besoins opérationnels, mais qu’elle exige davantage de conception, de tests, d’ajustements et parfois de maintenance.
Les plans gratuits imposent également des limites de fonctionnalités, de capacité et d’évolutivité. Ils représentent un compromis, pas une solution universelle.
Le choix d’une architecture doit donc intégrer non seulement le coût des licences, mais aussi le temps de mise en place, la fiabilité, la maintenance et la capacité du système à évoluer.
CRM Migration & Multi-Brand Sales Operations
Deux marques, un seul HubSpot, des parcours commerciaux distincts et une gouvernance des données reconstruite.
Une entreprise B2B, deux marques et une équipe commerciale à accompagner dans sa transformation CRM.
L’entreprise utilisait Pipedrive et souhaitait migrer vers HubSpot pour moderniser son fonctionnement commercial, centraliser ses données et automatiser davantage ses processus.
La particularité du projet : deux marques avec des parcours de qualification différents, devant coexister dans un même environnement HubSpot, sans disposer de la fonctionnalité Business Units.
L’enjeu n’était pas de réduire les coûts logiciels, mais de construire une architecture fiable, évolutive et adaptée aux pratiques commerciales réelles.
Des données historiques à fiabiliser et deux parcours commerciaux à faire coexister dans un seul CRM.
La migration impliquait plusieurs difficultés :
- Des données Pipedrive présentant des problèmes de qualité, de cohérence et de gouvernance.
- Des anomalies dans les exports, notamment des lignes fantômes nécessitant des contrôles et un travail de réconciliation.
- Des informations historiques à préserver pour conserver la continuité du suivi commercial.
- Deux marques avec des critères de qualification et des parcours de vente spécifiques.
- L’absence de Business Units HubSpot, imposant une architecture alternative pour séparer les parcours sans fragmenter inutilement les contacts.
- Des processus commerciaux nécessitant davantage de structuration, de suivi et d’automatisation.
Le défi consistait à déterminer ce qu’il fallait nettoyer avant la migration, ce qui pouvait être conservé et transféré, et ce qui nécessitait un traitement ou une restructuration après migration.
Une architecture HubSpot multimarque, une migration contrôlée et des workflows alignés sur les besoins commerciaux.
1. Analyse métier et conception du système cible
Analyse des besoins commerciaux, des parcours clients et des différences entre les deux marques.
Traduction de ces besoins en processus CRM : étapes de qualification, règles de passage entre les stages, informations à collecter, responsabilités commerciales et conditions d’automatisation.
L’objectif était de ne pas reproduire mécaniquement Pipedrive dans HubSpot, mais de concevoir un système mieux adapté aux besoins de l’entreprise.
2. Audit, data governance et migration Pipedrive → HubSpot
Audit des données existantes et identification des anomalies, doublons potentiels, incohérences et problèmes de gouvernance.
Contrôles de réconciliation des exports, notamment pour traiter les lignes fantômes et comprendre les écarts observés.
Définition des mappings entre les objets et propriétés Pipedrive et HubSpot.
Utilisation de l’application native Pipedrive–HubSpot pour la migration, avec création de propriétés personnalisées destinées à préserver les informations historiques nécessaires, notamment les dates de création et les références des contacts, Leads et Deals.
Distinction entre les corrections à effectuer en amont de la migration et les traitements à réaliser après transfert dans HubSpot.
Contrôles de qualité et de cohérence pour limiter les pertes d’information, les doublons et les erreurs d’association.
3. Architecture HubSpot pour deux marques sans Business Units
Conception d’un workaround reposant sur une architecture CRM partagée, avec séparation logique des parcours commerciaux.
- Un référentiel de Contacts commun afin de limiter la duplication d’une même personne.
- Une propriété Business Line pour identifier la marque concernée, ou les deux.
- Deux Lead Pipelines distinctes, avec des étapes de qualification propres aux marques.
- Des parcours de Deals séparés selon les besoins commerciaux.
- Un routing tenant compte de la marque, de l’origine du Lead et des règles de qualification.
- Une gestion du cas où un Contact peut être pertinent pour les deux marques, sans recréer inutilement le Contact.
Cette architecture permet de centraliser la donnée tout en conservant la distinction nécessaire entre les parcours commerciaux.
4. Connexion des sites web, formulaires et automatisation du routing
Mise en place des formulaires HubSpot et de leur intégration aux différents sites web.
Création de workflows permettant d’identifier la Business Line et de diriger les nouvelles demandes vers le bon Lead Pipeline.
Lorsqu’un prospect soumet un formulaire, le système peut déclencher la création du Lead correspondant, en tenant compte des contrôles nécessaires pour éviter les Leads actifs dupliqués.
Chaque marque conserve ainsi son propre parcours de qualification à l’intérieur d’un environnement commun.
5. Automatisation des processus commerciaux
Mise en place de workflows pour accompagner les équipes dans leurs tâches quotidiennes :
- Création et qualification des Leads.
- Progression dans les stages selon les règles métier définies.
- Création d’un Deal dans le pipeline approprié après qualification SQL et validation commerciale.
- Suivi des actions attendues aux différentes étapes du pipeline.
- Déclenchement de tâches ou de relances lorsque certaines actions commerciales restent à réaliser.
- Emails automatisés pour soutenir le suivi et les communications commerciales.
L’objectif n’était pas d’automatiser chaque interaction humaine, mais de réduire le travail administratif répétitif et de fiabiliser les transitions entre les étapes commerciales.
Un CRM structuré autour des parcours commerciaux, et non plus uniquement autour des données existantes.
La nouvelle architecture organise les activités des deux marques au sein d’un environnement HubSpot commun, avec des parcours de qualification distincts, des données historiques conservées selon les mappings retenus et des règles de routing adaptées.
Les automatisations permettent de réduire certaines manipulations manuelles, de structurer le suivi des opportunités et d’assister les commerciaux dans leurs prochaines actions.
Le travail d’audit et de migration apporte également une base plus structurée pour la gouvernance et le suivi de la qualité des données.
La difficulté d’une migration CRM n’est pas seulement de transférer des données : c’est de décider comment elles doivent vivre dans le nouveau système.
La principale complexité de ce projet résidait dans la compréhension des besoins commerciaux, la définition d’une architecture cohérente et la capacité à prendre rapidement des décisions face à des données imparfaites.
Toutes les anomalies ne doivent pas nécessairement être corrigées au même moment.
Certaines doivent être traitées avant la migration pour éviter de transférer des incohérences ou de perdre des associations essentielles. D’autres peuvent être traitées après migration, lorsque le nouveau modèle de données et les règles de gestion sont en place.
L’utilisation d’un CRM plus complet et d’un budget logiciel adapté facilite la construction, les tests et le déploiement des automatisations. Mais la performance de l’outil ne remplace ni l’analyse métier, ni la qualité des données, ni la gouvernance.
Un CRM performant ne corrige pas à lui seul un processus mal défini : il peut simplement l’automatiser plus vite.
Un projet similaire à construire ?
Que vous soyez une agence, un intégrateur ou une structure avec un CRM qui a perdu le fil, Datable part de votre réalité existante pour construire une architecture qui tient dans la durée.
Parlons-enStarting from reality, not an ideal spec
Every engagement starts with a structure that’s already in place: its history, its habits, its budget constraints, and its own rules — impossible financing here, the need to centralize everything into one tool there. Datable’s approach is to start from that reality, often chaotic, and build an architecture that holds up over time. Two recent engagements, anonymized, illustrate this method.
Structuring operations and automating client follow-up on a near-zero software budget
A multi-site coworking space, around ten interns, and a near-zero tooling budget.
The organization hosted around ten interns at a time, spread across several sites. The system had to run on the free tiers of HubSpot, Notion, Zapier, and in-house applications built with Claude, Node.js, Netlify, and GitHub.
Scattered information, limited tooling, and no automated follow-up after a booking.
There was no shared reference point for interns to find procedures, schedules, projects, or the information needed to run the sites and serve clients.
Free-tier HubSpot imposed limits on dashboards and reporting.
Finally, after each coworking space booking, no automated sequence took over to handle confirmation and client retention.
An operational ecosystem built around Notion, HubSpot, in-house tools, and Zapier.
1. Centralizing in Notion
Creation of a shared space bringing together intern profiles, schedules, projects, procedures, and the essential information about how the organization operated.
Access was differentiated by role: intern or manager.
2. Reporting and internal applications
Optimization of free-tier HubSpot and creation of lightweight applications with Claude, Node.js, Netlify, and GitHub to fill the gaps in the free offering.
These tools enabled tracking of intern projects, dashboard visualization, and operational management of the sites: cleaning, stock, and supplies.
Everything was accessible from a phone.
3. Post-booking automation with Zapier
Creation of a communication sequence triggered after each booking:
- Day 0: automated sending of the booking confirmation.
- Day 7: distribution of a first unique discount code, assigned individually to the client.
- Day 14: check on whether the first code had been used. If not, a new unique discount code was issued.
Since the codes were individual and single-use, their usage could be tracked per client, which determined whether the second one was sent.
Automated confirmations, more autonomous interns, and centralized operational oversight.
Confirmations no longer depended on a systematic manual send, reducing the risk of it being missed.
Interns had a shared access point for information and mobile applications to track their activities and the day-to-day running of the sites.
The system improved day-to-day organization without any significant investment in software licenses.
Free tools reduce financial costs, but shift part of the cost onto human time.
Stabilizing the Zapier routing took two weeks of work.
This project shows that a low-cost architecture can meet real operational needs, but it demands more design, testing, adjustment, and sometimes maintenance.
Free plans also come with limits on features, capacity, and scalability. They represent a trade-off, not a universal solution.
Choosing an architecture therefore needs to account not just for license costs, but also for setup time, reliability, maintenance, and the system’s ability to scale.
CRM Migration & Multi-Brand Sales Operations
Two brands, one HubSpot, distinct sales journeys, and rebuilt data governance.
A B2B company, two brands, and a sales team to guide through a CRM transformation.
The company used Pipedrive and wanted to migrate to HubSpot to modernize its commercial operations, centralize its data, and automate more of its processes.
The project’s particularity: two brands with different qualification journeys, needing to coexist within a single HubSpot environment, without access to the Business Units feature.
The stake wasn’t reducing software costs, but building a reliable, scalable architecture suited to real sales practices.
Historical data to make reliable, and two sales journeys to make coexist within a single CRM.
The migration involved several difficulties:
- Pipedrive data with quality, consistency, and governance issues.
- Export anomalies, including phantom rows requiring checks and reconciliation work.
- Historical information to preserve in order to maintain continuity of sales tracking.
- Two brands with distinct qualification criteria and sales journeys.
- The absence of HubSpot Business Units, requiring an alternative architecture to separate journeys without needlessly fragmenting contacts.
- Sales processes needing more structure, tracking, and automation.
The challenge was determining what needed to be cleaned up before migration, what could be preserved and transferred as-is, and what required processing or restructuring after migration.
A multi-brand HubSpot architecture, a controlled migration, and workflows aligned with sales needs.
1. Business analysis and target system design
Analysis of sales needs, customer journeys, and the differences between the two brands.
Translating these needs into CRM processes: qualification stages, rules for moving between stages, information to collect, sales ownership, and automation conditions.
The goal wasn’t to mechanically reproduce Pipedrive inside HubSpot, but to design a system better suited to the company’s needs.
2. Audit, data governance, and Pipedrive → HubSpot migration
Audit of existing data and identification of anomalies, potential duplicates, inconsistencies, and governance issues.
Reconciliation checks on exports, in particular to handle phantom rows and understand the discrepancies observed.
Defining the mappings between Pipedrive and HubSpot objects and properties.
Use of the native Pipedrive–HubSpot app for the migration, with custom properties created to preserve the necessary historical information, in particular creation dates and references for contacts, leads, and deals.
Distinguishing between fixes to make before migration and processing to carry out after the transfer into HubSpot.
Quality and consistency checks to limit information loss, duplicates, and association errors.
3. HubSpot architecture for two brands without Business Units
Design of a workaround built on a shared CRM architecture, with logical separation of sales journeys.
- A shared contact repository to limit duplicating the same person.
- A Business Line property to identify the relevant brand, or both.
- Two distinct lead pipelines, with brand-specific qualification stages.
- Separate deal journeys depending on sales needs.
- Routing that accounts for the brand, the lead’s origin, and qualification rules.
- Handling cases where a contact is relevant to both brands, without needlessly recreating the contact.
This architecture centralizes data while preserving the distinction needed between sales journeys.
4. Connecting websites, forms, and routing automation
Setting up HubSpot forms and integrating them with the different websites.
Creating workflows to identify the Business Line and route new requests to the correct lead pipeline.
When a prospect submits a form, the system can trigger the creation of the corresponding lead, accounting for the checks needed to avoid duplicate active leads.
Each brand thus keeps its own qualification journey within a shared environment.
5. Sales process automation
Workflows set up to support teams in their day-to-day tasks:
- Lead creation and qualification.
- Progression through stages according to defined business rules.
- Deal creation in the appropriate pipeline after SQL qualification and sales validation.
- Tracking of expected actions at each pipeline stage.
- Triggering tasks or reminders when certain sales actions are still outstanding.
- Automated emails to support follow-up and sales communication.
The goal wasn’t to automate every human interaction, but to reduce repetitive administrative work and make transitions between sales stages more reliable.
A CRM structured around sales journeys, not just around existing data.
The new architecture organizes both brands’ activities within a shared HubSpot environment, with distinct qualification journeys, historical data preserved according to the chosen mappings, and adapted routing rules.
The automations help reduce certain manual tasks, structure the tracking of opportunities, and assist sales reps with their next actions.
The audit and migration work also provides a more structured foundation for data governance and quality tracking.
The difficulty of a CRM migration isn’t just transferring data: it’s deciding how that data should live in the new system.
The main complexity of this project lay in understanding the sales needs, defining a coherent architecture, and being able to make quick decisions in the face of imperfect data.
Not all anomalies need to be fixed at the same time.
Some need to be addressed before migration, to avoid transferring inconsistencies or losing essential associations. Others can be handled after migration, once the new data model and business rules are in place.
Using a more complete CRM and a suitable software budget makes building, testing, and deploying automations easier. But the tool’s power doesn’t replace business analysis, data quality, or governance.
A capable CRM doesn’t fix a poorly defined process on its own: it can simply automate it faster.
A similar project to build?
Whether you’re an agency, an integrator, or an organization whose CRM has lost the thread, Datable starts from your actual, existing reality to build an architecture that holds up over time.
Let’s talk