Crear un modelo de análisis no es solo programar
Los modelos de analítica comercial que no funcionan no suelen ser técnicamente incorrectos. Suelen haber sido construidos sin entender cómo trabaja el equipo que debe usarlos. Este artículo explica qué hay que saber antes de programar.
Cuando alguien me dice que ha construido un modelo de análisis comercial, la primera pregunta que le hago no es sobre el modelo. Es sobre cómo trabaja el equipo comercial de la empresa para la que lo ha construido.
La mayoría de las veces, la respuesta es vaga. Saben qué datos han usado. Saben qué algoritmo han aplicado. No siempre saben cuántas visitas semanales hace un comercial medio, cómo decide a quién llamar el lunes por la mañana, qué conversación tiene con un cliente que lleva tres meses bajando compras, o qué hace cuando el sistema le dice que un cliente es de alto valor pero la relación está fría.
Esa distancia -entre la solidez técnica del modelo y el conocimiento del comportamiento real del equipo que debe usarlo- es la causa más frecuente de que los modelos de analítica comercial no lleguen a funcionar en la práctica. No porque estén mal construidos. Sino porque han sido construidos desde afuera.
El error de origen: construir para los datos, no para las personas
Los modelos de análisis comercial puramente técnicos tienen un patrón de fracaso muy reconocible. Producen resultados analíticamente correctos que nadie usa. Las clasificaciones son coherentes, los indicadores son precisos, las visualizaciones son claras. Y sin embargo, seis meses después de la implantación, el equipo comercial sigue tomando decisiones por intuición y el director comercial sigue preparando sus reuniones con el mismo Excel de siempre.
El problema no está en la calidad del modelo. Está en que el modelo no habla el idioma de quien debe usarlo. Ha sido diseñado para responder preguntas analíticas, no para facilitar decisiones operativas. Y esa diferencia, pequeña en teoría, es enorme en la práctica.
Una pregunta analítica es: ¿qué clientes tienen mayor concentración de ventas en un único producto? Una decisión operativa es: ¿a qué cliente llamo esta semana, con qué argumento, con qué objetivo y en cuánto tiempo espero ver un resultado? La segunda no es solo más difícil que la primera. Es de una naturaleza completamente distinta, y construir un modelo que llegue hasta la segunda requiere conocer el comportamiento de las personas que van a usarlo antes de tocar un solo dato.
Lo que hay que entender antes de programar
Cuando empecé a desarrollar Qube6, la primera decisión que tomé fue no empezar por los datos. Empecé por observar y documentar cómo funciona realmente una organización comercial B2B desde dentro: cómo se estructura la semana de un comercial, qué conversaciones tiene con su director, cómo se priorizan las visitas, qué ocurre cuando hay un conflicto entre cliente estratégico y cliente urgente, cómo se entiende el concepto de «buen cliente» en la práctica y cómo difiere casi siempre del concepto de "buen cliente" en el análisis.
Ese trabajo previo determinó decisiones de diseño que no habrían emergido de un enfoque puramente técnico. Por ejemplo: que el sistema debía producir una instrucción por cliente, no una clasificación. Porque el director comercial no necesita saber que un cliente está en el cuadrante C de rentabilidad y el B de evolución. Necesita saber qué hacer con ese cliente esta semana. La clasificación es el medio, la instrucción es el fin.
O que los indicadores debían ser comparables entre clientes de distinto tamaño, porque el equipo comercial trabaja con carteras heterogéneas y necesita poder decir "este cliente mediano merece más atención que ese grande" con una base objetiva, no solo con intuición. Un indicador absoluto -facturación bruta, margen en euros- no sirve para esa comparación. Necesitas indicadores relativos, normalizados sobre la media de la empresa, que pongan a todos los clientes en el mismo plano de análisis independientemente de su volumen.
O que la salida del sistema tenía que llegar al CRM como tarea asignada, no como informe adjunto. Porque si el resultado del análisis requiere que alguien lo lea, lo interprete y lo traslade manualmente a una acción, hay demasiados pasos entre el dato y la ejecución. Y en cada paso hay posibilidad de dilución, de postergación, de que la urgencia del día desplace la prioridad del sistema.
Ninguna de estas decisiones es técnicamente compleja. Todas requieren entender cómo venden las personas antes de decidir cómo debe funcionar el sistema que las apoya.
La trampa de la generalización
Hay un segundo problema que afecta específicamente a los modelos construidos sin ese conocimiento previo del comportamiento comercial: la tendencia a generalizar soluciones que solo funcionan en contextos específicos.
Un modelo de scoring de clientes construido para una empresa de distribución de productos de gran consumo no funciona igual en una empresa de servicios industriales B2B, aunque los datos disponibles sean similares. No porque los algoritmos sean distintos, sino porque la lógica con que opera un comercial es radicalmente diferente: ciclos de venta distintos, patrones de recompra distintos, señales de riesgo distintas, relación precio-volumen-margen distinta.
La analítica comercial que no está anclada en la lógica de negocio específica del sector y del modelo de venta produce modelos que son técnicamente correctos en abstracto e inútiles en concreto. Funcionan en la demo. No funcionan el lunes por la mañana cuando el comercial tiene que decidir su agenda.
La solución no es construir un modelo distinto para cada empresa desde cero, eso no es escalable. La solución es construir un sistema lo suficientemente flexible para adaptarse a distintas lógicas de negocio, pero con una arquitectura metodológica fija que garantice que la salida sea siempre operativa: un objetivo por cliente, una estrategia coherente con ese objetivo, una táctica principal y una acción concreta con un responsable y un plazo.
Qué significa construir bien un modelo de analítica comercial
Significa, en primer lugar, haber pasado tiempo suficiente observando cómo trabaja el equipo que va a usar el sistema. No en entrevistas formales. En reuniones de seguimiento, en conversaciones informales, en la revisión de cómo se preparan las visitas y cómo se reportan. Ese trabajo de observación es el que permite distinguir entre lo que el equipo dice que hace y lo que realmente hace, y diseñar el sistema para lo segundo.
Significa, en segundo lugar, haber tomado decisiones explícitas sobre qué preguntas el sistema responderá y cuáles no. Un modelo que intenta responder todo termina respondiendo nada bien. El foco es una decisión de diseño, no una limitación técnica.
Significa, en tercer lugar, haber definido la forma de la salida antes de construir la lógica que la produce. Si la salida es una tarea en el CRM, el modelo debe diseñarse hacia atrás desde esa tarea. Si la salida es un informe semanal para el director comercial, el modelo es diferente. La forma de la salida determina la arquitectura del sistema.
Y significa, en último lugar, haber validado el sistema con el equipo comercial real antes de darlo por terminado. No con el equipo de datos ni con la dirección. Con los comerciales que van a recibirlo. Porque ellos son los únicos que pueden decirte si lo que el sistema propone tiene sentido en su realidad operativa.