Reconstruir los datos de clientes de Elesa+Ganter en algo sobre lo que el negocio pueda actuar

La situación

Elesa+Ganter vende componentes mecánicos estándar a fabricantes industriales de España y Portugal. La parte comercial del negocio funciona en HubSpot y la transaccional en SAP, y las dos habían crecido durante años sin normalización y sin ningún control sobre lo que entraba en ellas. Los datos que contenían habían envejecido hasta un punto en que nadie podía actuar sobre ellos con seguridad, y todo el trabajo de atención al cliente que se apoyaba en ellos se hacía a mano.

El problema real

La respuesta obvia era una limpieza, y una limpieza no habría aguantado. Nada en el sistema se había actualizado nunca por sí solo, así que los registros habrían empezado a quedarse obsoletos otra vez el mismo día de su entrega. Lo mismo pasaba en el otro extremo. Nueve buzones compartidos creaban un contacto con cada email entrante, ese comportamiento no se puede desactivar en HubSpot, y ninguna regla decidía qué pasaba después con ninguno de esos contactos.

Y por debajo de las dos cosas, el trabajo de servicio. Cada petición de cliente la leía, clasificaba, enrutaba y respondía una persona, algo que funciona hasta que el volumen se mueve y entonces deja de funcionar.

El enfoque

Enrichment periódico, no una limpieza puntual. Los datos de clientes se quedan desactualizados por sí solos, así que se mantienen en lugar de limpiarse una vez. La base de clientes se vuelve a enriquecer cada seis meses con fuentes externas, y cada dirección de entrega se normaliza y se geocodifica en la misma pasada. Las direcciones importan más de lo que parece: las entregas salían con registros que ni siquiera tenían un campo de código postal, y con la población vacía en casi todas las filas.

Decidir en el punto de entrada, y dar a una persona los casos que requieren criterio. Cada contacto nuevo se admite, se retiene para revisión o se rechaza según el canal por el que llegó. Solo los contactos admitidos pasan al ERP, así que nada sin verificar llega al registro maestro, y los retenidos van a una lista de revisión en lugar de impedir a nadie responder a un cliente. La regla, a propósito, no es una barrera que detiene el trabajo; es un filtro que funciona en paralelo.

Automatizar lo que es seguro, y enviar el resto a una persona. Una petición se responde automáticamente solo cuando la respuesta ya existe en los datos, como el estado de un pedido. Todo lo que es dudoso, delicado o de alto valor va a una persona. En ambos casos la respuesta se registra en la propia petición, así que el caso guarda el historial completo en lugar de tener la mitad en el buzón de alguien.

Qué construimos

Enrichment y una actualización recurrente de la base de clientes en Clay, a partir del registro mercantil público y de un proveedor de datos de crédito, con las direcciones de entrega normalizadas y geocodificadas. Reglas en HubSpot que admiten, retienen o rechazan cada contacto nuevo según el canal del que vino, con una lista de revisión para los retenidos y solo los contactos admitidos pasando al ERP. Y en la parte de servicio, respuestas automáticas a través de n8n para las peticiones cuya respuesta ya existe en los datos, con todo lo demás enrutado a una persona.

Qué cambió

La base de clientes se ha enriquecido y se ha devuelto al ERP, y ya no es algo que haya que limpiar a mano cuando alguien se da cuenta de que se ha desviado. La solvencia crediticia y los depósitos públicos están ahora en la ficha del cliente, donde antes no existía nada parecido, aunque todavía no se ha construido nada encima. Las reglas de entrada y la automatización del servicio están especificadas y en construcción. Aquí no se describe como en marcha nada que no lo esté.

Por qué importa

La mayor parte del trabajo de CRM se vende como una limpieza, y una limpieza es una respuesta puntual a un problema continuo. Los registros se quedan obsoletos porque nada los actualiza y la base de datos se vuelve a llenar porque nada decide qué puede entrar, así que la pregunta útil no es lo sucios que están hoy los datos, sino qué los mantendrá limpios sin que nadie tenga que acordarse. Esa es una pregunta de arquitectura, y se responde antes de que nadie toque un registro.

Para quién es esto

Empresas que tienen un CRM junto a un ERP, donde el sistema comercial se ha desviado del transaccional y el equipo de servicio absorbe la diferencia a mano. Normalmente el síntoma no es que algo esté roto. Es que nadie se fía de los datos lo suficiente como para automatizar nada encima.