HubSpot et Ziggu sont reliés par Ziggu. Nous construisons la connexion et nous l'exploitons, donc il n'y a rien à installer dans votre portail HubSpot et rien à maintenir pour votre équipe. Dès qu'un deal atteint une étape que vous choisissez, ou dès que quelqu'un coche un champ sur ce deal, le projet est créé dans Ziggu, le client y est rattaché et les documents du deal suivent. HubSpot reste l'endroit où la vente se pilote. Ziggu est le portail client où votre client vit avec le résultat.
HubSpot est fait pour votre équipe : le pipeline, les séquences, les notes internes, le reporting. Rien de tout cela n'est ce dont un client a besoin une fois le contrat signé.
Après la signature, les questions changent, et sur un projet long elles continuent pendant un an ou plus. Quand dois-je faire mon prochain choix. Où est le document que j'ai signé. Qu'ai-je déjà payé, et que reste-t-il. Ces questions arrivent par e-mail et par téléphone, et chacune coûte une demi-journée à quelqu'un.
C'est la partie que HubSpot n'a jamais eu vocation à porter. Le transfert est tout l'intérêt de la connexion : au moment où un deal se conclut, tout ce dont le client aura besoin est déjà rassemblé au même endroit plutôt que dispersé dans une boîte mail.
Ziggu organise le travail en projets, et un projet peut contenir une unité ou des centaines. Une unité est la plus petite chose qu'un client possède : un appartement dans une promotion, une maison, un aménagement, une commande. Entre le projet et l'unité se trouvent des niveaux optionnels, phases, lots et bâtiments, que les grands projets utilisent et que les petits ne voient jamais.
Si vous menez un chantier par client, votre projet et votre unité sont la même fiche et ces niveaux restent invisibles. Si vous en livrez quatre-vingt-dix dans un même projet, vous les utilisez tous. La connexion se comporte pareil dans les deux cas ; ce qui change, c'est le mapping, et c'est la seule conversation qu'il faut mener correctement.
La première colonne est le nom que votre équipe connaît dans l'application, la seconde est l'endpoint qu'un développeur appellerait si vous vouliez un jour reconstruire ou étendre cette connexion vous-même.
| Ce que c'est dans Ziggu | Endpoint | Sens | Quand |
|---|---|---|---|
| Le projet, et les unités qu'il contient | /projects, /units | HubSpot vers Ziggu | Sur votre déclencheur |
| Le contact du deal, rattaché à la bonne unité | /customers, /unit_customers | HubSpot vers Ziggu | Avec le projet |
| L'entreprise derrière le contact | /companies | HubSpot vers Ziggu | Avec le contact |
| Les documents attachés au deal, classés sous la catégorie que vous choisissez | /documents, /attachment_categories | HubSpot vers Ziggu | Avec le projet |
| L'invitation au portail | Envoyée depuis Ziggu par votre équipe | Manuel | Quand vous décidez que le portail est prêt |
Vous préférez maîtriser ? Le même travail peut se faire sur l'API REST publique de Ziggu, par vos propres développeurs ou par IO Digital, qui construit cette connexion pour des clients Ziggu. Référence des endpoints : documentation de l'API Ziggu.
Une étape du deal est la réponse évidente et elle fonctionne tant que chaque vente suit le même chemin. Elle cesse de fonctionner dès que vous avez des deals qui se concluent mais ne doivent pas encore démarrer, ou des projets qui commencent avant que la paperasse soit bouclée.
C'est pour cela que le champ existe. Un champ oui/non, coché par celui qui sait, déplace une fiche quand elle est vraiment prête, sans tordre votre pipeline autour de l'intégration. La plupart des équipes finissent par utiliser l'étape pour le cas standard et le champ pour les exceptions.
Tout le reste est automatique, l'invitation ne l'est pas. C'est délibéré.
Un projet qui vient d'être créé est vide. Si le client entrait au moment même où le deal se conclut, il trouverait un portail sans contenu, et c'est une moins bonne première impression que pas de portail du tout. Comme inviter est une action distincte, quelqu'un regarde ce qui est arrivé, complète ce qui manque, puis ouvre la porte. Un clic, au moment que vous choisissez.
L'écart entre une signature et le premier vrai contact est l'endroit où la confiance se perd. Quand le deal crée le projet, tout est déjà en place, et ouvrir le portail devient une décision plutôt qu'un chantier en soi.
HubSpot contient le forecast, les notes internes et chaque deal que vous n'avez pas gagné. Rien de tout cela n'est destiné au client. Ziggu montre au client son propre projet et rien d'autre, et c'est ce qui rend sûr de lui donner accès.
Ce que la vente a saisi est déjà dans Ziggu quand l'équipe de réalisation reprend. Voir comment les promoteurs immobiliers utilisent Ziggu.
Non. Ziggu construit et exploite cette connexion pour vous, donc il n'y a rien à installer dans votre portail.
Un déclencheur que vous choisissez : un deal qui atteint une étape, ou un champ oui/non coché quand la fiche est prête. Beaucoup d'équipes utilisent les deux.
Non, et c'est délibéré. La connexion crée le projet et rattache le contact ; quelqu'un de votre équipe envoie l'invitation après avoir vérifié que le portail est prêt à être vu.
Oui. Ils atterrissent dans les documents du projet dans Ziggu, sous la catégorie convenue à la mise en place.
Oui. IO Digital construit cette connexion sur l'API REST publique de Ziggu, et vos propres développeurs peuvent faire de même.
Non. Les clients ne voient que Ziggu. HubSpot reste interne.
C'est exactement le cas pour lequel le déclencheur par champ existe. Laissez le champ vide et rien ne bouge, quelle que soit l'étape.
Dernière vérification : 28 août 2026.
Ziggu already integrates seamlessly with a number of CRM, ERP and document management systems. Can't find yours? Contact us and we'll research the possibilities!
CONTACT US
