Modèles d'attribution pour les affaires multi-parties

12 novembre 20258 min read

Modèles d'attribution pour les deals à parties multiples

Ouvrez un deal d'entreprise conclu le trimestre dernier et comptez les parties. Un partenaire de recommandation a fait l'introduction. Un intégrateur de systèmes réalise l'implémentation. L'intégration d'un ISV était l'exigence technique qui vous a fait présélectionner. La marketplace d'un hyperscaler a traité la transaction. Et votre propre AE a mené l'ensemble du début à la fin. Cinq contributeurs. Le CRM a un champ « Partenaire » et un champ « Propriétaire de l'opportunité ».

Cet écart est le problème d'attribution multi-parties, et il a cessé d'être un cas marginal. Dès que quatre parties touchent un deal, « qui l'a sourcé ? » n'a plus de réponse nette, et le défaut (celui qui remplit le champ en premier) produit un chiffre auquel personne ne fait confiance. La solution n'est pas de chercher le seul véritable propriétaire. C'est de choisir un modèle d'attribution délibérément, de comprendre ce qu'il sacrifie, et de l'appliquer de la même façon à chaque fois.

Pourquoi l'attribution à propriétaire unique échoue

L'instinct consiste à nommer la partie la plus responsable et à tout lui donner. Sur un deal véritablement multi-parties, cela induit en erreur de façons qui s'accumulent.

Cela efface la contribution. Créditer uniquement le partenaire de sourcing et le SI et l'ISV donnent l'impression de n'avoir rien fait, même si le deal ne se serait pas conclu sans eux. Faites cela pendant quelques trimestres d'affilée et ces partenaires cessent de se présenter.

Cela invite à la manipulation. Quand le crédit est à tout ou rien, chaque partie se bat pour être la gagnante, et celui qui contrôle le champ CRM gagne indépendamment de ce qui s'est réellement passé. Nous avons déjà écrit sur ce mécanisme dans le problème d'attribution du co-sell dont personne ne parle.

Et cela cache comment les deals se concluent réellement. Si vos données disent que chaque deal avait exactement un partenaire, vous ne pourrez jamais voir quelles combinaisons de partenaires produisent vos meilleurs résultats. C'est pourtant la chose que vous voudriez le plus savoir avant de décider où investir.

Le propriétaire unique avait du sens quand les deals étaient simples. Ils ne le sont plus, donc vous avez besoin d'un modèle capable d'exprimer un crédit partagé et différencié, et vous devez le choisir plutôt que d'hériter de ce que le CRM avait par défaut.

Les modèles, et ce que chacun vous coûte

Aucun d'eux n'est juste dans l'abstrait. Chacun échange la simplicité contre l'équité, à un endroit différent.

Le premier contact donne tout le crédit à celui qui a initié le deal, généralement le partenaire de recommandation ou de sourcing. Simple, et cela récompense la création de demande, la chose la plus difficile et la plus précieuse qu'un partenaire puisse faire pour vous. Mais cela ignore tous ceux qui ont fait avancer ou conclu le deal, donc les partenaires de co-sell et d'implémentation n'obtiennent rien. Raisonnable si le pipeline net nouveau est le comportement dont vous avez le plus besoin d'acheter.

Le dernier contact donne tout le crédit à la partie impliquée à la clôture, souvent le partenaire de co-sell ou de réalisation. Cela récompense celui qui a fait franchir la ligne au deal et efface complètement le partenaire de sourcing. D'après notre expérience, c'est généralement le résultat le moins juste disponible, et c'est rarement le bon modèle principal.

Le multi-touch égal répartit le crédit uniformément entre chaque partie ayant matériellement touché le deal. Tout le monde est reconnu, et l'incitation à se battre pour le crédit exclusif diminue. Le problème est que cela traite une introduction décisive de la même façon qu'un coup de main mineur. Égal n'est pas synonyme de juste.

Pondéré, ou basé sur le rôle, répartit le crédit par rôle : une part définie pour le sourcing, une part pour l'influence, une part pour la réalisation. C'est le modèle le plus proche de la façon dont les deals multi-parties créent réellement de la valeur. Le coût est que vous devez définir et convenir des pondérations à l'avance, et capturer le rôle de chaque partie dans les données.

La plupart des programmes matures se retrouvent sur le modèle pondéré, parce qu'il correspond directement à la véritable distinction entre le revenu partenaire influencé et sourcé. Vous pouvez donner un crédit significatif à un partenaire de sourcing et à un partenaire d'influence sur le même deal sans prétendre qu'un seul des deux a existé.

Choisir un modèle et s'y tenir

Le modèle que vous choisissez compte moins que deux choses : le choisir délibérément, et l'appliquer à chaque fois. Un modèle médiocre appliqué uniformément bat un modèle parfait renégocié deal par deal avec la commission en jeu.

Orientez le modèle vers le comportement qui vous manque. Besoin de plus de pipeline net nouveau ? Pondérez fortement le sourcing. Besoin que les partenaires aident à conclure ? Assurez-vous que la contribution à la clôture est créditée. Le modèle est une incitation, donc visez juste.

Décidez avant le trimestre, pas après. Convenez du modèle et de ses pondérations pendant que tout le monde est calme et que le versement de personne ne dépend de la réponse. L'attribution négociée en fin de trimestre tourne toujours à la politique.

Rapportez le crédit séparément de la commission. L'attribution pour comprendre l'activité (quels partenaires génèrent du revenu) peut, et devrait souvent, différer de ce que vous versez. Confondez les deux et vous finissez par déformer l'un pour satisfaire l'autre.

Comptez en double, délibérément. Pour la mesure du programme, le même dollar peut légitimement être crédité à plusieurs partenaires, tant que tout le monde sait que le total n'est pas censé correspondre aux ventes réservées. Étiquetez-le clairement pour que la finance ne s'y perde pas.

Le modèle de données sous-jacent

Chaque modèle ci-dessus s'effondre sans des données capables de le supporter. Vous ne pouvez pas faire tourner un modèle pondéré basé sur les rôles sur un CRM avec un seul champ partenaire. Le schéma ne peut littéralement pas exprimer deux partenaires avec deux rôles sur un même deal. Ce dont vous avez besoin par opportunité :

  • Plusieurs parties
  • Un rôle distinct pour chacune (sourcé, influencé, co-vendu, réalisé)
  • Un horodatage pour chaque contact, capturé au moment où il s'est produit plutôt que reconstitué plus tard

Sans cela, vous revenez à une seule liste déroulante et une dispute de fin de trimestre. Construire le fondement et le maintenir alimenté à travers le CRM, les portails partenaires, les marketplaces, et les fils Slack où le co-sell se produit réellement est un problème d'orchestration des revenus : faire converger les signaux multi-parties dans un modèle horodaté unique pour que quelle que soit la logique d'attribution que vous choisissiez, elle puisse s'exécuter dessus. Réussissez cela et changer ou ajuster les modèles devient un changement de configuration plutôt qu'une migration de données.

Points clés à retenir

  • La plupart des deals d'entreprise ont désormais plusieurs contributeurs, et un champ à propriétaire unique efface des gens ou récompense celui qui tape le plus vite.
  • Premier contact, dernier contact, égal, et pondéré vous coûtent chacun quelque chose. Le pondéré est là où atterrissent la plupart des programmes sérieux.
  • La cohérence l'emporte sur la précision. Convenez du modèle avant le trimestre et ne le rouvrez pas sous pression de commission.
  • Gardez l'attribution de programme et la commission comme des calculs séparés, et soyez honnête sur le fait que le crédit de programme dépassera les ventes réservées.
  • Rien de tout cela ne fonctionne sur un CRM avec un seul champ partenaire. Réglez d'abord le modèle de données.

Une fois que l'attribution multi-parties fonctionne, les données partenaires cessent d'être une dispute trimestrielle et commencent à vous montrer comment le revenu se fait réellement. Si vous concevez un modèle pour des deals à quatre contributeurs, l'approche de Revnewo pour le crédit multi-parties est un point de départ raisonnable.

See revenue orchestration in action

Unify your revenue data, signals, and plays on one AI-native platform.