Business Brief
Waarom mkb-MSPs marge verliezen terwijl hun omzet groeit
Engineering-uren per klant per maand is de variabele die de meeste eigenaren niet sturen.
Veel mkb-MSPs zien hun omzet groeien terwijl hun marge stilstaat of erodeert. De oorzaak zit zelden in pricing of klantmix — die zit in één variabele die de meeste eigenaren niet structureel sturen: het aantal engineering-uren per klant per maand. Zolang die variabele meegroeit met de omzet, schaalt het personeelsmodel mee in plaats van het bedrijf. Operationele automatisering haalt herhalend werk uit dat model en is daarmee de meest directe EBITDA-hefboom die een mkb-MSP vandaag heeft.
1. De marge-paradox bij groeiende MSPs
Het patroon is bij groeiende mkb-MSPs opvallend consistent. De omzet stijgt jaar op jaar — nieuwe klanten, nieuwe contracten, uitbreiding van bestaande overeenkomsten. Op papier is het bedrijf gezond. Maar de marge beweegt amper. Soms staat hij stil. Soms erodeert hij langzaam. En de eigenaar weet niet precies waarom.
De gangbare verklaringen zijn allemaal plausibel. De arbeidsmarkt is duur. Klanten onderhandelen scherper. Tooling-kosten lopen op. Compliance vraagt meer tijd. Allemaal waar — maar geen van die factoren verklaart waarom een MSP die op alle drie de fronten goed gemanaged is, alsnog dezelfde paradox ervaart.
Wat zich werkelijk afspeelt, is een schaalbaarheidsprobleem in het verkeerde deel van de waardeketen. De omzetkant van de business schaalt. De leveringskant niet. Elke nieuwe klant brengt zijn eigen incidentpatroon mee, en dat patroon wordt grotendeels handmatig afgehandeld door engineers. Meer klanten betekent meer incidenten, en meer incidenten betekent meer uren. Niet pro rata — meestal sneller dan pro rata, omdat incidenttypes elkaar kruisen en escaleren in een grotere portefeuille.
Het gevolg: het personeelsmodel groeit mee met de omzet. En zodra je personeel evenredig met omzet schaalt, ben je de facto geen schaalbaar bedrijf meer. Je bent een tijd-voor-geld-dienstverlener met een SaaS-laag eromheen. De marge die je in jaar één had bij 30 klanten, is bij 80 klanten dezelfde — of lager — ondanks alle technologie-investeringen.
2. De dominante variabele: engineering-uren per klant per maand
Er is één metriek die deze paradox verklaart, en die de meeste mkb-MSPs niet structureel meten of sturen: engineering-uren per klant per maand. We noemen die hier kortweg EKM. Het is het totaal aantal engineering-uren dat een klant per maand verbruikt — reactief op tickets, proactief op monitoring-events, en alles ertussenin.
EKM is niet hetzelfde als gefactureerde uren. Het is alle engineering-tijd die je portefeuille daadwerkelijk opslokt, ongeacht of die in een factuur terechtkomt. Het is de meest directe maat voor wat je klantenbestand kost in personeelsinzet. En in een bedrijf waar personeel veruit de grootste kostenpost is, is EKM daarmee feitelijk de variabele die je brutomarge en EBITDA bepaalt.
Wat EKM bijzonder maakt als stuurvariabele: het is een van de weinige metrieken die structureel benvloedbaar is door productbeslissingen, niet door commerciële beslissingen. Pricing kun je opschroeven, maar dat wordt door de markt teruggeduwd. Klantmix kun je aanpassen, maar dat is een traag proces. EKM kun je verlagen door werk uit het personeelsmodel te halen — en dat effect is structureel en cumulatief.
Tegenargument: “Is pricing niet belangrijker?”
Een veelgehoorde reactie: prijs verhogen lost het marge-probleem ook op. Klopt — tijdelijk. Een prijsverhoging van 10% verbetert je marge in het lopende contractjaar. Maar het effect is eindig: klanten compenseren bij renewal, concurrenten passen pricing aan, en bij elke nieuwe klant begint de onderhandeling opnieuw.
Een EKM-verlaging van 25% werkt anders. Het effect is structureel: het reist mee met elke nieuwe klant die je aansluit. Het verbetert niet alleen de marge op je bestaande portefeuille — het verlaagt de marginale leveringskost van elke volgende klant, en daarmee de schaalvoet van je hele bedrijf.
Prijs verhoog je één keer. EKM verlaag je structureel.
Dat maakt EKM niet de enige variabele die telt. Pricing-discipline, klantselectie en contractkwaliteit zijn allemaal relevant. Maar het zijn aanvullende hefbomen op een marge-structuur die uiteindelijk door EKM wordt bepaald.
3. Waarom traditioneel kostenbeheer dit niet vangt
De meeste mkb-MSPs sturen op kost-per-klant, omzet-per-klant (ARPC) en bezettingsgraad van engineers. Goede metrieken — maar ze missen de essentie. Ze rapporteren wat er gebeurt, niet waarom de marge stagneert.
Kost-per-klant is een uitkomstmaat. Je weet pas achteraf wat een klant je heeft gekost, en dan is het te laat om er iets aan te doen. ARPC zegt iets over commerciële sterkte, niet over leveringskosten. Bezettingsgraad meet of je engineers druk zijn, maar niet of die drukte iets oplevert: een 90% bezette engineer die L1-tickets afhandelt levert minder waarde dan een 60% bezette engineer die aan klantarchitectuur werkt.
EKM is een procesmaat: het meet de leveringsintensiteit per klant, en het is leidend in plaats van volgend. Een dalende EKM bij gelijke ARPC betekent margeverbetering — voordat de jaarrekening die laat zien. Een stijgende EKM is een vroegtijdig waarschuwingssignaal: er is iets in de portefeuille waardoor de leveringskost oploopt, en dat moet voor renewal worden geadresseerd.
4. Hoe automatisering omzet en personeelsgroei ontkoppelt
In het traditionele MSP-model zijn omzet en personeelsgroei aan elkaar vastgeklonken. Elke 8 tot 12 nieuwe klanten vereist een extra engineer — de exacte ratio verschilt per type MSP, maar het lineaire verband is universeel. Dat verband is geen wet. Het is een gevolg van waar je werk vandaan haalt: een gemiddelde mkb-MSP haalt het grootste deel van zijn engineering-uren uit reactief incidentwerk en herhalende remediatie. Beide zijn arbeidsintensief en niet-gestandaardiseerd in uitvoering.
Operationele automatisering verandert dat. Niet door engineers te vervangen, maar door het type werk dat ze doen te verschuiven. Herhalend incidentwerk — de specifieke set van services-die-niet-meer-draaien, disks-die-vollopen, certificaten-die-aflopen — gaat naar een policy-gedreven uitvoeringslaag die zelf detecteert, beslist en remedieert. Engineers houden zich bezig met wat geen herhaling is: onbekende incidenten, architectuur, advies, projectwerk.
Het bedrijfseffect zit niet in de techniek, maar in de schaalvoet. Een MSP die EKM via automatisering verlaagt, doorbreekt de relatie tussen klantgroei en hire-druk. Tien extra klanten vragen niet meer per definitie om een extra engineer. Personeel groeit met advies-werk en strategische capaciteit — niet met operationeel volume. Dat is het verschil tussen een schaalbaar bedrijf en een tijd-voor-geld-bedrijf.
De technische werking van die uitvoeringslaag is een onderwerp op zichzelf. Voor de marge-discussie volstaat één observatie: zolang de detect-decide-act-loop op herhalend werk autonoom verloopt, is EKM geen lineaire functie meer van het aantal klanten. Voor de mechanica: zie de pagina over self-healing infrastructure.
5. Drie scenario’s: licht, gemiddeld, zwaar MSP-profiel
De exacte EKM-waarde verschilt sterk per MSP. Klanttype, infrastructuur-volwassenheid, contractmodel en proces-discipline drukken allemaal hun stempel. Daarom werken we hier met drie illustratieve scenario’s — geen marktnormen, maar werkhypotheses om de orde van grootte te laten zien.
Werkhypothese
Baseline EKM per profiel
| Profiel | EKM (uren) | Engineering-uren / jaar | Personeelskost engineering | % van omzet |
|---|---|---|---|---|
| Licht | 2,0 | ~1.920 | ~€125k | ~10% |
| Gemiddeld | 3,5 | ~3.360 | ~€220k | ~18% |
| Zwaar | 5,0 | ~4.800 | ~€310k | ~26% |
Het is geen marginaal verschil. Een “zwaar” MSP-profiel besteedt ruwweg een kwart van zijn omzet aan engineering-tijd die specifiek aan klantonderhoud opgaat — nog vóór overhead, sales, management en infrastructuur. Een “licht” profiel zit op ongeveer 10%. Dat verschil is de orde van grootte van een complete EBITDA-laag.
EBITDA-effect bij EKM-reductie via automatisering
| Profiel | Bij 25% EKM-reductie | Bij 40% EKM-reductie |
|---|---|---|
| Licht | ~€31k bespaard · +~2,6 pp EBITDA | ~€50k bespaard · +~4,2 pp EBITDA |
| Gemiddeld | ~€55k bespaard · +~4,6 pp EBITDA | ~€88k bespaard · +~7,3 pp EBITDA |
| Zwaar | ~€78k bespaard · +~6,5 pp EBITDA | ~€125k bespaard · +~10,4 pp EBITDA |
pp = procentpunten EBITDA-marge, uitgedrukt als bespaarde personeelskost gedeeld door jaaromzet. Werkhypothese, geen marktnorm. Werkelijke uitkomsten zijn sterk afhankelijk van welke incidenttypes geschikt zijn voor autonome remediatie, de mate van standaardisatie in jouw omgeving, en hoe vrijgekomen capaciteit wordt herbestemd.
Voor een gemiddeld profiel met een bestaande EBITDA-marge van zeg 12–15% betekent een EBITDA-uplift van 4 tot 7 procentpunten geen incrementele verbetering — het is een structurele verschuiving in de winstgevendheid van het bedrijf. Voor een zwaar profiel kan het de helft van de EBITDA toevoegen die er al was.
6. Besliskader: in welke fase van marge-optimalisatie zit jij?
Niet elke MSP staat op hetzelfde punt op de marge-curve. Voor sommige bedrijven is automatisering nu de juiste hefboom; voor andere is het te vroeg, en is portfolio- of proceswerk eerst nodig. Vier profielen:
Profiel 1
Hoge klant-heterogeniteit, vrijwel geen herhalend werk
Elk incident is anders. Klantomgevingen lijken weinig op elkaar. Engineers besteden hun tijd vooral aan diagnose, niet aan uitvoering. De EKM-belasting komt niet voort uit volume maar uit complexiteit.
→ Nog niet automatiseren. Eerst klantportfolio rationaliseren of segmenteren.
Profiel 2
Werk is standaardiseerbaar, maar niet gedocumenteerd
Engineers doen vergelijkbare dingen, maar elk in zijn eigen volgorde. Geen runbooks, weinig procesdiscipline. Automatisering zonder voorafgaande standaardisatie codificeert de chaos en levert teleurstellende resultaten op.
→ Eerst proces standaardiseren. Automatisering komt daarna — binnen 3 tot 6 maanden.
Profiel 3
50+ herhalende L1/L2-incidenten per maand, redelijk gedocumenteerd, EKM > 3
Het werk is voorspelbaar. Engineers volgen runbooks die ze allemaal kennen. EKM zit op een niveau waarbij operationele automatisering directe marge-impact heeft, met een typische payback onder 12 maanden in deze configuratie.
→ Nu automatiseren. Start met de top-5 herhalende incidenttypes.
Profiel 4
Schaalfase met onevenredige hire-druk of verloop-spiraal
Omzet groeit, maar het lukt niet om voldoende engineers te vinden of te behouden. EKM zit aan de hoge kant (> 4 uur per klant). Elke maand zonder structurele EKM-verlaging is een maand met groeiende afhankelijkheid van een arbeidsmarkt die niet meewerkt.
→ Nu agressief automatiseren. Anders blijf je personeel-gelimiteerd groeien — en wordt verloop een tweede orde-effect dat de marge nog verder onder druk zet.
7. Veelgestelde vragen
Geldt deze logica ook bij hoge ARPC-klanten, of vooral bij volume-MSPs?
Bij beide, maar de hefboom werkt anders. Bij volume-MSPs zit de winst in het verminderen van het aantal uren per klant. Bij high-ARPC-MSPs (managed cloud, complexe security-stacks) zit de winst in het beschermen van engineering-tijd zodat die naar advies en architectuur kan in plaats van naar incident response. In beide gevallen is EKM de relevante metriek — alleen het automatiseringsdoel verschilt: schaalbaarheid bij volume, capaciteitsherbestemming bij premium.
Hoe meet ik mijn huidige EKM — mijn data is niet schoon genoeg.
Dat is voor de meeste mkb-MSPs het uitgangspunt. Een ruwe eerste schatting is meestal voldoende om de orde van grootte vast te stellen: pak het totaal aantal billable plus non-billable engineering-uren over een kwartaal, en deel door (aantal klanten × 3 maanden). De uitkomst is geen precieze EKM, maar wel een werkbare baseline. PSA-tools die tijdregistratie ondersteunen geven een betere benadering. Als die data niet beschikbaar is, is het al een signaal: een MSP die EKM niet kan meten, stuurt er ook niet op.
Mijn engineers zijn nu al onderbenut. Verlies ik dan geen capaciteit met automatisering?
Nee — mits je de vrijgekomen tijd actief herbestemt. Automatisering verlaagt de inzet op herhalend werk, niet op je hele engineering-functie. De vrijgekomen capaciteit gaat doorgaans naar projectwerk (billable), advieswerk, of het opnemen van extra klanten zonder bijbehorende hire. Onderbenutting is bovendien zelden gelijkmatig verdeeld: vaak zijn senior engineers overbelast met escalaties terwijl L1-werk de tijd van iedereen opslokt.
Hoe verantwoord ik deze investering richting een investeerder of bank?
Het sterkste argument is niet de operationele besparing, maar de schaalbaarheid van het bedrijfsmodel. Een MSP die structureel personeel moet bijschalen om omzet te laten groeien, heeft een lineair waarderingsprofiel. Een MSP die automatisering inzet om EKM te verlagen, koppelt omzetgroei los van personeelsgroei. Dat verandert de groeicurve, de cashconversie en uiteindelijk de waardering. De ROI-berekening op individueel niveau (payback per incidenttype) is daarbij de onderbouwing, niet de hoofdboodschap.
Waarom is dit anders dan de RMM- of PSA-investering die we vijf jaar geleden deden?
RMM en PSA hebben de detectie- en administratie-laag opgelost: je weet wat er gebeurt en je kunt het factureren. Maar de uitvoeringslaag — het daadwerkelijk afhandelen van het incident — is grotendeels menselijk gebleven. Dat is precies de laag waar EKM zit. Operationele automatisering vult dat gat: de beslis- en actielaag tussen de alert en de menselijke interventie. Het is geen vervanging van RMM of PSA, maar de schakel die er tot nu toe ontbrak.
Hoe UptimePilot dit aanpakt
UptimePilot is het autonomous infrastructure platform voor mkb-MSPs. Het richt zich specifiek op de uitvoeringslaag waar EKM ontstaat: de herhalende infrastructuur-incidenten die nu nog handmatig worden afgehandeld door engineers.
Het bedrijfseffect is EKM-verlaging op de incidenttypes die zich daarvoor lenen — zonder de RMM- of PSA-laag te vervangen, en zonder integratie-marathons.
Volgende stap
Benieuwd hoe deze rekening eruitziet voor jouw MSP?
In een demo lopen we door welke incidenttypes in jouw omgeving de meeste engineering-uren opslokken — en welke direct geschikt zijn voor autonome remediatie. Zonder vrijblijvende belofte over marge-uplift, met een concrete inschatting van waar jouw EKM zit.
Plan een demo →