Teams gebruiken de begrippen bedrijfsmodel, verdienmodel, prijs en pakketten vaak alsof ze hetzelfde betekenen. Dat leidt tot kostbare diagnosefouten.
Een lage conversie wordt aan de prijs toegeschreven, terwijl het echte probleem een onduidelijk pakket is. Een probleem met opzeggingen kan aanzetten tot een korting, hoewel klanten helemaal geen terugkerende waarde ontvangen. Een oprichter kan aankondigen dat het bedrijf "is doorgegroeid naar enterprise" nadat hij een pakket van 499 € heeft toegevoegd, terwijl het product, de koper, het verkoopproces en de manier van leveren hetzelfde zijn gebleven.
Deze begrippen hangen samen, maar elk beschrijft een andere beslissing:
- Bedrijfsmodel: hoe het hele bedrijf waarde creëert, levert en verwerft.
- Verdienmodel: welke economische gebeurtenis omzet genereert.
- Waardemaatstaf: op welke eenheid de vergoeding meeschaalt.
- Pakketten: wat de klant krijgt en waarin de aanbiedingen verschillen.
- Prijs: hoeveel de klant betaalt en volgens welke formule.
- Factureringsmechanica: wanneer en hoe het geld wordt geïnd.
Door deze lagen te scheiden, is monetisatie makkelijker te ontwerpen, te testen en te verbeteren.
De volledige monetisatiestack
| Laag | Kernvraag | Voorbeeld voor SaaS voor projectbeheer |
|---|---|---|
| Klant en probleem | Wiens kostbare probleem lossen we op? | Bureaus die klanten bedienen en de uitvoering van projecten coördineren |
| Waardecreatie | Welke waardevolle verandering levert het product? | Minder gemiste taken en minder tijd besteed aan coördinatie |
| Bedrijfsmodel | Hoe gaat het bedrijf deze waarde creëren, leveren en rendabel verwerven? | Cloudsoftware die rechtstreeks wordt verkocht met zelfstandige onboarding |
| Verdienmodel | Welke gebeurtenis zorgt ervoor dat het bedrijf omzet krijgt? | Een abonnement dat terugkerende toegang geeft |
| Waardemaatstaf | Welke eenheid laat de vergoeding groeien? | Een actieve werkruimte in plaats van elke uitgenodigde gast |
| Pakketten | Wat is beschikbaar en wat is beperkt? | De pakketten Core, Pro en Agency met verschillende werkstromen |
| Prijs | Welk bedrag rekenen we? | 39, 99 en 249 € per maand |
| Factureringsmechanica | Wanneer en hoe wordt de betaling geïnd? | Maandelijkse kaartbetaling of jaarlijkse vooruitbetaling met korting |
Een beslissing in één laag beperkt de andere, maar bepaalt ze niet volledig. Hetzelfde SaaS-bedrijf kan abonnementen per gebruiker, per werkruimte of per gebruik hanteren. Dezelfde maatstaf van het aantal gebruikers kan voorkomen in een maandelijks zelfbedieningspakket of in een onderhandeld jaarcontract voor enterprise.
Bedrijfsmodel: de volledige werkingslogica
Het bedrijfsmodel legt uit hoe het bedrijf functioneert als economisch systeem. Het omvat veel meer dan de manier waarop facturen worden berekend.
Het moet minstens het volgende vastleggen:
- het klantsegment;
- de gebruiker, de koper en de betaler;
- het probleem en het gewenste resultaat;
- het product of de dienst die wordt geleverd;
- de manier waarop klanten worden geworven en de verkoop wordt gevoerd;
- het systeem voor levering en support;
- de belangrijkste partners of leveranciers;
- de belangrijkste vaste en variabele kosten;
- de manier waarop omzet wordt verworven;
- de reden waarom het systeem in de loop van de tijd waarde kan beschermen of opbouwen.
Bij een marktplaats omvat het bedrijfsmodel het aantrekken van zowel aanbod als vraag, het opbouwen van vertrouwen, de afhandeling van transacties en het beslechten van geschillen. De uitspraak "wij rekenen 12 %" beschrijft maar een deel van het mechanisme waarmee omzet wordt verworven.
Bij open-sourcesoftware kan het bedrijfsmodel bestaan uit een gratis beschikbare kern, distributie via de community en een commerciële cloud of beheerlaag voor enterprise-klanten. "Abonnement" verklaart niet waarom gebruikers een gratis product aannemen, noch wat het betaalde aanbod moeilijk vervangbaar maakt.
Een bruikbaar bedrijfsmodel op één pagina
Schrijf voor elk element één zin:
- Klant: We bedienen [een specifiek segment] in [een specifieke context].
- Probleem: Zij verliezen [geld, tijd, kansen of controle] door [oorzaak].
- Resultaat: We helpen hen [een waarneembaar resultaat] te bereiken.
- Product: We leveren dit resultaat met [software, een marktplaats, data, een dienst of een combinatie daarvan].
- Distributie: Klanten ontdekken en kopen het aanbod via [kanalen en manier van verkopen].
- Levering: Hun bediening vraagt om [infrastructuur, operatie, leveranciers en support].
- Omzet: We verdienen wanneer [een economische gebeurtenis] plaatsvindt.
- Kosten: Onze belangrijke vaste en variabele kosten komen voort uit [kostenfactoren].
- Voorsprong: Het systeem wordt beter of moeilijker te vervangen dankzij [overstapkosten, data, werkstroom, netwerk, merk of expertise].
Als deze uitspraken geen samenhangend systeem vormen, verhelpt het kiezen van een vernuftige prijspagina dat niet.
Verdienmodel: de gebeurtenis die omzet genereert
Het verdienmodel bepaalt waarvoor klanten of derden betalen.
De verzameling mechanismen is bekend: een eenmalige aankoop, een terugkerend abonnement, een vergoeding voor gebruik, een transactiecommissie, een vergoeding per verkregen lead, licenties, advertenties of sponsoring, een affiliate-commissie, implementatie of een beheerde dienst, een vergoeding voor een resultaat, vrijwillige steun, en combinaties van meerdere daarvan.
De meeste producten kunnen op drie of vier van deze manieren worden verkocht. De vraag is bijna nooit welke mogelijk is, maar welke past bij hoe het budget van de klant zelf werkt.
Een product kan meerdere omzetstromen hebben. Het belangrijkste is of elke stroom overeenkomt met echte waarde en of het bedrijf haar rendabel kan bedienen.
Omzetstroom versus verdienmodel
Het verdienmodel is het algemene mechanisme. Een omzetstroom is de concrete bron van geld binnen dat mechanisme.
Een analyseplatform kan bijvoorbeeld hebben: terugkerende zelfbedieningsabonnementen, terugkerende enterprise-licenties, eenmalige implementatievergoedingen, betaalde trainingen en vergoedingen voor gebruik boven de limiet.
Deze stromen kunnen verschillende kopers of kostenstructuren bedienen, maar ze behoren tot één gemeenschappelijk operationeel systeem.
Waardemaatstaf: de eenheid die prijs en waarde verbindt
De waardemaatstaf bepaalt hoe de vergoeding van de klant verandert naarmate de relatie zich ontwikkelt.
De factureringsmaatstaf is alles wat je afspreekt te tellen: gebruikers of actieve gebruikers, werkruimtes, winkels of organisaties, projecten, contacten of records, transacties of hun waarde, API-verzoeken, tokens, rekentijd of opslagruimte, gegenereerde resultaten, geleverde leads, locaties of apparaten, beheerde omzet of reikwijdtes van mogelijkheden.
Een goede maatstaf groeit wanneer het voordeel voor de klant groeit en blijft leesbaar op de factuur. De meeste geschillen komen voort uit maatstaven die maar aan één van deze twee voorwaarden voldoen.
Een goede waardemaatstaf heeft vier eigenschappen:
- Aansluiting op waarde: klanten die meer eenheden gebruiken, ontvangen doorgaans meer waarde.
- Aansluiting op kosten: meer gebruik veroorzaakt geen leveringskosten die niet in de prijs zijn verwerkt.
- Begrijpelijkheid: klanten begrijpen de eenheid en kunnen die voorspellen.
- Operationele uitvoerbaarheid: het product kan het gebruik ervan betrouwbaar meten, rapporteren en afdwingen.
Geen enkele maatstaf is perfect. Facturering per gebruiker is begrijpelijk, maar kan ervan weerhouden collega's uit te nodigen. Facturering per gebruik sluit aan op het verbruik, maar kan zorgen over het budget wekken. Pakketten op basis van functies zijn voorspelbaar, maar kunnen een cruciale werkstroom in het verkeerde pakket plaatsen.
Verwar de maatstaf niet met het model
"Per gebruiker" hoeft geen verdienmodel te betekenen. Vaak is het een waardemaatstaf binnen een abonnementsmodel.
"Credits" zijn doorgaans een factureringseenheid in een prijslijst op basis van gebruik of in een hybride model. De onderliggende omzet kan voortkomen uit terugkerende creditpools, vooruitbetaalde pakketten, achteraf betaald verbruik of een combinatie daarvan.
Dit onderscheid is van belang, omdat twee aanbiedingen met dezelfde maatstaf totaal verschillend kunnen werken:
- 20 € per actieve gebruiker per maand;
- 200 € voor tien gebruikers per jaar;
- 2.000 € voor een onbeperkte licentie voor tien gebruikers;
- gratis toegang plus 5 € voor elke geslaagde transactie die via een gebruiker wordt uitgevoerd.
Pakketten: wat de klant daadwerkelijk koopt
Pakketten bepalen de grenzen van het aanbod. Ze veranderen een product met veel mogelijkheden in een klein aantal begrijpelijke koopopties.
Een pakket kan het volgende vastleggen:
- beschikbare functies en werkstromen;
- de gebruikslimiet;
- het aantal gebruikers, werkruimtes of locaties;
- mechanismen voor beveiliging en governance;
- het niveau van support en de reactietijd;
- onboarding of migratie;
- de bewaarperiode van data;
- integraties;
- een overeenkomst over gegarandeerde dienstverlening;
- flexibiliteit van het contract;
- wat er gebeurt na overschrijding van de limiet;
- beschikbaarheid afhankelijk van het type klant.
Goed ontworpen pakketten helpen de klant het aanbod te herkennen dat voor zijn situatie bedoeld is. Ze mogen er niet toe leiden dat tientallen willekeurige cellen vergeleken moeten worden.
Bouw pakketten rond wezenlijke verschillen
Bruikbare pakketgrenzen weerspiegelen vaak een van de volgende overgangen:
- van individueel gebruik naar teamsamenwerking;
- van incidenteel gebruik naar een operationele werkstroom;
- van een klein team naar governance over meerdere afdelingen;
- van een standaardproces naar maatwerk;
- van een toepassing met laag risico naar een toepassing die cruciaal is voor naleving;
- van zelfbediening naar begeleide implementatie;
- van gewoon verbruik naar de economie van grote schaal.
Een functie hoort niet in een hoger pakket omdat ze populair is. Vraag of ze meer waarde vertegenwoordigt, hogere kosten, een andere koper of een complexere operationele eis.
Rechten maken deel uit van pakketten
Beloftes over pakketten moeten worden vertaald naar afdwingbare regels van het product. Als een plan vijf werkruimtes omvat, heeft de applicatie een definitie van een werkruimte nodig, betrouwbaar tellen, regels voor het upgraden van het plan en afhandeling van verwijderde of gearchiveerde werkruimtes.
Elke pakketgrens roept operationele vragen op:
- Wat gebeurt er wanneer de limiet is bereikt?
- Wordt de toegang geblokkeerd, beperkt of wordt een vergoeding voor overschrijding in rekening gebracht?
- Ziet de beheerder het actuele gebruik?
- Worden de limieten pro rata berekend wanneer midden in de factureringsperiode wordt overgestapt op een hoger plan?
- Welke historische data blijven beschikbaar na overstap naar een lager plan?
- Kan de supportafdeling een tijdelijke uitzondering verlenen?
Een pakket dat niet consequent kan worden geïmplementeerd, leidt tot geschillen over facturering en handmatig afgehandelde uitzonderingen.
Prijs: bedrag en formule
De prijs bepaalt de financiële voorwaarden die aan het model, de maatstaf en het pakket zijn gekoppeld.
Een prijs is meerdere getallen tegelijk: een basisbedrag, een tarief per eenheid, een minimale verplichting, volumedrempels, de beschikbare limiet, het tarief voor overschrijding, een startvergoeding, het kortingsbeleid, de looptijd van het contract, de valuta en de manier waarop belastingen worden verwerkt, en de voorwaarden voor verlenging.
Het tarief voor overschrijding en de voorwaarden voor verlenging leest de klant het laatst, en onthoudt hij het langst. Een verrassing in een van beide verandert een gesprek over verlenging in een inkoopbeoordeling.
Hetzelfde pakket kan worden geprijsd met de methode kostprijs plus marge, op basis van prijzen van concurrenten, onderzoek naar betalingsbereidheid of redeneringen op basis van waarde. In de praktijk combineren teams bewijs uit alle vier de bronnen.
Het prijsniveau is maar één variabele
Stel dat een pakket slecht converteert. Er zijn meerdere mogelijke verklaringen:
- het aanbod wordt gezien door het verkeerde segment;
- het resultaat is niet waardevol genoeg;
- het pakket bevat te weinig of te veel;
- de waardemaatstaf voelt oneerlijk;
- het bedrag is te hoog;
- het bedrag is verdacht laag;
- de verplichtingsperiode is te lang;
- de koper kan een bepaalde betaalmethode niet goedkeuren;
- het aanbod wekt onzekerheid over overschrijding van limieten;
- het vertrouwen is niet voldoende om vooruit te betalen.
Het verlagen van het bedrag toetst slechts een deel van deze verklaringen en kan bovendien de waargenomen kwaliteit verlagen of het rendabel werven van klanten onmogelijk maken.
Factureringsmechanica: geld innen is niet hetzelfde als waarde creëren
De factureringsmechanica bepaalt wanneer geld stroomt en hoe wijzigingen worden afgehandeld.
Voorbeelden zijn:
- maandelijkse vooruitbetaling;
- jaarlijkse vooruitbetaling;
- maandelijkse afrekening van gebruik achteraf;
- vooruitbetaald creditsaldo;
- facturering per mijlpaal;
- een aanbetaling en betaling na oplevering;
- automatische verlenging met kaartbetaling;
- een factuur met een betalingstermijn van 14, 30 of 60 dagen.
De overstap van maandelijkse naar jaarlijkse facturering beïnvloedt de kasstroom en de verplichting, maar het verdienmodel kan nog steeds een abonnement zijn. Het toevoegen van kaartbetalingen zorgt niet voor product-marktfit. Betalen op factuur mogelijk maken kan aankopen die aan procedures moeten voldoen vergemakkelijken zonder het pakket te wijzigen.
Behandel de details van het innen van betalingen als strategisch belangrijk, maar conceptueel afzonderlijk.
Diagnosticeer problemen op de juiste laag
| Symptoom | Mogelijke laag | Bewijs om te verzamelen vóór wijzigingen |
|---|---|---|
| Veel gebruikers doorlopen de activatie, maar weinig betalen | Waarde, koper, pakket of prijs | Gesprekken met geactiveerde personen die niet hebben gekocht; inkoopbevoegdheden; reactie op het aanbod |
| Klanten kopen en zeggen na één project op | Verdienmodel of terugkerende waarde | Gebruik na het bereiken van het eerste resultaat; reden van opzegging; hoe vaak het probleem terugkeert |
| Intensieve gebruikers zijn verliesgevend | Waardemaatstaf, prijs of limieten | Marge per gebruiksbandbreedte; variabele kosten; gedrag na overschrijding van de limiet |
| Prospects vragen naar één ontbrekende mogelijkheid | Pakketten of product | Patroon in het segment; bereidheid tot toezegging na toevoeging; implementatiekosten |
| Teams vermijden het uitnodigen van collega's | Maatstaf van het aantal gebruikers of pakketlimiet | Benutting van gebruikers; uitnodigingsgedrag; opmerkingen van kopers |
| Enterprise-contracten vragen om uitzonderingen | Bedrijfsmodel, pakketten of verkoopproces | Soorten uitzonderingen; beveiligingsbehoeften; last voor de dienstverlening; economie van het contract |
| Klanten vrezen onvoorspelbare rekeningen | Maatstaf of factureringsmechanica | Verwacht en werkelijk gebruik; gewenste bovengrenzen; budgetproces |
| Hoge conversie, maar lage omzet | Prijs, segment of pakketstructuur | Omzet per account; kortingen; supportkosten; uitbreidingsgedrag |
Eén symptoom kan meerdere oorzaken hebben. Combineer kwalitatief en kwantitatief bewijs.
Praktijkvoorbeeld: één product, vier verschillende stacks
Neem software die klantgesprekken automatisch transcribeert en samenvat.
Stack A: zelfbedieningsabonnement
- Bedrijfsmodel: cloudsoftware die klanten werft via content en productgestuurde onboarding.
- Verdienmodel: terugkerend abonnement.
- Waardemaatstaf: aantal verwerkte uren.
- Pakketten: individuele plannen en teamplannen met een maandelijkse pool van uren.
- Prijs: 29 en 99 € per maand en vergoedingen voor overschrijding van de limiet.
- Facturering: kaartbetaling per maand of per jaar.
Deze oplossing past bij onderzoeksteams die cyclisch werken en het product op een relatief stabiel niveau gebruiken.
Stack B: API die uitsluitend op basis van gebruik wordt gefactureerd
- Bedrijfsmodel: transcriptie-infrastructuur die wordt geïntegreerd door bedrijven die software maken.
- Verdienmodel: omzet afhankelijk van gebruik.
- Waardemaatstaf: aantal verwerkte minuten opname.
- Pakketten: standaard-API, prioritaire verwerking en enterprise-besturingsmechanismen.
- Prijs: tarief per minuut met volumedrempels.
- Facturering: maandelijkse factuur achteraf en een minimale verplichting voor grotere accounts.
Dezelfde technische mogelijkheid bedient nu ontwikkelaars binnen een ander distributie- en leveringsmodel.
Stack C: beheerde onderzoeksdienst
- Bedrijfsmodel: onderzoekers leveren gestructureerde inzichten met behulp van interne software.
- Verdienmodel: projectvergoeding of terugkerende beheerde dienst.
- Waardemaatstaf: reikwijdte van het project en aantal gesprekken.
- Pakketten: transcriptie, analyse, workshop en rapport voor het management.
- Prijs: 4.000 € per project of 8.000 € maandelijks forfait.
- Facturering: aanbetaling en facturen per mijlpaal.
De software is onderdeel van het leveringsproces, maar klanten kopen expertise en afgeronde resultaten.
Stack D: enterprise-licentie
- Bedrijfsmodel: beveiligde software die via directe verkoop wordt uitgerold in gereguleerde organisaties.
- Verdienmodel: jaarlicentie inclusief implementatie.
- Waardemaatstaf: bedrijfseenheid, implementatie of gecontracteerd volume.
- Pakketten: private implementatie, identiteitsbeheer, auditmechanismen en support.
- Prijs: onderhandelde jaarlijkse verplichting.
- Facturering: jaarfactuur en facturen voor fasen van de implementatie.
Als je alle vier de varianten "transcriptieabonnement" noemt, verberg je belangrijke verschillen in klant, verkoop, kosten en operatie.
Hoe je de stack in de juiste volgorde ontwerpt
Het proces is iteratief, maar een doordachte volgorde beperkt toevallige beslissingen.
Stap 1: definieer de klant en het resultaat
Formuleer een zin:
[Klant] gebruikt of koopt het product om [een waarneembaar resultaat] te bereiken in [een specifieke context].
Vermijd brede categorieën zoals "bedrijven" of "makers". Verschillende contexten betekenen een verschillende betalingsbereidheid, andere supporteisen en andere inkoopprocessen.
Stap 2: breng de waardelevering en de kosten in kaart
Leg vast:
- wanneer de waarde voor het eerst ontstaat;
- of ze opnieuw ontstaat;
- wat haar laat groeien;
- de variabele kosten van infrastructuur en leveranciers;
- onboarding en support door mensen;
- operationele of regelgevende lasten;
- het geld dat nodig is voordat de levering begint.
Zo'n kaart beperkt de verzameling waarschijnlijke verdienmodellen.
Stap 3: kies een hypothese voor het verdienmodel
Kies het eenvoudigste mechanisme dat past bij het moment van waardelevering en de verdeling van het risico. Schrijf op waarom het past en welk bewijs het zou kunnen weerleggen.
Voorbeeld:
We verwachten dat een terugkerend abonnement per werkruimte past, omdat bureaus wekelijks projecten coördineren en doorlopende gedeelde toegang waarderen. De hypothese wordt verzwakt als de meeste klanten de tool voor één migratie gebruiken en binnen 60 dagen stoppen.
Stap 4: kies de waardemaatstaf
Vergelijk de mogelijke eenheden op aansluiting op waarde, voorspelbaarheid, kostenveiligheid en meetbaarheid. Test de manier waarop je ze beschrijft met kopers voordat je ingewikkelde metingen invoert.
Stap 5: maak een minimaal levensvatbare set pakketten
Begin met één aanbod wanneer het publiek en de toepassing smal zijn. Voeg een tweede of derde pakket pas toe wanneer er een wezenlijk verschil in segment of waarde bestaat.
Leg voor elk pakket vast:
- de doelklant;
- het beloofde resultaat;
- de beschikbare mogelijkheden;
- de limiet en wat er na overschrijding gebeurt;
- het supportmodel;
- de reden om over te stappen op een hoger pakket.
Stap 6: bepaal de hypothese voor de prijs
Bepaal het bedrag uit meerdere bronnen tegelijk: gesprekken met klanten over huidige alternatieven en budget, gedrag in betaalde pilots, de gecreëerde economische waarde, prijzen van concurrenten en substituten, de minimale duurzame marge, kosten van verkoop en support, en strategische positionering.
Gesprekken zeggen wat klanten verklaren; een betaalde pilot zegt wat ze doen. Wanneer het ene het andere tegenspreekt, heeft de pilot gelijk.
Kies een bedrag dat belangrijk bewijs kan leveren. Een symbolische prijs kan alleen bewijzen dat klanten een symbolische prijs accepteren.
Stap 7: definieer de factureringsregels
Leg de verplichting, de betalingstermijn, verlengingen, pro-ratawaarderingen, terugbetalingen, belastingen, mislukte betalingen en opzegging vast. Het vertrouwen van de klant hangt van deze details af.
Stap 8: test en meet elke laag
Zoek de plek waar het aanbod echt breekt. Er komt een verkeerde bezoeker; het probleem wordt niet herkend; de waarde is onduidelijk; het omzetmechanisme past niet; de maatstaf verwart; het pakket trekt niet aan; het bedrag wordt afgewezen; de afronding van de aankoop of de inkoopprocedure hindert; de activatie is zwak; de aangehouden waarde is laag.
In het conversiecijfer zien al deze storingen er hetzelfde uit, en ze worden verschillend behandeld. Een prijsverlaging waar activatie het probleem is, koopt goedkopere opzegging.
Reduceer de hele funnel niet tot de uitspraak "de prijslijst werkte niet".
Hoe je zinvolle experimenten uitvoert
Verander waar mogelijk één hoofdlaag
Als je tegelijk het doelsegment, het pakket, de maatstaf, de prijs en de lengte van het contract wijzigt, wijst de uitkomst niet aan welke beslissing ertoe deed.
Sommige wijzigingen moeten samen plaatsvinden. De overstap van zelfbedienende freelancers naar gereguleerde enterprise-klanten kan een ander pakket en een ander factureringsproces vergen. Behandel dat in dat geval als een nieuw aanbod voor een nieuw segment, niet als een zuivere prijstest.
Houd een experimentenlogboek bij
Leg elke prijstest op dezelfde manier vast: segment en steekproef, het oude en het nieuwe aanbod, de geteste laag, de hypothese, start- en einddatum, drempels voor succes, aanpassingen en beëindigingen, het kwantitatieve resultaat, bezwaren van klanten, operationele gevolgen, de beslissing en de verantwoordelijke persoon.
Vooraf vastgestelde drempels zijn het onderdeel dat teams overslaan. Zonder die drempels eindigt een prijstest wanneer iemand zijn geduld verliest, en lezen degenen die toch al een wijziging wilden de uitkomst als bewijs.
Zo voorkom je het herhalen van experimenten en selectief geheugen.
Geef gedrag voorrang boven meningen
De kracht van bewijs groeit doorgaans van complimenten naar een volgehouden betaling:
- "Dat klinkt nuttig".
- Een keuze tussen concrete aanbiedingen.
- Voorstelling aan de persoon die over het budget beslist.
- Een geaccepteerd aanbod.
- Een betaalde pilot.
- Verlenging nadat de waarde is ontvangen.
- Uitbreiding op dezelfde voorwaarden.
Onderzoek helpt bij het ontwerpen van de stack, maar pas aankoop en retentie toetsen of hij werkt.
Maatstaven per laag
Gezondheid van het bedrijfsmodel
- Klantacquisitiekosten per kanaal
- Lengte van de verkoopcyclus en winstpercentage
- Brutomarge en bijdragemarge
- Cyclus voor de omzetting naar kasgeld
- Aantal uren support en service per account
- Concentratie van omzet
- Retentie per klantsegment
Gezondheid van het verdienmodel
- Terugkerende en niet-terugkerende omzet
- Voorspelbaarheid van omzet
- Percentage verlengingen of herhaalaankopen
- Variabiliteit van het gebruik
- Verlies van transactieomzet
- Gevoeligheid van omzet voor seizoenseffecten
Gezondheid van de waardemaatstaf
- Omzetgroei ten opzichte van groei van de waarde voor de klant
- Verdeling van de eenheid waarvoor wordt gefactureerd
- Marge per gebruiksbandbreedte
- Hoe vaak de hoogte van de rekening verrast
- Gedrag van klanten in de buurt van limieten
- Redenen voor uitbreiding en beperking
Gezondheid van de pakketten
- Verkoopmix van de pakketten
- Paden naar een hoger en lager pakket
- Gebruik van functies per pakket
- Conversie die wordt veroorzaakt door het bereiken van een limiet
- Frequentie van uitzonderingen
- Supportvragen over rechten
Gezondheid van de prijs
- Conversie naar een betaald aanbod per segment
- Gemiddelde verkoopprijs
- Hoogte van kortingen
- Frequentie van bezwaren tegen de prijs
- Bereidheid tot een jaarlijkse verplichting
- Brutomarge en terugverdientijd van CAC
Gezondheid van de facturering
- Afronding van de aankoop
- Mislukte betalingen en het terugwinnen ervan
- Gemiddelde betalingstermijn van openstaande facturen
- Percentage terugbetalingen en geschillen
- Reactie op de melding van verlenging
- Onvrijwillige opzeggingen
Veelvoorkomende fouten bij categorisering
"We hebben een nieuw bedrijfsmodel nodig" terwijl het pakket zwak is
Als klanten het resultaat waarderen en terugkerende betaling accepteren maar het juiste pakket niet kunnen vinden, ontwerp dan de pakketten opnieuw voordat je het bedrijf ombouwt.
"Klanten haten abonnementen" terwijl terugkerende waarde ontbreekt
Het probleem hoeft niet in de houding van klanten te zitten. Als het probleem eenmalig wordt opgelost, is opzeggen rationeel. Voeg terugkerende waarde toe of pas een model toe dat past bij levering van beperkte duur.
"Onze prijs is gebaseerd op gebruik"
De aanduiding "gebaseerd op gebruik" beschrijft hoe het bedrag verandert. Het aanbod heeft nog steeds een eenheid, een tarief, een afrekentermijn, minimale verplichtingen, bovengrenzen, pakketten en een uitleg voor de klant nodig.
"De jaarlijkse variant is goedkoper, dus de retentie is verbeterd"
Een jaarlijkse vooruitbetaling stelt het zichtbare moment van opzegging uit. Meet het gebruik van het product, verlengingen en resultaten van klanten, in plaats van veiliggesteld geld als bewijs van aangehouden waarde te beschouwen.
"Enterprise is ons hoogste pakket"
Enterprise kan een andere koper, een ander verkoopproces, een ander beveiligingsmodel, een andere manier van implementeren, een andere supportverplichting en een ander contract betekenen. Een grotere set functies alleen creëert nog geen enterprise-bedrijfsmodel.
"Freemium is een prijs"
Freemium is een manier om pakketten en klantwerving te ontwerpen, waarbij een permanent gratis aanbod naast een betaalde uitbreiding bestaat. Het beïnvloedt support, de productarchitectuur, conversiepaden en unit economics.
Beslissingschecklist
Bedrijfsmodel
- We kunnen een concrete klant en een kostbaar probleem aanwijzen.
- We begrijpen de rollen van gebruiker, koper en betaler.
- Acquisitie, levering, support en omzet vormen een samenhangend systeem.
- We hebben de factoren voor vaste en variabele kosten gedocumenteerd.
- We weten waarom het model moeilijk vervangbaar of efficiënt kan blijven.
Verdienmodel
- De omzetgebeurtenis komt overeen met het moment waarop waarde voor de klant ontstaat.
- Het risico wordt gedragen door de partij die het het best kan beheersen.
- De omzetstromen hebben afzonderlijke, onderbouwde rollen.
- Het mechanisme kan rechtmatig en betrouwbaar worden uitgevoerd.
Waardemaatstaf
- Meer gebruik van de eenheid betekent doorgaans meer waarde.
- De eenheid beschermt tegen belangrijke variabele kosten.
- Klanten kunnen haar begrijpen en voorspellen.
- De regels voor meting en correctie zijn betrouwbaar.
Pakketten
- Elk pakket heeft een duidelijk gedefinieerde doelklant.
- De verschillen weerspiegelen wezenlijke waarde of operationele behoeften.
- Limieten en gedrag na overstap naar een lager pakket zijn ondubbelzinnig.
- Het product kan rechten consequent afdwingen.
- De reden om over te stappen op een hoger pakket is begrijpelijk.
Prijs en facturering
- Het bedrag wordt bevestigd door bewijs over klant, waarde en kosten.
- Kortingen hebben een vastgesteld doel en een regel voor goedkeuring.
- De verplichting en de manier van innen sluiten aan op het proces van de koper.
- De regels voor verlenging, opzegging, terugbetalingen en mislukte betalingen zijn duidelijk.
- De maatstaven maken het mogelijk de laag aan te wijzen die bijsturing vraagt.
Een stack, geen losse beslissing
Ontwerp monetisatie als een stack, niet als één enkel getal.
Zorg eerst dat het bedrijf waardevolle resultaten levert aan een concrete klant met een uitvoerbaar leveringssysteem. Kies daarna de omzetgebeurtenis, de eenheid waarmee wordt geschaald, de pakketgrenzen, het bedrag en de regels voor het innen van betalingen.
Wanneer de resultaten teleurstellen, diagnosticeer dan de laag die faalt voordat je de hele stack wijzigt. Die discipline leidt tot eenduidiger experimenten, minder uitzonderingen in de facturering en een model dat klanten goed genoeg begrijpen om het te kopen en te blijven gebruiken.