985 inzendingen op de verkeerde lijst. En niemand die het zag.

Case · Automatisering & integratie

Holos33 had werkende formulieren, een ingerichte Zoho CRM en een e-mailsysteem dat netjes verstuurde. Alles leek te functioneren. Toen ik ging meten, droeg 985 van de 1.136 inzendingen het verkeerde herkomstlabel. Filter je de spamgolf eruit, dan ging van het échte verkeer twee derde naar de verkeerde bestemming. Eén formulier weigerde bovendien 25 dagen lang elke inzending — zonder één foutmelding. Dit is wat AIAgentCycle heeft gevonden, gerepareerd en — belangrijker — aantoonbaar gemaakt. Niet met een rapport, maar met een keten die dagelijks zichzelf natoetst.

Over deze case. Holos33 is mijn eigen platform. Ik publiceer deze case omdat ik alles eerst op mezelf test en omdat de cijfers gemeten zijn, niet geschat. Externe cases volgen; de eerste is in voorbereiding.

• 985

  van 1.136 inzendingen met verkeerd herkomstlabel

• 100%

  van het prijzenformulier werd stil geweigerd

• 0

  foutmeldingen die iemand ooit bereikten

• 21/32

  van het échte verkeer werd misgerouteerd

De case in één alinea

AIAgentCycle heeft voor privacy-first welzijnsplatform Holos33 de complete keten van webformulier naar CRM, boekingssysteem en e-maillijst doorgemeten, gerepareerd en van bewijs voorzien. De keten loopt van vier actieve Fluent Forms-formulieren op tien pagina’s van een WordPress-site, via een PHP-brug en een self-hosted n8n-workflow, naar Zoho CRM, Zoho Bookings en Listmonk. Ik vond drie oorzaken van stil verlies — een routeringsfout in PHP, een anti-spamfilter dat zijn eigen invoer nooit ontving, en een n8n-keten die sessie-attributie boven paginacontext liet gaan — plus een waarschuwingssysteem dat nooit had gewerkt. Na afloop zijn zes van de zeven bestemmingen end-to-end aangetoond met echte browserinzendingen — de zevende, de losse nieuwsbrieflijst, heeft geen bereikbaar formulier en is synthetisch getoetst. Een dagelijkse controle bewaakt sindsdien of het zo blijft.

Wat AIAgentCycle heeft opgeleverd

Eén doorlopende keten, van klik tot lijst, met bewijs op elke overgang. Concreet is dit opgeleverd en in productie genomen:

Over Holos33

Holos33 is een privacy-first welzijnsplatform van Good Nature Vibe B.V., met een AI-coach, biofeedback en modules voor mensen, teams en onderzoekspartners. Het platform bedient particulieren, bedrijven, professionals zoals coaches en therapeuten, en academische onderzoekspartners — vier doelgroepen die elk hun eigen formulier, eigen opvolging en eigen e-maillijst hebben. Daarnaast loopt er een early-accesstraject via de prijzen- en early-accesspagina van Holos33.

Precies die vier doelgroepen maken de zaak interessant: zodra één binnenkomende aanvraag op de verkeerde lijst belandt, krijgt een onderzoeker een verkoopmail en een inkoper een onderzoeksuitnodiging. Het systeem werkt dan technisch, maar richt commerciële schade aan.

De volledige workflow: van webhookontvangst tot bevestigingsmail, met idempotente schrijfacties naar Zoho CRM en Listmonk.

Wat ik aantrof

De opdracht begon met één zin van de eigenaar: “de formulieren werken niet, mensen komen niet op de juiste lijst.” Dat bleek geen enkel probleem te zijn, maar vier onafhankelijke — die elkaar bovendien maskeerden.

1. Een vergeten regel die 985 records raakte

De PHP-brug die formulierinzendingen doorgeeft, herkende het onderwerp “Zakelijke samenwerking” wel, maar zette in die tak alleen het CRM-veld en vergat de herkomst. Gevolg: 985 van de 1.136 inzendingen kwamen binnen als “Contact algemeen” in plaats van hun werkelijke segment. Geen foutmelding, geen logregel — de gegevens waren compleet, alleen het etiket klopte niet.

2. Een anti-spamfilter dat zijn eigen invoer nooit kreeg

Op het prijzenformulier stond een zelfgebouwde anti-spamcontrole met drie verborgen velden. Fluent Forms filtert binnenkomende velden echter tegen de formulierdefinitie (array_intersect_key), en die drie velden stonden daar niet in. Ze werden dus weggegooid vóórdat de controle draaide. De controle concludeerde daarop “geen bewijs van een echte bezoeker” en weigerde iedereen, 25 dagen lang, met een rode melding en zonder ergens iets op te slaan.

3. Routering op sessie-attributie in plaats van paginacontext

De n8n-workflow bepaalde de herkomst opnieuw uit de velden source_url en landing_page. Dat zijn attributievelden: ze bewaren waar de bezoeker de site is binnengekomen, niet waar hij het formulier invult. Wie binnenkwam op de bedrijvenpagina en vervolgens het onderzoeksformulier invulde, werd als “Bedrijven” geclassificeerd — de correcte waarde die PHP meestuurde werd overschreven. Van de 32 echte inzendingen had er 21 een landingspagina die afweek van de formulierpagina: twee derde van het echte verkeer.

4. Een spamgolf die de cijfers onleesbaar maakte

Ongeveer 1.117 van de 1.136 inzendingen kwamen uit één klein IP-bereik (80.94.95.0/24). Die bots gingen rechtstreeks naar het contactformulier, dus voor hen wás de landingspagina de formulierpagina. Daardoor leek de routeringsfout een randgeval: 25 afwijkingen op 1.215 inzendingen. Pas na het uitsplitsen van echt verkeer en spam kwam het werkelijke beeld boven.

De aanpak: meten, dan pas repareren

Ik heb niets aangeraakt voordat de nulmeting stond. De volgorde was vast, en elke stap had een poort die van twee kanten dicht moest voordat de volgende begon.

1. Audit en nulmeting. Alle inzendingen, executies, lijsten en logregels geteld en gedateerd, inclusief backup en rollbackpunt per systeem.
2. Poort 0 — komt legitiem verkeer nog door? Niet afgeleid uit “geen spam meer”, maar bewezen met een echte browserinzending die aantoonbaar in n8n aankwam.
3. Poort 1 — is de bezorging sluitend? Inclusief herkansingen en een dead-letter met alarm.
4. Fase 3a — routering in PHP. Stabiele sleutels in plaats van labelteksten, plus paginacontext op post-ID.
5. Poort 2 — brede toets. Eén echte browserinzending per bestemming, waarvan minstens twee met een landingspagina die bewust afweek van de formulierpagina.
6. Fase 3b — routering in n8n. De dubbele afleiding eruit, zodat er nog één bron van waarheid is.
7. Poort 3 — negatieve test. Bewust een fout veroorzaken en aantonen dat het vangnet vult en alarmeert.
8. Fase 4 — geen stille terugval meer. Pas als al het bovenstaande bewezen is.

De brede poort: één echte inzending per bestemming, allemaal teruggelezen op herkomst, segment en doellijst.

De architectuur

De keten heeft vier schakels en één regel: elk feit heeft precies één bron.

Formulieren koppelen aan Zoho CRM

Elke inzending wordt genormaliseerd tot één vaste vorm en daarna weggeschreven met een upsert op e-mailadres. Dat maakt de bezorging idempotent: komt dezelfde inzending door een herkansing twee keer binnen, dan ontstaat er geen dubbele lead maar wordt de bestaande bijgewerkt. Zonder die eigenschap is elke retry-strategie een dubbeltjesmachine.

De herkomst wordt op één plek bepaald — in PHP, op basis van het werkelijke post-ID van de pagina waarop het formulier staat — en daarna door de hele keten meegedragen. Waar eerder de labeltekst van een keuzeoptie de routering stuurde, staat nu een stabiele sleutel. Gevolg: de teksten mogen vertaald of herschreven worden zonder dat er iets omvalt. Dat was geen theoretisch risico: van de acht onderwerpen waren er zes al vertaald en stonden precies de twee waar de routering op steunde nog open.

De routeringstabel: acht herkomsten, elk met hun segment en doellijst, op één plek vastgelegd in plaats van verspreid over de keten.

Een aangemaakte lead in Zoho CRM, met herkomst, segment en taalvoorkeur als gestructureerde velden in plaats van vrije tekst.

Boekingen: van formulier naar agenda

Een demo-aanvraag hoeft niet in een mailbox te belanden. Na verzending gaat de aanvrager direct door naar Zoho Bookings, waar hij zelf een moment kiest uit het juiste gesprekstype — zakelijke demo, professional-intake of researchkennismaking. De lead staat op dat moment al in het CRM met de juiste herkomst, dus het gesprek begint met context in plaats van met uitvragen.

Direct doorgeleid naar het juiste gesprekstype, met de lead al in het CRM.

E-mail, dubbele opt-in en AVG

Listmonk is het self-hosted e-mailsysteem in deze keten. Acht doellijsten in totaal: één per segment, plus een aparte nieuwsbrieflijst per taal. Wie zich aanmeldt krijgt een dubbele opt-in in zijn eigen taal, en pas na bevestiging telt de aanmelding als toestemming.

Bij aanvang was de bevestigingspagina Engelstalig, ongebrand en toonde hij de tekst “Private list” aan Nederlandse bezoekers. Dat is precies het moment waarop iemand besluit of hij je vertrouwt. Nu is die pagina Nederlands, gebrand en in lijn met de rest van het platform.

Acht doellijsten met hun aantallen. Twee lijsten kregen tijdens dit traject hun allereerste correct gerouteerde aanmelding.

Foutafhandeling: wat er gebeurt als iets stukgaat

Een keten die alleen werkt als alles meewerkt, is geen keten maar een hoop geluk. De foutafhandeling is daarom in lagen gebouwd, van binnen naar buiten, en elke laag kapt eerder af dan de laag erbuiten:

Mislukt een bezorging, dan volgt een herkansingsladder van 60, 300 en 900 seconden. Slagen alle vier de pogingen niet, dan gaat de inzending naar de dead-letter — mét payload, zodat de lead terug te halen is — en slaat de dagelijkse controle alarm. Slaagt een herkansing wel, dan wordt dat apart genoteerd zonder persoonsgegevens, als waarschuwing en niet als storing.

Het vangnet dat nooit had gewerkt

De monitoringworkflow stond correct ingesteld als foutafhandelaar van alle andere workflows. Toch was er nog nooit één waarschuwing verstuurd. De reden: de workflow miste de node die op fouten reageert, en de alertstap die er wél in zat, was nergens op aangesloten. De opzet stond in de documentatie ín de workflow beschreven; alleen de bedrading ontbrak. Na aansluiten vuurde hij bij de eerstvolgende gecontroleerde fout voor het eerst in zijn bestaan.

Dead-letter met bewaartermijn, herkansingslog zonder persoonsgegevens, en de dagelijkse samenvatting die beide bewaakt.

Anti-spam zonder legitieme bezoekers te blokkeren

De spamgolf kwam uit één klein IP-bereik en was daarmee gericht af te vangen: IP Access Rules en een WAF-regel in Cloudflare. Een Turnstile-widget is aangemaakt en staat klaar voor de formulieren; die wordt geactiveerd zodra de sleutels zijn geplaatst. Dat is de makkelijke helft.

De moeilijke helft is bewijzen dat je daarmee geen klanten hebt buitengesloten. Daarom is elke anti-spammaatregel fail-open gebouwd: ontbreekt de invoer waarop de controle steunt, dan weigert hij niet, maar noteert hij dat de invoer ontbrak. Ontbrekende invoer is een fout aan mijn kant, geen bewijs tegen de bezoeker. Precies die omkering was de oorzaak van de 25 dagen stille weigering.

Gerichte blokkade op het bereik waar de golf vandaan kwam, met een tweezijdige toets dat legitiem verkeer er nog doorheen komt.

Serverhardening en Cloudflare Zero Trust

De automatiseringsomgeving staat achter Cloudflare Zero Trust Access: de n8n-omgeving is niet langer bereikbaar met alleen een wachtwoord, maar zit achter een toegangsbeleid dat vóór de applicatie beslist wie er binnenkomt. Dat is voor een automatiseringsplatform belangrijker dan voor een website, omdat er credentials van CRM, e-mail en boekingen in liggen opgeslagen.

Verder ingericht op de omgeving:

• Gescheiden staging en productie met een promotieprocedure: linten, kopiëren, eigenaar zetten, cache legen, rooktest — en pas dan live.
• Rollbackpunt per wijziging, met SHA-256 vóór en na, plus een volledige databasedump. Eén dump faalde stil omdat de uitvoerende gebruiker geen schrijfrechten had op het doelpad; sindsdien wordt op bestandsgrootte getoetst vóórdat een backup als geldig telt.
• Credentials uitsluitend in bestanden met beperkte rechten, nooit in documenten, chats of workflowdefinities.
• Bewaartermijnen op elk logboek: 90 dagen voor de dead-letter met inhoud, 30 dagen voor het weigeringslog met alleen een adres, 14 dagen voor het herkansingslog zonder persoonsgegevens.
• Tijdslimieten die kloppen met de omgeving — de bezorging bleek in de webcontext te draaien met een limiet van 30 seconden, terwijl de meting via de commandoregel onbeperkt was. Zonder die correctie zou een trage bezorging fataal afbreken en het vangnet overslaan.

Cloudflare Zero Trust vóór de automatiseringsomgeving: toegang wordt beoordeeld voordat de applicatie überhaupt antwoordt.

Monitoring: bewakers die kunnen falen

Er draaien drie controles die dagelijks nameten wat er is opgeleverd: komt er nog spam uit het geblokkeerde bereik en komt legitiem verkeer er nog wél doorheen; is de bezorging sluitend en is de dead-letter leeg; en klopt de routering nog voor alle bestemmingen in beide talen.

Elke bewaker is negatief getest. Dat wil zeggen: ik heb hem bewust een situatie voorgeschoteld die fout is, en gecontroleerd dat hij dan ook echt rood wordt. Een van mijn eigen bewakers gaf bij de eerste versie namelijk PASS op nul metingen — een fatale fout in de leesroutine werd door foutonderdrukking opgeslokt, waarna het script “niets gevonden, dus niets mis” concludeerde. Dat is dezelfde denkfout als “geen spam meer, dus het werkt”, en de negatieve test is het enige dat hem vangt.

Drie controles, elk met een positieve én een negatieve test, dagelijks in de samenvatting.

Het resultaat

Wat dit voor jouw organisatie betekent

Deze case gaat niet over Holos33. Hij gaat over een patroon dat ik bij vrijwel elke gekoppelde omgeving terugzie: het systeem meldt niets, dus gaat iedereen ervan uit dat er niets mis is. Stille fouten hebben geen klagende gebruiker. Ze hebben alleen een omzet die lager is dan hij zou moeten zijn, zonder dat iemand kan aanwijzen waarom.

Drie vragen die je vandaag zelf kunt stellen:

1. Kun je aanwijzen waar de laatste tien aanvragen terecht zijn gekomen? Niet “in het CRM”, maar op welke lijst, met welke herkomst.
2. Wat gebeurt er als de koppeling er tien minuten uit ligt? Als het antwoord “dat weet ik niet” is, is het antwoord waarschijnlijk “dan is die aanvraag weg”.
3. Wanneer heeft jouw foutmelding voor het laatst gevuurd? Nooit is geen goed teken — het is meestal het teken dat hij niet is aangesloten.

Wat AIAgentCycle voor je bouwt

Ik koppel systemen die elk voor zich werken maar samen niets bewijzen. Formulieren, CRM, e-mail, agenda’s, facturatie, voorraad, klantportalen — en alles wat een API heeft. De techniek is zelden het probleem; de aantoonbaarheid wel.

Waar ik voor sta

• Workflow-automatisering met n8n, self-hosted op jouw eigen omgeving, zodat jouw klantgegevens jouw infrastructuur niet verlaten en de logica leesbaar blijft in plaats van verstopt in een SaaS-dienst.
• CRM-integraties — Zoho, HubSpot, Pipedrive, Dynamics — met idempotente schrijfacties, zodat herkansingen nooit dubbele records opleveren.
• AI-agents die iets doen in plaats van iets zeggen: verrijken, classificeren, routeren en samenvatten binnen een keten die controleerbaar is.
• Backoffice- en administratie-automatisering: offertes, orders, facturen en documentstromen tussen systemen die niet met elkaar praten.
• Serverhardening en Cloudflare Zero Trust, inclusief gescheiden staging, promotieprocedures en rollbackpunten per wijziging.
• Meetbaarheid als opleverpunt: elke koppeling krijgt een bewaker die kan falen, met een negatieve test die bewijst dat hij dat ook doet.

Zo werk ik

1. Nulmeting. Ik tel eerst. Hoeveel aanvragen kwamen binnen, hoeveel staan er in jouw systemen, en waar loopt dat uiteen.
2. Diagnose met bewijs. Geen vermoedens, maar een reproductie: ik laat de fout zien voordat ik hem repareer.
3. Repareren achter poorten. Elke stap heeft een toets die van twee kanten dicht moet, en een rollbackpunt voordat er iets verandert.
4. Aantonen. Echte inzendingen door de echte keten, teruggelezen tot in de doellijst.
5. Overdragen. Bewakers, bewaartermijnen, alarmering en een leesbare trail van wat er is gedaan en hoe je het terugdraait.

Veelgestelde vragen

Wat kost het om een formulier aan een CRM te koppelen?

Dat hangt minder af van de koppeling dan van wat eromheen moet. Eén formulier naar één CRM-veld is een kwestie van uren. Wat tijd kost is het aantoonbaar maken: herkansingen, een vangnet, herkomstbepaling met één bron, en controles die kunnen falen. In deze case ging het merendeel van de tijd niet naar de koppeling, maar naar meten, bewijzen en bewaken.

Waarom self-hosted n8n en niet een kant-en-klare koppeling?

Omdat de logica hier niet in één regel past. Vier actieve formulieren, tien pagina’s, twee talen, acht bestemmingen en een boekingssysteem — dat is geen “als dit dan dat”. n8n is een workflow-automatiseringsplatform dat je zelf kunt draaien, wat betekent dat de gegevens jouw omgeving niet verlaten en dat je de logica kunt lezen in plaats van hem te moeten vertrouwen.

Hoe weet ik of mijn formulieren leads verliezen?

Vergelijk drie tellingen over dezelfde periode: het aantal inzendingen in jouw formulierplugin, het aantal aangemaakte records in jouw CRM, en het aantal aanmeldingen op jouw e-maillijst. Lopen die uiteen, dan verdwijnt er iets tussen twee schakels. Loopt het gelijk, controleer dan of de herkomst klopt — dat is de fout die geen verschil in aantallen oplevert.

Wat is een dead-letter en waarom heb ik die nodig?

Een dead-letter is een wachtrij waarin een bezorging belandt die na alle herkansingen nog steeds niet is aangekomen, inclusief de volledige inhoud. Zonder dead-letter is een mislukte bezorging definitief weg. Mét dead-letter is hij een handmatige actie van vijf minuten. Het verschil tussen die twee is precies het verschil tussen een verloren klant en een late reactie.

Is dit AVG-proof?

De keten is zo ingericht dat toestemming pas telt na een bevestigde dubbele opt-in, dat logboeken een bewaartermijn hebben, dat het herkansingslog geen persoonsgegevens bevat, en dat er nooit een mailing wordt gedraaid op adressen die de bevestigingsstap niet hebben gehaald. Dat is een technische inrichting, geen juridisch advies — laat de verwerkingsgrondslag en het verwerkingsregister altijd door jouw eigen jurist toetsen.

Werkt dit ook met HubSpot, Pipedrive of Microsoft Dynamics?

Ja. De bestemming is de makkelijkste schakel om te vervangen; de moeilijke delen — herkomst met één bron, idempotente schrijfacties, herkansingen met een vangnet, en controles die kunnen falen — zijn niet CRM-specifiek.

Case uitgevoerd door AIAgentCycle voor Holos33, een merk van Good Nature Vibe B.V., augustus–september 2026. Holos33 en AIAgentCycle zijn handelsnamen van hetzelfde bedrijf, Good Nature Vibe B.V.; dit traject is uitgevoerd onder dezelfde werkwijze, poortcontroles en documentatiediscipline als bij externe opdrachten. Alle genoemde aantallen zijn gemeten waarden uit de betrokken systemen. Techniek: WordPress, Fluent Forms, WPML, PHP, Action Scheduler, n8n (self-hosted), Zoho CRM, Zoho Bookings, Listmonk, Cloudflare (WAF, Turnstile, Zero Trust Access).