Modelos de atribución para tratos multipartitos

Toma un trato cerrado-ganado del trimestre pasado y cuenta las partes involucradas. Un partner de referidos hizo la presentación. Un integrador de sistemas está haciendo la implementación. La integración de un ISV fue el requisito técnico que te puso en la lista corta. El marketplace de un hyperscaler procesó la transacción. Y tu propio AE llevó todo de principio a fin. Cinco contribuyentes. El CRM tiene un campo de Partner y un Propietario de la oportunidad.

Esa brecha es el problema de atribución multipartita, y ha dejado de ser un caso excepcional. Una vez que cuatro partes tocan un trato, "¿quién lo originó?" no tiene una respuesta clara, y el valor predeterminado (quien complete el campo primero) produce un número en el que nadie confía. La solución no es buscar al único propietario verdadero. Es elegir un modelo de atribución de forma deliberada, entender qué sacrifica y aplicarlo de la misma manera cada vez.

Por qué falla la atribución a un solo propietario

El instinto es nombrar a la parte más responsable y darle todo el crédito. En un trato genuinamente multipartito, eso es engañoso de maneras que se acumulan.

Borra la contribución. Si solo se acredita al partner que originó el trato, el integrador de sistemas y el ISV parecen no haber hecho nada, aunque el trato no se hubiera cerrado sin ellos. Haz eso durante varios trimestres seguidos y esos partners dejan de aparecer.

Invita a manipular el sistema. Cuando el crédito es todo o nada, cada parte lucha por ser la ganadora, y quien controle el campo del CRM gana sin importar lo que realmente ocurrió. Ya hemos escrito sobre este mecanismo en el problema de atribución del co-sell del que nadie habla.

Y oculta cómo se cierran realmente los tratos. Si tus datos dicen que cada trato tuvo exactamente un partner, nunca podrás ver qué combinaciones de partners producen tus mejores resultados. Eso es justo lo que más querrías saber antes de decidir dónde invertir.

La atribución a un solo propietario tenía sentido cuando los tratos eran simples. Ya no lo son, así que necesitas un modelo que pueda expresar crédito compartido y diferenciado, y necesitas elegirlo en lugar de heredar lo que trajera el CRM de fábrica.

Los modelos, y lo que cada uno te cuesta

Ninguno de estos es correcto en abstracto. Cada uno intercambia simplicidad por equidad en un lugar diferente.

Primer contacto (first-touch) da todo el crédito a quien originó el trato, generalmente el partner de referidos o de origen. Simple, y recompensa la creación de demanda, que es lo más difícil y valioso que un partner puede hacer por ti. Pero ignora a todos los que avanzaron o cerraron el trato, así que los partners de co-sell e implementación no reciben nada. Razonable si el pipeline neto nuevo es el comportamiento que más necesitas comprar.

Último contacto (last-touch) da todo el crédito a la parte involucrada en el cierre, a menudo el partner de co-sell o cumplimiento. Recompensa a quien llevó el trato hasta la línea de meta y elimina por completo al partner de origen. En nuestra experiencia, ese suele ser el resultado menos justo disponible, y rara vez es el modelo principal correcto.

Multitáctil equitativo (equal multi-touch) divide el crédito de manera uniforme entre cada parte que tocó materialmente el trato. Todos son reconocidos, y el incentivo para pelear por el crédito exclusivo disminuye. El problema es que trata una presentación que generó el trato igual que una asistencia menor. Equitativo no es lo mismo que justo.

Ponderado, o basado en roles, distribuye el crédito por rol: una parte definida para el origen, una parte para la influencia, una parte para el cumplimiento. Es la coincidencia más cercana con cómo los tratos multipartitos realmente crean valor. El costo es que tienes que definir y acordar las ponderaciones de antemano, y tienes que capturar el rol de cada parte en los datos.

La mayoría de los programas maduros terminan en el modelo ponderado, porque se corresponde directamente con la distinción real entre ingresos de partners influenciados y originados. Puedes dar crédito significativo a un partner de origen y a un partner de influencia en el mismo trato sin fingir que solo uno de ellos existió.

Elegir uno y mantenerlo

El modelo que elijas importa menos que dos cosas: elegirlo deliberadamente y aplicarlo siempre. Un modelo mediocre aplicado de manera uniforme supera a un modelo perfecto renegociado trato por trato con la comisión en juego.

Apunta el modelo al comportamiento que te falta. ¿Necesitas más pipeline neto nuevo? Pondera fuertemente el origen. ¿Necesitas que los partners ayuden a cerrar? Asegúrate de que la contribución al cierre reciba crédito. El modelo es un incentivo, así que apúntalo.

Decide antes del trimestre, no después. Acuerda el modelo y sus ponderaciones mientras todos están tranquilos y el pago de nadie depende de la respuesta. La atribución que se litiga a fin de trimestre siempre se convierte en política.

Reporta el crédito por separado de la comisión. La atribución para entender el negocio (qué partners impulsan los ingresos) puede, y a menudo debería, diferir de lo que pagas. Combina ambas cosas y terminarás distorsionando una para satisfacer a la otra.

Cuenta doble a propósito. Para la medición del programa, el mismo dólar puede acreditarse legítimamente a varios partners, siempre que todos sepan que el total no debe sumar a las reservas. Etiquétalo claramente para que finanzas no se confunda.

El modelo de datos subyacente

Todos los modelos anteriores se derrumban sin datos que puedan sostenerlos. No puedes ejecutar un modelo ponderado basado en roles con un CRM que tiene un solo campo de partner. El esquema literalmente no puede expresar dos partners con dos roles en un mismo trato. Lo que necesitas por oportunidad:

• Múltiples partes
• Un rol distinto para cada una (originado, influenciado, co-vendido, cumplido)
• Una marca de tiempo para cada contacto, capturada cuando ocurrió en lugar de reconstruida después

Sin eso, vuelves a un solo menú desplegable y una discusión de fin de trimestre. Construir la base y mantenerla alimentada a través del CRM, los portales de partners, los marketplaces y los hilos de Slack donde realmente ocurre el co-sell es un problema de orquestación de ingresos: traer señales multipartitas a un solo modelo con marca de tiempo para que la lógica de atribución que elijas pueda ejecutarse sobre él. Si logras esto, cambiar o ajustar modelos se convierte en un cambio de configuración en lugar de una migración de datos.

Conclusiones clave

• La mayoría de los tratos empresariales ahora tienen varios contribuyentes, y un campo de propietario único borra a personas o recompensa a quien escribe más rápido.
• Primer contacto, último contacto, equitativo y ponderado te cuestan algo cada uno. Ponderado es donde terminan la mayoría de los programas serios.
• La consistencia vence a la precisión. Acuerda el modelo antes del trimestre y no lo reabras bajo presión de comisiones.
• Mantén la atribución del programa y la comisión como cálculos separados, y sé honesto de que el crédito del programa superará las reservas.
• Nada de esto funciona con un CRM que tiene un solo campo de partner. Arregla primero el modelo de datos.

Una vez que la atribución multipartita funciona, los datos de partners dejan de ser una pelea trimestral y empiezan a mostrarte cómo se generan realmente los ingresos. Si estás diseñando un modelo para tratos con cuatro contribuyentes, el enfoque de Revnewo para el crédito multipartita es un buen punto de partida.