Het Revenue Operations (RevOps) organogram voor 2026

"De beste structuur garandeert geen resultaten en prestaties. Maar de verkeerde structuur is een garantie voor mislukking." - Peter Drucker

Snel vooruitspoelen naar twee jaar nadat ik ze achterliet in het boek. MyGym24 - het fictieve bedrijf in fitnesssoftware dat ik gebruik om dit concreet te maken - haalde een Series A op in Berlijn-Mitte, en de gok betaalde zich uit. Ze haalden opnieuw kapitaal op. Het commerciële team groeide van een handvol mensen naar zo'n vijfendertig medewerkers in sales, marketing en customer success.

En Maria, hun Head of RevOps, verdrinkt in het werk.

Ze is nog steeds de complete RevOps-functie in haar eentje. Eén persoon. Er wordt van haar verwacht dat ze de strategie bepaalt, de data opschoont, het CRM-systeem beheert, de automatisering ontwerpt, de dashboards bouwt, enablement verzorgt en - nieuw dit jaar - de AI-roadmap uitstippelt. In een goede week doet ze twee van die dingen goed. De rest blijft liggen.

Dit is het moment waarop de vraag verandert. In het begin is de vraag: "hebben we überhaupt wel RevOps nodig?" Vanaf een bepaalde omvang wordt het: "hoe richten we het in?" Als je 20 tot 50 FTE's in je commerciële functies hebt, ben je op dat punt aanbeland. Laten we dus het organogram voor revenue operations gaan bouwen.

Waarom dit moeilijker is in 2026

Het is moeilijker vanwege AI, en niet op de manier die de meeste mensen denken.

In ons wereldwijde RevOps-onderzoek onder 123 experts meldde driekwart van de bedrijven een AI-mandaat vanuit de directie. Slechts ongeveer een derde had de data-infrastructuur om dit te ondersteunen. Die kloof - een mandaat zonder het fundament eronder - is geen toolingsprobleem dat je kunt oplossen door software te kopen. Het is een probleem van organisatie-ontwerp. Iemand moet de data beheren. Iemand moet de systemen en de AI daarbovenop beheren. Iemand moet het proces en de mensen beheren. En dat is niet dezelfde persoon.

En dat is precies het hele idee achter de onderstaande teamstructuur voor revenue operations.

Start vanuit de pijlers

RevOps heeft vier pijlers: Data & Insights, Processen, Systemen en Enablement. Een goed organogram bestaat simpelweg uit deze pijlers met de namen van de verantwoordelijken erbij. Krijg de pijlers goed en de vakjes tekenen zichzelf. Krijg je ze verkeerd - één persoon die alle vier beheert, of enablement dat ergens los rondzweeft - en je krijgt een situatie zoals die van Maria.

Dit is hoe ik het gewicht zou verdelen.

Head of RevOps - proces en enablement

Dit is jouw generalistische functie, en "generalist" is geen belediging. De Head of RevOps geeft leiding aan een team van specialisten - één per domein dat daadwerkelijk van toepassing is op jouw bedrijf (sales ops, marketing ops, CS ops, partner ops; alleen de rollen die je echt nodig hebt). Hun focus ligt op strategie, proces en enablement.

Enablement - content, training, onboarding - hoort hier thuis, bij de generalisten. Niet als een losse, opzichzelfstaande aanstelling.

Ik zeg dit heel duidelijk, want ik heb het elke keer weer zien mislukken: neem geen pure enablement-specialist aan die geen RevOps-vaardigheden heeft. Ze produceren presentaties die niemand gebruikt en trainingen die losstaan van hoe het proces daadwerkelijk verloopt. Enablement werkt alleen als het gekoppeld is aan iemand die het systeem begrijpt dat de mensen moeten gebruiken.

Belangrijkste vaardigheden voor deze rol: stakeholdermanagement, strategisch denken, communicatie. Deze persoon brengt zijn dag door met mensen, niet in de terminal.

Head of Systems - tooling, automatisering en AI

Dit hoofd is eigenaar van de tech stack. Rapporterend aan hen:

• Een expert in tooling en automatisering die de systemen draaiende en gekoppeld houdt.

• Een AI Operations-rol die AI-use cases ontwerpt en de AI-stack beheert - dit is inmiddels een echte baan, geen zijproject.

• Een software engineer die maatwerkoplossingen bouwt en onderhoudt.

Die laatste rol is waar mensen zich vaak tegen verzetten, dus laat me direct zijn: in 2026 ga je bouwen, niet alleen kopen. De interessante GTM-voordelen zitten niet meer in een standaard kant-en-klare tool. En ja, met "vibe coding" heb je in een weekend een prototype. Maar het levert je niets op waar je commerciële team daadwerkelijk het bedrijf op kan runnen. Een prototype dat stilletjes het productiesysteem wordt, is een tikkende tijdbom. Als je gaat bouwen, laat het dan door een echte engineer doen.

Dit is ook waar AI binnen GTM leeft. RevOps is hier de eigenaar van. Uit ons CRO-onderzoek: zonder eigenaarschap van RevOps zorgt AI voor meer ruis in plaats van impact. AI gekoppeld aan een rommelig systeem produceert alleen maar sneller verkeerde antwoorden.

Belangrijkste vaardigheden: zeer technisch, sterke focus op AI.

Head of Data - de motor

Data is onderdeel van RevOps. Niet een gunst die je aan het centrale datateam vraagt, geen driemaandelijkse export. Een Head of Data die een datateam aanstuurt, binnen RevOps, rapporterend aan de functie.

Waarom trekken we hier zo strak de grens? Omdat data is wat de omzet zal aanjagen - pipeline scoring, voorspelling van churn, capaciteitsmodellen, de input waar elke AI-use case van afhankelijk is. Denk aan het onderzoek: de bedrijven die winnen met AI zijn het derde deel dat de data op orde heeft. Die groep is daar niet gekomen door af en toe data te lenen wanneer het hen uitkwam.

Belangrijkste vaardigheden: sterke focus op data, machine learning (ML) engineering.

VP of RevOps - de spil

Drie hoofden die drie verschillende kanten op trekken, vormen geen systeem. Het zijn drie afdelingen die toevallig dezelfde naam delen.

De VP (Vice President) of RevOps is het spilfiguur - het punt waar de hele teamstructuur van revenue operations om draait. Zij orkestreren: data voedt systemen, systemen ondersteunen processen, processen zijn wat enablement overbrengt, en dit alles is gericht op omzet. Zonder deze spil heb je gewicht zonder hefboom. Met spil verzet dezelfde kracht iets dat vele malen groter is dan zichzelf.

Wat dit je oplevert

Ik raad deze B2B SaaS organogram-opzet aan voor bedrijven met 20 tot 50 FTE's in commerciële functies. Daaronder is het te zwaar - je hebt geen drie hoofden nodig om vijftien verkopers te ondersteunen.

In mijn werk met klanten zorgt een structuur als deze ervoor dat een bedrijf zijn commerciële team met een factor 3 tot 5 kan opschalen zonder een enkele extra ops-medewerker aan te nemen. De ops-functie schaalt niet langer lineair mee met de salesafdeling. En het commerciële team zelf wordt aanzienlijk efficiënter - ergens tussen de 2x en 10x, afhankelijk van hoe slecht de zaken ervoor stonden toen je begon. Dit zijn indicaties op basis van wat ik heb gezien, geen garanties. De rest is uitvoering.

Dit is bovendien slechts één van de levensvatbare opties. Een bedrijf met veel partneractiviteiten of meerdere regio's in verschillende groeifasen zal de accenten anders leggen. Het principe blijft echter overeind, ook als de vakjes verschuiven: verdeel de vier pijlers, geef elk een echte eigenaar en zet een spil in het midden.

Structuur is het skelet. De moeilijkere vraag - de vraag die ik meteen krijg zodra iemand dit schema ziet - is de volgorde: als je dit niet allemaal tegelijk kunt aannemen, wie komt dan eerst? Dat is stof voor een volgend artikel.

Socratische reflecties

• Hoeveel mensen werken er vandaag in jouw ops-functie, afgezet tegen jouw commerciële personeelsbestand? Schaalt de verhouding mee met de salesafdeling, of staat deze er los van?

• Is er van de vier pijlers - data, systemen, proces, enablement - momenteel één waar niemand eigenaar van is?

• Als je GTM-team morgen de opdracht krijgt om AI te implementeren, wie is dan verantwoordelijk voor de uitrol? Zijn zij ook eigenaar van de data waarop het draait?

• Ligt jouw enablement bij iemand die daadwerkelijk ervaring heeft met een RevOps-domein - of bij iemand die trainingen ontwikkelt in een vacuüm?

• Wie is jouw spil? En als het eerlijke antwoord "niemand" is, wat houdt je functies dan momenteel bij elkaar?