Over deze case: Op verzoek van de klant zijn bedrijfsnaam en specifieke details geanonimiseerd. Het bedrijf opereert in een competitieve markt waar hun operationele efficiëntie een strategisch voordeel is.
”Ik had het zelf gebouwd, en het werkte”
De operations manager van deze B2B scale-up in de mobiliteitsmarkt stond onder druk. Het bedrijf groeide snel—te snel voor de handmatige processen die ze hadden.
“We kregen tientallen nieuwe leads per dag binnen via de website. Elke lead moest verrijkt worden met bedrijfsdata, gekwalificeerd worden op basis van criteria, en toegewezen aan de juiste sales rep. Dat was uren werk per dag, elke dag.”
Ze had geen development-achtergrond, maar wel een Make.com-account en YouTube. “Ik dacht: dit moet te automatiseren zijn. En dat was het ook.”
In drie weekenden bouwde ze een flow die alles deed:
- Nieuwe HubSpot-lead triggert de flow
- Bedrijfsdata wordt opgehaald uit de KvK-API
- Lead wordt gescoord op basis van bedrijfsgrootte en branche
- Score bepaalt de prioriteit en toewijzing
- Sales rep krijgt een Slack-notificatie met alle context
“De eerste keer dat het werkte, voelde ik me een held. Mijn collega’s waren onder de indruk. Onze directie zei: ‘Dit is precies wat we nodig hadden.’”
Totdat het niet werkte
De problemen begonnen subtiel. Een lead die niet doorkwam. Een dubbele entry in HubSpot. Een sales rep die geen notificatie kreeg.
“In het begin dacht ik: incidenten. Ik fixte ze handmatig en ging door. Maar het werden er meer.”
Ze begon een spreadsheet bij te houden van wat er misging:
- KvK-API timeout: flow crashed, lead verdwijnt
- Speciale tekens in bedrijfsnaam: JSON-parse error, flow crashed
- HubSpot rate limit: te veel requests, alle leads van dat uur missen
- Dubbele webhook-trigger: dezelfde lead twee keer verwerkt
- Lege velden: flow crashed als een veld niet bestaat
“Ik besteedde meer tijd aan het fixen van de automatisering dan ik ooit aan handmatig werk had besteed. En het ergste: ik wist nooit of er iets mis was gegaan totdat iemand klaagde.”
“Mijn automatisering werkte 80% van de tijd perfect. Maar die andere 20% was een nachtmerrie.”
Het dilemma: weggooien of doormodderen?
Ze stond voor een keuze. Terug naar handmatig? Onacceptabel—het bedrijf groeide te hard. Doormodderen met de huidige flow? Onhoudbaar. Een developer inhuren om het helemaal opnieuw te bouwen? Te duur en te langzaam.
“Ik had het gevoel dat ik vast zat. Ik had iets gebouwd dat bijna werkte, maar niet helemaal. En ik had geen idee hoe ik die laatste 20% moest fixen.”
Analyseren, niet oordelen
Onze eerste stap: de Make-flow begrijpen. Niet om te oordelen, maar om te leren.
“Ik verwachtte dat jullie zouden zeggen: dit is amateurwerk, we beginnen opnieuw. Maar jullie zeiden iets anders. Jullie zeiden: dit is slim gebouwd, alleen niet robuust.”
Wat ze goed had gedaan:
- De logica was helder en goed gedocumenteerd
- De stappen waren logisch opgedeeld
- De integraties waren correct geconfigureerd
- De happy path werkte perfect
Wat ontbrak:
- Error handling: als iets faalt, crasht de hele flow
- Retry-logica: tijdelijke fouten worden niet automatisch herhaald
- Logging: geen zicht op wat er gebeurt
- Alerts: niemand weet het als er iets misgaat
- Idempotency: dezelfde input kan meerdere outputs creëren
“Jullie tekenden het uit op een whiteboard: hier zijn de plekken waar het mis kan gaan. Het waren er meer dan ik dacht.”
Niet opnieuw bouwen, wel professionaliseren
We kozen voor een hybride aanpak: de Make-flow bleef de basis, maar we voegden een “safety net” toe.
Stap 1: Centraal logging Elke stap in de flow logt nu naar een centrale database. Als er iets misgaat, kunnen we exact zien waar en waarom.
Stap 2: Error handling per stap Als de KvK-API faalt, crashed de flow niet. In plaats daarvan wordt de lead gemarkeerd als “handmatig te verrijken” en gaat de rest van de flow door.
Stap 3: Retry met backoff Tijdelijke fouten (rate limits, timeouts) worden automatisch herhaald met exponentiële backoff. Drie pogingen over 5 minuten voordat het als echte fout wordt gemarkeerd.
Stap 4: Deduplicatie Een check aan het begin van de flow: is deze lead al verwerkt? Zo ja, stop. Dit voorkomt dubbele entries bij webhook-retries.
Stap 5: Alerting Slack-notificaties bij fouten, met context over wat er mis ging. Ze weet nu binnen minuten als er iets niet klopt.
Stap 6: Graceful degradation Voor edge cases die geen automatisering aankan (complexe bedrijfsstructuren, buitenlandse leads) is er een handmatige queue. De flow herkent deze cases en routeert ze automatisch.
“Het voelde niet als opnieuw beginnen. Het voelde als volwassen maken wat ik al had gebouwd.”
De technische details
Voor wie het wil weten—dit is wat we technisch hebben aangepast:
- n8n als orchestrator in plaats van Make (meer controle over error handling)
- Python microservice voor complexe logica die te fragiel was in no-code
- PostgreSQL voor logging en state management
- AWS Lambda voor de retry-queue
- Webhook signature validation om te voorkomen dat externe partijen de flow kunnen triggeren
De migratie van Make naar n8n duurde twee dagen. De rest van de tijd ging naar het bouwen van de robuustheidlaag.
Maanden later: stilte is goud
Het beste bewijs dat het werkt: ze denkt niet meer aan de automatisering.
“Vroeger was het elke dag: wat is er nu weer mis? Nu open ik één keer per week het dashboard om te checken of alles goed gaat. En dat doet het.”
De resultaten:
- Geen handmatige interventies meer nodig
- Vrijwel alle leads worden automatisch verwerkt
- Edge cases naar handmatige queue (complexe situaties die menselijke beoordeling vragen)
- Snelle responsetijd van lead naar sales-contact
- Salesteam uitgebreid zonder aanpassingen aan de flow
“Het mooiste moment was toen we nieuwe salespeople aannamen. Vroeger had dat een week werk betekend om alle routering aan te passen. Nu was het: nieuwe naam in de tabel, klaar.”
“Ik zeg nu tegen iedereen: bouw het zelf, maar laat het daarna professionaliseren. Je leert enorm veel van het zelf bouwen. Maar op een gegeven moment heb je iemand nodig die weet hoe je het betrouwbaar maakt.”
Lessons learned
-
80% werkend is niet goed genoeg
Bij automatisering is de happy path makkelijk. De waarde zit in hoe je omgaat met de andere 20%: fouten, uitzonderingen, edge cases. -
Zelf bouwen heeft waarde
Ze begreep haar proces beter dan wie ook, juist omdat ze het zelf had geautomatiseerd. Die kennis was onmisbaar voor de professionalisering. -
Error handling is geen afterthought
In productie-systemen is error handling 50% van de code. Bij no-code tools wordt dit vaak vergeten—tot het misgaat. -
Logging is je beste vriend
Je kunt niet fixen wat je niet kunt zien. Elke automatisering zou moeten loggen wat er gebeurt, ook als het goed gaat. -
Graceful degradation > perfecte automatisering
Sommige dingen kun je niet automatiseren. Een systeem dat zijn eigen grenzen kent en graceful terugvalt op handmatig is beter dan eentje dat crashed. -
Alerts moeten actionable zijn
”Er is iets misgegaan” is geen goede alert. “Lead X kon niet worden verrijkt omdat de KvK-API een 429 gaf, lead staat in handmatige queue” is dat wel.
