De meeste RevOps-implementaties mislukken niet door slechte tools of te weinig budget. Ze mislukken omdat er geen structuur is in de eerste drie maanden. Teams kopen een nieuw CRM, stellen een analyst aan met de titel "RevOps Manager", en verwachten dat alignment vanzelf volgt. Zo werkt het niet.
Ik zie dit patroon telkens terugkomen. Een scale-up besluit dat het RevOps serieus gaat aanpakken. Er wordt een CRM-licentie uitgebreid, een consultant ingehuurd, of een intern iemand aangewezen die "RevOps" op zijn LinkedIn zet. Zes maanden later zijn de tools in gebruik, maar de definities kloppen nog steeds niet, marketing en sales werken nog steeds langs elkaar heen, en de CFO vraagt nog steeds waarom de forecast zo onbetrouwbaar is.
De eerste 90 dagen zijn het fundament. Wat je in die periode goed regelt, bepaalt of RevOps een strategische motor wordt of een rapportage-laag die niemand vertrouwt. Dit is de roadmap.
Waarom de eerste 90 dagen alles bepalen
De vergelijking met een product launch is treffend. Als je een product lanceert zonder gestructureerde go-live, verlies je adoptie en vertrouwen in de eerste weken. Daarna is het moeilijk om dat terug te winnen. Hetzelfde geldt voor RevOps.
De eerste 90 dagen bepalen hoe de rest van de organisatie RevOps ziet. Als marketing, sales en CS in die periode ervaren dat RevOps hen helpt, dat definities worden vastgelegd die hun werk makkelijker maken, en dat rapportages eindelijk kloppen, dan is er draagvlak voor de rest van de transformatie. Als ze in die periode ervaren dat RevOps een extra laag bureaucratie is die hen vraagt om data in te voeren maar zelf weinig oplevert, dan is het vertrouwen beschadigd en moeilijk te herstellen.
De drie meest voorkomende fouten die ik zie in de eerste weken:
- Beginnen met tools in plaats van definities. Het eerste wat een nieuw RevOps-team doet, is een tool demonstratie van een CRM-platform plannen. Maar als de definities van MQL, SQL en Opportunity niet kloppen, maakt het niet uit hoe mooi het platform is.
- Geen stakeholder buy-in. RevOps heeft de medewerking nodig van marketing, sales en CS. Als die teams niet begrijpen wat RevOps doet en waarom het voor hen relevant is, blokkeren ze de implementatie passief of actief.
- Geen duidelijke ownership. Als niemand weet wie de CRM bezit, wie verantwoordelijk is voor datakwaliteit, en wie het laatste woord heeft over lifecycle-definities, dan worden al die beslissingen eindeloos uitgesteld.
Een referentiepunt: Forrester's onderzoek naar RevOps-implementaties toont dat organisaties die de eerste 90 dagen besteden aan alignment en definities, gemiddeld 40% sneller een werkende RevOps-functie hebben dan organisaties die direct met tooling beginnen.
De nulmeting: waar sta je nu? (Week 1 en 2)
Voordat je iets verandert, moet je begrijpen wat er al is. Niet vanuit theorie, maar vanuit een eerlijk beeld van de werkelijke staat van je operations. Dat betekent drie concrete audits.
Datakwaliteitsaudit
Kijk in je CRM. Hoeveel procent van de contactrecords is volledig ingevuld? Wat is de duplicaatgraad? Hoeveel procent van de deals heeft een verwachte sluitdatum? Hoeveel deals staan al langer dan 90 dagen in dezelfde fase? Hoeveel contacten hebben geen e-mailadres?
De meeste scale-ups die ik spreek, denken dat hun CRM-data redelijk is. Na de audit blijkt 30 tot 50% van de records incomplete of verouderde informatie te bevatten. Dat is geen aanklacht: het is de realiteit van een groeiende organisatie die jarenlang mensen heeft laten invullen wat ze wilden.
Lifecycle-definitieaudit
Vraag vijf mensen afzonderlijk: wat is een MQL? Wat is een SQL? Wanneer wordt een deal "Closed Won"? Noteer de antwoorden. In bijna elk geval zijn er twee tot vier verschillende antwoorden, ook als het CRM technisch gezien dezelfde velden heeft. De definities die in de tooling zitten, zijn niet de definities die mensen in hun hoofd hebben.
Dit is geen IT-probleem. Het is een alignment-probleem dat al jaren sluimert en dat RevOps moet oplossen.
Stakeholder-interviews
Plan 30 minuten met de hoofden van marketing, sales en CS. Stel één vraag: wat is het grootste operationele pijnpunt in jouw team? Luister zonder agenda. De antwoorden geven je de prioriteitenlijst voor de eerste maand.
Typische antwoorden: "Sales volgt onze MQL's niet op" (marketing). "De leads van marketing zijn slecht" (sales). "We weten niet wat sales de klant heeft beloofd" (CS). "De forecast klopt nooit" (CEO). Schrijf alles op. Dit is je baseline.
Output van week 1 en 2: een eerlijk beeld van de huidige staat, vastgelegd in een document dat iedereen kan lezen. Geen sugarcoating. Geen uitgebreide PowerPoint. Een directe samenvatting van wat goed gaat, wat niet goed gaat, en wat de drie grootste problemen zijn die RevOps moet oplossen.
Definities en alignment (Week 3 en 4)
Dit is de stap die de meeste teams overslaan. Het is ook de belangrijkste stap. Zonder gedeelde definities is RevOps een lege huls.
Wat je in deze twee weken vastlegt:
- Lifecycle stages: de exacte definitie van elke fase, van anonieme bezoeker tot expanding customer. Welke criteria bepalen de overgang van de ene naar de andere fase?
- Lead-definities: wat is een lead? Wat is een MQL? Wat zijn de minimale criteria? Welke bron-kanalen tellen mee?
- SQL-criteria: welke criteria moet een lead voldoen om door sales geaccepteerd te worden als Sales Qualified Lead? Budget, autoriteit, behoefte, tijdlijn?
- Deal-stages: welke stadia doorloopt een opportunity in het CRM? Wat is de definitie van elke fase? Welke activiteiten of mijlpalen hoort daarbij?
- Closed Won en Closed Lost: wanneer is een deal gewonnen? Wanneer verloren? Welke redenen voor verlies worden bijgehouden?
- Verplichte velden per fase: welke data is verplicht om een deal van fase A naar fase B te laten gaan?
Het format: een workshop van drie tot vier uur met de leads van marketing, sales en CS samen in één sessie. Niet afzonderlijk. De waarde zit in het gezamenlijk bespreken en betwisten van definities, niet in het afstemmen van afzonderlijk opgestelde documenten.
Het eindproduct is een definitie-document van twee tot vijf pagina's dat iedereen heeft gezien en goedgekeurd. Niet ondertekend in de juridische zin, maar expliciet akkoord gegaan. Dit document is het fundament van alles wat daarna komt. Als de definities in het CRM later afwijken van dit document, weet je wat je moet aanpassen.
Output van week 3 en 4: een goedgekeurd definitie-document, klaar voor implementatie in het CRM.
Tech stack audit en data cleanup (Maand 2)
Nu de definities vast staan, is het tijd voor de technische basis. Maand twee bestaat uit twee parallelle trajecten: de tech stack beoordelen en de bestaande data opschonen.
Tech stack review
Loop door de volledige lijst van tools die de drie omzetteams gebruiken. Voor elke tool: wat is het doel? Wie is de eigenaar? Hoe integreert het met het CRM? Wordt het actief gebruikt?
Typisch vind je in deze audit tools die niemand meer gebruikt maar waarvoor het abonnement nog loopt, tools die dezelfde functie hebben als andere tools in de stack, en integraties die halfzijdig zijn opgezet en data op één manier syncen maar niet terug.
Dit is niet het moment om grote beslissingen te nemen over welke tools je vervangt. Het is het moment om een eerlijk overzicht te hebben van wat er is, wat het kost, en wat het doet. De meeste organisaties zijn verrast hoe groot hun stack is en hoe weinig ze hem begrijpen.
CRM-hygiene
Op basis van de definities uit week 3 en 4 en de datakwaliteitsaudit uit week 1 en 2, begin je met de cleanup van het CRM:
- Duplicaten samenvoegen. Gebruik de ingebouwde deduplicatiefunctie van je CRM of een externe tool zoals Dedupely voor HubSpot. Stel daarna automatische deduplicatieregels in.
- Verplichte velden instellen. Configureer het CRM zo dat de verplichte velden per lifecycle stage en deal stage daadwerkelijk verplicht zijn bij het doorschuiven van een record.
- Verouderde records archiveren. Deals die al twee jaar staan met geen activiteit: archiveer ze. Contacten zonder e-mailadres en zonder activiteit van meer dan 18 maanden: archiveer ze. Een schone database is meer waard dan een grote database.
- Lifecycle stages corrigeren. Pas de bestaande records aan op basis van de nieuwe definities. Dit is handmatig werk, maar het moet een keer gebeuren.
Eerste geïntegreerde rapportage
Aan het einde van maand twee bouw je de eerste geïntegreerde rapportage: een pipeline-view die loopt van eerste marketing-touchpoint tot CS-retentie in één overzicht. Nog niet perfect. Nog niet compleet. Maar werkend en vertrouwd door de drie teams. Dit is de eerste keer dat iedereen dezelfde getallen ziet op hetzelfde scherm.
Output van maand 2: een functionerende basisinfrastructuur, een schoner CRM, en een eerste gedeeld dashboard.
Governance en reporting (Maand 3)
In de derde maand bouw je de routines en verantwoordelijkheden die RevOps duurzaam maken. Want RevOps is niet een project met een einddatum. Het is een operationele functie die permanent onderhoud vereist.
De RevOps-cadans
Stel een vaste vergaderstructuur in die de drie teams verbindt:
- Weekly pipeline review: 30 minuten, sales en RevOps. Welke deals zijn vooruit gegaan? Welke zijn vastgelopen? Wat is de pipeline coverage voor het lopende kwartaal?
- Monthly reporting meeting: 60 minuten, marketing, sales, CS en leadership. Alle drie de teams presenteren hun key metrics. Eén versie van de waarheid.
- Quarterly OKR review: hoe verhoudt de operationele performance zich tot de kwartaaldoelen? Wat gaan we anders doen in het volgende kwartaal?
Metric-eigenaarschap
Definieer wie welke metrics bezit. Niet wie ze rapporteert, maar wie verantwoordelijk is voor de kwaliteit van de meting en voor acties als de metric buiten de verwachte range valt:
- MQL-volume en MQL-kwaliteit: Marketing
- SQL-acceptatierate: Sales, met input van Marketing
- Pipeline coverage en win rate: Sales
- Time-to-close: Sales Operations / RevOps
- Onboarding completion rate: Customer Success
- NRR en churn rate: Customer Success
- CAC en CAC payback: RevOps, samen met Finance
SLA's tussen marketing en sales
Leg vast: binnen hoeveel uur volgt sales een MQL op? Wat is de maximale tijd voordat een MQL terugkeert naar marketing als "niet geaccepteerd"? Wat is de verplichte feedback die sales geeft bij een afgewezen MQL? Hoeveel touchpoints zijn minimaal vereist voor een SQL die "Closed Lost" wordt?
SLA's klinken formeel, maar ze zijn het praktische mechanisme dat de MQL-SQL-handoff werkend houdt. Zonder SLA's is er geen basis voor het gesprek als het fout gaat.
Drie kernse dashboards
Bouw drie dashboards die elke stakeholder kan lezen:
- Marketing health dashboard: traffic, MQL-volume, MQL-kwaliteit, attributie per kanaal, kosten per MQL.
- Sales pipeline dashboard: pipeline per fase, coverage, win rate, average deal size, time-to-close, forecast versus actual.
- CS retention dashboard: onboarding completion, health scores per segment, NPS, churn rate, expansion revenue, NRR.
Output van maand 3: een lopend systeem met vaste routines, duidelijke verantwoordelijkheden, en dashboards die door de hele organisatie worden vertrouwd.
De meest gemaakte fouten
Na de roadmap: de vijf fouten die ik het vaakst zie in RevOps-implementaties, en hoe je ze vermijdt.
1. Beginnen met tools, niet met definities. Tools zijn het laatste wat je configureert, niet het eerste. Als de definities niet kloppen, maakt het niet uit hoe goed de software is. Sla de definitie-workshop niet over.
2. RevOps als IT-project behandelen. RevOps is een business-transformatie, geen CRM-implementatie. Het succes hangt af van gedragsverandering bij de drie teams, niet van de correcte configuratie van een tool. Als RevOps alleen als IT-project wordt gezien, krijgt het nooit het mandate om de processen te veranderen die de problemen veroorzaken.
3. Te weinig mandate voor de RevOps-functie. Als de RevOps Manager geen bevoegdheid heeft om beslissingen te nemen over definities, processen en tool-configuratie, is hij of zij een rapportage-analist. RevOps heeft het mandate nodig om te zeggen: "De definitie van MQL is dit, en dat is niet ter discussie."
4. Te snel te veel willen. De meest ambitieuze RevOps-plannen die ik zie, falen het vaakst. Niet omdat de ambities verkeerd zijn, maar omdat ze te veel hooi op de vork nemen in de eerste maanden. Begin klein. Leg het fundament goed. Bouw van daaruit.
5. Geen sponsorship vanuit de directie. Als de CEO of COO niet actief achter RevOps staat, heeft het geen schijn van kans. De eerste keer dat marketing en sales het oneens zijn over een lifecycle-definitie, trekt iedereen naar zijn eigen silo terug als er geen directie-level sponsor is die de beslissing dwingt.
Wat als je geen RevOps-manager kunt aannemen?
Niet elk bedrijf heeft de budget of de fase om een fulltime RevOps Manager aan te nemen. Dat is geen belemmering om met RevOps te beginnen, maar het vereist een andere aanpak.
De eerste optie is fractional RevOps: een ervaren RevOps-professional die twee of drie dagen per week beschikbaar is om de implementatie te leiden. Dit is effectief in de eerste 90 dagen, wanneer de zware definitie- en architectuurbesluiten worden genomen. Na de fundament-fase kan een intern iemand het onderhoud overnemen. Zie interim GTM-ondersteuning voor hoe dit in de praktijk werkt.
De tweede optie is minimum viable RevOps: één intern iemand die de CRM bezit en verantwoordelijk is voor de definities, aangevuld met een gedeeld definitie-document dat door alle teams is goedgekeurd. Dat is al een fundamentele verbetering ten opzichte van de situatie waarbij niemand verantwoordelijk is voor de data.
Wat in elk geval niet werkt: RevOps "erbij doen" als extra verantwoordelijkheid voor iemand die al een fulltime functie heeft. RevOps vereist focus, eigenaarschap en beslisbevoegdheid. Die drie dingen zijn moeilijk te combineren met een bestaande rol.
Wil je meer weten over hoe je RevOps opbouwt? Lees het artikel over wat RevOps eigenlijk is en het vergelijkingsartikel over RevOps versus Sales Operations. Of doe de GTM Scan voor een beeld van de bottlenecks in jouw specifieke situatie.