Je begroot automatisering als een bouwproject, maar het is een abonnement

Acht mislukte afleveringen in vier uur. Meer is er niet nodig. Daarna wordt het webhook-abonnement verwijderd en komt er niets meer binnen tot je het opnieuw aanmaakt, staat er droog in de documentatie van Shopify. Je bestellingen lopen intussen gewoon door. Ze komen alleen niet meer aan in je boekhouding.

Er verschijnt geen rood kruis. Er komt geen mail. De koppeling die je hebt laten bouwen staat er nog, en doet niets.

Dat is precies wat er ontbreekt in bijna elke automatiseringsbegroting die ik voorbij zie komen. Er staat een bouwsom in, een opleverdatum, en als het meezit een regel "onderhoud in overleg". Wat er niet in staat, is dat je vanaf die opleverdatum een verplichting hebt die elk jaar terugkomt, of je hem nu begroot of niet.

Een draaiende automatisering is geen afgeronde investering maar een doorlopende verplichting. De koppeling hangt aan API's van derden met een houdbaarheidsdatum, hij valt stil zonder foutmelding, en de schade daarvan valt in het proces erna. Elke terugverdiensom die alleen de eenmalige bouwkosten afzet tegen de bespaarde uren laat de grootste kostenpost buiten beeld, en komt daardoor structureel te gunstig uit.

Je onderhoudskalender ligt bij je leveranciers

Onderhoud klinkt als iets dat gebeurt zodra er iets stukgaat. Bij koppelingen is dat niet zo. Het meeste onderhoud is ingepland werk, alleen plan jij het niet.

Shopify brengt elk kwartaal een nieuwe API-versie uit en ondersteunt elke stabiele versie minimaal twaalf maanden. Bij Meta is een versie twee jaar na de release van zijn opvolger niet meer bruikbaar, en zijn Marketing API houdt een oude versie na een nieuwe release nog minimaal negentig dagen in de lucht. Microsoft is het ruimhartigst en merkt een versie minstens 24 maanden voor de uitfasering als verouderd aan.

Zet die drie naast elkaar en je ziet wat een koppeling eigenlijk is: een afspraak met een vervaldatum die de ander zet. Twee koppelingen op Shopify, één op WhatsApp via Meta en één op Microsoft 365 zijn geen vier afgeronde projecten. Het zijn vier vervaldata in vier kalenders waar jij geen invloed op hebt.

Het venijn zit in wat er gebeurt als je zo'n datum mist. Je krijgt geen deur in het gezicht. Shopify beantwoordt een aanroep naar een niet meer toegankelijke versie met de oudste versie die nog wel wordt ondersteund, en bij Meta gaan aanroepen naar een verlopen versie door naar de eerstvolgende oudere beschikbare versie. Je koppeling blijft dus antwoord krijgen. Alleen van een ander contract dan waarop hij gebouwd is, met velden die anders heten of waarden die anders zijn ingedeeld. Dat is geen storing die je opmerkt. Dat is een verschuiving die je pas terugziet in je data.

Een stille breuk geeft geen foutmelding, hij geeft een leegte

De tweede reden dat dit werk onzichtbaar blijft, zit in het ontwerp van de platforms zelf. Make zet een scenario standaard uit na drie opeenvolgende fouten. Dat is verstandig gebouwd: het voorkomt dat een kapotte flow duizend keer dezelfde fout maakt en je tegoed opeet. Maar het beschermt het platform en je verbruik, niet je proces.

De flow staat uit, en in het proces verandert er niets zichtbaars. Er komt geen foute factuur. Er komt geen factuur. Een fout schreeuwt, een leegte niet, en systemen zijn gebouwd om fouten te melden, niet om afwezigheid te melden.

Daarom komt de ontdekking bijna altijd uit het proces erna. De boekhouder die bij de maandafsluiting achtendertig orders mist. De klant die belt over een bevestiging die nooit kwam. Een voorraadstand die al drie weken naast de werkelijkheid loopt. Op dat moment is de rekening niet de reparatie van de koppeling, want die kost meestal een uurtje. De rekening is het aantal dagen stilte maal het aantal transacties per dag maal het herstelwerk per transactie, plus het uitzoekwerk om überhaupt vast te stellen wélke transacties ontbreken.

Detectietijd is daarmee de enige knop waarmee je de kosten van een stille breuk echt indrukt. Niet betere koppelingen, niet duurdere koppelingen. Sneller merken dat er niets meer binnenkomt.

De rekensom die aan één kant niet klopt

Dat onderhoud de grootste kostenpost is, is geen nieuw inzicht. Ruediger Zarnekow en Walter Brenner van de Universiteit St. Gallen onderzochten in 2005 de levenscycluskosten van dertig applicatiesystemen en vonden dat bij vijf jaar productie 79 procent van de kosten na de oplevering valt, tegen 21 procent in de plannings- en bouwfase. Twintig jaar later koop je software vaker per maand dan per project, en is die verhouding er niet gunstiger op geworden.

De gangbare afweging voor een automatisering ziet er anders uit. Je deelt de eenmalige bouwkosten door wat je maandelijks bespaart aan overtypen en kijkt of daar een paar maanden uitkomt. Die som heb ik zelf zo opgeschreven en hij is nuttig, maar hij is niet compleet. Hij zet een eenmalig bedrag tegenover een maandelijkse besparing, terwijl er aan de kostenkant ook iets maandelijks staat.

Wat er per draaiende koppeling structureel bij komt, is te overzien maar niet nul:

• De licentie. Een no-code-platform is geen bouwkost maar een abonnement. Zapier rekent voor zijn Professional-plan vanaf 19,99 dollar per maand bij jaarbetaling voor 750 taken, en wie meer volume draait klimt door de staffels omhoog. De platforms rekenen bovendien in verschillende eenheden af: n8n per hele workflow-run, Make per credit en Zapier per taak, dus je maandlast beweegt mee met je drukte.
• De gedwongen migratie. Elke koppeling die op een platform met een kwartaalcyclus hangt, moet minstens één keer per jaar langs. Niet omdat er iets mis is, maar omdat de versie waarop hij draait afloopt.
• De bewaking. Iemand of iets dat merkt dat er niets meer binnenkomt, en een plek waar die melding landt.

Mijn eigen vuistregel, en dat is een vuistregel en geen benchmark: reken per draaiende koppeling op vier tot zestien uur per jaar, afhankelijk van hoeveel eigen logica erin zit en hoe vaak de leverancier aan zijn API sleutelt. Vertaald naar geld zit je dan al snel op een paar honderd euro per koppeling per jaar, nog voor de licentie.

Het effect op je beslissing is groter dan die getallen suggereren. Vervang in de terugverdiensom de bespaarde uren door nettobespaarde uren, dus bespaard min onderhoud. Een flow die twee uur per maand scheelt en acht uur per jaar kost, houdt zestien uur over in plaats van vierentwintig. Nog steeds ruim positief. Maar een flow die twintig minuten per maand scheelt, is met diezelfde onderhoudslast verliesgevend. En dat is precies het type flow dat mensen enthousiast bouwen, juist omdat de bouwkosten zo laag zijn.

Om eerlijk te zijn: daarvoor betaal je een no-code-platform

Het sterkste tegenargument tegen dit hele stuk is dat je die last allang hebt afgekocht. Dat is namelijk letterlijk wat Zapier, Make en n8n verkopen. Verandert Shopify zijn API, dan past hun team de connector aan en merk jij er niets van. Dat is geen marketingpraatje, dat is de kern van hun waarde, en het is de reden dat ik vrijwel nooit iemand aanraad om zelf een Shopify-connector te schrijven. Voor de meeste bedrijven is een no-code-platform de goedkoopste vorm van onderhoud die er is.

Alleen loopt er een naad door je flow. Aan de ene kant staat de connector, die het platform onderhoudt. Aan de andere kant staat jouw bedrijfslogica: het veld waarin het ordernummer terecht moet komen, de vertakking die je maakte voor de statuswaarden van vorig jaar, de aanname dat een klantnummer altijd zes cijfers heeft, het filter dat orders onder de tien euro overslaat. Die kant onderhoudt niemand. En een connector-update die keurig werkt volgens de nieuwe API kan jouw aanname stukmaken zonder dat de connector zelf iets fout doet.

Die naad is ook precies waar de verantwoordelijkheid ophoudt. Dat een platform zichzelf uitzet na drie fouten is daar het bewijs van: het beschermt zijn eigen infrastructuur tegen jouw kapotte flow. Niemand aan die kant van de tafel beschermt jouw proces tegen de stilte die daarna volgt. Dat is jouw kant, en dus jouw begroting.

Wat er in de offerte hoort te staan

Het antwoord hierop is geen extra checklist. Het is een regel in een document waar nu geen regel staat. Laat je een automatisering bouwen, of bouw je hem zelf, dan horen er naast de bouwsom drie dingen op papier te staan.

Een onderhoudsregel met een bedrag erachter. Niet "onderhoud in overleg", maar een jaarbedrag of een urenbudget per koppeling, zichtbaar naast de bouwkosten. Een offerte zonder die regel is geen goedkopere offerte, het is een onvolledige. En wie die regel wel opneemt, verkoopt niet duurder maar eerlijker.

Een detectie-afspraak met een tijd erin. Niet "er wordt gemonitord", maar: binnen hoeveel uur weet een mens dat deze koppeling stilstaat, en welke mens is dat. Een eigenaar per flow die een melding krijgt als er iets misgaat is het begin, maar een melding zonder afgesproken reactietijd is niet meer dan een archief van dingen die niemand las.

Een lijstje met vervaldata. Per koppeling twee kolommen: op welke API-versie draait hij, en wanneer loopt die af. Dat is een spreadsheet van tien regels, en het verandert onderhoud van een verrassing in een agenda-item. Het is dezelfde blinde vlek als bij toegang, waar een API-token dat een vertrokken collega ooit aanmaakte gewoon blijft werken tot iemand het intrekt. Wat bij de uitgifte geen eindmoment krijgt, krijgt het later ook niet.

In de beslisfase verschuift daarmee ook de vergelijking. Tussen twee kandidaat-flows wint niet degene met de hoogste brutobesparing, maar degene met de hoogste nettowaarde over drie jaar. Dat is vaak niet dezelfde flow. Die met veel eigen logica en drie externe koppelingen scoort bruto het mooist en netto het slechtst, want hij hangt aan drie kalenders tegelijk.

Wat je eigenlijk koopt

Terug naar die acht mislukte afleveringen. Wat me daaraan blijft fascineren is niet dat het gebeurt. Het is dat het volledig volgens plan gebeurt: het staat in de documentatie, iedereen kan het weten, en toch verrast het bijna elk bedrijf dat het overkomt. Niet omdat de techniek ingewikkeld is, maar omdat de kosten ervan nergens waren opgeschreven.

Wie een automatisering laat bouwen, koopt geen machine die af is. Je neemt een abonnement op de releasekalender van iedereen aan wie je hem hebt geknoopt, en je betaalt de premie in uren die je pas ziet als je ze begroot. De vraag bij een offerte is daarom niet wat het kost om dit te bouwen. De vraag is wat het kost om dit vijf jaar te laten draaien, en wie het merkt op de dag dat het stopt.

Beantwoord je die tweede vraag niet, dan heb je geen goedkope automatisering gekocht. Je hebt een dure gekocht en de rekening doorgeschoven naar de maandafsluiting.