Een RevOps maturity model is een framework dat beoordeelt hoe ver de revenue operations van een bedrijf zijn, meestal op proces, data, technologie en de afstemming tussen marketing, sales en customer success. Het plaatst het bedrijf in een fase, van reactief tot strategisch.

Je hebt er een nodig omdat "RevOps" bij elk bedrijf iets anders betekent, en de verschillen zijn groot. Bij het ene bedrijf is het één analist die kapotte rapporten repareert. Bij het andere is het een team dat de CEO vertelt waar het geld van volgend jaar naartoe moet. Allebei voeren ze dezelfde titel, en een maturity model zet ze op dezelfde kaart, zodat je ziet hoe ver ze uit elkaar liggen.

De meeste gepubliceerde modellen worden wel op gevoel gescoord. Iemand vult een vragenlijst in, geeft het team voor data de score "geïntegreerd", en er verandert niets. Wij kiezen liever een strengere test: wat kun je vandaag echt uit je CRM halen, zonder export en zonder discussie? Die versie lopen we in dit artikel door, met een zelfevaluatie die je deze week kunt doen en een manier om te bepalen wat je als eerste repareert.

TL;DR

• Maturity models komen uit de software-engineering. Het Software Engineering Institute van Carnegie Mellon publiceerde in 1993 zijn Capability Maturity Model met vijf niveaus, en RevOps-versies met drie of vijf fases lenen dezelfde klim, van improviseren naar continu verbeteren.

• Beoordeel elke fase van RevOps-maturity op de vragen die je CRM kan beantwoorden. Reageren: je kunt de openstaande deals tellen. Draaien: je kunt zeggen hoe lang deals in elke fase blijven hangen en waarom ze verloren gaan. Sturen: je vertrouwt de forecast genoeg om er je wervingsplan op te baseren.

• De zelfevaluatie bestaat uit twaalf vragen, drie per dimensie. Een vraag scoort 2 als een opgeslagen rapport hem beantwoordt, 1 als er een export en een spreadsheet voor nodig zijn, en 0 als niemand het antwoord weet of twee teams verschillende antwoorden geven.

• Tel de scores niet op. Zoek de dimensie met de meeste nullen en repareer het ene veld of de ene regel waar de meeste daarvan op teruggaan, zoals een bron die je vastlegt als een record wordt aangemaakt, of instapregels voor dealfases.

• Geavanceerde tools op data uit fase één leveren zelfverzekerde onzin op. Een hogere fase betaalt zich uit in forecasts die standhouden en minder leads die tussen teams verloren gaan, en een klein bedrijf kan jarenlang prima in de middelste fase zitten.

• Nebor bouwt in het eigen CRM van een team de velden, faseregels, routing en rapporten die het van de ene fase naar de volgende brengen, en draagt ze daarna over aan degene die ermee gaat werken.

Waar het RevOps maturity model vandaan komt, en waarom versies het oneens zijn over het aantal fases

Het idee is tientallen jaren ouder dan RevOps. In 1993 publiceerde het Software Engineering Institute van Carnegie Mellon het Capability Maturity Model for Software. Het moest organisaties helpen beter software te schrijven, en de Amerikaanse overheid een manier geven om haar leveranciers te beoordelen. Het model onderscheidde vijf niveaus: Initial, Repeatable, Defined, Managed en Optimizing.

De beschrijving van het onderste niveau klinkt bekend voor iedereen die ooit bij een snelgroeiend salesteam is begonnen. Op het Initial-niveau, zo staat in het rapport, kun je prestaties alleen voorspellen aan de hand van wat individuen kunnen, in plaats van wat de organisatie kan. Vervang "softwareproject" door "kwartaal" en je hebt een revenueteam waar de resultaten afhangen van welke drie reps een goede maand hadden.

RevOps-frameworks namen die vorm over. Sommige gebruiken drie fases, andere vijf. De labels verschillen per consultancydeck, maar de richting is altijd dezelfde: van handmatig en reactief onderaan naar voorspellend en doordacht bovenaan. Vijf fases geven je fijnere stappen voor het plannen van werk zoals quota- en capaciteitsplanning, terwijl drie fases makkelijker uit te leggen zijn aan een board. Kies er één en blijf erbij. Vergelijk je je score op het ene framework met de score van vorig jaar op een ander, dan leer je niets.

De meeste modellen beoordelen je bovendien op vier dimensies in plaats van één: proces (zijn de stappen vastgelegd en worden ze gevolgd), data (is er één versie van de waarheid), technologie (geven de tools records aan elkaar door) en afstemming (werken marketing, sales en success naar dezelfde cijfers toe). Die vier komen terug in de zelfevaluatie hieronder.

Drie fases van RevOps-maturity, te herkennen aan wat het CRM kan beantwoorden

Over namen van fases kun je eindeloos discussiëren. Over vragen niet. Het CRM kan iets vertellen of het kan het niet, dus we beschrijven elke fase aan de hand van de vragen die daar te beantwoorden zijn. We gebruiken hier drie fases (reageren, draaien en sturen). Modellen met vijf niveaus splitsen meestal de middelste fase in tweeën.

Reageren

Wie in deze fase eigenaar is van RevOps, besteedt de week aan verzoeken: een rapport dat kapot is, een veld dat iemand nodig heeft, een lijst voor een event. Data staat deels in het CRM en deels in spreadsheets, dus marketing en sales noemen verschillende cijfers voor dezelfde maand. CRM-hygiëne is een voortdurend gevecht, omdat niemand eigenaar is van de regels die de rommel bij de invoer zouden tegenhouden.

Draaien

De omslag komt als definities op papier komen en het CRM ze gaat afdwingen. Dealfases krijgen instapcriteria, voor een verloren deal moet je een reden uit een keuzelijst kiezen, en nieuwe leads gaan via lead routing in plaats van via een gedeelde inbox. Omdat de input nu consistent is, betekenen metrics als pipeline velocity en win rate elk kwartaal hetzelfde, en wordt forecast accuracy iets wat je bijhoudt in plaats van iets waarop je hoopt. Vanaf hier gaat de functie lijken op echte revenue operations en minder op een schoonmaakploeg.

Sturen

In de hoogste fase is de data betrouwbaar genoeg om vooruit te kijken. Tools voor revenue intelligence signaleren deals die lijken op eerdere verliezen, plannen voor territories en werving zijn gebouwd op de echte conversieratio's van het team, en win-lossanalyses passen elk kwartaal het playbook aan. De RevOps-lead stelt meer vragen dan hij beantwoordt. Verlengingen en uitbreiding staan in dezelfde forecast als nieuwe business, dus net revenue retention is iets wat je stuurt in plaats van iets waar je aan het eind van het jaar achter komt.

Genoeg gezonde bedrijven hebben de derde fase nooit nodig. Een team van 20 mensen dat één product in één land verkoopt, kan jarenlang goed draaien in fase twee. Het model laat je de weg zien. Hoe ver je bedrijf die weg af moet rijden, vertelt het je niet.

Doe de zelfevaluatie: twaalf vragen voor je CRM

Trek twee uur uit met degene die het CRM beheert, plus één persoon van marketing, één van sales en één van customer success. Probeer elke vraag live te beantwoorden, vanuit het CRM, terwijl iedereen meekijkt. Geef daarna een score:

• 2 als een opgeslagen rapport of dashboard de vraag binnen een paar minuten beantwoordt.

• 1 als iemand de vraag kan beantwoorden, maar alleen met een export, een spreadsheet en een middag werk.

• 0 als niemand de vraag kan beantwoorden, of als twee mensen verschillende antwoorden geven.

De vragen zijn verdeeld in vier groepen van drie, één groep per dimensie. Binnen elke groep is de eerste vraag er een die een team moet kunnen beantwoorden voordat het de fase reageren achter zich laat. De tweede hoort bij de fase draaien en de derde bij sturen.

1. Proces. Heeft elke openstaande deal een volgende stap en een closedatum die nog niet verstreken is?

2. Proces. Heeft elke dealfase opgeschreven voorwaarden om erin te komen, en blokkeert het CRM een deal die daar niet aan voldoet?

3. Proces. Hoe lang blijven deals in elke fase, en welke fase werd dit kwartaal trager? HubSpot kan dit bijhouden met stage calculated properties (de datum van binnenkomst, de datum van vertrek en de tijd in elke fase), al staan die bij nieuwe pipelines standaard uit.

4. Data. Hoeveel van je bedrijven staan meer dan één keer in het CRM?

5. Data. Waar kwam elke deal die je vorig kwartaal won oorspronkelijk vandaan? De eigenschap Original Traffic Source in HubSpot legt de eerste bekende webbron van een contact vast, maar voor outbound- en referraldeals heb je een eigen bronveld nodig.

6. Data. Wat was je win rate per segment en bron in elk van de afgelopen vier kwartalen, met ongewijzigde definities?

7. Technologie. Verschijnt er automatisch een eigenaar met naam op het record als iemand een formulier invult, en kun je zien hoe lang dat duurde?

8. Technologie. Komen verzonden e-mails, reacties, calls en meetings uit je sequencer terecht bij het contact en de deal, of blijven ze in de sequencer?

9. Technologie. Mag voor belangrijke velden als lifecycle stage, eigenaar en ICP-tier precies één systeem naar elk veld schrijven?

10. Afstemming. Rapporteren marketing en sales hetzelfde aantal gekwalificeerde leads over vorige maand?

11. Afstemming. Wat zei de forecast op de eerste dag van vorig kwartaal, en hoe ver zat hij ernaast? De forecasttool van HubSpot zet ingediende forecasts naast doelen en gesloten omzet, dus deze vraag is makkelijk te beantwoorden zodra reps hem gebruiken.

12. Afstemming. Welke klanten verlengen in de komende 90 dagen, en staat er iets in hun record waaruit blijkt dat ze risico lopen?

Weersta de neiging om de scores op te tellen. Een team dat 2, 2, 2 scoort op technologie en 0, 0, 0 op afstemming, komt gemiddeld uit op "middelmatig", en dat gemiddelde beschrijft een bedrijf dat niet bestaat. Lees de resultaten daarom per dimensie. Scoren de meeste tweede vragen in elke groep een 2, dan zit je in de fase draaien. Doen de derde vragen dat ook, dan stuur je. Je bottleneck is de dimensie met de meeste nullen.

De vragen laten ook zien hoe fases op elkaar voortbouwen. Vraag 11 kan geen 2 scoren zolang vraag 10 een 0 scoort, want een forecast die is gebouwd op leadaantallen waar niemand het over eens is, kun je nergens aan toetsen.

Wat je als eerste repareert zodra de nullen op tafel liggen

Begin bij de dimensie met de meeste nullen, en zoek daarbinnen het ene veld of de ene regel waar meerdere nullen op teruggaan. Eén reparatie stroomopwaarts zet vaak twee of drie antwoorden van 0 op 2.

Een paar patronen komen steeds terug.

• Nullen op vraag 5 en 6 hebben meestal één oorzaak: niemand legt vast waar een lead vandaan kwam op het moment dat het record wordt aangemaakt. Maak bron een verplicht veld bij het aanmaken, met een vaste lijst waarden, en zorg dat latere bewerkingen er niet aan kunnen komen. Win rate per bron volgt daar binnen een kwartaal uit.

• Nullen op vraag 1 tot en met 3 wijzen op dealfases zonder instapregels. Schrijf op wat er moet kloppen voordat een deal een fase in mag, laat het CRM dat afdwingen en zet de tijdregistratie per fase aan. Vanaf die dag zie je hoeveel dagen deals in elke fase zitten.

• Nullen op vraag 7 en 8 betekenen dat tools onderweg records laten vallen. Dat is loodgieterswerk voor workflow orchestration, en daar begint ook de meeste lead leakage.

• Een nul op vraag 10 wijst op een probleem met definities, en minder op een dataprobleem. Marketing en sales tellen verschillende dingen. Schrijf dus op wat gekwalificeerd betekent, spreek het af met beide afdelingshoofden en maak er een lifecycleregel van in het CRM.

• Een nul op vraag 4 betekent duplicaten, en die vervuilen elk ander antwoord. Ruim ze op voordat je iets bouwt dat records telt.

Wat je niet als eerste repareert, is de bovenkant van de ladder. Koop je een voorspellende forecasttool terwijl vraag 6 een nul scoort, dan krijg je precies ogende voorspellingen, getraind op win rates die nooit twee keer op dezelfde manier zijn gemeten. De geavanceerde laag leest uit de eenvoudige velden eronder, dus hij kan nooit beter zijn dan die velden.

De bredere bouwvolgorde (strategie, dan gedeelde data, dan overdrachten, dan automatisering) staat in het artikel over de revenue engine. De zelfevaluatie vertelt je bij welke stap van die volgorde je eigen bedrijf vastzit. Stel de twaalf vragen een kwartaal later opnieuw. Een reparatie die werkte, zie je terug als een 0 die een 2 werd, en dat is een veel beter voortgangsrapport dan een nieuw maturitylabel.

Te gul scoren, een fase kopen, het cijfer najagen

Bij het meeste misbruik van een maturity model wil iemand liever een goede uitslag dan een eerlijke.

Te gul scoren komt het vaakst voor. Iemand zegt "dat kunnen we eruit halen" over een vraag die al maanden niemand er echt uit heeft gehaald, en de vraag krijgt een 2. Daarom geldt de regel dat je live antwoordt. Kun je het niet in de kamer laten zien, dan scoort het een 0 of een 1, wat iemand er ook van denkt.

Een fase kopen is de dure variant. Software kan een hogere fase ondersteunen, maar de definities en gewoontes waaruit die fase bestaat, maakt software niet. Een team dat een revenue-intelligencetool toevoegt aan een CRM waarin verliesredenen vrije tekst zijn, heeft een dashboard gekocht voor data die het niet heeft.

Het cijfer najagen is de subtiele variant. Niemand buiten het bedrijf kan het schelen in welke fase je zit. Wat opschuiven oplevert, is concreet: forecasts die standhouden, minder leads die tussen teams verloren gaan, en reps die hun tijd aan deals besteden in plaats van aan het bijwerken van records. Diezelfde opbrengst maakt een volwassen operatie ook moeilijk te kopiëren. Een concurrent kan zich binnen een week aanmelden voor dezelfde tools, maar afgesproken definities en een CRM dat ze afdwingt, bouw je in kwartalen op. Gaat de score omhoog door een maturityproject en verbetert geen van die dingen, dan heeft het project het verkeerde gemeten.

Samenvatting

Hoe bruikbaar een RevOps maturity model is, hangt af van hoe concreet het is. De versie die op meningen draait, levert een slide op. De versie die draait op vragen die je CRM wel of niet kan beantwoorden, levert een lijst velden, regels en rapporten op, en elk daarvan kan iemand in een week of twee bouwen.

De volgorde doet er meer toe dan de bestemming. Definities komen vóór meten, meten komt vóór voorspellen, en de dimensie met de meeste nullen gaat vóór de dimensie waar je het liefst aan werkt. Een fase opschuiven is minder een project dan een reeks kleine reparaties, die elk een onbeantwoorde vraag veranderen in een opgeslagen rapport.

Als die reparaties staan, merkt de rest van het bedrijf het ook. Planning leunt niet langer op onderbuikgevoel, het outboundvolume kan groeien zonder het CRM te overspoelen (het thema van ons stuk over prospectingresearch op de automatische piloot), en elke nieuwe workflow sluit aan op data die al schoon is. Op dat punt wordt een stapel tools een werkend GTM-systeem dat elke dag draait.

Dit werk doet Nebor binnen onze CRM- en RevOps-projecten. We nemen de nullen uit een evaluatie als deze, bouwen de reparaties in de HubSpot- of Salesforce-omgeving van de klant, en laten de rapporten en de onderbouwing achter bij degene die de klim voortzet.

Veelgestelde vragen