Teamleader Focus + Ziggu

Teamleader Focus et Ziggu se connectent via l'API REST publique de Ziggu. Un deal qui atteint l'étape que vous choisissez devient un projet Ziggu avec ses contacts rattachés, et les devis et factures arrivent comme décisions et tranches. L'enjeu n'est pas que les données circulent. L'enjeu est que votre client cesse de chercher : chaque choix du projet, votre devis et tout ce qui vient après, attend dans un seul portail client plutôt que dispersé entre votre outil de devis, votre boîte mail et un disque partagé.

L'essentiel

• Teamleader Focus se connecte à Ziggu via l'API REST publique de Ziggu. Vous pouvez construire vous-même, faire construire par votre partenaire, ou utiliser un modèle prêt à l'emploi sur Peliqan.
• Un deal qui atteint l'étape que vous désignez devient un projet Ziggu, avec les contacts liés déjà rattachés.
• Les devis arrivent dans Ziggu comme décisions et les factures comme tranches, si bien qu'un client répond à votre proposition au même endroit où il valide tout ce qui suit.
• Un devis signé électroniquement dans Teamleader garde ce flux : la décision dans Ziggu porte un lien qui ouvre l'application de signature Teamleader.
• C'est une connexion planifiée, pas événementielle. Un deal qui atteint votre étape devient un projet au passage suivant, et vous en fixez la fréquence.

Pourquoi les connecter

Teamleader envoie déjà le devis, et le client peut déjà le signer là. La raison de connecter n'est donc pas le devis. C'est tout ce qui l'entoure.

Sur un projet qui comporte du sur-mesure, un client ne prend pas une seule décision. Il valide la proposition, puis ce que votre métier exige ensuite : un plan, un cahier des charges, un matériau, une modification en cours de chantier, un rapport à la fin. La liste dépend de votre métier. La forme, non. Si la proposition vit dans votre outil de devis et le reste dans les e-mails, le client a deux endroits à consulter et vous avez un problème de suivi.

Amener le devis Teamleader dans les décisions de Ziggu place toute la séquence dans une seule liste, dans l'ordre où elle doit se dérouler. La signature électronique reste où elle doit être : Ziggu affiche la décision, et le lien qu'elle porte ouvre l'application de signature Teamleader, si bien que vous gardez le flux de signature que vous connaissez et que le client n'ouvre toujours qu'une seule application. Voir Décisions et approbations.

Projet, unité, et pourquoi la distinction compte ici

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, ce qui est la façon de travailler de la plupart des utilisateurs de Teamleader, votre projet et votre unité sont la même fiche et ces niveaux restent invisibles. C'est utile à savoir avant de convenir du mapping, car cela décide de ce qu'un deal Teamleader doit devenir.

Quelles données circulent entre Teamleader Focus et Ziggu

Écrites dans Ziggu via l'API publique. La première colonne est le nom que votre équipe connaît dans l'application, la seconde est l'endpoint que votre développeur appelle.

‍

Comment connecter Teamleader Focus à Ziggu ?

Trois voies, la même API en dessous. Choisissez celle qui correspond à qui va la maintenir.

1. Construire vous-même. Demandez un jeton d'intégration à Ziggu, puis écrivez contre api.ziggu.app/public. Les jetons sont émis par organisation. Référence : documentation de l'API Ziggu.
2. Faire construire par votre partenaire d'intégration. Même API, même jeton, la maintenance chez quelqu'un d'autre.
3. Utiliser un modèle prêt à l'emploi sur Peliqan. Peliqan dispose de connecteurs pour Teamleader Focus et pour Ziggu, donc le modèle se déploie et se configure plutôt qu'il ne s'écrit. Les modèles sont copiés et adaptés par client, donc le mapping des champs se convient à la mise en place.

Quelle que soit la voie, trois décisions viennent d'abord : quelle étape crée le projet, quels champs Teamleader atterrissent où dans Ziggu, et à quelle fréquence cela tourne. Fixez-les, faites tourner une fois sur un seul deal, et vérifiez le projet, les contacts, les décisions et les tranches avant de pointer sur tout votre pipeline.

Où les équipes l'utilisent

Donner au client un seul endroit pour chaque décision, pas seulement pour le devis

La proposition vient de Teamleader. Tout ce que le client doit valider ensuite, non. Dans Ziggu, tout s'aligne en une seule liste que le client déroule, et c'est ce qui évite qu'il vous écrive pour demander ce qu'il lui reste à approuver.

Transmettre un deal signé sans rien retaper

La vente travaille dans Teamleader et s'arrête là. Le client, les contacts et le périmètre convenu sont déjà dans Ziggu quand l'équipe de réalisation ouvre le projet. Personne ne copie un contact dans un second système, et personne ne démarre sur une adresse périmée.

Faire tourner le même transfert sur chaque projet

Parce que le déclencheur est une étape du deal, le transfert se fait de la même façon à chaque fois. Aucun projet ne démarre parce que quelqu'un y a pensé. Voir comment architectes et entrepreneurs utilisent Ziggu.

Ce que Teamleader Focus et Ziggu ne font pas

• C'est une connexion planifiée, pas événementielle. Un deal qui atteint votre étape devient un projet au passage suivant, pas dans la seconde. Vous fixez le rythme.
• Il n'y a pas d'application Ziggu dans Teamleader ni d'application Teamleader dans Ziggu. Quelqu'un construit ou déploie la connexion, que ce soit vous, votre partenaire ou un modèle sur Peliqan.
• Les clients ne sont pas invités automatiquement. La connexion prépare le projet et les contacts ; une personne dans Ziggu décide quand le portail s'ouvre.
• Ce qu'une implémentation donnée déplace se convient à la mise en place. Traitez le tableau ci-dessus comme la forme de la connexion, pas comme un contrat figé.
• L'API publique de Ziggu n'a pas de webhooks : rien n'est renvoyé vers Teamleader au moment où cela se produit dans Ziggu.
• L'API est limitée à 60 requêtes par minute tous endpoints confondus, ce qui détermine le premier chargement d'un pipeline existant.

Questions sur l'intégration Teamleader

Y a-t-il une application Ziggu dans le Teamleader Marketplace ?

Non. La connexion tourne sur l'API REST publique de Ziggu. Vous la construisez, un partenaire la construit, ou vous déployez un modèle sur Peliqan.

Qu'est-ce qui déclenche la création d'un projet dans Ziggu ?

Un deal qui atteint l'étape que vous désignez. Le projet apparaît au passage planifié suivant.

Le client peut-il encore signer le devis dans Teamleader ?

Oui. La décision dans Ziggu porte un lien qui ouvre l'application de signature Teamleader, donc le flux de signature ne change pas et le client n'ouvre toujours qu'une application.

Pourquoi amener les devis dans Ziggu si Teamleader les envoie déjà ?

Parce que le devis n'est qu'une décision parmi d'autres sur un projet qui n'est pas standard. Plans, cahiers des charges, matériaux, modifications et rapports de réception demandent aussi une réponse. Dans Ziggu, ils forment une seule liste que le client déroule dans l'ordre.

Le client est-il invité automatiquement ?

Non. La connexion crée le projet et rattache les contacts ; quelqu'un de votre équipe envoie l'invitation depuis Ziggu une fois le portail prêt à être vu.

Quelque chose se synchronise-t-il de Ziggu vers Teamleader ?

Pas dans le sens décrit ici. Cette connexion déplace les données de Teamleader vers Ziggu.

Et si nous utilisons déjà un autre CRM ?

La même API sert HubSpot, Salesforce et Zoho.

Dernière vérification : 28 août 2026.