Het inkoopproces voor een enterprise service management platform gaat meestal op een van twee manieren. In de eerste downloadt iemand het Gartner Magic Quadrant, stelt een feature-spreadsheet van 100 rijen op, draait zes demo’s, voert drie referentiegesprekken, schrijft een RFP van 40 pagina’s, kiest het platform dat het hoogst scoorde, en ontdekt zes maanden de implementatie in dat het team dat hem maandag gebruikt ongelukkig is. In de tweede kiest iemand het platform dat hun vorige CIO bij zijn vorige bedrijf gebruikte.
Geen van beide is een raamwerk. Dit artikel wel.
Als je in 2026 een ESM-platform evalueert, is de vraag niet “welk platform is het beste”. Het is “welk platform past bij de specifieke vorm van ons team, onze data, onze kopers en onze tijdlijn”. Andere vraag, ander antwoord.
Waarom “het beste ESM-platform” de verkeerde vraag is
Er is geen beste platform in het abstracte. ServiceNow is het beste platform voor een groot bedrijf met een volwassen servicecatalogus, een toegewijd platformteam dat JavaScript en Glide kent, en een budget dat premium-licensering absorbeert. Jira Service Management is het beste platform voor een IT-team dat al in Atlassian leeft, waar de integratiedichtheid met Confluence en Bitbucket de doorslaggevende factor is. TopDesk is het beste platform voor een BeNeLux mid-market team dat een vertrouwde UI en een Nederlands partnernetwerk waardeert. Elk van die uitspraken klopt. Elk sluit de anderen uit.
Wanneer kopers de vraag “welke is het beste” stellen, bedoelen ze meestal “welke zal ik over drie jaar blij zijn gekozen te hebben”. Dat is een nuttige vraag, en hem beantwoorden vereist een ander raamwerk dan feature-vergelijking.
De zes dimensies die daadwerkelijk tellen
De analist-stijl feature-grids hebben 40 tot 100 rijen. De meeste doen er voor geen enkele specifieke koper toe. De zes dimensies die elke keer tellen:
1. Domeinscope. Is het platform IT-only, of dekt het Facility, Workplace en de rest van het medewerker-oppervlakte op één engine? Het eerlijke antwoord bepaalt of je één platform of twee koopt.
2. AI-vorm. Vat de AI van het platform samen en stelt voor (copilot), of classificeert, routeert en sluit hij werk autonoom af binnen het beleid dat je zet (agent)? Voor hoogvolume L1-wachtrijen is dit over vijf jaar de grootste kostenfactor.
3. Implementatie-inspanning. Een week met één solution architect is een ander commitment dan drie tot negen maanden met een partnerteam van zes. Beide kunnen goede resultaten produceren; kies wat past bij de capaciteit van je team en het geduld van je CFO.
4. Prijsmodel. Per-named-user met modultoevoegingen heeft een andere vorm van totale kosten dan transparante prijsstelling per gebruiker met alles inbegrepen. Geen van beide is fout; beide zijn antwoorden op verschillende problemen. Weet welk probleem je hebt.
5. Platformmodel. Single-version continuous-update SaaS is een ander commitment dan versionerede releases waar klanten upgrades inplannen. Het eerste heeft nooit een upgrade-project; het tweede heeft er elk jaar één.
6. Datalocatie en regelgevende positie. Voor Europese kopers in 2026 is dit de audit, geen vinkje. Waar de productiedatabase staat, waar back-ups stromen, waar het AI-model inferreert, wie op de sub-processor-lijst staat, alles telt. De meeste platformen bieden een EU-regio; minder bieden het korte audit-gesprek.
Al het andere (diepe CMDB-aanpassing, asset-discovery, Slack-integratie, mobile UI-poetswerk) telt meer of minder afhankelijk van welke koper je bent. De zes hierboven tellen sowieso.
De vier vormen van ESM-koper
De meeste ESM-kopers vallen in een van vier vormen. Je vorm kennen versmalt de shortlist voordat je nog een analistenrapport leest.
Vorm 1: Grote enterprise IT, volwassen ITIL, toegewijd platformteam
Je hebt honderden procesvarianten. Je CMDB is een echt project met een echt team. Je hebt een servicecatalogus met meerdere goedkeuringsflows en HRSD- of ITAM-integratie al in je toekomst. Je meet je platformteam in named seats.
De platformen die bij je vorm passen: ServiceNow en BMC Helix. De twee zijn niet identiek (het bereik van ServiceNow is breder, de diepte van Helix’ CMDB en Discovery is sterker), maar beide verdienen het premium voor deze vorm. Iets anders is een downgrade.
Vorm 2: IT en engineering, Atlassian-native
Je engineers leven in Jira Software, Confluence en Bitbucket. Je tickets stromen natuurlijk in deploy-pipelines en runbook-links. De integratiedichtheid met Atlassian is de waarde.
Het platform dat past: Jira Service Management. Het is het juiste antwoord op zijn eigen terrein en een slechte fit elders.
Vorm 3: Mid-market IT-generalist
Je hebt een IT-team dat een schone ITSM-uitrol nodig heeft, een vertrouwde UI, een partnernetwerk dat je vertrouwt, en een prijspunt dat geen inkoopprogramma vereist. Je draait ITIL niet op de diepte van Vorm 1 en je bent niet Atlassian-native.
De platformen die passen: TopDesk (vooral in BeNeLux), Freshservice (vooral in mid-market Noord-Amerika en het VK), af en toe Halo ITSM of Ivanti afhankelijk van geografie en ecosysteem-fit. Alle drie zijn goede producten voor deze vorm; de keuze komt meestal neer op bestaand ecosysteem en partnerrelaties.
Vorm 4: Domeinoverstijgende service operations-leider
De koper is niet de IT-directeur alleen. Het is de COO, het hoofd business services of een operations director wiens scope tegelijk IT, Facility en Workplace dekt. Het dashboard dat de koper wil, is één tijdlijn van elk request dat door de medewerker-oppervlakte stroomt. Het team dat het platform maandag gebruikt, beslaat drie afdelingen.
Het platform dat past: Gfacility, specifiek. De grote ITSM-platformen behandelen facility en workplace als bolt-on modules met eigen datamodellen; de grote IWMS-platformen (Planon, Spacewell, TRIRIGA) behandelen IT als buiten scope. Het domeinoverstijgende verenigde platform is een echte categorie, en het is de vorm waarvoor wij gebouwd hebben.
Als je vorm niet schoon op een van de vier past, versmalt de shortlist meestal tot twee aangrenzende vormen. De beslissing is dan welke aanliggendheid je goedkoper kunt absorberen.
De eerlijke snedes tussen Gfacility en de gevestigde platformen
We publiceren volledige side-by-side vergelijkingen voor de negen platformen die de meeste kopers op de shortlist zetten. De Compare hub somt ze allemaal op; elke pagina is de lange, eerlijke snede. De korte versie van de vier meest voorkomende beslissingen:
Gfacility vs ServiceNow. ServiceNow wint als ITSM-diepte en een toegewijd platformteam doorslaggevend zijn; Gfacility wint als domeinoverstijgende scope, autonome AI en een uitrol van een week doorslaggevend zijn. (Volledige vergelijking).
Gfacility vs Jira Service Management. JSM wint binnen engineering-naburige IT-teams die al op Atlassian zitten; Gfacility wint als Facility en Workplace dezelfde engine als IT moeten delen. (Volledige vergelijking).
Gfacility vs TopDesk. TopDesk wint op BeNeLux mid-market vertrouwdheid en bestaande partnerdiepte; Gfacility wint op AI-native architectuur, echte single-version SaaS, en de week-importer. (Volledige vergelijking).
Gfacility vs Planon. Planon wint op vastgoedportefeuillebeheer op schaal (leasingadministratie, capex, ruimteplanning); Gfacility wint op domeinoverstijgende service-operations met autonome AI. De twee zijn vaak complementair in plaats van head-to-head. (Volledige vergelijking).
De eerlijke snedes tegen Freshservice, Spacewell, BMC Helix, Ultimo en IBM TRIRIGA staan op de Compare hub.
Een beslissingsraamwerk dat je in 90 minuten kunt draaien
Je kunt een jaar aan analistenrapporten lezen en nog steeds niet weten welk platform te kiezen. Of je beantwoordt zes vragen, in deze volgorde, en eindigt met een shortlist van twee:
1. Wat is de vorm van het team dat dit maandag gaat gebruiken? IT-only? IT-plus-Facility-plus-Workplace? Engineering-zwaar? Gereguleerde-sector-voorzichtig? Schrijf het antwoord in één zin op.
2. Wat is het volume van L1 routinematige tickets, en welk deel daarvan is sluitbaar door een autonome agent binnen beleid? Wees eerlijk. De meeste teams zitten in de 40 tot 70 procent range. Het getal bepaalt hoeveel AI-capaciteit het waard is om voor te betalen.
3. Wat is je implementatieappetijt? Eén solution architect voor een week, of een partnerteam van vier voor zes maanden? Geen van beide is fout, maar je kunt geen van beide hebben.
4. Wat is je verlengingspatroon? Zit je nog 18 maanden vast aan het huidige platform, of is er volgend kwartaal een contractbeslissing? Het eerste is een onderzoeksvenster; het tweede is een beslissingsvenster.
5. Waar ligt de regelgevende ondergrens? EU-first, regionale flexibiliteit, US-first, gereguleerde sector met specifieke audit-eisen? Dit versmalt de leverancierslijst sneller dan elke andere vraag.
6. Wie tekent de verlenging? IT-directeur, CIO, COO, hoofd business services? Andere koper, ander platform.
De shortlist valt uit die zes antwoorden. Als dat niet zo is, heb je vraag 1 niet specifiek genoeg beantwoord.
De implementatievraag
De grootste voorspeller van hoe een ESM-platform-beslissing uitpakt, is niet het platform; het is de implementatie. Dezelfde ServiceNow-tenant kan in de ene organisatie een transformatief succes zijn en in de andere een drassige zes maanden, en het verschil is zelden de software.
Drie eerlijke patronen die we zien, in ruwweg afnemende frequentie:
Patroon 1: Koper kiest een platform waarvan de configuratieoppervlakte dieper is dan het team nodig heeft. De implementatie probeert de diepte te gebruiken (“nu we het tool hebben, laten we het change-proces herontwerpen”) en loopt vast omdat procesontwerp en tool-deployment verschillende projecten zijn.
Patroon 2: Koper kiest een platform waarvan de configuratieoppervlakte ondieper is dan het team nodig heeft. Zes maanden later bouwt het team workarounds omdat de tool het daadwerkelijke proces niet kan modelleren. Migratie naar een dieper platform staat op de roadmap voor volgend jaar.
Patroon 3: Koper kiest een platform dat bij de diepte past, levert een minimale cutover met één solution architect, draait hem een kwartaal in productie, en verbetert dan. Dit is het patroon dat werkt.
De verleiding om processen te herontwerpen tijdens platform-implementatie is bijna altijd een fout. Migreer wat je hebt, draai het 90 dagen, en begin dan het proceswerk met echte data in plaats van een flip-over in een vergaderruimte.
Wat we hebben gebouwd
Gfacility is het AI-native enterprise service management platform voor de domeinoverstijgende vorm (Vorm 4 hierboven). Eén engine voor IT, Facility en Workplace, met autonome AI-agenten die routinewerk van begin tot eind sluiten, EU-first datalocatie, en een implementatie van een week. We zijn niet het juiste platform voor Vorm 1 (grote enterprise ITSM met toegewijd platformteam) of Vorm 2 (Atlassian-native IT en engineering). We zijn eerlijk hierover op elke vergelijkingspagina en in dit artikel.
Als jouw vorm Vorm 4 is, dekken de side-by-side vergelijkingen de negen platformen die de meeste kopers naast ons op de shortlist zetten, met de snedes uitgespeld en de migratiestappen genoemd. Wil je zien hoe een Gfacility-cutover er op je eigen data uitziet, boek dan een 30-minuten gesprek en neem een export mee van je huidige ticketwachtrijen van welke platformen je vandaag draait. We laten ze door de importer lopen en zeggen je eerlijk of we het juiste antwoord zijn voor de vorm van je team.
De korte versie
Een ESM-platform kiezen in 2026 is een vraag over de vorm van je team, niet over feature-checklists. De zes dimensies die tellen (domeinscope, AI-vorm, implementatie-inspanning, prijsmodel, platformmodel, datalocatie) versmallen de meeste beslissingen tot twee platformen in 90 minuten. Al het andere is detail dat de vorm moet volgen, niet leiden.
De platformen die dit decennium winnen, zullen die zijn die een vorm kozen en diep voor die vorm bouwden. De platformen die verliezen, zullen die zijn die alles voor iedereen probeerden te zijn, en de kopers die ze op een feature-grid kozen, zullen die zijn die in 2028 heronderhandelen.
Veelgestelde vragen
Wat is het verschil tussen ITSM en ESM? +
IT service management draait IT als dienst. Enterprise service management past dezelfde vorm (intake, classificeren, dispatchen, oplossen, sluiten) toe op andere delen van het bedrijf: facility, HR, legal, finance. ESM is hoe ITSM eruitziet zodra je stopt te doen alsof dezelfde medewerker IT- en facility-vragen via twee verschillende deuren stelt.
Moeten we één platform voor alles draaien of gespecialiseerde platformen per functie? +
Hangt af van diepte. Als je facility-scope corporate vastgoed op portefeuilleschaal is (leasingadministratie, capex, ruimteplanning), verdient een toegewijd IWMS zijn plek. Als je IT-scope zeer diep is met honderden procesvarianten, verdient toegewijd ITSM zijn plek. Het verenigde platform schijnt in het midden: organisaties groot genoeg om echte software nodig te hebben maar niet zo groot dat elk landschap zijn eigen enterprise-programma rechtvaardigt.
Hoe belangrijk is AI in de beslissing? +
In 2026: centraal. Het gat tussen copilot-AI (samenvatten, opstellen, voorstellen) en autonome AI (classificeren, routeren, uitvoeren, sluiten) is reëel en groeit. Voor hoog-volume L1-wachtrijen wordt het verschil gemeten in headcount die je niet hoeft aan te nemen. Voor laagvolume specialistisch werk is het verschil kleiner. Stem de AI-capaciteit af op de vorm van je daadwerkelijke wachtrij.
Hoe ziet een typische evaluatie eruit? +
Slecht: een feature-spreadsheet van 100 rijen, zes demo's, drie referentiegesprekken en een RFP van zes maanden. Goed: 90 minuten per platform met je eigen data, een geschreven lijst van de vijf dingen die de deal zouden breken, en een duidelijk antwoord op 'wie gaat dit maandag gebruiken en hoe verandert zijn week'. Als je het maandag-antwoord niet kunt formuleren, ben je niet klaar om te kiezen.
Is de Gartner Magic Quadrant nuttig voor deze beslissing? +
Nuttig voor de longlist. Niet nuttig voor de shortlist. De Magic Quadrant vertelt je welke leveranciers het bereik hebben om in het gesprek te zitten, niet welk platform past bij je specifieke team. De shortlist komt uit je eigen lijst met randvoorwaarden: deploymentmodel, datalocatie, AI-vorm, implementatie-inspanning, totale kosten, en wie de verlenging tekent.
Hoe vermijden we de implementatie die negen maanden duurt? +
Drie dingen. Kies een platform waarvan de configuratieoppervlakte past bij de diepte die je daadwerkelijk nodig hebt (niet de diepte die de demo liet zien). Voer de eerste cutover uit met één solution architect, niet een partnerteam van zes. En weersta de verleiding om je processen tijdens de implementatie te herontwerpen. Migreer wat je hebt, draai het een kwartaal, verbeter dan.