Reconstruir el CRM de Nextmol en un sistema que cualifica sin depender de la memoria de una persona

La organización

Nextmol vende química computacional a equipos de I+D de la industria química, como servicio y como plataforma de software. Los proyectos son largos y técnicos. Pasan unos doce meses desde el primer contacto hasta la firma, y cada propuesta la escribe desde cero el director científico de la empresa. El equipo comercial es pequeño y el CEO lleva la mayoría de las relaciones.

La situación

Las herramientas se habían ido añadiendo según hacían falta, nunca se diseñaron como un sistema. HubSpot guardaba el historial del trabajo, pero se consultaba en lugar de usarse para operar, y el registro de cualquier deal estaba repartido en cinco sitios: el CRM, la plataforma de reuniones, el repositorio de documentos, una hoja de cálculo personal y una agenda de papel. Solo el CEO podía reconstruir en qué punto estaba cada cosa.

El problema real

El encargo obvio era una limpieza del CRM. Esa nunca fue la parte difícil.

El pipeline se había construido para registrar lo que ya había pasado, no para decidir qué pasaba después. Se abrían deals sobre prospectos que nunca habían tenido una conversación comercial, así que el número de deals, la tasa de cierre y la antigüedad de los deals medían cada uno algo distinto de lo que decían medir.

Qué estaba roto

Dos pipelines para un solo proceso de venta. El embudo estaba dividido según cómo se iba a entregar el trabajo, aunque la venta era idéntica en los dos casos. El reporting se dividía con él.

Leads y oportunidades en el mismo sitio. Se abrían deals sobre prospectos que nunca habían tenido una conversación comercial.

Nada con lo que hacer forecast ni atribución. La mayoría de los deals no tenían valor, y la mayoría de los contactos no tenían registro de dónde venían. Nada avisaba de un deal que se había quedado en silencio.

Las decisiones de arquitectura

Un solo pipeline, con el modelo de entrega como propiedad. Los dos pipelines registraban cómo se haría el trabajo, no cómo se vendía. Convertir eso en un campo mantenía la distinción sin fragmentar el forecast.

Un objeto aparte para todo lo que todavía no es una oportunidad. Un deal se crea en un único momento: cualificación superada, primera reunión hecha, encaje de capacidades confirmado. Todo lo anterior, y todo lo que se ha enfriado, vive en un pipeline de leads. Esa regla es lo que hace legibles la tasa de cierre y la antigüedad de los deals.

Scoring sobre el lead, para que la cualificación se pueda traspasar. Había vivido entero en el criterio de una persona, así que no se podía enseñar ni delegar. El encaje de la empresa y el engagement puntúan por separado en lugar de mezclarse: una cuenta equivocada y en silencio y una cuenta correcta y en silencio necesitan acciones opuestas. Un tercer score ordena los deals abiertos, para que la redacción de propuestas haga cola según la evidencia.

Automatización que vigila el silencio. Nada en el sistema anterior podía decir qué deals se habían quedado en silencio. Un deal o un lead sin actividad durante cuarenta y cinco días ahora genera una tarea y una alerta para su propietario, y el umbral está en un solo sitio para poder ajustarlo a medida que se acumula historial.

Qué construimos

Un pipeline de seis etapas con criterios de entrada en cada etapa y campos obligatorios que controlan el avance. Un pipeline de leads, once propiedades de deal, una taxonomía de nueve canales conectada a cada formulario web. Doce workflows que cubren ciclo de vida, atribución, creación de tareas y detección de estancamiento. Tres scores y dos dashboards.

Cómo se hizo el trabajo

Primero vinieron dos auditorías, una de la configuración de HubSpot y otra de cómo vende realmente el equipo, ambas entregadas en junio con cada cifra medida en el portal en lugar de estimada. La arquitectura se propuso y se aprobó antes de tocar nada en producción. La base se montó a finales de julio, construida en paralelo a los pipelines existentes para no alterar nada de lo que estaba en uso.

La migración se hizo en agosto contra un mapa aprobado, deal por deal, con los registros de etapas tempranas enviados al nuevo pipeline de leads en lugar de borrados. La documentación se escribió a medida que se construía el sistema y después se revisó línea por línea contra el portal en vivo antes de la entrega. Esa revisión es lo que detectó un conjunto de afirmaciones que ya no coincidían con lo construido, y las corrigió antes de que el cliente las leyera, no después.

Qué cambió

El pipeline abierto contiene solo oportunidades vivas, y nada se queda en silencio sin que alguien se entere. La cualificación funciona con un modelo y no con la memoria de una persona: cada cuenta lleva un score de encaje y otro de engagement, y los deals abiertos llevan un score de prioridad que ordena la cola de propuestas. Lo que el modelo no puede aportar es la parte que solo conoce el equipo, y la construcción dejó establecido exactamente qué campos son esos.

Por qué importa

En este caso no hay métricas de campaña. El sistema se puso en marcha en las últimas semanas del proyecto, y lo honesto es reconocer que los números que lo demostrarían todavía no existen.

Lo que existe es un sistema comercial con sus reglas por escrito. Un deal significa una sola cosa. La cualificación que vivía en la cabeza de una persona ahora tiene un modelo detrás. Nada se queda en silencio sin que alguien se entere. Esas son las condiciones en las que vale la pena medir métricas, y ninguna se cumplía antes.

Para quién es esto

Empresas donde el CRM guarda el historial pero no sabe decir qué está vivo. Donde el pipeline se ha convertido en una lista de todo aquel con quien alguien habló alguna vez, así que nadie se fía del forecast. Donde la cualificación funciona porque una persona la tiene en la cabeza, y todo el mundo sabe que es un riesgo pero nadie ha tenido un trimestre para arreglarlo.

El problema rara vez es la herramienta. Es que nadie decidió nunca para qué sirve el pipeline.