#CRM #hubspot #pipedrive #bizdev #B2B #qualification #prospect #leads #clients
Stack :
- Bubble
- Vercel, Edge Function, Redis K/V
- NextAuth, Pathfix, Oauth2
- NestJS
- Typescript
- Webhook
Disclamer : Pour des raisons de confidentialité, la plupart des captures sont indisponibles.
Bob est Sales / Bizdev. Il fait de la propsection commerciale pour dénicher de nouveaux clients
Il est partenaire de Tom.
Il estiment que l'union fait la force et qu'en partagant mutuellement certaines données précises, ils peuvent rendre leur prospection commerciale beaucoup plus efficace.
Bob a son CRM chez Pipedrive, Tom a son CRM chez Hubspot. Les 2 acceptent un partage croisé.
Tom synchronise son CRM avec celui de Bob, et réciproquement.
Dès lors,
- Bob est informé que l'entreprise X qu'il a en commun avec Tom est Client de Tom.
- Tom est informé que l'entreprise X qu'il a en commun avec Bob est Lead de Tom.
Et ca, pour toutes les entreprises qu'ils ont en commun.
Leurs CRM respectifs viennent d'etre enrichis, qualifiés de manière croisée.
mais ca ne s'arrête pas là : puisque le 2 ont aussi d'autres partenaires. Donc ils démultiplient la qualification de leur carnet d'entreprises. :
- Bob est informé que l'entreprise Y qu'il a en commun avec Tom est Client d'un autre partenaire de Tom.
- Tom est informé que l'entreprise X qu'il a en commun avec Bob est Lead d'un autre partenaire de Bob.
...et la liste s'allonge pour autant de partenaires de chaque côté.
Spoiler : les screenshots sont à l'heure actuell sous le sceau de la confidentialité
Résultat d'une synchro : même entreprise, sur 2 CRM différents, enrichie des 2 côtés
Un aperçu de l'architecture
Pourquoi cette architecture ?
Rappleon le contexte fonctionbnel eigent : il y a 3 algos dans ce système :
1. first-synchro :
je compare tous les entreprise client avec toutes celles de son partenaire
et j'enrichis les enterperises du client. Partenaire fera pareil de son côtré en sens inverse
2. hook-create
je créer une nouvelle entreprise dans mon CRM : l'algo vérifie auprès de mes partnaires lesquels référencent cette entreprise et s'ils travaillent avec ou pas.
3. hook-update
il y a du mouvement dans le CRM de mes partenaire : si l'entreprise mise à jour chez lui à une correspondance chez moi, mon CRM bénéiffice immédiatement de cette mise à jour.
Cette architecture est avant tout asynchrone, c'est nécessaire car on traite du volume :
Une firt-synchro peut comparer 30.000 enterprises de part et d'autres
Une update peut concerner N entreprise à la fois
Un création d'entreprise qui matcher N entreprises chez mes patenaires
Un import d'entreprises (création en masse) peut matcher N entreprise chez mes patenaires
Les webhook coté CRM qui viennent notifier la plateform sont très exigent sur la durée timeout du endpoint chez nous. On ne peut pas attendre la fin d'un fin d'exec algo pour enfin répondre au webhook du CRM.
A ce titre nous avon
Redis
- stocke temporairement les collections à comparer
- stocke les access-tokens des CRM clients et partenaire
- stocke les settings client (migration à prévoir sur une DB noSQL sur un volume, pas in-memory)
BullMQ
- enmagazine dans Redis les ordres à executer de manière asynchrone (les jobs)
- déclenche et orchestre les Workers qui exec les étapes composant chaque algo (collecte, API updates, export CSV, ...)
NestJS
- pilote bullMQ
- implémente les algos
- planifie le renouvellement des tokens OAuth2
NextJS (legacy)
- Gère les actions CRUD des settings client en lien direct avec Bubble
- C'est le backend technique pour Bubble
Bubble.io
- tout le frontend
- gestion des settings clients
- branchement au CRM
- gestion relations partenaires et partage de données
Et d'un flow de synchro
