Archisnapper et Ziggu se connectent via l'API REST publique de Ziggu. Les réserves que votre équipe relève sur chantier arrivent chaque jour dans Ziggu, où vous décidez lesquelles publier vers le client. À partir de là, le client suit les points qui le concernent, en signale de nouveaux, et confirme une réparation quand elle est faite. Cette confirmation peut repartir vers Archisnapper. Votre client n'ouvre jamais Archisnapper, et rien de tout cela n'arrive par e-mail.
Parce qu'Archisnapper est un outil de chantier. Il contient chaque point de chaque affaire en cours, dans le langage de votre équipe terrain, à un niveau de détail juste pour elle et écrasant pour un client. Lui donner cette vue crée des questions, pas de la clarté, et expose des travaux en cours qui ne lui étaient pas destinés.
L'alternative sur laquelle la plupart des équipes se rabattent est l'e-mail, et c'est pire. Un point signalé par e-mail atterrit dans une seule boîte, où il doit être lu, transféré au responsable et relancé. Il se perd, et quand il ne se perd pas, il coûte quand même trois messages.
Ziggu se place entre les deux. Le client voit les points que vous avez publiés, en termes clairs, sur son propre projet. Il en signale un nouveau depuis là, votre équipe l'examine, et il part vers Archisnapper s'il y a sa place. Voir Rapports.
La synchronisation quotidienne fait entrer les réserves dans Ziggu. Elle ne les met pas sous les yeux du client. Quelqu'un de votre équipe les publie, et cet écart est délibéré : un point relevé à huit heures du matin avec une photo et un mot n'est pas ce que vous voulez faire lire à un acquéreur à neuf heures.
Il y a donc trois filtres, et ils répondent à des questions différentes. Les catégories dans Archisnapper décident de ce qui passe. La publication décide quand le client le voit. L'accès par rapport décide qui le voit. La plupart des équipes utilisent les trois.
Ce que les équipes sous-estiment : dans Ziggu, vous pouvez demander au client de confirmer qu'un point est résolu. Il appuie sur un bouton. Cette confirmation peut repartir vers Archisnapper comme statut mis à jour, pour que votre équipe terrain la voie là où elle travaille.
Ce que cela vous apporte n'est pas le clic. C'est que six semaines plus tard, personne ne discute pour savoir si un point avait été réparé, parce que le client l'a dit lui-même, par écrit, sur le moment.
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. Là où le tableau dit projet, lisez le logement ou l'unité si vous en livrez plusieurs dans une même promotion : dans Ziggu, c'est le même type de fiche.
| Ce que c'est dans Ziggu | Endpoint | Sens | Quand |
|---|---|---|---|
| Les réserves, comme points d'un rapport Ziggu | /issues | Archisnapper vers Ziggu | Chaque jour, puis publiées par votre équipe |
| La liste à laquelle un point appartient | /issue_lists | Archisnapper vers Ziggu | Avec le point |
| Catégorie et statut | /issue_categories, /issue_statuses | Mappés dans les deux sens | Avec le point |
| Un point signalé par le client, pour examen par votre équipe | /issues | Créé dans Ziggu | Poussé vers Archisnapper après examen |
| Un point confirmé résolu par le client | /issue_statuses | Ziggu vers Archisnapper | Chaque jour |
| Le projet auquel le point appartient, ou l'unité qu'il contient | /projects, /units | Rapproché, pas créé | Avec le point |
Trois voies, la même API en dessous. Choisissez celle qui correspond à qui va la maintenir.
Quelle que soit la voie, deux décisions viennent d'abord. Quelles catégories Archisnapper sont destinées au client, et sur quel projet Ziggu un chantier Archisnapper donné se rattache. Si vous livrez plusieurs logements dans une même promotion, cette seconde décision est tout le travail, parce que chaque acquéreur doit voir ses propres points et ceux de personne d'autre. Fixez les deux, faites tourner une fois sur un seul chantier, et regardez ce que le client verrait avant d'élargir.
Un client qui voit le point, sa catégorie et son statut cesse de demander. Votre équipe terrain enregistre un point une fois, dans l'application qu'elle utilise déjà, et personne ne le retape pour le montrer au client.
Les clients remarquent des choses. Dans Ziggu, ils les signalent sur leur propre projet, avec une photo, et votre équipe décide de la suite. Comparez avec le même signalement arrivant par e-mail un vendredi à vingt et une heures.
Les points relevés à la réception sont les mêmes que ceux encore ouverts un mois plus tard. Comme ils vivent dans les Rapports de Ziggu, à côté du reste du projet, le SAV continue là où la réception s'est arrêtée au lieu de repartir d'un tableur vierge.
Non, et vous le contrôlez trois fois. Les catégories dans Archisnapper décident de ce qui passe. La publication décide quand le client le voit. L'accès par rapport décide qui le voit.
Les réserves se synchronisent chaque jour. Ensuite, c'est visible pour le client dès que votre équipe publie.
Oui, dans Ziggu, sur son propre projet. Votre équipe l'examine et le pousse vers Archisnapper s'il y a sa place, pour que rien n'atteigne l'équipe terrain sans filtre.
Oui. Vous pouvez lui demander de marquer un point comme résolu dans Ziggu, et ce statut peut repartir vers Archisnapper comme mise à jour. Un bouton pour lui, une trace écrite pour vous.
Oui, à condition que le mapping soit fait ainsi. Ziggu peut diviser un projet en unités individuelles, et un point se rattache à l'une d'elles. Les équipes qui mènent un chantier par client n'ont jamais besoin de cette division : leur projet et leur unité sont la même fiche.
Oui, par le même type de voie. Voir Letsbuild et Ziggu.
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
