Rebuilding Elesa+Ganter’s customer data into something the business can act on

The situation

Elesa+Ganter sells standard mechanical components to industrial manufacturers across Spain and Portugal. The commercial side of the business runs in HubSpot and the transactional side in SAP, and both had grown for years with no normalisation and no control over what came into them. The data inside had aged into something nobody could safely act on, and the customer service work running on top of it was all done by hand.

The real problem

The obvious answer was a cleanup, and a cleanup would not have held. Nothing in the system had ever refreshed itself, so the records would have started going stale again the day they were handed back. The same was true at the other end. Nine shared mailboxes created a contact from every inbound email, that behaviour cannot be switched off in HubSpot, and no rule decided what happened to any of those contacts afterwards.

And underneath both, the service work. Every customer request was read, classified, routed and answered by a person, which is workable until volume moves and then is not.

The approach

Enrichment on a schedule, not a one-off cleanup. Customer data goes out of date on its own, so it is maintained rather than cleaned once. The customer base is re-enriched every six months against outside sources, and every delivery address is normalised and geocoded in the same run. The addresses matter more than they sound: deliveries were going out against records that had no postcode field at all, with the town empty on almost every row.

Decide at the point of entry, and give a person the cases that need judgement. Each new contact is admitted, held for review, or rejected according to the channel it arrived through. Only admitted contacts are passed to the ERP, so nothing unverified reaches the master record, and the held ones go to a review list rather than blocking anyone from answering a customer. The rule is deliberately not a gate that stops work; it is a filter that runs alongside it.

Automate what is certain, and send the rest to a person. A request is answered automatically only when the answer already exists in the data, such as the status of an order. Anything unclear, sensitive or high value goes to a person. Either way the reply is written back onto the request, so the case holds the full history rather than half of it sitting in somebody’s mailbox.

What we built

Enrichment and a recurring refresh of the customer base in Clay, drawing on the public company registry and a credit-data provider, with delivery addresses normalised and geocoded. Rules in HubSpot that admit, hold or reject each new contact by the channel it came from, with a review list for the held ones and only admitted contacts passed to the ERP. And on the service side, automated replies through n8n for the requests whose answer already exists in the data, with everything else routed to a person.

What changed

The customer base has been enriched and written back to the ERP, and it is no longer something that has to be cleaned by hand when someone notices it has drifted. Credit standing and public filings now sit on the customer record, where nothing of the kind existed before, though nothing has yet been built on top of them. The entry rules and the service automation are specified and in build. Nothing here is described as running that is not.

Why this matters

Most CRM work is sold as a cleanup, and a cleanup is a one-off answer to a continuous problem. The records go stale because nothing refreshes them and the database refills because nothing decides what may enter it, so the useful question is not how dirty the data is today but what will keep it clean without anyone remembering to. That is an architecture question, and it gets answered before anybody touches a record.

Who this is for

Businesses running a CRM alongside an ERP, where the commercial system has drifted from the transactional one and the service team absorbs the difference by hand. Usually the symptom is not that anything is broken. It is that nobody trusts the data enough to automate anything on top of it.