Neem een bureau dat een leadflow verkoopt aan een klant. Formulier op de website, contact in het CRM, een taak voor sales, een bevestigingsmail naar de aanvrager. Vaste prijs, netjes opgeleverd, iedereen tevreden.
Drie maanden later komt er een mail van Make: het plan van de klant zit aan zijn limiet. Er komen gemiddeld veertig aanvragen per dag binnen. Niemand begrijpt waar al die credits naartoe gaan.
Het antwoord zit in de eerste module. Het scenario kijkt elke minuut of er een nieuwe aanvraag is. Die blik kost telkens een credit, ook als er niets te vinden is. Zestig keer per uur, dag en nacht, de hele maand door: 43.200 credits om vast te stellen dat er niets gebeurd is.
Dat is geen bouwfout in de klassieke zin. Het scenario deed precies wat het moest doen. Het is een prijsfout: niemand had het verbruik uitgerekend voor de offerte vertrok.
Een automatisering heeft drie prijzen, niet één
Wie een website verkoopt, verkoopt vooral de bouw. Hosting en onderhoud zijn kleine lijnen onderaan. Bij een automatisering liggen de verhoudingen anders. Ze heeft drie prijzen, en veel offertes noemen er maar één.
- De bouw. Eenmalig, bij jou. Analyse, bouwen, testen, documenteren.
- Het verbruik. Maandelijks, bij Make, in credits. Hangt af van hoe vaak het scenario draait en hoeveel modules het doorloopt.
- Het onderhoud. Maandelijks, weer bij jou. Omdat de pakketten rond het scenario blijven veranderen, ook als het scenario zelf stilstaat.
Een scenario is geen website. Het is een machine die elke minuut kan draaien, en een machine heeft brandstof en onderhoud nodig.
Deel 1 — de bouw: tel grenzen, geen modules
De verleiding is groot om te prijzen per module. Twaalf modules, dus zoveel uur. Dat werkt niet, omdat een module niet bepaalt hoe moeilijk iets is. Een module die een rij in Google Sheets zet, is vijf minuten werk. Een koppeling met een boekhoudpakket zonder degelijke API kan een dag kosten, en dan heb je nog niet getest.
Wat de bouwtijd wel voorspelt:
- het aantal systeemgrenzen: elke plek waar gegevens van het ene pakket naar het andere gaan, met een eigen login en een eigen manier om te falen;
- het aantal uitzonderingen: elke keer dat het proces anders loopt dan het standaardpad, komt er een route bij in je router;
- de foutafhandeling: wat er gebeurt als een koppeling faalt, hoe vaak het scenario opnieuw probeert en wie het te horen krijgt.
Die drie haal je niet uit een briefing. Je haalt ze uit een gesprek met de mensen die het werk vandaag doen. Hoe je dat gesprek voert, staat in de 12 vragen die je stelt vóór je één automatisering bouwt.
Deel 2 — het verbruik: zo rekent Make
Make rekent in credits. Voor gewone modules is dat eenvoudig: één module die één keer draait, is één credit. Een scenario van zes modules dat één aanvraag verwerkt, kost zes credits. Ongebruikte credits schuiven niet door naar de volgende periode, ze vervallen.
Drie dingen maken de som minder eenvoudig dan ze lijkt.
Waar de credits naartoe gaan
De trigger telt, ook als hij niets vindt.
Een scenario dat op een vast interval draait, controleert telkens of er nieuwe gegevens zijn. Die controle kost een credit, of er nu nul of vijftig resultaten zijn. Hoe vaker het scenario kijkt, hoe meer het kost, los van hoeveel er binnenkomt.
AI-modules kosten meer dan één credit.
De ingebouwde AI-functies van Make rekenen naar verbruik: hoe langer de tekst of hoe groter het bestand, hoe meer credits. Een scenario dat elke binnenkomende mail laat samenvatten, heeft een ander prijskaartje dan hetzelfde scenario zonder die stap.
Een herpoging draait opnieuw.
Foutafhandeling die een mislukte stap opnieuw probeert, laat modules een tweede keer draaien. Dat is precies wat je wil, maar het staat wel op de rekening. Reken het mee, zeker bij koppelingen die bekendstaan als wispelturig.
Zo ziet de som eruit voor de leadflow uit de inleiding.
Rekenvoorbeeld — trigger die elke minuut kijkt
Hetzelfde scenario, met een webhook als trigger
Negen keer minder, voor precies hetzelfde resultaat. Lukt een webhook niet, dan scheelt een interval van een kwartier al enorm: 2.880 controles per maand in plaats van 43.200.
De duurste module in je scenario is vaak de trigger die niets vindt.
Tel er daarna een buffer bij, zo'n dertig procent, voor groei, herpogingen en de maand waarin de klant een campagne lanceert. Kies dan een plan waar dat verbruik in past. Bijkopen kan altijd, maar een plan dat past is een beslissing vooraf. Bijkopen is een verrassing achteraf.
Wie betaalt de licentie?
Deze vraag ontbreekt vaak in de offerte, en ze geeft later het meeste gedoe. Er zijn twee manieren.
- Het account van de klant. De klant neemt een eigen Make-organisatie en betaalt het plan rechtstreeks. Jij wordt uitgenodigd als lid. De klant is eigenaar van zijn scenario's, ziet wat hij verbruikt, en als de samenwerking stopt, blijft alles gewoon draaien.
- Het account van het bureau. Alles draait bij jou en je rekent een maandbedrag door. Je houdt de controle en kan een marge nemen op het verbruik. Maar jij draagt het risico als het verbruik ontspoort, en bij een vertrek moet alles verhuizen.
Mijn voorkeur gaat naar het account van de klant, met een duidelijke afspraak over wie wat mag aanpassen. Werk je met een externe bouwer, dan nodig je die gewoon uit in dezelfde organisatie. De klant ziet een extra teamlid, geen extra leverancier.
Wat je ook kiest: zet het in de offerte, samen met het verwachte verbruik. Dan is het plan van de klant een keuze die hij zelf maakt, en geen mail die hij na drie maanden krijgt.
Deel 3 — onderhoud: automatiseringen verouderen
Een website die je vandaag oplevert, doet volgend jaar nog hetzelfde. Een automatisering niet, omdat ze afhangt van pakketten die elk in hun eigen tempo veranderen. Wat er in de praktijk breekt:
- een verbinding die vervalt, omdat iemand zijn wachtwoord wijzigt of een toegangssleutel verloopt;
- een veld in het CRM dat hernoemd of verplicht gemaakt wordt;
- een app die een nieuwe versie van zijn koppeling uitbrengt en de oude uitfaseert;
- en het vaakst: het proces van de klant zelf, dat na een half jaar anders loopt dan toen je bouwde.
Dat is geen falen van de bouw. Het is de aard van het ding. Daarom hoort onderhoud als apart maandbedrag in de offerte: iemand die mislukte runs opvolgt, een vaste reactietijd en een aantal uren voor kleine aanpassingen. Zonder die afspraak wordt elk incident een discussie over wie het betaalt.
De rekensom, in vijf stappen
Tel systeemgrenzen en uitzonderingen.
Dat is je bouwprijs. Niet het aantal modules.
Reken het verbruik uit.
Modules per run maal het aantal runs per maand, plus de controles van je trigger. Tel er een buffer bij.
Kies de trigger bewust.
Een webhook waar het kan, een ruim interval waar het moet. Elke minuut kijken is zelden nodig.
Leg vast op wiens account het draait.
En wie het plan betaalt. Schriftelijk, voor de bouw begint.
Prijs onderhoud als maandbedrag.
Met een reactietijd en een aantal uren. Wat daarbuiten valt, is meerwerk.
Wat er dan in je offerte staat
Drie lijnen in plaats van één. De bouw, als vaste prijs. Het verwachte verbruik, met het plan dat erbij past en wie het betaalt. Het onderhoud, als maandbedrag.
Dat oogt misschien duurder dan een offerte met één bedrag. In de praktijk werkt het omgekeerd. De klant weet vooraf wat de automatisering hem per jaar kost, en jij hoeft na drie maanden geen mail te sturen die begint met “we hadden niet voorzien dat…”.