Hoe wij klantwensen automatisch verwerken — van e-mail tot live op de website

De manier waarop klanten wijzigingen aan hun website aanvragen is al jaren hetzelfde: een mailtje sturen, een belletje, misschien een WhatsApp-bericht. En dan wachten. Wij vroegen ons af: wat als we die e-mail als startpunt gebruiken voor een volledig geautomatiseerde pipeline die eindigt met een live update op de website? Geen tussenkomst, geen handmatig werk, tenzij het echt nodig is. Dit is hoe we dat gebouwd hebben.

Het idee: e-mail als trigger

Klanten van Webforged krijgen een eigen e-mailadres waarmee ze wijzigingsverzoeken kunnen indienen. Dat adres is uniek per klant en direct gekoppeld aan hun project. Sturen ze een mail? Dan start automatisch een gestructureerde workflow — van verzoek tot live op de website.

Voor de klant verandert er niets. Ze sturen een e-mail, net zoals ze altijd doen. Wat er op de achtergrond gebeurt is onzichtbaar, maar de snelheid en nauwkeurigheid waarmee hun verzoek wordt verwerkt is dat zeker niet.

Van e-mail naar pull request

Zodra een e-mail binnenkomt, controleert het systeem of de afzender bekend en goedgekeurd is. Onbekende afzenders worden stilletjes genegeerd — geen foutmelding, geen reactie, niets. Dit is een bewuste keuze: het systeem geeft geen enkel signaal terug dat er überhaupt iets achter het adres zit.

Is de afzender goedgekeurd, dan wordt het verzoek automatisch omgezet in een branch en pull request in GitHub. De inhoud van de e-mail vormt de basis van de wijzigingsbeschrijving. Tegelijk wordt een AI-codeeragent gestart die de daadwerkelijke implementatie oppakt.

De AI-agent als developer

De codeeragent leest het wijzigingsverzoek en werkt de relevante bestanden bij — van configuratie tot Next.js-code. De agent is strikt beperkt tot de bestanden van die specifieke klant. Andere klanten, gedeelde packages, infrastructuur: buiten bereik.

Dit klinkt eenvoudig, maar de implementatie vereist zorgvuldige afbakening. Een agent die te veel rechten heeft is een risico. Wij kozen bewust voor een zo smal mogelijk bereik: de agent mag precies doen wat nodig is voor die klant, en niets meer.

Het resultaat is een pull request met echte code-wijzigingen, klaar voor review. Geen markdown-beschrijving als eindproduct, maar daadwerkelijke implementatie.

Menselijk toezicht als harde grens

Na de implementatie door de agent is er één stap die nooit geautomatiseerd wordt: de code review. Wij bekijken elke pull request voordat die gemerged wordt. Wat de AI ook heeft gedaan — het gaat pas live na handmatige goedkeuring.

Dit is geen technische beperking, maar een bewuste keuze. AI-gegenereerde code kan fouten bevatten, verkeerde aannames maken, of iets implementeren dat technisch klopt maar inhoudelijk niet past. Een tweede paar ogen blijft onmisbaar.

Auto-merge is bewust niet ingebouwd. De snelheidswinst die je daarmee zou behalen weegt niet op tegen het risico van ongecontroleerde wijzigingen op productieomgevingen.

Na goedkeuring: volledig geautomatiseerde uitrol

Zodra de pull request gemerged is, neemt de CI/CD-pipeline het over. GitHub Actions bouwt automatisch een nieuw Docker-image, pusht dat naar de container registry, en Helm voert een rolling update uit in het Kubernetes-cluster. Alleen de namespace van die specifieke klant wordt geraakt — andere klanten merken er niets van.

De klant ziet de wijziging live verschijnen zonder dat er iemand handmatig een deploy heeft uitgevoerd. De enige menselijke handeling was de code review.

Beveiliging op meerdere lagen

Een workflow die automatisch code uitrolt naar productie vereist een solide beveiligingsarchitectuur. We hebben bewust meerdere lagen ingebouwd:

• Afzenderverificatie — elk e-mailadres moet vooraf expliciet goedgekeurd worden. Goedkeuring verloopt via een beveiligd kanaal dat alleen wij kunnen gebruiken.
• Scope-isolatie — de AI-agent heeft uitsluitend toegang tot bestanden van de betreffende klant. Geen toegang tot andere projecten, infrastructuur of gedeelde code.
• PR-deduplicatie — staat er al een open pull request voor een klant, dan wordt een nieuw verzoek geblokkeerd tot de bestaande is afgehandeld.
• Geen auto-merge — elke wijziging wordt handmatig beoordeeld voor ze live gaat.
• Eigen infrastructuur — geen externe SaaS-diensten die toegang hebben tot klantcode of -data.

Wat dit oplevert

Voor klanten is het een eenvoudigere manier van werken. Ze hoeven niet te begrijpen hoe GitHub werkt, wat een deployment is, of hoe Kubernetes functioneert. Ze sturen een e-mail en hun website wordt bijgewerkt.

Voor ons betekent het minder repetitief handmatig werk bij standaard wijzigingen, met behoud van volledige controle. We besteden onze aandacht aan wat er echt toe doet: de inhoudelijke beoordeling van wat er live gaat.

De combinatie van automatisering en menselijk toezicht is precies het evenwicht dat we zochten. Snel waar het kan, zorgvuldig waar het moet.

Herkenbaar?

Veel ondernemers herkennen het probleem: een simpele tekstwijziging kost onevenredig veel tijd, communicatie en energie. Niet omdat de wijziging complex is, maar omdat het proces eromheen dat is. Wij geloven dat het anders kan.

Wil je weten of zo een workflow ook voor jouw situatie werkt? Neem contact op — we denken graag mee.