Frank Verberne

Sociale nerd die processen automatiseert

Ik ben Frank Verberne. Ik promoveerde op de interactie tussen mens en technologie, werkte als coach en trainer en stuurde als productmanager UX-designers en developers aan. Sinds eind 2024 bouw ik zelf: automatiseringen die terugkerend handwerk overnemen, zodat er tijd vrijkomt voor werk dat ertoe doet.

Hieronder staat wat ik bouwde, wat ik onderweg leerde en wat ik voor jouw organisatie kan automatiseren.

Portretfoto van Frank Verberne

Professioneel werk

Gebouwd in mijn werk als Business Process Automation Engineer, sinds eind 2024.

2025 – 2026

Verloning die zichzelf klaarzet

Python, Selenium, PyQt5, Google Apps Script, Make.com, Employes, Google Drive

Probleem

Elke maand moesten reiskosten, thuiswerkdagen, verlof en ziekte per medewerker in de loonstroken komen. De gegevens zaten verspreid over NS Zakelijk, Employes en spreadsheets. En NS heeft geen API.

Wat ik bouwde

Een Python-desktopapp logt in op NS Zakelijk, downloadt per abonnement de reistransacties en zet ze in Google Drive. Een tweede app dient woon-werkdeclaraties voor meerdere dagen tegelijk in bij Employes. Make.com regisseert de rest: het haalt medewerkers, verlof en ziekte uit Employes en roept mijn Apps Script aan. Dat script maakt een tabblad voor elke nieuwe medewerker, koppelt NS-kosten via het kaartnummer aan de juiste persoon en rekent reiskosten, thuiswerkdagen en het resterende mobiliteitsbudget uit. Daarna zet Make de conceptloonstroken klaar in Employes.

Wat ik leerde

Kalenders zijn lastiger dan ze lijken. De feestdagen komen uit een publieke Google-agenda, maar niet elke feestdag is een vrije dag: Goede Vrijdag en Bevrijdingsdag moest ik uitzonderen. Declaraties komen soms laat binnen, dus het script wacht per bron een paar dagen en stempelt verwerkte dagen met de maand. Zo telt niets dubbel.

En waar een mens nodig is, laat ik een mens het doen. Vraagt NS om een CAPTCHA, dan wacht de app tot iemand hem oplost.

Resultaat

De conceptloonstroken staan elke maand klaar in Employes en hoeven alleen nog goedgekeurd te worden. Ook de jaarovergang gaat vanzelf: back-up, nieuw jaar, nieuwe feestdagen.

2026

Een podcast die op tijd online staat

Python, GitHub Actions, Notion API, YouTube API, LinkedIn API, Slack, Claude

Probleem

Een nieuwe aflevering betekent: de video openbaar zetten op YouTube, LinkedIn-posts plaatsen en in Slack laten weten dat hij live staat. Op de juiste dag en in de juiste volgorde.

Wat ik bouwde

In Notion staat wat er wanneer uitgaat. Een lokale stap maakt met Claude concepten voor de posts en zet de video privé klaar. Op de publicatiedag zet de scheduler de video openbaar, plaatst de LinkedIn-posts zodra hun video's openbaar zijn en kondigt de aflevering aan in Slack. Die laatste stap deed eerst Make.com.

Wat ik leerde

Een geplande taak die niet draait, valt niemand op. De planner van GitHub sloeg ongeveer de helft van de runs over. Daarom haalt de scheduler een gemiste dag alsnog in, met een vinkje in Notion als rem tegen dubbel posten. Een verlopen LinkedIn-token geeft nu een luide fout, en zeven dagen van tevoren een waarschuwing.

Resultaat

De scheduler draait om 09:07 en als reserve om 14:07, met 67 tests als vangnet. Spotify heeft geen API om op een tijdstip te publiceren, dus dat blijft bewust handwerk.

2026

Reminders zonder server

Node 22 zonder dependencies, GitHub Actions, Notion API, Slack API

Probleem

Twee Google Apps Scripts herinnerden collega's aan contacten die opvolging nodig hadden en aan verjaardagen. Eén ervan werd via Make.com aangeroepen.

Wat ik bouwde

Ik herschreef beide als kleine Node-programma's zonder dependencies. Ze hebben een dry-run, en bij de contactreminder kun je een andere datum simuleren om te zien wat er die dag verstuurd zou worden. Mislukt één ontvanger, dan gaat de rest gewoon door. De verjaardagsreminder houdt rekening met 29 februari, en wie zijn leeftijd liever niet deelt, kan dat uitzetten.

Wat ik leerde

Bij het uitschrijven van de spec vond ik vier bugs in het oude script, waaronder een datumfout door UTC. Daarna bleek dat GitHub geplande runs 39 tot 59 minuten te laat startte. Mijn conclusie staat in een commit: een uur verschuiving is een kleiner probleem dan een dag die stil wordt overgeslagen.

Resultaat

70 en 29 tests. Het Make-scenario is uitgezet en gearchiveerd.

2025 – 2026

Geplande taken die echt op tijd draaien

Kubernetes CronJobs, Helm, GitHub Actions, Python, Notion API

Probleem

Mijn automatiseringen draaiden op de planner van GitHub Actions. Die start runs te laat of slaat ze over, en dat merk je pas als een reminder of publicatie uitblijft.

Wat ik bouwde

Eén Helm-chart bevat alle schema's, van de dagelijkse reminders en de podcastpublicatie tot de maandelijkse marge-update. Elke CronJob start de workflow via de GitHub API. Dezelfde job kan niet twee keer tegelijk draaien, een mislukte start wordt twee keer opnieuw geprobeerd, en alle tijden staan in Europe/Amsterdam. Zomertijd is daarmee geen probleem meer.

De marge-update haalt elke maand per medewerker de billable uren van vier maanden op en zet maand- en jaarmarges in Notion. Historische tarieven blijven bewaard, en aanroepen naar Notion krijgen bij een fout een retry met exponentiële backoff.

Wat ik leerde

De zomertijdcontroles en uurchecks in mijn workflows waren lapmiddelen voor een onbetrouwbare planner. Eén plek met betrouwbare planning maakte ze overbodig.

Resultaat

Acht geplande jobs uit zes repo's starten nu vanuit één chart.

2026, in aanbouw

Uren uit Moneybird, direct in Notion

Python, Docker, Kubernetes, Helm, Moneybird-webhooks, Notion API

Probleem

Urenregistraties en de status van facturen uit Moneybird moeten in de urendatabase in Notion staan. Dat deden twee Make.com-scenario's.

Wat ik bouwde

Een kleine Python-service ontvangt de webhooks, controleert de HMAC-handtekening (met een venster van vijf minuten tegen replay) en werkt Notion bij. Elke nacht haalt een sync de laatste zeven dagen opnieuw op, voor het geval er een webhook gemist is. De service draait als container op Kubernetes. Alleen het webhookpad is van buitenaf bereikbaar.

Wat ik leerde

Het eerste ontwerp had een eigen database om dubbele berichten te herkennen. Ik koos voor iets eenvoudigers: elke verwerking is idempotent, dus een bericht twee keer verwerken geeft hetzelfde resultaat. De nachtelijke sync vangt de rest op. Minder onderdelen betekent minder dat stuk kan gaan.

Resultaat

18 tests. De volgende stap is live zetten en daarna de Make-scenario's uitzetten.

2026, in aanbouw

Contacten die niet heen en weer blijven stuiteren

TypeScript, Fastify, Google People API, Notion API, vitest, Docker

Probleem

Het team houdt contacten bij in een CRM in Notion, maar wil ze ook op de telefoon en in Gmail hebben. Synchroniseren in twee richtingen klinkt simpel, tot twee systemen elkaars wijzigingen eindeloos terugschrijven.

Wat ik bouwde

Teamleden kiezen in Notion welke contacten ze willen hebben. Per contact vergelijkt de sync Notion en alle Google-kopieën met een opgeslagen baseline, en schrijft alleen de velden die echt veranderd zijn. Telefoonnummers worden genormaliseerd, zodat '06-' en '+31 6' niet als wijziging tellen.

Wat ik leerde

De eerste versie schreef bij elke run zes wijzigingen per gebruiker die er niet waren: echo's van zijn eigen schrijfacties. Ik bouwde de engine om naar een vergelijking per contact, en een integratietest bewijst nu dat een run zonder wijzigingen niets schrijft. Een geplande droogloop faalt bovendien bewust, want een groene run die niets doet, is een stille fout.

Resultaat

288 tests in 12 bestanden. Live gaan wacht nog op een beheerdersinstelling bij Google (domain-wide delegation).

Wat kan ik voor jou automatiseren?

Deze cases bouwde ik voor één organisatie, maar hetzelfde soort werk zit in elk bedrijf: taken die elke dag, week of maand terugkomen en samen uren kosten. Vaak doet een MT-lid of de eigenaar ze zelf, omdat het er "even bij" moet. Hieronder staan voorbeelden van wat zich goed laat automatiseren. Waar ik het al bouwde, staat de case erbij.

al gebouwd kan ik voor je bouwen

Elke dag

  • Klanten en leads opvolgen: wie moet vandaag gebeld of gemaild worden? Zo deed ik het
  • Gegevens overtypen tussen systemen, zoals uren, facturen en contacten. Zo deed ik het
  • Nieuwe leads uit de website, formulieren of LinkedIn direct in het CRM, met een melding aan de juiste collega.
  • De inbox en aanvraagformulieren sorteren: AI leest mee, labelt en zet een conceptantwoord klaar.
  • Veelgestelde vragen van klanten beantwoorden met een AI-assistent die je eigen kennisbank gebruikt. Een mens keurt het antwoord.

Elke week

  • Content en aankondigingen op tijd publiceren. Zo deed ik het
  • Een weekoverzicht voor het MT met omzet, pijplijn en bezetting, elke maandagochtend klaar.
  • Controleren wie zijn uren nog niet heeft geschreven, met een herinnering aan die mensen.
  • Notulen samenvatten en actiepunten met AI als taken in je projectsysteem zetten.
  • De planning bewaken: wie werkt waar, en waar dreigt volgende week een gat?

Elke maand

  • De verloning voorbereiden: reiskosten, thuiswerkdagen, verlof en ziekte. Zo deed ik het
  • Marge en bezetting per medewerker berekenen. Zo deed ik het
  • Facturen maken uit geregistreerde uren of vaste maandbedragen.
  • Bonnetjes en inkoopfacturen uit de mail halen en klaarzetten voor de boekhouding.
  • Herinneringen sturen voor openstaande facturen.

Bij elke nieuwe medewerker of klant

  • On- en offboarding: accounts, toegang, contract en checklist in één keer geregeld.
  • Een nieuwe klant tegelijk aanmaken in CRM, boekhouding en projectmap.
  • Een offerte opbouwen uit de notities van een intake, met AI als eerste schrijver.
  • Contracten vullen vanuit een sjabloon en digitaal laten ondertekenen.

Voorbeeld: een marketingbureau voor franchiseketens

Eén merk, tientallen vestigingen, en per vestiging steeds dezelfde handelingen. Juist daar levert automatiseren veel op. Zo zou ik het aanpakken:

  • Maandrapportage per vestiging: cijfers uit Google Ads, Google Business Profile en Search Console automatisch verzameld, met een AI-samenvatting als startpunt voor het maandgesprek.
  • Een nieuwe vestiging in één keer live: vanuit één formulier de campagne uit een sjabloon, het dashboard, de mappen en de takenlijst aanmaken.
  • Lokale varianten van landelijke campagnes: AI schrijft per vestiging teksten met plaatsnaam en lokaal aanbod, binnen de merkrichtlijnen, klaar voor een laatste check.
  • Reviews en vestigingsgegevens bewaken: een melding bij elke nieuwe review met een conceptreactie, en een check of adressen en openingstijden overal kloppen.
  • Mediabudget per vestiging bewaken: een waarschuwing als een vestiging te snel of te langzaam door het budget gaat.
  • Werving van franchisenemers: aanmeldingen automatisch naast het kandidaatprofiel leggen, met een eerste matchscore en een samenvatting voor het gesprek.
  • Facturatie per vestiging: vaste maandbedragen automatisch gefactureerd, ook als er vestigingen bijkomen of stoppen.

Code of low-code: wat het probleem nodig heeft

Ik bouw in code, vooral Python en TypeScript, en in low-code tools als Make.com en Zapier. Met n8n heb ik nog niet officieel gewerkt, maar het werkt volgens hetzelfde principe en ik pak het op als jouw organisatie het gebruikt. Een eenvoudige koppeling staat in low-code vaak sneller. Wordt het complexer, moet het getest worden of gaat er veel data doorheen, dan kies ik code.

Vraagt een probleem om een taal of tool die ik nog niet ken, dan leer ik die. Zo leerde ik Lua om Tabletop Simulator te scripten.

Dit is maar een greep. Herken je iets, of loop je tegen iets anders aan?

Hoe ik werk

Ik bouw met Claude Code als pair programmer. Ik bepaal wat er moet gebeuren en waarom, de AI helpt bij het hoe, en tests controleren het resultaat. Dat werkt alleen met een vaste volgorde.

  1. Het proces begrijpen

    Ik begin bij de mensen die het werk doen: wat kost tijd en waar gaat het mis? Dat leerde ik als productmanager.

  2. Eerst een spec

    Een korte spec beschrijft wat het moet doen en wat nooit mag gebeuren. Bij de contactreminder vond ik zo vier bugs in het oude script, nog voor er nieuwe code was.

  3. Testen en droogdraaien

    Elke integratie heeft tests en een dry-run. Een oud Make-scenario gaat pas uit als het nieuwe aantoonbaar hetzelfde doet.

  4. Luid falen

    Een stille fout is erger dan een luide. Een verlopen token of een overgeslagen run moet meteen opvallen, niet pas weken later.

Hobbyprojecten

In mijn vrije tijd script ik voor Tabletop Simulator, een digitale speeltafel voor bord- en kaartspellen. Ik schrijf de tools zo dat andere spelers ze ook kunnen gebruiken, en de code is openbaar.

2024 – 2025

Munchkin Complete Collection

Lua-scripts voor een complete versie van het kaartspel Munchkin in Tabletop Simulator. Ze rekenen per speler de totale gevechtskracht uit en sturen dobbelstenen, tokens en side quests aan. Een Python-script ruimt de oude assetbestanden van eerdere versies op.

Lua, Python

Code op GitHub

2024 – 2025

Kapotte links in speelbestanden repareren

Gaat een server met afbeeldingen of modellen offline, dan werkt een gedeeld spel niet meer voor anderen. Dit script vervangt dode links in een opgeslagen spel door de bestanden die je lokaal nog hebt, en maakt eerst een back-up. Daarna upload je alles opnieuw naar de Steam Cloud. Getest op Windows 11, Ubuntu en macOS.

Python

Code op GitHub

Persoonlijk

Ik ben een sociale nerd: gefascineerd door menselijk gedrag, en net zo blij met een goed stuk code. Mijn overtuiging is simpel: technologie is pas echt innovatief als ze ruimte maakt voor menselijk talent. Mijn kwispelmodus gaat aan zodra ik een inefficiënt of ingewikkeld proces mag doorgronden, vereenvoudigen en automatiseren. Het mooiste resultaat is vrijgespeelde tijd, ons meest kostbare bezit.

Mijn route

  1. 2003 – 2009 Psychologie in Nijmegen

    Sociale psychologie, met programmeercursussen ernaast. Afgestudeerd op immersive virtual environments.

  2. 2010 – 2015 Promotie aan de TU/e

    Onderzoek naar vertrouwen in zelfrijdende auto's, met avatars en een rijsimulator. Experimenten gebouwd in Authorware en Python.

  3. 2016 – 2020 Coach en trainer

    Eigen bedrijf in coaching en training. Schreef een boek en automatiseerde de matches voor speeddates op de Dutch Comic Con.

  4. 2021 – 2024 Productmanager bij Code Yellow

    Technische kant, klantcontact, testen en het developmentteam aansturen.

  5. 2025 Eerste eigen tools

    Python-apps voor uren, declaraties en NS-reisdata. Daarna de verloningsketen met Apps Script en Make.com.

  6. 2026 Geteste integraties

    Code met tests en dry-runs, gepland op Kubernetes, gebouwd met Claude als pair programmer.

Hoe ik hier kwam

Waarom doen mensen wat ze doen? Die vraag bracht me naar de opleiding psychologie in Nijmegen, waar ik me specialiseerde in sociale psychologie. Daarnaast was ik nieuwsgierig naar hoe je computers kunt laten doen wat jij wilt, dus volgde ik naast de psychologievakken ook programmeercursussen. In de research master Behavioural Science kwamen mijn interesse in menselijk gedrag en technologie samen. Voor mijn afstudeerproject heb ik virtuele omgevingen geprogrammeerd om menselijk gedrag te meten in een toentertijd gloednieuw virtual reality lab.

Tijdens mijn promotie in Human-Technology Interaction aan de Technische Universiteit Eindhoven onderzocht ik hoe ik mensen meer vertrouwen kon geven in een zelfrijdende auto, waarbij ik avatars en een rijsimulator heb ingezet. De experimenten bouwde ik zelf, in Authorware en vooral veel Python.

Daarna ging ik de menselijke kant op: als zelfstandige coach en trainer werkte ik direct met mensen, al automatiseerde ik toen ook de matches voor de speeddates die ik organiseerde op de Dutch Comic Con. Bij Code Yellow kwam alles samen: ik zat aan de technische kant, had het klantcontact, testte nieuwe features (en maakte ze stuk) en stuurde het developmentteam aan.

Hoe ik met AI werk

Die vaardigheden gebruik ik nu elke dag. Een AI-assistent als Claude, ChatGPT of Gemini aansturen lijkt sterk op een developmentteam aansturen: een heldere opdracht geven, het resultaat kritisch testen en bijsturen tot alle details kloppen. Mijn testmentaliteit en oog voor detail zijn daarbij net zo belangrijk als de code zelf.

Ik ben geen vibe coder. Ik lees en begrijp code ook zonder AI. Wel gebruik ik AI om sneller te werken en nieuwe dingen snel op te zetten, met als voorwaarde dat ze stabiel draaien: met tests, dry-runs en een mens die snapt wat er gebeurt.

In een professionele samenwerking zijn eerlijkheid, duidelijkheid en open communicatie voor mij de standaard. Humor en diepgang horen daar vanzelfsprekend bij.

In het dagelijks leven

Bouwjaar
1984. Goed jaar, al zeg ik het zelf.
Thuis
Getrouwd met Aris Bartholomeus. Samen hebben we een DINKdouble income, no kids-lifestyle in Westerhoven met schoonouders in de achtertuin. Dat verhaal vertel ik graag face-to-face.
Vrije tijd
Bordspelfanaat: er is een heuse gameroom in de maak, want de collectie blijft groeien. Verder 3D-printen, escape rooms, cabaret en (muziek)theater, gamen op pc, PS5, Switch en VR, reizen, persoonlijke ontwikkeling en scripten voor Tabletop Simulator.
Beschikbaar
Alles wat MT kon bedenken is inmiddels geautomatiseerd en draait als een tiet. Kortom: ik heb mezelf weggeautomatiseerd. Zo goed ben ik.

Stack

Talen
Python, TypeScript, JavaScript (Node), Google Apps Script, SQL. En Lua, voor mijn hobbyprojecten.
Integraties
REST API's en webhooks van Notion, Slack, Moneybird, Employes, Google Workspace, YouTube en LinkedIn.
Platform
GitHub Actions, Docker, Kubernetes met Helm.
Low-code
Make.com en Zapier.
Kwaliteit
vitest, node --test, Python-tests, dry-runs, conventional commits.
Desktop en browser
PyQt5, Selenium, PyInstaller.
AI
Slimme assistenten zoals Claude, ChatGPT en Gemini.

Contact

Wil je praten over automatisering of AI? Stuur me een bericht.