Budget vs Werkelijk: De Wekelijkse Lus voor Oprichters

Startups sterven zelden in één dramatische week. Ze sterven in een reeks weken waarbij niemand vergeleek wat er zou moeten gebeuren met wat er werkelijk gebeurde. MRR groeide iets langzamer dan verwacht. Kosten dreven iets omhoog. Churn verslechterde stilletjes. De prognose werd nooit bijgewerkt. Runway werd korter en niemand merkte het totdat het ongemakkelijk was om te corrigeren.

Budget vs werkelijk is de gewoonte die die drift opvangt. Het is geen financieel ritueel of een deliverable voor het bestuur, het is een 10-minuten wekelijkse vergelijking tussen je prognose en de werkelijkheid die je vertelt of je nu of volgende maand gedrag moet veranderen. Voor de meeste vroegefase SaaS-oprichters komt die vergelijking neer op zes getallen, één tabel en één beslissing.

Dit artikel behandelt wat budget vs werkelijk betekent, hoe je de wekelijkse lus uitvoert, een volledig budget vs werkelijk rapporttemplate, een uitgewerkt SaaS-voorbeeld met variantiepercentages, en de fouten die de review omzetten in administratie. Y Combinator’s financiële richtlijnen voor startups identificeert de budget vs werkelijk gewoonte als een van de meest hefboomwerkende financiële praktijken beschikbaar voor vroegefase oprichters.

Wat is budget vs werkelijk?

Budget vs werkelijk is de vergelijking tussen geplande cijfers en werkelijke resultaten over omzet, kosten en kas. Het budget is de prognose: wat je verwachtte dat er zou gebeuren. De actuals zijn wat het bedrijf produceerde. De variantie, het gat ertussen, is wat een beslissing vereist.

Vier concepten die in dezelfde lus thuishoren:

Budget, wat je van plan was te besteden en te verdienen. Een vooruitblikkende toezegging. Werkelijk, wat het bedrijf produceerde in een gegeven periode. De echte cijfers. Budgetvariantie, het verschil tussen budget en werkelijk, in absolute waarde of percentage. Budget vs werkelijk rapport, de gestructureerde vergelijking die alle drie toont, met een actie verbonden aan significante varianties.

In oprichterstaaltje: “Ging de maand zoals ik verwachtte? Zo niet, wat veranderde er, en wat doe ik deze week anders?”

Dat is het hele idee. Prognoses en budgetten zijn alleen nuttig als deze vergelijkingslus regelmatig wordt uitgevoerd. Een prognose die nooit wordt gecontroleerd aan de werkelijkheid is zelfverzekerd storytelling. Een budget dat nooit wordt vergeleken met actuals is decoratie.

Voor het financieel model dat de prognose produceert waarop deze lus draait, zie de minimalistische 8-invoergegevengids.

Elke prognose heeft een schone MRR-basislijn nodig. Haal de jouwe uit Stripe in 90 seconden →

Waarom budget vs werkelijk meer telt dan oprichters verwachten

Het argument voor het uitvoeren van budget vs werkelijk is niet dat het goede financiële hygiëne is. Het is dat zonder het het bedrijf significant kan driften voordat iemand het merkt, en hoe langer drift onopgemerkt blijft, hoe minder hefbomen er beschikbaar zijn om het te corrigeren.

Omzetmissers cumuleren stilletjes. Een MRR-miss van €500 in januari ziet er klein uit. Als nieuwe MRR consistent 15% onder plan ligt, is het gat in maand zes materieel. De budget vs werkelijk lus vangt het patroon in maand twee op, niet in maand zes.

Kosten driften zonder beslissing. De meeste kostenafwijkingen zijn niet dramatisch. Het is een toolabonnement dat verlengde, een API-rekening die omhoogkroop naarmate het gebruik groeide, een aannemer die meer werk opnam. Maandelijkse budget vs werkelijk vangt deze op voordat ze structureel ingebed raken.

Churn is de gevaarlijkste verborgen variabele. Oprichters modelleren churn als een vast percentage in hun financieel model, en vergeten vervolgens te controleren of werkelijke churn de aanname klopt. Bij 3% maandelijkse churn versus de gemodelleerde 1,5% is het verschil in klantencount in maand twaalf bijna 20%. Het bedrijf dat dit in maand twee merkt, kan retentie verbeteren. Het bedrijf dat dit in maand tien merkt, heeft een structureel probleem.

Onvrijwillige churn is deels herstelbaar, maar alleen als vroeg gevangen. Een significant deel van wat verschijnt in “gechuurnde MRR” is eigenlijk churn door mislukte betalingen, geen vrijwillige opzeggingen. Stripe-data maakt het onderscheid zichtbaar: een abonnement gemarkeerd als geannuleerd na een mislukte betaling is herstelbaar via een dunning-reeks als het binnen dagen wordt gevangen. Weken later is de klant verder gegaan. Budget vs werkelijk dat een regel voor mislukte betalingen bevat, vangt dit herstelvenster op. NoNoiseMetrics toont mislukte vs vrijwillige churn afzonderlijk uit Stripe precies om deze reden.

Runway is de metric die niet fout kan zijn. Een runway-berekening is alleen nuttig als de invoergegevens, burn rate en kassaldo, weerspiegelen wat er werkelijk is gebeurd. Een model dat niet is bijgewerkt aan de actuals zal runway tonen op basis van verouderde aannames. Oprichters zijn al eerder verrast door korte runways, en de oorzaak is bijna altijd een model dat maanden eerder van de werkelijkheid afweek zonder dat iemand de vergelijking uitvoerde.

De 10-minuten wekelijkse lus

De wekelijkse review hoeft niet ingewikkeld te zijn. Vijf stappen, één tabel, één beslissing:

Stap 1: Trek de huidige cijfers op. Elke week: eind-MRR, nieuwe MRR, gechuurnde MRR, kassaldo. Maandelijks: werkelijke vaste kosten, werkelijke variabele kosten. Bronnen: Stripe voor omzet en churn, bankfeed of boekhoudtool voor kosten. Een schoon terugkerende omzet-dashboard maakt deze stap in minder dan twee minuten.

Stap 2: Vergelijk met budget. Vul de vergelijkingstabel in (template hieronder). Voor elke regel: budget, werkelijk, variantie in euro’s, variantie als percentage.

Stap 3: Vlag alleen betekenisvolle variantie. Niet elk verschil rechtvaardigt actie. Gebruik drempelwaarden: omzetvariantie boven 5%, uitgavenvariantie boven 10%, runwayvariantie boven 0,5 maanden, churnpercentage meer dan 50% boven aanname. Onder die drempelwaarden: noteer het, handel er niet naar.

Stap 4: Schrijf één actie per gevlagde variantie. Één. Geen strategiedocument, geen retrospectief. Één concrete actie, één eigenaar, deze week. Churn boven drempel → vandaag Stripe-opzeggingsgebeurtenissen en mislukte betalingen controleren. Uitgaven boven drempel → de regelpost identificeren die bewoog en beslissen of je hem wilt snijden.

Stap 5: Werk het model bij als de werkelijkheid duidelijk veranderd is. Niet elke week, alleen wanneer een aanname aantoonbaar is verschoven. Nieuwe MRR heeft drie opeenvolgende weken onder plan gelegen → de aanname bijwerken. Een miss van één week is ruis. Een patroon van drie weken is signaal.

De lus zou 10 minuten moeten duren als de data toegankelijk is. Als het een uur duurt, is de data-infrastructuur het probleem, niet het proces.

Budget vs werkelijk rapport: het volledige template

Een budget vs werkelijk rapport voor oprichters zou op één scherm moeten passen en één beslissing moeten produceren. Hier is de volledige structuur:

Omzetblok

Metric	Budget	Werkelijk	Variantie	Variantie %
Eind-MRR	€12.000	€11.400	−€600	−5,0%
Nieuwe MRR	€1.800	€1.500	−€300	−16,7%
Uitbreidings-MRR	€400	€380	−€20	−5,0%
Gechuurnde MRR (vrijwillig)	€300	€360	+€60	+20,0%
Gechuurnde MRR (mislukte betaling)	€100	€220	+€120	+120,0%

Kostenblok

Metric	Budget	Werkelijk	Variantie	Variantie %
Vaste kosten	€5.500	€5.500	€0	0,0%
Variabele kosten	€2.000	€2.700	+€700	+35,0%
Totale uitgaven	€7.500	€8.200	+€700	+9,3%

Kasblok

Metric	Budget	Werkelijk	Variantie
Maandelijkse burn	€2.100	€3.400	+€1.300
Kas in hand	€48.900	€47.600	−€1.300
Runway	11,0 mnd	9,7 mnd	−1,3 mnd

Actieblok

Vlag	Drempel	Status	Actie deze week
Churn boven plan	+50%	⚠️ Mislukte betalingschurn +120%	Dunning-reeks uitvoeren op cohort mislukte betalingen
Variabele kosten boven plan	+10%	⚠️ +35%	API-kostendrijver identificeren; gebruiksalert instellen
Nieuwe MRR onder plan	−15%	⚠️ −16,7%	Activatie-drop-off in Stripe bekijken; trial-conversie controleren
Runway onder plan	−0,5 mnd	⚠️ −1,3 mnd	Niet-omzet-experimenten bevriezen totdat herstel bevestigd is

Gechuurnde MRR splitsen in vrijwillige en mislukte betalingscomponenten is de meest actiegerichte wijziging die de meeste oprichters aan hun budget vs werkelijk rapport kunnen maken. Vrijwillige churn vereist product- en retentiewerk, langzamer te repareren. Churn door mislukte betalingen is herstelbaar binnen dagen als het gevangen wordt. Beide als hetzelfde getal behandelen verspilt het herstelvenster.

Budget vs werkelijk voorbeeld: een volledige SaaS-maand

Scenario: Een SaaS-analysetool, maand vier. Het budget werd ingesteld met het financieel model van vorige maand’s review.

Invoergegevens voor het budget (van het model van vorige maand):

Start-MRR: €10.000
Nieuwe MRR: €1.800
Uitbreiding: €400
Churn (totaal): €400
Vaste kosten: €5.500
Variabele kosten: €2.000
Kas: €50.000

Wat er werkelijk is gebeurd:

Start-MRR: €10.000 (correct)
Nieuwe MRR: €1.500 (€300 gemist)
Uitbreiding: €380 (dichtbij)
Vrijwillige churn: €360 (iets boven)
Churn door mislukte betaling: €220 (significant boven; model had €100)
Vaste kosten: €5.500 (op plan)
Variabele kosten: €2.700 (€700 over. API-kosten groeiden met gebruik)

De berekening:

Eind-MRR = 10.000 + 1.500 + 380 − 360 − 220 = 11.300
(Budget was 10.000 + 1.800 + 400 − 300 − 100 = 11.800)
MRR-variantie: −€500, of −4,2%

Totale uitgaven: 5.500 + 2.700 = 8.200
Budgetuitgaven: 5.500 + 2.000 = 7.500
Uitgavenvariantie: +€700, of +9,3%

Maandelijkse burn: 8.200 − 11.300 = −3.100 (nog steeds cashflow-positief)
Budgetburn: 7.500 − 11.800 = −4.300
Het bedrijf is cashflow-positief in beide gevallen, maar genereert €1.200 minder kas dan gebudgetteerd.

Wat de oprichter specifiek zou moeten doen:

De MRR-miss is €500, onder de 5%-alertdrempel op MRR, maar nieuwe MRR miste met 16,7% en werd deels gecompenseerd door lagere churn. De churn door mislukte betalingen op €220 tegenover een aanname van €100 is de meest actiegerichte bevinding. Dat zijn herstelbare klanten. Een dunning-reeks getriggerd binnen de week vangt een betekenisvolle fractie van hen op.

De variabele kostenoverschrijding is €700. Bij €2.700 werkelijk vs €2.000 budget is dit een overschrijding van 35%. Voor een AI- of API-zwaar product betekent dit vaak dat gebruik sneller groeide dan gemodelleerd, wat een goed probleem is, maar het kostenmodel heeft bijwerking nodig. Als het product groeit, groeien variabele kosten mee, en het financieel model moet dat weerspiegelen of runwayprojecties zullen optimistisch zijn.

Acties deze week:

Lijst mislukte betalingen uit Stripe trekken; e-mailherstelreeks triggeren via Brevo
API-gebruiksdashboard controleren; een factureringsalert instellen op 80% van de werkelijke kosten van vorige maand
Financieel model bijwerken: aanname nieuwe MRR → €1.600 (tussen plan en actuals); aanname variabele kosten → €2.400

Dat is alles. Geen boardpresentatie. Geen financieel overleg. Drie concrete acties uit een 10-minuten review.

KeyBanc Capital Markets SaaS Survey-data toont dat SaaS-bedrijven die wekelijkse budget vs werkelijk reviews uitvoeren, kostendrift gemiddeld zes weken eerder detecteren dan die met maandelijkse reviews, een significant verschil in het sub-€1M ARR-stadium.

Budgetvariantieformule

De mechanica is eenvoudig:

Budgetvariantie (absoluut) = Werkelijk − Budget

Budgetvariantie (%) = (Werkelijk − Budget) / Budget × 100

Tekenconventie telt. Voor omzetregels is een negatieve variantie slecht (je verdiende minder dan gepland). Voor kostenregels is een positieve variantie slecht (je besteedde meer dan gepland). Sommige oprichters draaien het teken om bij kostenregels om “alles slecht = negatief” te maken, beide conventies werken zolang ze consistent zijn.

Voorbeeld:

Gebudgetteerde nieuwe MRR: €1.800
Werkelijke nieuwe MRR: €1.500
Variantie: €1.500 − €1.800 = −€300
Variantie %: −€300 / €1.800 = −16,7%

Gebudgetteerde variabele kosten: €2.000
Werkelijke variabele kosten: €2.700
Variantie: €2.700 − €2.000 = +€700
Variantie %: +€700 / €2.000 = +35,0%

Voor oprichters die een gecombineerde burnmetric gebruiken, is de variantie:

Budgetburn = Budgetomzet − Budgetkosten
Werkelijke burn = Werkelijke omzet − Werkelijke kosten
Burnvariantie = Werkelijke burn − Budgetburn

Als werkelijke burn hoger is dan budgetburn (het bedrijf verbrandde meer kas dan verwacht), is de variantie positief en negatief, positief in kostenafwijking en negatief in omzet. Toon beide componenten zodat je weet welke hefboom je moet trekken.

De budget vs werkelijk lus in het prognosesysteem

Budget vs werkelijk staat niet op zichzelf. Het is één stap in een continue operationele cyclus:

Financieel model (aannames)
    → Prognose (geprojecteerde maandelijkse uitkomsten)
        → Budget (periodespecifiek uitgavenplan)
            → Actuals (wat het bedrijf produceerde)
                → Variantie (gat tussen plan en werkelijkheid)
                    → Beslissing (actie of aanname-update)
                        → Bijgewerkt financieel model

Zonder de actuals-naar-beslissing-stap is de lus gebroken. Een prognose die nooit wordt vergeleken met actuals geeft oprichters vals vertrouwen, het model ziet er goed uit, de runway ziet er toereikend uit, maar de onderliggende aannames zijn van de werkelijkheid afgedreven.

De beslissing-naar-model-stap is even belangrijk. Als je merkt dat nieuwe MRR drie opeenvolgende maanden 15% onder plan heeft gelopen en je de aanname niet bijwerkt, liegt het financieel model over runway. De aanname bijwerken is oncomfortabel omdat het de runway korter maakt, maar het maakt hem nauwkeurig, wat het model voor bedoeld is.

Voor de MRR-prognose laag is het 3-invoermodel ontworpen om te integreren met deze budget vs werkelijk lus, licht genoeg om elke week bij te werken naast de actualsvergelij king.

Voor de scenarioplanning-laag die het model stresstestbaar maakt, zie Scenariomodellering voor Bootstrappers: Stresstest in 15 Minuten.

Bessemer’s State of the Cloud rapport identificeert geautomatiseerde MRR-data als de meest impactvolle infrastructuurinvestering voor het verbeteren van de nauwkeurigheid en cadans van budget vs werkelijk reviews.

Veelgemaakte fouten bij budget vs werkelijk

Maandelijks doen en de drift missen. Maandelijkse reviews vangen problemen op na vier weken van cumulering. Een wekelijkse puls op MRR en burn duurt tien minuten en vangt hetzelfde probleem in week één op, wanneer het nog gemakkelijk te repareren is. Voor vroegefase SaaS waar de MRR-basis fragiel is, is wekelijks bijna altijd beter.

Te veel budgetregels. Een budget vs werkelijk tabel met 40 regels wordt niet consistent beoordeeld. Condenseer naar de zes getallen die het bedrijf bewegen: MRR, nieuwe MRR, churn, variabele kosten, burn, runway. Voeg alleen regels toe wanneer een beslissing meer granulariteit vereist.

Geen variantiedrempel. Elk klein verschil creëert ruis. Stel expliciete drempels in, omzetmiss boven 5%, uitgaven boven 10%, runwaydaling boven 0,5 maanden, en vlag alleen die. Onder de drempel: noteer het, handel er niet naar. Dit houdt de review weg van een wekelijks angstevenement.

Vergelijken met een fantasiebudget. Als de budgetaannames van tevoren optimistisch waren, meet de vergelijking hoe ver van fantasie de werkelijkheid terechtkwam. Een nuttig budget moet iets ongemakkelijk zijn om aan vast te houden, haalbaar in een redelijk scenario, niet aspirationeel in een perfecte.

Geen actie verbonden aan de variantie. Een review die “interessant, laten we het in de gaten houden” produceert, is geen review, het is rapportage. Elke gevlagde variantie zou een beslissing, een eigenaar en een tijdlijn moeten produceren. Anders wordt het proces wekelijkse administratie in plaats van een beslissingsondersteunend instrument.

Alle churn als gelijkwaardig behandelen. Vrijwillige churn (klant koos te vertrekken) en onvrijwillige churn (mislukte betaling) vereisen volledig verschillende reacties. Beide in één churncijfer combineren verbergt welk type de variantie aandrijft en verspilt het herstelvenster voor mislukte betalingen.

Budget vs werkelijk automatiseren

De grootste wrijving bij het uitvoeren van de wekelijkse review is het handmatig ophalen van de cijfers. Drie automatiseringsinvesteringen betalen zich snel terug:

MRR-data uit Stripe automatiseren. Nieuwe MRR, gechuurnde MRR (gesplitst naar vrijwillig en mislukte betaling), uitbreidings-MRR en eind-MRR kunnen allemaal worden opgehaald uit Stripe-abonnementsgebeurtenissen zonder handmatige berekening. NoNoiseMetrics doet dit automatisch en toont de wekelijkse MRR-waterval in het dashboard, het omzetblok van de budget vs werkelijk tabel vult zichzelf.

Stripe-factureringsalerts instellen voor bewaking variabele kosten. Als variabele kosten API-kosten bevatten gefactureerd via Stripe of clouddiensten, stel budgetalerts in bij elk providerdashboard. De alert triggert wanneer uitgaven de drempel naderen, niet nadat de rekening is gearriveerd.

Gebruik een lichtgewicht vaste tracker voor kosten. Vaste kosten veranderen niet veel van maand tot maand. Een eenvoudige lijst van terugkerende kosten met maandelijkse bedragen, alleen bijgewerkt wanneer er iets verandert, is voldoende. Aggregeer het in één cel in plaats van een multi-tab kostenmodel te bouwen.

De wekelijkse review die 45 minuten duurde bij handmatige uitvoering duurt typisch 10 minuten wanneer de MRR-data geautomatiseerd is en kosten worden bijgehouden in één tracker.

JSON-structuur voor een budget vs werkelijk tracker

{
  "budget_vs_actual": {
    "period": "2026-04",
    "currency": "EUR",
    "revenue": {
      "mrr_budget": 12000,
      "mrr_actual": 11300,
      "mrr_variance": -700,
      "mrr_variance_pct": -5.8,
      "new_mrr_budget": 1800,
      "new_mrr_actual": 1500,
      "expansion_mrr_budget": 400,
      "expansion_mrr_actual": 380,
      "churn_voluntary_budget": 300,
      "churn_voluntary_actual": 360,
      "churn_failed_payment_budget": 100,
      "churn_failed_payment_actual": 220
    },
    "costs": {
      "fixed_budget": 5500,
      "fixed_actual": 5500,
      "variable_budget": 2000,
      "variable_actual": 2700,
      "total_budget": 7500,
      "total_actual": 8200,
      "total_variance_pct": 9.3
    },
    "cash": {
      "burn_budget": -4300,
      "burn_actual": -3100,
      "runway_budget_months": 11.0,
      "runway_actual_months": 9.7
    },
    "variance_flags": {
      "new_mrr_below_threshold": true,
      "failed_payment_churn_above_threshold": true,
      "variable_costs_above_threshold": true,
      "runway_below_target": true
    },
    "actions": [
      {
        "flag": "failed_payment_churn",
        "action": "Trigger dunning sequence for failed payment cohort",
        "owner": "founder",
        "due": "this week"
      },
      {
        "flag": "variable_costs",
        "action": "Identify API cost driver; set usage alert at 80% of actual",
        "owner": "founder",
        "due": "this week"
      },
      {
        "flag": "new_mrr",
        "action": "Review trial-to-paid conversion in Stripe; check activation drop-off",
        "owner": "founder",
        "due": "this week"
      }
    ]
  }
}

De actions-array is de belangrijkste toevoeging aan een standaard budget vs werkelijk JSON-structuur. Hij sluit de lus tussen de cijfers en de beslissingen, wat de enige reden is om de review in de eerste plaats uit te voeren.

FAQ

Wat is budget vs werkelijk?

Budget vs werkelijk is de vergelijking tussen wat een bedrijf van plan was te verdienen en te besteden (het budget) en wat het werkelijk produceerde in een gegeven periode (de actuals). Het verschil ertussen, de budgetvariantie, bepaalt of en wat je wilt veranderen. Voor SaaS-oprichters omvat deze vergelijking doorgaans MRR, nieuwe MRR, churn, variabele kosten, burn rate en runway.

Wat moet er in een budget vs werkelijk rapport staan?

Een budget vs werkelijk rapport voor oprichters zou moeten bevatten: een omzetblok (gebudgetteerde vs werkelijke MRR, nieuwe MRR en churn, gesplitst naar vrijwillig en mislukte betaling), een kostenblok (vast en variabel), een kasblok (burn rate en runway), en een actieblok met één concrete reactie per gevlagde variantie. Het zou op één scherm moeten passen en in minder dan 10 minuten klaar moeten zijn.

Wat is budgetvariantie en hoe bereken je het?

Budgetvariantie is het verschil tussen een gebudgetteerd getal en het werkelijke resultaat: Variantie = Werkelijk − Budget. Als percentage: Variantie % = (Werkelijk − Budget) / Budget × 100. Voor omzetregels betekent een negatieve variantie onderprestatie. Voor kostenregels betekent een positieve variantie overbesteding. Beide zouden een review moeten triggeren als ze de drempel van de oprichter overschrijden (typisch 5% voor omzet, 10% voor kosten).

Wat is een budget vs werkelijk voorbeeld voor een SaaS-bedrijf?

Een veelvoorkomend voorbeeld: een SaaS-oprichter budgetteert €12.000 eind-MRR en €7.500 aan kosten. Actuals komen binnen op €11.300 MRR en €8.200 kosten. De omzetvariantie is −€700 (−5,8%), voornamelijk gedreven door een nieuwe MRR-miss van €300 en churn door mislukte betalingen die het gebudgetteerde bedrag verdubbelde. De kostenafwijking is €700 (+9,3%), gedreven door API-gebruiksgroei. Acties: een herstelreeks voor mislukte betalingen triggeren, de API-kostendrijver onderzoeken, het financieel model bijwerken met herziene aannames.

Hoe verschilt budget vs werkelijk van werkelijk vs budget?

Het is dezelfde vergelijking beschreven vanuit verschillende richtingen. “Budget vs werkelijk” (budget eerst) benadrukt het plan als basislijn en toont hoe de werkelijkheid ervan afweek. “Werkelijk vs budget” (actuals eerst) toont wat er is gebeurd en hoe dat zich verhoudt tot het plan. De berekening en het nut zijn identiek. De volgorde is een presentatievoorkeur.

Hoe vaak moet een SaaS-oprichter budget vs werkelijk bekijken?

Wekelijks voor vroegefase producten waar MRR nog fragiel is en runway onder 18 maanden ligt. Maandelijks voor meer gevestigde producten met stabiele groeipatronen. De wekelijkse versie is een kortere polscontrole, zes kernmetrics, één tabel, één beslissing, geen volledige modelreview. Maandelijkse reviews zijn uitgebreider en bevatten aanname-updates.

Waarom is churn door mislukte betalingen belangrijk in een budget vs werkelijk review?

Churn door mislukte betalingen is het aandeel van “gechuurnde MRR” dat afkomstig is van betalingsfouten in plaats van vrijwillige opzeggingen. Het is deels herstelbaar, een goed getimede dunning-e-mailreeks kan 20–40% van de churn door mislukte betalingen binnen dagen terugwinnen. Als churn door mislukte betalingen wordt gecombineerd met vrijwillige churn in het budget vs werkelijk rapport, is het herstelvenster onzichtbaar. De twee regels scheiden creëert de mogelijkheid onmiddellijk te handelen op het herstelbare deel.

Prognoses maken van vuile MRR is fout prognoses maken. Begin met getallen die je kunt vertrouwen →