Situation
The client had built a large installed base over decades, but the commercial and service information required to monetize it was fragmented. Little history was retained, and what existed was dispersed across commercial, technical and field systems. Teams could not answer three basic questions with confidence: which machines were installed where, what had already been serviced, and when the next maintenance was due.
- A large installed base, but no consolidated view of it.
- Little retained history, spread across commercial, technical and field tools.
- No reliable answer to where, what and when.
Friction
The temptation in this situation is to treat the problem as a CRM problem and to buy a bigger CRM. That reading was wrong. The company was not failing to record activity; it was unable to systematically convert an installed base into recurring service, spare-parts and customer-development revenue. That is a business-model question, and no tool selection answers it. Framing it as a systems project would have produced a migration with better data hygiene and the same missed revenue.
- The visible symptom was data fragmentation.
- The actual constraint was the revenue model around the installed base.
- A tool-led reading would have delivered a migration, not an outcome.
Intervention
The engagement ran in four sequenced moves, and the order mattered more than any individual choice. We started from the economics of the installed base: where revenue was being missed, which customer moments mattered, and which information was required to trigger action. We then defined a target operating model that is simultaneously customer-centric, a 360-degree view of the customer, and machine-centric, a 360-degree view of each machine from pre-sales through to decommissioning, connecting customer, site, machine, service history and maintenance or upgrade due dates so that commercial and technical teams could work from the same truth. Only then did technology choices follow: an open-source CRM, the existing ERP, field operations tooling and a shared data layer were connected rather than replaced wholesale. Deployment was designed for adoption rather than for a go-live date, through short delivery cycles, explicit governance, structured country-by-country onboarding and integration into the routines field teams already used.
- Reframe around value: start from where revenue is actually missed.
- Redesign the operating model: customer-centric and machine-centric at once.
- Build only what enables the model: connect the existing estate, do not replace it wholesale.
- Deploy for adoption, not for a go-live date: short cycles, governance, country onboarding.
Operating model
What the organization now runs on is a single shared view that resolves at three levels: one customer, one customer operating across several countries, and an entire geography under analysis. That is what allows Sales and Service to act on the same object without negotiating whose data is correct. Maintenance and machine-upgrade opportunities moved from a reactive posture, where the trigger was a customer call, to a proactive and predictive one, where the due dates and the service history generate the work list that guides operational teams.
- One shared view, resolving at customer, multi-country customer and geography level.
- Sales and Service act on the same object, not on competing extracts.
- Maintenance and upgrades shifted from reactive to proactive and predictive.
Evidence
The rollout covered more than 30 countries and several thousand machines, on one shared customer- and machine-centric view. The first delivery paid for itself inside the first year. Figures in this brief are deliberately expressed as ranges: the client is not named, and precise counts would narrow the identification of an anonymized engagement more than they would inform the reader.
- More than 30 countries onboarded.
- Several thousand machines covered.
- One shared customer- and machine-centric view.
- First delivery paid back inside the first year.
Cas d’usage et impact
A large installed base that could not be systematically converted into recurring service, spare-parts and customer-development revenue, because commercial and service data was fragmented across commercial, technical and field systems.
Solution: A target operating model that is both customer-centric and machine-centric, established before any tool selection, then enabled by connecting an open-source CRM, the existing ERP, field tooling and a shared data layer.
- View of the installed base: Fragmented across systems
- Machine service history: Partial, little retained
- Maintenance and upgrade trigger: Reactive, customer-initiated
- Sales and Service alignment: Separate extracts
- View of the installed base: One shared view, 30+ countries
- Machine service history: Consolidated per machine
- Maintenance and upgrade trigger: Proactive and predictive
- Sales and Service alignment: Same object, same truth
FAQ
Why was this not a CRM project?
Because the company was already recording activity. What it could not do was turn an installed base into recurring service and spare-parts revenue, which is a question about the revenue model and the operating model, not about the system of record. Buying a larger CRM first would have produced a migration with cleaner data and the same missed revenue.
Why connect the existing systems instead of replacing them?
Because the target operating model, not the vendor landscape, defined what had to exist. Once customer, site, machine, service history and due dates were modelled correctly, the existing ERP and field tooling could serve that model. Replacing them wholesale would have added years of risk without adding anything the model required.
What made the rollout hold across so many countries?
Deployment was designed for adoption rather than for a go-live date. Short delivery cycles, explicit governance, structured country-by-country onboarding and integration into the routines field teams already used. A go-live in a country where nobody changes how they work is not a deployment.
Why are the figures given as ranges?
The engagement is anonymized. Precise country counts and machine volumes would narrow identification of the client without making the brief more useful. The pattern, the sequence and the operating model are the transferable part.
Conclusion
The transformation worked because the sequence was business first and technology second: identify where value is created, redesign the operating model, establish the data model, then implement the enabling platforms and the change routines, all of it in close proximity with the client teams. Reverse that order and the same budget buys a better-documented version of the original problem.