Archisnapper en Ziggu koppelen via de publieke REST API van Ziggu. De punten die je team op de werf registreert, komen dagelijks in Ziggu terecht, waar jij beslist welke je publiceert naar de klant. Vanaf daar volgt de klant de punten die hem aangaan, meldt hij nieuwe, en bevestigt hij een herstelling wanneer ze klaar is. Die bevestiging kan terugvloeien naar Archisnapper. Je klant opent nooit Archisnapper, en niets van dit alles komt binnen als e-mail.
Omdat Archisnapper een werftool is. Het bevat elk punt op elke opdracht die je lopen hebt, in de taal die je werfteam gebruikt, op een detailniveau dat voor hen klopt en een klant overspoelt. Die weergave doorgeven levert vragen op in plaats van duidelijkheid, en het toont werk in uitvoering dat nooit voor hem bedoeld was.
Het alternatief waar de meeste teams op terugvallen is e-mail, en dat is slechter. Een punt dat per mail gemeld wordt, belandt in één mailbox, waar het gelezen, doorgestuurd en opgevolgd moet worden. Het raakt kwijt, en als het niet kwijtraakt, kost het nog altijd drie berichten.
Ziggu zit ertussen. De klant ziet de punten die jij gepubliceerd hebt, in gewone taal, op zijn eigen project. Hij meldt daar een nieuw punt, je team beoordeelt het, en het gaat naar Archisnapper als het daar thuishoort. Zie Verslagen.
De dagelijkse sync brengt punten binnen in Ziggu. Ze zet ze niet voor de klant. Iemand van je team publiceert ze, en die tussenstap is bewust: een punt dat om acht uur 's ochtends gelogd wordt met een foto en één woord uitleg, is niet wat je een koper om negen uur wil laten lezen.
Er zijn dus drie filters, en ze beantwoorden verschillende vragen. Categorieën in Archisnapper bepalen wat überhaupt overkomt. Publiceren bepaalt wanneer een klant het ziet. Toegang per verslag bepaalt wie het ziet. De meeste teams gebruiken alle drie.
Het stuk dat teams onderschatten: in Ziggu kan je de klant vragen te bevestigen dat een punt opgelost is. Hij drukt op één knop. Die bevestiging kan als gewijzigde status terug naar Archisnapper, zodat je werfteam ze ziet waar het werkt.
Wat dat oplevert is niet de klik. Het is dat er zes weken later niemand discussieert over de vraag of een punt hersteld was, want de klant heeft het toen zelf bevestigd, op papier.
De eerste kolom is de naam die je team uit de app kent, de tweede is het endpoint dat je ontwikkelaar effectief aanroept. Waar de tabel project zegt, lees de individuele woning of unit als je er meerdere levert binnen één ontwikkeling: in Ziggu is dat hetzelfde soort record.
| Wat het is in Ziggu | Endpoint | Richting | Wanneer |
|---|---|---|---|
| Punten, als lijnen in een Ziggu-verslag | /issues | Archisnapper naar Ziggu | Dagelijks, daarna gepubliceerd door je team |
| De lijst waar een punt bij hoort | /issue_lists | Archisnapper naar Ziggu | Met het punt |
| Categorie en status | /issue_categories, /issue_statuses | In beide richtingen gemapt | Met het punt |
| Een punt dat de klant meldde, ter beoordeling door je team | /issues | Aangemaakt in Ziggu | Naar Archisnapper geduwd na beoordeling |
| Een punt dat de klant als opgelost bevestigde | /issue_statuses | Ziggu naar Archisnapper | Dagelijks |
| Het project waar het punt bij hoort, of de individuele unit erin | /projects, /units | Gematcht, niet aangemaakt | Met het punt |
Drie routes, dezelfde API eronder. Kies degene die past bij wie het gaat onderhouden.
Welke route je ook kiest, twee beslissingen komen eerst. Welke Archisnapper-categorieën naar de klant mogen, en op welk Ziggu-project een bepaalde Archisnapper-werf uitkomt. Lever je meerdere woningen binnen één ontwikkeling, dan is die tweede beslissing de hele klus, want elke koper moet zijn eigen punten zien en die van niemand anders. Leg allebei vast, laat het één keer lopen op één werf, en kijk naar wat de klant zou zien voor je het breder zet.
Een klant die het punt, de categorie en de status kan zien, stopt met vragen. Je werfteam logt een punt één keer, in de app die het al gebruikt, en niemand typt het een tweede keer over om het aan de klant te tonen.
Klanten merken dingen op. In Ziggu melden ze die op hun eigen project, met een foto, en beslist je team wat er daarna gebeurt. Vergelijk dat met dezelfde melding die op vrijdagavond om negen uur als mail binnenkomt.
De punten van de oplevering zijn dezelfde punten die een maand later nog openstaan. Omdat ze in de Verslagen van Ziggu staan, naast de rest van het project, gaat de nazorg verder waar de oplevering gestopt is in plaats van te starten vanaf een nieuw rekenblad.
Nee, en je bepaalt het drie keer. Categorieën in Archisnapper bepalen wat overkomt. Publiceren bepaalt wanneer de klant het ziet. Toegang per verslag bepaalt wie het ziet.
Punten synchroniseren dagelijks. Daarna is het zichtbaar voor de klant zodra je team het publiceert.
Ja, in Ziggu, op zijn eigen project. Je team beoordeelt het en duwt het naar Archisnapper als het daar thuishoort, zodat niets ongefilterd bij het werfteam terechtkomt.
Ja. Je kan de klant vragen een punt in Ziggu op opgelost te zetten, en die status kan als update terug naar Archisnapper. Eén knop voor hem, en een schriftelijk spoor voor jou.
Ja, op voorwaarde dat de mapping zo opgezet is. Ziggu kan een project opdelen in de individuele units erin, en een punt hangt aan één ervan. Teams met één opdracht per klant hebben die opdeling nooit nodig: hun project en hun unit zijn hetzelfde record.
Ja, via hetzelfde soort route. Zie Letsbuild en Ziggu.
Laatst nagekeken: 28 augustus 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
