Cómo quitamos el lastre del sistema GTM de Device Solutions

La situación

No se podía confiar del todo en el CRM. Las listas se construían a mano. Los comerciales dedicaban una parte importante de la semana a trabajo que no era vender. Ops estaba atrapado reaccionando en lugar de mejorar.

Cada acción de GTM exigía más esfuerzo del que debería.

No necesitaban más leads ni otra campaña. Necesitaban convertir el caos acumulado en algo intencionado.

El problema real

A primera vista parece un problema de outbound o de campañas. No lo era.

Cuando mapeamos el flujo GTM completo, el problema resultó ser estructural. El sistema nunca se había diseñado para soportar la forma en que el negocio ya funcionaba.

Los datos vivían repartidos entre varias herramientas. Las etapas del ciclo de vida existían pero no imponían nada. Las automatizaciones corrían aisladas en lugar de funcionar como un sistema.

Eso produjo una serie de problemas de segundo orden fáciles de diagnosticar mal:

Ventas no podía fiarse del todo de lo que veía, así que montaba sus propios registros paralelos.

Ops no podía construir nada sin temer romper otra cosa, así que las mejoras se pararon.

La atribución estaba fragmentada, así que las decisiones se tomaban con información parcial.

El enfoque

No empezamos añadiendo actividad ni parcheando problemas aislados. Empezamos por entender el sistema sobre el que esa actividad tendría que funcionar.

Así que mapeamos cómo fluían realmente los ingresos, de punta a punta:

Por dónde entraban los datos en el sistema. Cómo se movían por Ventas. Dónde se duplicaban, se atascaban o se quedaban obsoletos. Dónde el trabajo manual se había convertido, sin hacer ruido, en la norma.

Ese mapa marcó el trabajo. En lugar de tratar los síntomas de uno en uno, quitamos las restricciones que frenaban el sistema, en el orden que desbloqueaba más trabajo aguas abajo.

Todo siguió una regla. Si no reducía fricción ni creaba palanca a largo plazo, no se lanzaba.

Qué construimos

La columna vertebral del CRM. Registros duplicados, campos inconsistentes y lógica frágil rompían todo lo que venía detrás. En cuanto el modelo de datos se limpió y se gobernó, el CRM dejó de pelearse con el equipo y empezó a ayudarle.

Estructura del ciclo de vida. Etapas claras, transiciones claras, reglas claras sobre cómo avanzaban los leads y las cuentas. Menos suposiciones, menos casos límite y un modelo que reflejaba cómo trabajaba realmente Ventas, no cómo decía una plantilla que debía trabajar.

Un motor de listas repetible. Construir listas dejó de ser algo que una persona hacía a mano y pasó a ser algo que el sistema generaba, enriquecía y actualizaba bajo demanda.

Alineación de herramientas. Los datos fluyen en una dirección en lugar de en cinco. Los workflows nuevos dejaron de romper los antiguos. Las mejoras dejaron de generar trabajo de limpieza después.

Y nada de eso vivía solo en la ejecución. Cada workflow principal se documentó a medida que se construía. Los SOPs y diagramas de flujo hicieron el sistema comprensible, repetible y transferible, que es lo que separa un sistema de una dependencia.

Qué cambió

El mayor cambio no fue una métrica. Fue cómo trabajaba el equipo en el día a día.

Ventas dejó de dudar del CRM. Podían fiarse de lo que veían y dedicar el tiempo a vender en lugar de a arreglar datos.

Ops dejó de apagar fuegos. En lugar de reaccionar a workflows rotos y entradas malas, podían mejorar el sistema sabiendo que los cambios no se propagarían de forma imprevisible.

Las listas dejaron de ser un bloqueo. Cuando el equipo necesitaba un segmento, el sistema lo generaba sin carreras manuales.

El trabajo de GTM pasó a sumar en lugar de ser frágil. Los workflows nuevos no rompían los existentes.

Y la dirección por fin tenía un sistema que podía mirar y decir: así se mueven los ingresos aquí.

Nada cambió de la noche a la mañana. La fricción bajó en todos los frentes, y cuando baja la fricción todo lo demás va más rápido.

Todo lo que habéis trabajado con nosotros hasta ahora ha sido genial. Lo que me gusta es que podemos llegar con ideas a medio hacer y vosotros encontráis la forma de que funcionen. No quiero pasarme 40 horas a la semana detrás de una pantalla conectando todo esto, y no tengo que hacerlo.

Ted Dann, Founder, Device Solutions

Por qué importa

No se trataba de arreglar unos cuantos workflows rotos. Se trataba de instalar un sistema GTM capaz de seguir evolucionando sin hundirse bajo su propio peso.

Como la base se construyó bien, Device Solutions no acabó solo con un CRM más limpio. Acabó con algo sobre lo que construir. Los workflows nuevos, los segmentos nuevos y las iniciativas nuevas ya no empiezan de cero.

Por eso el trabajo tampoco terminó con la entrega del proyecto. Con el sistema principal en marcha, tenía sentido seguir mejorándolo. Seguimos trabajando juntos de forma fraccional, ampliando y afinando el mismo sistema en lugar de añadirle soluciones desconectadas.

El valor aquí no es un único resultado. Es un sistema que se acumula.

Para quién es esto

Equipos que ya venden pero notan el lastre debajo de todo lo que hacen.

Donde hay ingresos pero los sistemas no han seguido el ritmo. Donde Ventas hace más tareas administrativas de las que debería. Donde el CRM técnicamente funciona pero nadie se fía del todo.

Es para founders y responsables de GTM que ya saben que añadir más actividad no arregla un problema estructural, y que escalar sobre el caos solo produce más caos.

Si os suena, el problema normalmente no es el esfuerzo, el talento ni las herramientas. Es el sistema que hay debajo.