Van mailflow naar eigen applicatie: rechtstreeks en in eigen beheer
De flow werkte. Dat was het probleem niet. Tijdens één testdag liep het geregistreerde creditverbruik sneller op dan ik voor deze proef verwachtte. Voor mij was dat een goed moment om niet alleen naar de werking te kijken, maar ook naar de constructie eronder.
Ik had de eerste versie in Make.com gebouwd om de werkwijze snel te testen. De mail kwam binnen, werd herkend en kreeg de juiste vervolgstap. De test had daarmee zijn werk gedaan: de logica was zichtbaar en controleerbaar.
Als die logica eenmaal stabiel is, ontstaat een andere vraag. Moet iedere mail door een extra workflowplatform blijven lopen? Of kan dezelfde taak rechtstreeks in een kleine applicatie worden uitgevoerd?
Credits zijn geen AI-tokens
Het dashboard toont credits. Dat is de rekeneenheid binnen Make. Het zijn dus geen AI-tokens. Bij sommige ingebouwde AI-functies kan tokenverbruik wel meewegen in de creditberekening. Met een eigen AI-providerverbinding kunnen Make-credits en de rekening van de AI-provider bovendien naast elkaar bestaan.
Volgens de documentatie ten tijde van deze test kost bij de meeste gewone modules een uitgevoerde module één credit. Loopt één bericht door meerdere stappen, dan tellen die uitgevoerde stappen mee. Bij meerdere mails of bestanden kunnen vervolgstappen zich per onderdeel herhalen.
Bronnen: uitleg over credits, uitleg over operations en creditgebruik per functie.
De mailflow in drie stappen
Het oorspronkelijke schema is niet weggegooid. Het is juist de blauwdruk voor de applicatie. Hieronder staat dezelfde werkwijze zonder alle technische blokken. Kies een mailsoort om de vervolgstap te bekijken.
Van binnenkomende mail naar gecontroleerde actie
Drie vaste stappen. Daarna bepaalt het type mail wat er wordt klaargezet.
- 1 Mail afbakenen Alleen mail en bijlagen binnen de afgesproken scope worden verwerkt.
- 2 Informatie herkennen De app haalt de noodzakelijke informatie op en herkent het type bericht.
- 3 Route kiezen Vaste regels bepalen de vervolgstap en waar menselijke controle nodig is.
Wat gebeurt er na stap 3?
De herkende mail gaat naar één passende vervolgactie. Kies een mailsoort om die actie te bekijken.
De PDF opslaan op de afgesproken plek en een boekhoudtaak aanmaken. De factuur staat klaar voor de ingestelde controle.
Waarom dit als eigen applicatie?
Wil je eerst uitgebreider zien wat er met facturen, afspraken en klantvragen uit een inbox kan gebeuren? Lees dan ook hoe ik een mailbox automatiseer met controle waar dat nodig is.
Kan een bestaande flow worden omgebouwd?
Vaak wel. Of dat technisch en praktisch zinvol is, hangt onder meer af van beschikbare koppelingen, beveiliging, volume en uitzonderingen. Een visuele flow en een eigen applicatie zien er anders uit, maar functioneel bevatten ze vaak dezelfde onderdelen.
| In de bestaande flow | In de eigen applicatie |
|---|---|
| Nieuwe mail als startpunt | Veilige mailboxkoppeling of achtergrondtaak |
| Filters en router | Functies met vaste bedrijfsregels en controles |
| Losse koppelingen | Rechtstreekse API-koppelingen met de benodigde diensten |
| Opslagblokken | Eigen database, bestandsopslag of een gekozen bedrijfsdienst |
| Foutafhandeling | Eigen logboek, wachtrij en melding voor uitzonderingen |
| Handmatige vervolgstap | Controlescherm of concept dat een medewerker goedkeurt |
De bedrijfslogica hoeft meestal niet vanaf nul opnieuw te worden bedacht. Ik leg vast wat ieder blok doet, vertaal de regels en test elke route. Het bestaande schema kan zo uitzoekwerk besparen.
Wat er verandert met een eigen applicatie
Een workflowplatform vormt een extra softwarelaag in de uitvoerketen tussen de mailbox, agenda, opslag en andere systemen. Bij een proef is die laag vaak handig. Je ziet snel of het proces klopt. Zodra de regels stabiel zijn en de flow vaak draait, kan rechtstreeks koppelen logischer worden.
- Eigen regie: de belangrijke logica en logging worden in de afgesproken omgeving ingericht en beheerd.
- Gericht programmeerbaar: een uitzondering hoeft niet te passen binnen de mogelijkheden van een standaardblok.
- Geen extra platformcredits: als deze flow volledig buiten het workflowplatform draait, vervallen de credits voor dat platform. Gebruikte API’s kunnen wel eigen gebruikskosten hebben.
- Meerdere processen op één omgeving: dezelfde server en basisfuncties kunnen meer dan één gerichte automatisering ondersteunen.
- Foutafhandeling op maat: meldingen en controles kunnen worden ingericht voor het dagelijkse werk.
Dat kan de terugkerende kosten voorspelbaarder maken. Niet automatisch volledig vast. De gekozen server, opslag en externe API’s bepalen wat daarnaast nog per gebruik wordt afgerekend.
Zonder apart workflowplatform blijven externe diensten nodig
De applicatie blijft meestal praten met bestaande diensten. Denk aan Gmail of Microsoft 365, een agenda, opslag, een boekhoudpakket en soms een AI-provider. Hosting, onderhoud, beveiliging en back-ups blijven ook nodig.
De precieze claim is daarom:
De eigen applicatie haalt het aparte workflowplatform uit deze uitvoerketen. De benodigde mail-, hosting- en API-diensten verdwijnen niet automatisch.
Dat onderscheid is belangrijk. Met eigen beheer bedoel ik hier: regie over de inrichting, code, regels en dataselectie. Wie de code en server bezit en wie het onderhoud uitvoert, leg ik per project vast. Geen enkele inrichting voorkomt dat een externe leverancier ooit een koppeling wijzigt.
Wanneer een workflowplatform gewoon logisch blijft
Niet iedere flow hoeft te worden omgebouwd. Een visueel workflowplatform past vaak goed wanneer:
- het proces nog wordt uitgeprobeerd;
- de stappen vaak veranderen;
- er weinig berichten of uitvoeringen zijn;
- de standaardkoppelingen precies doen wat nodig is;
- een medewerker de flow zelf visueel wil aanpassen;
- bouw en onderhoud van maatwerk niet opwegen tegen het gebruik.
Het gaat dus niet om “platform slecht, maatwerk goed”. De betere vraag is welke vorm past bij het proces, het volume en de gewenste controle.
De testflow heeft zijn werk gedaan
Het creditverbruik van deze test bewijst niet dat ieder workflowplatform te duur is. Het is wel een goede aanleiding om naar de constructie te kijken.
In dit geval weet ik welke mails binnenkomen, welke routes nodig zijn en waar een mens moet controleren. Daarmee is de flow ver genoeg uitgewerkt om als kleine applicatie te bouwen. Niet groter dan nodig. Gewoon één programma dat het afgesproken proces uitvoert.
Heb je een terugkerende flow die al werkt? Stuur mij een screenshot of korte beschrijving. Dan kijk ik of laten staan of ombouwen logischer is.
Lees ook: mailbox automatiseren · AI laten nadenken en koppelingen laten uitvoeren · automatiseringskansen herkennen