Technische inkoper versus economische beslisser: wat beoordelaars melden
In de internationale enquête van Stack Overflow, waaraan mensen vrijwillig deelnamen, koos het merendeel van de softwarebeoordelaars noch de uiteindelijke aankoopbeslissing, noch het goedkeuren of beheren van toolbudgetten. Wat betekent die overlap voor een contentbriefing over software?
Eigen analyse van zelfgerapporteerde softwaretaken in de Stack Overflow Developer Survey 2026.
Samenvatting
Van de 9.664 respondenten die in Stack Overflows vrijwillige internationale enquête uit 2026 de optie software beoordelen, aanbevelen of op een shortlist zetten kozen, selecteerde 77,7% noch de uiteindelijke aankoopbeslissing, noch het goedkeuren of beheren van budgetten. Verder koos 10,8% beide opties, 7,7% de eindbeslissing zonder de budgetoptie en 3,9% de budgetoptie zonder de eindbeslissing. Influence IQ berekende deze vier groepen door de antwoorden binnen elke respons te combineren. [1]
De resultaten beschrijven taken die mensen zelf aangaven in een vrijwillige enquête. Ze identificeren geen geverifieerde technische inkopers of economische beslissers en stellen niet vast wie over een specifieke aankoop beslist. Voor bedrijven, bureaus en makers betekent dit praktisch: vraag afzonderlijk naar de beoordelingsvraag, de budgetverantwoordelijkheid en de eindbeslissing voordat je een briefing voor productcontent opstelt.
Een potentiële klant vraagt of je software aansluit op de tools die het team al gebruikt. Die persoon heeft een gerichte vraag, een duidelijk gebruiksdoel en genoeg kennis om door te vragen bij een vaag antwoord. Het is verleidelijk om te denken dat dit gesprek je een compleet beeld van de koper geeft. Het is pas het begin.
Iemand die een product test, kan het aanbevelen, besluiten het te kopen, het budget beheren of meerdere van die taken combineren. Een bruikbare briefing houdt die verschillen zichtbaar. We onderzochten in een grote openbare enquête hoe vaak beoordelaars ook de andere twee taken selecteerden. Vervolgens vertaalden we die bevindingen naar vragen die een marketingteam kan gebruiken.
Eén product, meerdere verantwoordelijkheden

- Beoordeel de tool
- Bekijk het budget
- Neem een aankoopbeslissing
Wat is het verschil tussen een technische inkoper en een economische beslisser?
Het onderscheid gaat over iemands taak bij een aankoop. Een technische inkoper beoordeelt hoe een product werkt en aansluit op de behoeften van de organisatie. Binnen het MEDDICC-model heeft de economische beslisser de overkoepelende bevoegdheid om over de aankoop te beslissen. Dat zijn nuttige zaken om uit te zoeken, maar een functietitel alleen geeft er geen antwoord op. [3][4]
Ons onderzoek gebruikt een beperktere, direct waarneembare maat: de taken die mensen in een enquête selecteerden. Respondenten konden meerdere rollen aangeven bij het kiezen of gebruiken van software binnen hun organisatie. We richtten ons op degenen die beoordelen, aanbevelen of op een shortlist zetten selecteerden. Daarna keken we of zij ook de uiteindelijke aankoopbeslissing en het goedkeuren of beheren van budgetten selecteerden. [5]
Deze enquêteopties zijn niet gelijk aan de rollen uit een verkoopmodel. Een beoordelaar hoeft geen technisch specialist te zijn. Iemand die een toolbudget beheert, hoeft niet de overkoepelende aankoopbevoegdheid te hebben. Als iemand zowel beslissings- als budgettaken selecteert, bewijst dat niet dat beide taken over dezelfde tool gaan.
Dat onderscheid houdt de praktische vraag scherp. Als een potentiële klant om een technische vergelijking vraagt, weet een marketeer dat er behoefte is aan informatie. In het volgende gesprek kun je vaststellen wat die persoon beoordeelt, waarover die kan beslissen en wie er verder onderbouwing nodig heeft.
Welke andere taken gaven softwarebeoordelaars aan?
Van de 9.664 respondenten die in Stack Overflows vrijwillige internationale enquête uit 2026 beoordelen, aanbevelen of op een shortlist zetten selecteerden, kozen 7.505 noch de eindbeslissing, noch budgetgoedkeuring of -beheer. Dat is 77,7% van deze groep beoordelaars. Het is de grootste van de vier categorieën in de onderstaande tabel. [1]
De overige categorieën laten de overlap zien die een simpele verdeling in beoordelaars en kopers zou missen. In totaal selecteerden 1.041 beoordelaars beide taken, 744 de eindbeslissing zonder de budgetoptie en 374 de budgetoptie zonder de eindbeslissing. Hun aandelen waren respectievelijk 10,8%, 7,7% en 3,9%.
Elke beoordelaar valt in precies één categorie. De percentages gaan over dezelfde groep respondenten en kunnen daarom samen worden gelezen. De afgeronde waarden tellen op tot 100,1%; de onderliggende aantallen tot precies 9.664.
“Geen van beide geselecteerd” moet je zorgvuldig lezen. Het geeft aan welke twee opties een respondent niet aankruiste. Het bewijst niet dat die persoon geen bevoegdheid of invloed heeft, of je niet met iemand anders in contact kan brengen. De enquête legde ook niet één specifieke aankoop vast waarvan we de betrokkenen konden reconstrueren.
De vier combinaties onder softwarebeoordelaars
Alle 9.664 respondenten in deze tabel selecteerden beoordelen, aanbevelen of op een shortlist zetten. De rijen splitsen vervolgens hun keuzes voor de uiteindelijke aankoopbeslissing en budgetgoedkeuring of -beheer uit.
| Door beoordelaars geselecteerde opties | Respondenten | Aandeel beoordelaars |
|---|---|---|
| Eindbeslissing en budgetgoedkeuring of -beheer | 1.041 | 10,8% |
| Alleen eindbeslissing | 744 | 7,7% |
| Alleen budgetgoedkeuring of -beheer | 374 | 3,9% |
| Geen van deze twee opties geselecteerd | 7.505 | 77,7% |
Wat kan een marketeer met dit onderscheid?
Laat de vraag van de beoordelaar centraal staan in je eerste antwoord. Als iemand een integratie wil begrijpen, leg dan uit welke koppeling wordt ondersteund, welke instellingen nodig zijn en welke belangrijke beperkingen gelden. Een algemene businesscase kan later relevant zijn, maar beantwoordt geen openstaande vraag over compatibiliteit.
Vraag vervolgens waarvoor de onderbouwing gebruikt gaat worden. Wil die persoon het product testen, een shortlist aanbevelen, een budgetgesprek voorbereiden of een beslissing nemen? Meerdere antwoorden kunnen tegelijk kloppen. De overlap in de enquête is een reden om daar ruimte voor te laten in je briefing.
Voor een maker die bedrijfssoftware uitlegt, verandert dit de opdracht. Een demonstratie kan een concrete beoordelingsvraag beantwoorden en kijkers tegelijk een bron geven die ze kunnen delen. De briefing moet duidelijk maken wat de demonstratie kan aantonen en waar de kijker de productinformatie kan controleren. De maker hoeft daarbij geen aankoopbevoegdheid of afgeronde verkoop te suggereren.
Voor een bureau hoort dit onderscheid thuis in de overdracht van content naar sales. Leg vast welke vraag de contactpersoon stelde en welke onderbouwing is gegeven. Houd antwoorden over budget of uiteindelijke goedkeuring apart, inclusief de vraag of die over deze specifieke aankoop gaan. Zo begrijpt de volgende collega het dossier zonder dat een reactie op content wordt omgezet in een onbevestigd kopersprofiel.
Een bruikbare gevolgtrekking voor marketeers is om de gemelde beoordelings-, budget- en beslissingstaken in aparte velden vast te leggen. Zo bewaar je wat de contactpersoon daadwerkelijk heeft gezegd en blijft zichtbaar welke vraag nog openstaat.
Van een productvraag naar een bruikbare briefing

Bepaal de vraag
Benoem de voorgenomen aankoop en de specifieke taak die de contactpersoon moet beoordelen.
Controleer de onderbouwing
Verifieer het productdetail en leg vast wat nog niet is beantwoord.
Bereid de overdracht voor
Leg de beoordelings-, budget- en beslissingstaken voor deze aankoop afzonderlijk vast.
Een briefing voor softwarebeoordeling die je kunt overnemen
Gebruik de volgende vragen voor één voorgenomen aankoop. Laat een antwoord open zolang het niet vaststaat. Een leeg veld maakt een openstaande vraag zichtbaar; invullen op basis van een veronderstelde functietitel zou die juist verbergen.
Voorgenomen aankoop: Welke tool, welk abonnement of welke verandering wordt overwogen? Benoem het beoogde gebruik en het team dat ermee gaat werken. Leg vast of het gesprek gaat over een nieuwe aankoop, een vervanging of een uitbreiding.
Beoordelingstaak: Wat moet de contactpersoon beoordelen? Schrijf de vraag op in diens eigen woorden, bijvoorbeeld of een koppeling de benodigde werkwijze ondersteunt. Noteer wat een bevredigend antwoord zou zijn en wie het productdetail kan verifiëren.
Te leveren onderbouwing: Welke demonstratie, specificatie, welk uitgewerkt voorbeeld of welke bron beantwoordt de vraag? Vermeld wie ervoor verantwoordelijk is en wanneer de informatie is gecontroleerd. Maak onderscheid tussen een functie die nu wordt ondersteund, een voorgestelde mogelijkheid en een illustratief voorbeeld.
Budgetverantwoordelijkheid: Keurt de contactpersoon het budget goed, beheert die het, bereidt die een aanvraag voor of heeft die een andere rol? Vraag specifiek naar de voorgenomen aankoop. Leg resterende onzekerheid vast in plaats van deze verschillende taken samen te vatten onder één label, zoals budgethouder.
Eindbeslissing: Wie kan deze aankoop goedkeuren en wat moet er nog gebeuren voordat die beslissing kan worden genomen? Houd degene die de aanbeveling doet apart van degene die definitief beslist als de contactpersoon aangeeft dat dit verschillende mensen zijn.
Andere betrokkenen en volgende stap: Wie moet de onderbouwing nog bekijken? Spreek af welk document of gesprek volgt, wie het voorbereidt en wanneer de contactpersoon het wil ontvangen. Zo kunnen een maker, marketeer en verkoper vanuit dezelfde uitgesproken vraag werken.
Gebruik dit als gespreksverslag. Werk de velden bij als de voorgenomen aankoop of de betrokkenen veranderen. Houd een antwoord van de contactpersoon apart van een aanname die nog gecontroleerd moet worden.
Een uitgewerkt voorbeeld voor een team dat marketingsoftware verkoopt
Stel je voor dat een softwarebedrijf een demonstratie voorbereidt voor een bureau. Het hoofd operations van het bureau wil weten of het product een goedgekeurde campagne kan doorgeven aan de bestaande rapportageworkflow van het team. Dit is een fictief voorbeeld van het gebruik van de briefing, geen waargenomen respondent of gemeten campagne.
Een eerste versie van de briefing kan luiden: “Voorgenomen aankoop: een tool voor de campagneoverdracht binnen het bureau. Beoordelingstaak: vaststellen welke overdracht het operationele team precies nodig heeft. Onderbouwing: een gedocumenteerd voorbeeld met een ondersteunde koppeling en de benodigde instellingen erbij.” Dat is genoeg om een maker of productspecialist een gerichte opdracht te geven.
Voordat het team de demonstratie opneemt, controleert het de koppeling. Wordt die niet ondersteund, dan hoort dat antwoord in de briefing en het volgende gesprek. Werkt de koppeling alleen met een bepaald abonnement of een specifieke inrichting, dan moet het voorbeeld die voorwaarde duidelijk maken.
Vervolgens vraagt de marketeer wat er na de technische beoordeling gebeurt. Stel dat de contactpersoon uitlegt zelf een tool aan te bevelen, dat een collega van finance de budgetaanvraag beoordeelt en dat een directeur de eindbeslissing neemt. Dit zijn aangenomen antwoorden voor dit voorbeeld. Leg ze vast als afzonderlijke verantwoordelijkheden voor deze aankoop, met de mensen en openstaande stappen die de contactpersoon noemt.
Het contentplan kan nu concreet worden. De beoordelaar krijgt de gecontroleerde workflowdemonstratie en de bijbehorende bron. Degene die de budgetaanvraag voorbereidt, krijgt de actuele prijs, de omvang en eventuele bekende implementatiekosten. Voor het gesprek over de eindbeslissing kan een korte samenvatting dienen van het beoogde gebruik, de bevestigde vereisten en de resterende vragen.
Alle drie de onderdelen moeten op dezelfde productfeiten steunen. Een zakelijke samenvatting mag geen mogelijkheid beloven die in de demonstratie ontbreekt. Een technische pagina mag geen belangrijke abonnementsvoorwaarde verbergen die de prijs verandert. Een andere nadruk in het materiaal rechtvaardigt geen andere feiten.
Als de contactpersoon juist zegt de tool te beoordelen, het budget te beheren én de eindbeslissing te nemen, kan de briefing die overlap weerspiegelen. Het team kan dan één beknopt pakket met duidelijk gescheiden onderdelen aanbieden. De enquête vertelt ons niet welke situatie bij dit bureau geldt; het gesprek doet dat.
De volgende stap is concreet: bevestig de gevraagde workflow, stuur de afgesproken onderbouwing en noteer welke vragen nog openstaan. Wanneer de contactpersoon reageert, kan het team het juiste veld bijwerken in plaats van het beeld van de aankoop helemaal opnieuw op te bouwen.
Hoe we de enquête hebben geanalyseerd
We gebruikten de openbare uitgave van de Stack Overflow Developer Survey 2026, vastgelegd op één specifieke archiefversie zodat een andere analist dezelfde invoer kan ophalen. Die bevat 30.903 antwoorden. Volgens de uitgever liep het veldwerk van 23 juni tot 5 augustus 2026 en kwamen de respondenten uit 169 landen. Deelname was vrijwillig. De resultaten beschrijven deze gepubliceerde groep antwoorden, geen representatieve steekproef van alle bedrijven of softwarekopers. [1][2]
De vraag over softwarerollen was optioneel en liet meerdere keuzes toe. Bij de controle van de gepubliceerde aantallen respondenten bij deze vraag behielden we alle 20.042 respondenten die de vraag beantwoordden. De hoofdanalyse omvatte daarna alle 9.664 respondenten die beoordelen, aanbevelen of op een shortlist zetten selecteerden. Elk percentage in de hoofdtabel gebruikt die groep beoordelaars als noemer. [1][5]
Voordat we de gecombineerde antwoorden bekeken, legden we de invoerversie, exacte optielabels, regels voor ontbrekende waarden, inclusieregels en vier categorieën vast. We controleerden het bronbestand, de kolomdefinities, unieke respons-ID’s, de vraagrouting en de aantallen niet-ontbrekende antwoorden. Beide onafhankelijk geschreven implementaties reproduceerden de noemer van de vraag en alle zes gepubliceerde optieaantallen exact.
Voor elke beoordelaar controleerden we of de opties voor de eindbeslissing en budgetgoedkeuring of -beheer waren geselecteerd. Elk antwoord valt op basis daarvan in één van de vier categorieën. We deelden elk categorieaantal door 9.664 en rondden de percentages afzonderlijk af op één decimaal. Deze analyse bevat geen enquêtegewichten, betrouwbaarheidsintervallen voor een populatie of causale schattingen.
We legden vooraf ook twee aanvullende controles vast: een versie zonder beoordelaars die tegelijk de optie “geen rol” selecteerden, en een uitsplitsing naar vijf vaste groepen voor werkgeversomvang. Zowel het volledige gevoeligheidsresultaat als de volledige uitsplitsing naar omvang wordt niet gepubliceerd, omdat ze niet aan onze vooraf vastgestelde rapportageregels voldeden. We gebruiken geen van beide ongepubliceerde resultaten om stabiliteit of verschillen naar werkgeversomvang te claimen.
De hoofdgroep moet minstens 500 respondenten hebben en geen enkele positieve cel mag minder dan tien antwoorden bevatten. De gevoeligheidsanalyse moet zelf minstens 500 respondenten hebben, zonder positieve resultaatcel of positieve uitgesloten cel kleiner dan tien. Die laatste voorwaarde voorkomt dat een kleine groep via aftrekken wordt onthuld. Voor de uitsplitsing naar omvang moet elk van de vijf vaste groepen minstens 100 respondenten hebben, zonder positieve cel kleiner dan tien. Bij een mislukte controle wordt het hele bijbehorende overzicht achtergehouden. We hebben categorieën niet samengevoegd nadat we de antwoorden zagen.
Dit zijn redactionele voorwaarden voor voldoende onderbouwing en zorgvuldige rapportage, geen claim van statistische representativiteit of formele privacygarantie. We behouden de door de uitgever vrijgegeven groep. De interne indicatoren voor toestemming, kwaliteit en bots staan niet in het openbare bestand. Daardoor kunnen we niet elke beslissing waarmee die groep is samengesteld onafhankelijk reconstrueren. [2]
De vragen beschrijven verantwoordelijkheden binnen een organisatie, geen geverifieerde transactie. De taken die één persoon selecteert, kunnen over verschillende tools gaan. Een optie niet selecteren bewijst geen gebrek aan bevoegdheid. De antwoorden identificeren ook geen andere mensen in een inkoopgroep. Die grenzen zijn belangrijk wanneer je een enquêtepercentage gebruikt in een klantgesprek.
De downloads bevatten de onderbouwde geaggregeerde resultaten, de berekeningscode en de exacte methode. Ze bevatten geen individuele respondentgegevens of identificatoren. De bronenquête is afzonderlijk beschikbaar onder de Open Database License en Database Contents License. Ons reproductiepakket behoudt de bijbehorende bronvermeldingen en licentiekennisgevingen. [6][7]
- Download de geaggregeerde resultaten in het Nederlands (CSV)
- Download de methode en reproductiecode (ZIP, Engels)
Aanmelden is niet nodig. De downloads bevatten onderbouwde geaggregeerde resultaten en de technische methode in het Engels, zonder individuele respondentgegevens of identificatoren. De bronenquête is afzonderlijk beschikbaar onder ODbL 1.0 en DbCL 1.0. [6][7]
Bronnen en noten
- Openbare responsgegevens en schema van de Stack Overflow Developer Survey 2026, vastgelegd op archiefcommit 6c646551e86ffcafca0ac04f1dfb17a2558ec23d. Influence IQ gebruikt alle respondenten die beoordelen, aanbevelen of op een shortlist zetten selecteerden, na exacte controles van de bron en gepubliceerde totalen.
- Officiële methodologie voor 2026, met vrijwillige werving, veldwerkdata en het proces waarmee de uitgever antwoorden selecteerde. De openbare export bevat niet de interne indicatoren die nodig zijn om elke kwaliteitsbeslissing over de groep te reproduceren.
- MEDDICC definieert de economische beslisser aan de hand van de overkoepelende bevoegdheid bij de aankoopbeslissing. Deze modeldefinitie dient als context en is niet gebruikt om respondenten te classificeren.
- Korn Ferry maakt in zijn bespreking van kopersverantwoordelijkheden onderscheid tussen technisch begrip en geschiktheid enerzijds en de economische beslisrol anderzijds. We gebruiken dit uitsluitend om de terminologie van de lezer toe te lichten, niet de afzonderlijke claims over verkoopprestaties.
- Officiële PurchasePower-resultaten voor 2026 en de vraagcontext. De vraag laat meerdere verantwoordelijkheden toe bij het kiezen of gebruiken van software op het werk. Ze identificeert geen specifieke aankoop en bevestigt geen formele beslissingsbevoegdheid.
- Open Database License (ODbL) 1.0. Het pakket met geaggregeerde resultaten en reproductiecode behoudt bronvermelding, licentiekennisgevingen en toepasselijke verplichtingen voor afgeleide databases.
- Database Contents License (DbCL) 1.0, van toepassing op de afzonderlijke inhoud van de bronenquêtedatabase. De datakennisgevingen staan los van de licentie voor de applicatiecode van de website.
Het artikel, de briefing, figuurlabels en de CSV met resultaten zijn beschikbaar in tien talen. Het technische reproductiepakket is in het Engels. Alle versies beschrijven dezelfde internationale groep enquêteantwoorden en dezelfde analyse.