Attributiemodellen voor deals met meerdere partijen

Haal een gesloten-gewonnen enterprise-deal van vorig kwartaal erbij en tel de partijen. Een verwijzingspartner regelde de introductie. Een systeemintegrator doet de implementatie. De integratie van een ISV was de technische eis waardoor je op de shortlist kwam. De marketplace van een hyperscaler verwerkte de transactie. En je eigen AE runde het geheel van begin tot eind. Vijf bijdragers. De CRM heeft één veld Partner en één Opportunity Owner.

Dat gat is het multi-party-attributieprobleem, en het is gestopt een randgeval te zijn. Zodra vier partijen een deal raken, heeft "wie sourcete het?" geen schoon antwoord, en het standaard-antwoord (wie het veld het eerst invult) levert een cijfer op dat niemand vertrouwt. De oplossing is niet zoeken naar de ene ware eigenaar. Het is bewust een attributiemodel kiezen, begrijpen wat het wegruilt, en het elke keer op dezelfde manier toepassen.

Waarom single-owner-attributie breekt

Het instinct is de partij met de meeste verantwoordelijkheid te benoemen en die alles te geven. Bij een echte multi-party-deal is dat misleidend op manieren die zich opstapelen.

Het wist bijdrage uit. Alleen de sourcing-partner crediteren en de SI en de ISV lijken niets te hebben gedaan, ook al was de deal zonder hen niet gesloten. Doe dat een paar kwartalen op rij en die partners stoppen met verschijnen.

Het nodigt uit tot gamen. Wanneer credit winner-take-all is, vecht elke partij om de winnaar te zijn, en wie het CRM-veld beheerst wint ongeacht wat er gebeurde. Wij hebben eerder over dit mechanisme geschreven in het co-sell-attributieprobleem waar niemand het over heeft.

En het verbergt hoe deals daadwerkelijk tot stand komen. Als je data zegt dat elke deal precies één partner had, kun je nooit zien welke combinaties van partners je beste resultaten opleveren. Dat is nou net het ding dat je het liefst zou willen weten voordat je beslist waar te investeren.

Single-owner was zinvol toen deals simpel waren. Dat zijn ze niet meer, dus je hebt een model nodig dat gedeelde, gedifferentieerde credit kan uitdrukken, en je moet het kiezen in plaats van klakkeloos over te nemen wat de CRM standaard meelevert.

De modellen, en wat elk je kost

Geen van deze is in het abstracte juist. Elk ruilt eenvoud tegen eerlijkheid op een andere plek.

First-touch geeft alle credit aan wie de deal oorspronkelijk startte, meestal de verwijzings- of sourcing-partner. Simpel, en het beloont vraagcreatie, wat het lastigste en waardevolste is dat een partner voor je kan doen. Maar het negeert iedereen die de deal voortstuwde of sloot, dus co-sell- en implementatiepartners krijgen niets. Redelijk als net-new pipeline het gedrag is dat je het meest moet kopen.

Last-touch geeft alle credit aan de partij betrokken bij het sluiten, vaak de co-sell- of leveringspartner. Het beloont wie de deal over de streep trok en wist de sourcing-partner volledig uit. Naar onze ervaring is dat meestal het minst eerlijke beschikbare resultaat, en het is zelden het juiste primaire model.

Gelijke multi-touch verdeelt credit gelijk over elke partij die de deal wezenlijk raakte. Iedereen wordt erkend, en de prikkel om te vechten om volledige credit daalt. Het probleem is dat het een dealmakende introductie hetzelfde behandelt als een kleine assist. Gelijk is niet hetzelfde als eerlijk.

Gewogen, of rolgebaseerd, verdeelt credit naar rol: een gedefinieerd aandeel voor sourcing, een aandeel voor beïnvloeden, een aandeel voor leveren. Het komt het dichtst bij hoe multi-party-deals daadwerkelijk waarde creëren. De kost is dat je de wegingen vooraf moet definiëren en overeenkomen, en de rol van elke partij in de data moet vastleggen.

De meeste volwassen programma's komen uit bij het gewogen model, omdat het direct aansluit op het echte onderscheid tussen beïnvloede en gesourcete partnerrevenue. Je kunt betekenisvolle credit geven aan een sourcing-partner en een beïnvloedende partner op dezelfde deal zonder te doen alsof er maar één van bestond.

Er één kiezen en erbij blijven

Welk model je kiest doet er minder toe dan twee dingen: het bewust kiezen, en het elke keer toepassen. Een middelmatig model dat consistent wordt toegepast verslaat een perfect model dat deal voor deal opnieuw wordt onderhandeld met commissie op het spel.

Richt het model op het gedrag waar je te weinig van hebt. Meer net-new pipeline nodig? Weeg sourcing zwaar. Partners nodig om te helpen sluiten? Zorg dat closing-bijdrage credit krijgt. Het model is een prikkel, dus richt hem.

Beslis vóór het kwartaal, niet erna. Kom het model en zijn wegingen overeen terwijl iedereen kalm is en niemands uitbetaling van het antwoord afhangt. Attributie die aan het einde van het kwartaal wordt uitgevochten, verandert altijd in politiek.

Rapporteer credit los van commissie. Attributie voor het begrijpen van het bedrijf (welke partners drijven revenue) kan, en zou vaak moeten, verschillen van wat je uitbetaalt. Verwar de twee en je verstoort uiteindelijk de ene om de andere tevreden te stellen.

Dubbeltel doelbewust. Voor programmameting kan dezelfde dollar legitiem aan meerdere partners worden gecrediteerd, zolang iedereen weet dat het totaal niet hoort op te tellen tot bookings. Label het duidelijk zodat finance niet in de war raakt.

Het datamodel eronder

Elk model hierboven stort in zonder data die het kan ondersteunen. Je kunt geen gewogen, rolgebaseerd model draaien op een CRM met één partnerveld. Het schema kan letterlijk geen twee partners met twee rollen op één deal uitdrukken. Wat je per opportunity nodig hebt:

• Meerdere partijen
• Een aparte rol voor elk (gesourced, beïnvloed, co-sold, geleverd)
• Een tijdstempel voor elke touch, vastgelegd op het moment dat het gebeurde in plaats van later gereconstrueerd

Zonder dat zit je terug bij één dropdown en een ruzie aan het einde van het kwartaal. Het fundament bouwen en het gevoed houden over de CRM, partnerportalen, marketplaces, en de Slack-threads waar co-sell daadwerkelijk gebeurt is een revenue-orchestratie-probleem: multi-party-signalen naar één model met tijdstempel trekken zodat welke attributielogica je ook kiest erop kan draaien. Krijg dat goed en modellen wisselen of afstemmen wordt een configuratiewijziging in plaats van een datamigratie.

Belangrijkste inzichten

• De meeste enterprise-deals hebben nu meerdere bijdragers, en een single-owner-veld wist ofwel mensen uit ofwel beloont wie het snelst typt.
• First-touch, last-touch, gelijk, en gewogen kosten je elk iets. Gewogen is waar de meeste serieuze programma's uitkomen.
• Consistentie verslaat precisie. Kom het model vóór het kwartaal overeen en heropen het niet onder commissiedruk.
• Houd programma-attributie en commissie als aparte berekeningen, en wees eerlijk dat programmacredit de bookings zal overschrijden.
• Niets ervan draait op een CRM met één partnerveld. Fix eerst het datamodel.

Zodra multi-party-attributie werkt, stopt partnerdata een kwartaalgevecht te zijn en begint het te tonen hoe revenue daadwerkelijk tot stand komt. Als je een model ontwerpt voor deals met vier bijdragers, is de aanpak van Revnewo voor multi-party-credit een redelijk startpunt.