Revenue Intelligence voor MSP's

Revenue Intelligence voor MSP's is het doorlopend naast elkaar leggen van wat je beheert, wat je inkoopt en wat je factureert: de devices en gebruikers in je RMM en PSA, de licenties bij je leveranciers en distributeurs, de tickets en uren die je team besteedt, en de contracten en facturen per klant. Elke afwijking tussen die bronnen is ofwel een kostenpost die je niet doorbelast, ofwel een dienst die je levert zonder dat de klant ervoor betaalt. Bij een MSP met honderden klanten en duizenden licenties zijn dat er altijd meer dan je denkt.

Een managed service provider heeft een ongewoon verdienmodel. Het grootste deel van de omzet is terugkerend en voorspelbaar, maar de onderliggende hoeveelheden veranderen elke maand: gebruikers komen en gaan, devices worden vervangen, licenties worden toegevoegd, leveranciers passen hun prijzen aan. Wie de facturatie niet elke maand laat aansluiten op die werkelijkheid, lekt. Niet één keer, maar elke maand opnieuw.

Hoe een MSP omzet maakt

Elke stroom heeft een eigen bron voor de hoeveelheid en een eigen route naar de factuur. De managed services worden gefactureerd op basis van een aantal dat in het contract of de PSA staat. De licenties op basis van wat de distributeur factureert, of wat iemand heeft ingevoerd. Het werk buiten contract op basis van tickets die als factureerbaar zijn gemarkeerd. Als die bronnen niet met elkaar worden vergeleken, gaan ze uit elkaar lopen.

De vier vergelijkingen

Revenue Intelligence voor een MSP komt neer op vier vergelijkingen die elke maand moeten sluiten.

1. Wat je beheert tegen wat je factureert

Het aantal devices met een actieve agent in je RMM, het aantal gebruikers in de omgeving van de klant, het aantal locaties. Leg dat naast het aantal waarvoor de klant betaalt volgens het contract. Als je 140 devices beheert en er 120 factureert, lever je twintig devices gratis.

Dit verschil ontstaat bijna altijd geleidelijk. De klant neemt mensen aan, er komen laptops bij, iemand van jouw team installeert de agent zoals het hoort. Het contract wordt niet aangepast, omdat niemand het signaal doorgeeft aan wie de facturatie bijhoudt. Andersom komt ook voor: devices die al maanden offline zijn, maar nog wel worden gefactureerd. Dat is geen lekkage, maar wel een risico voor de relatie dat je liever zelf ontdekt.

2. Wat je inkoopt tegen wat je doorverkoopt

Voor elke licentie die je doorverkoopt, betaal je je leverancier of distributeur. Het aantal licenties dat je inkoopt, moet overeenkomen met het aantal dat je factureert, plus eventuele licenties die je bewust voor eigen gebruik of als buffer aanhoudt.

In de praktijk sluit dit zelden. Licenties worden toegevoegd in het portaal van de leverancier zonder dat de facturatie wordt bijgewerkt. Een klant schakelt over naar een duurder pakket, en je factureert het oude. Een medewerker vertrekt bij de klant, de licentie wordt bij de klant niet meer gefactureerd, maar blijft bij de leverancier doorlopen. Dit is het terrein van SaaS billing leakage bij MSP's, waar het in detail wordt behandeld.

3. Wat je doet tegen wat onder het contract valt

Elk managed-servicecontract heeft een scope. Wat erbuiten valt, wordt apart gefactureerd: projecten, werk aan systemen die niet onder beheer vallen, verhuizingen, trainingen, soms werk buiten kantooruren. In de praktijk wordt de grens ruim uitgelegd. Een engineer die een ticket oppakt, kijkt niet in het contract. Hij lost het op.

De vergelijking: tickets per klant naar categorie, naast de scope van het contract. Welke tickets hadden als factureerbaar gemarkeerd moeten worden? Welke klanten kosten structureel meer uren dan het contract dekt?

4. Wat je contracten zeggen tegen wat je factureert

Het contract noemt een prijs per eenheid, een indexatieregeling, een looptijd en soms een minimumafname. Wordt de indexatie jaarlijks doorgevoerd? Worden prijsverhogingen van leveranciers doorbelast als het contract dat toestaat? Klopt de prijs per eenheid op de factuur met die in het contract? Het algemene patroon van terugkerende omzet die niet klopt, staat in hoe ontdek je fouten in terugkerende omzet.

Waar de gegevens staan

Een MSP heeft veel systemen, en de meeste zijn goed gestructureerd. Dat is een voordeel: de vergelijkingen zijn technisch goed te maken.

Het probleem is niet dat de gegevens ontbreken. Het probleem is dat ze in zes of meer systemen staan, met elk een eigen klantnummer en een eigen manier van tellen. Het naast elkaar leggen vergt dat je klanten, producten en eenheden tussen systemen aan elkaar koppelt. Dat is eenmalig werk, maar het moet wel gebeuren.

De lekken, in het kort

De afzonderlijke lekken staan uitgewerkt in revenue leakage bij MSP's. Hier het overzicht:

1. Devices en gebruikers boven het contract. De klant groeit, het contract niet.
2. Licenties ingekocht maar niet gefactureerd. Toegevoegd bij de leverancier, niet bij de klant.
3. Licenties op het verkeerde niveau. De klant gebruikt een duurder pakket dan je factureert.
4. Prijsverhogingen van leveranciers niet doorbelast. De inkoopprijs stijgt, de verkoopprijs niet.
5. Werk buiten scope als contractwerk afgehandeld. Het ticket wordt opgelost, niet gefactureerd.
6. Urenbundels die ongemerkt worden overschreden. De bundel is op, het werk gaat door.
7. Projecten met onboarding en migratie die over budget gaan. De vaste prijs was te laag of de scope groeide.
8. Contracten zonder indexatie. De prijs staat nog op het niveau van jaren geleden.
9. Verplichtingen bij de leverancier die niet aansluiten op de klant. Je hebt een jaarverplichting bij de leverancier, de klant kan maandelijks opzeggen.
10. Hardware zonder marge of zonder factuur. Een vervangende laptop gaat de deur uit en wordt niet gefactureerd.

Rekenvoorbeeld

Rekenvoorbeeld: stel, een MSP met EUR 4 miljoen omzet en 150 klanten. De omzet bestaat uit EUR 2 miljoen managed services, EUR 1,4 miljoen doorverkochte licenties en EUR 600.000 projecten en werk buiten contract.

Dat is ongeveer 3,8 procent van de omzet. Het bedrag voor licenties is gebaseerd op de inkoopwaarde: bij een doorverkoopmarge komt het gemiste omzetbedrag hoger uit. En omdat alles terugkerend is, kost elk van deze lekken hetzelfde bedrag volgend jaar opnieuw als het niet wordt rechtgezet.

De aannames zijn illustratief. Voor lekkage bij MSP's bestaat geen betrouwbaar branchegemiddelde. Wat het voorbeeld laat zien, is waar het accent ligt: bij de meeste MSP's zit het grootste bedrag in het verschil tussen wat wordt beheerd en wat wordt gefactureerd.

Signalen dat je MSP lekt

Een paar signalen komen bij MSP's zo vaak voor dat ze bijna altijd op lekkage wijzen:

1. De licentiemarge schommelt per maand zonder duidelijke reden. Als inkoop en verkoop elke maand in dezelfde verhouding zouden bewegen, is de marge stabiel. Schommelingen betekenen dat de twee niet synchroon lopen.
2. Het aantal beheerde devices groeit sneller dan de managed-serviceomzet. Dan komen er devices bij zonder dat de contracten meegroeien.
3. Engineers zeggen dat bepaalde klanten "altijd bellen". Klanten die veel tickets aanmaken, kosten meer dan hun contract. De vraag is of dat werk binnen de scope valt.
4. De backoffice past de facturatie aan op verzoek, niet op signaal. Als een klant belt dat een medewerker is vertrokken, wordt de factuur aangepast. Als er een medewerker bij komt, belt niemand.
5. Niemand weet uit zijn hoofd wanneer de contractprijzen voor het laatst zijn aangepast. Dan is dat waarschijnlijk te lang geleden.

Het vierde signaal is het belangrijkste. Het laat een asymmetrie zien die in bijna elke MSP bestaat: afnames worden snel verwerkt, omdat de klant erom vraagt. Toenames worden traag verwerkt, omdat niemand erom vraagt. Die asymmetrie is op zichzelf al genoeg om elke maand omzet te verliezen.

Waarom een PSA dit niet vanzelf oplost

Een goede PSA brengt veel samen: tickets, contracten, uren, en vaak ook de facturatie. Waarom sluit het dan niet?

De PSA factureert wat erin staat. Als het aantal devices in het contract op 120 staat, factureert hij 120. Dat de RMM er 140 ziet, is een andere module, en het aanpassen van het contract is een handeling die iemand moet doen.

Licenties staan niet in de PSA, of met vertraging. Leveranciersportalen zijn vaak wel te koppelen, maar niet altijd volledig. En een koppeling die de hoeveelheid ophaalt, zegt nog niet of de verkoopprijs klopt.

De scope van een contract staat in een document, niet in een veld. De PSA weet dat een klant een contract heeft. Welke systemen, welke soorten werk en welke tijden erin vallen, staat vaak in een pdf. Een engineer die een ticket oppakt, ziet dat niet.

Niemand vergelijkt. Het grootste probleem is organisatorisch. De service desk lost tickets op, de accountmanager verkoopt, de backoffice factureert. Niemand heeft als taak om elke maand te controleren of de vier vergelijkingen sluiten.

Revenue Intelligence neemt precies die taak over: de systemen samen lezen en de verschillen op een lijst zetten, met per klant een bedrag. Het vervangt de PSA en de RMM niet. Wat Revenue Intelligence in het algemeen is, lees je in wat is Revenue Intelligence.

Verwante patronen buiten de MSP-wereld

Veel van deze patronen komen ook voor bij bedrijven die zelf software verkopen op abonnementsbasis. De mechanismen zijn vergelijkbaar: hoeveelheden die veranderen zonder dat de facturatie meebeweegt, prijsniveaus die niet kloppen met het werkelijke gebruik. Voor wie dat verder wil lezen: SaaS billing leakage behandelt het vanuit de softwareleverancier, en revenue leakage door verkeerde abonnementen vanuit het abonnement zelf.

Aanpak in vijf stappen

Stap 1: koppel je klanten tussen systemen

Maak een tabel waarin elke klant één regel heeft, met het klantnummer in elk systeem: PSA, RMM, elk leveranciersportaal, de facturatie. Dit is het saaie deel en het belangrijkste. Zonder deze koppeling kun je niets vergelijken.

Stap 2: vergelijk devices en gebruikers

Per klant: aantal actieve devices in de RMM, aantal gebruikers in de omgeving, aantal volgens het contract, aantal gefactureerd. Kies een definitie van actief, bijvoorbeeld gezien in de afgelopen dertig dagen, en houd die consequent aan.

Stap 3: vergelijk licenties

Per klant per licentietype: aantal bij de leverancier, aantal gefactureerd, inkoopprijs, verkoopprijs. Elke regel waar het ingekochte aantal hoger is dan het gefactureerde, of waar de verkoopprijs onder de inkoopprijs plus je beoogde marge ligt, is een bevinding.

Stap 4: analyseer tickets buiten scope

Neem de tickets van drie maanden. Laat iemand die de contracten kent een steekproef beoordelen: viel dit binnen de scope? Extrapoleer naar een jaar. Kijk ook welke klanten structureel meer uren kosten dan hun contract rechtvaardigt.

Stap 5: maak het maandelijks, of doorlopend

De eerste vier stappen zijn een nulmeting. De waarde zit in herhalen. Omdat de onderliggende aantallen elke maand veranderen, is een jaarlijkse controle te traag: in een jaar lopen ze weer uit elkaar. Veel MSP's bouwen deze vergelijking met exports en een spreadsheet, en merken dat het na een paar maanden niet meer wordt bijgehouden. Doorlopende bewaking, waarbij de systemen zelf worden gekoppeld, voorkomt dat. RiOS is een platform dat daarvoor wordt gebouwd: het is in bèta, koppelt aan bestaande systemen, bewaakt omzetlekkage doorlopend en is geprijsd per bedrijf, niet per gebruiker. Welke systemen het koppelt, staat op de systeempagina.

Controlelijst

1. Is er per klant een koppeling tussen PSA, RMM, leveranciersportalen en facturatie?
2. Hoeveel devices beheren we in totaal, en hoeveel factureren we?
3. Hoeveel licenties kopen we in, per type, en hoeveel factureren we?
4. Zijn de prijsverhogingen van onze leveranciers van het afgelopen jaar doorgevoerd bij onze klanten?
5. Wanneer zijn onze managed-servicecontracten voor het laatst geïndexeerd?
6. Welk percentage van de tickets wordt als factureerbaar gemarkeerd, en is dat de afgelopen jaren veranderd?
7. Welke klanten kosten structureel meer uren dan hun contract dekt?
8. Welke urenbundels zijn overschreden zonder nieuwe bundel of factuur?
9. Welke licenties hebben bij de leverancier een langere verplichting dan bij de klant?
10. Wie is eigenaar van de maandelijkse aansluiting?

Veelgestelde vragen

Waarom lekt een MSP meer dan een gewone IT-leverancier?

Omdat de omzet bestaat uit hoeveelheden die elke maand veranderen: gebruikers, devices, licenties. Elke verandering moet in de facturatie worden verwerkt. Een leverancier die eenmalig verkoopt, heeft dat probleem niet.

Is een PSA met geïntegreerde facturatie niet genoeg?

Het helpt, maar het lost het niet op. De PSA factureert wat in de contracten staat. De lekkage ontstaat doordat de contracten niet worden bijgewerkt als de werkelijkheid verandert. Daarvoor moet je de PSA naast de RMM, de leveranciersportalen en de omgeving van de klant leggen.

Hoe vaak moet je licenties aansluiten?

Maandelijks, bij elke factuurronde. Licenties veranderen voortdurend, en een verschil dat een maand blijft staan, kost een maand aan marge. Bij grote klanten met veel wisselingen is vaker controleren zinvol.

Wat doe je met devices die wel beheerd worden maar niet in het contract staan?

Bespreek het met de klant. Meestal is het een logisch gevolg van groei, en past het contract zich daarop aan. Leg vooraf in je contracten vast hoe dat werkt, bijvoorbeeld een maandelijkse telling op basis van je RMM, zodat het geen onderhandeling wordt.

Waar begin je als je dit nog nooit hebt gedaan?

Bij de licenties van je grootste leverancier. Het is een afgebakende vergelijking, de gegevens zijn goed beschikbaar, en elk verschil is direct geld. Daarna de devices, daarna de tickets.