IT systems integration in the automotive industry: common challenges

A customer calls the service desk about a car bought three years earlier at the same dealership, and the agent can’t see the purchase, only the repair history. The data isn’t lost — it just sits in a system that never had to talk to the sales system. Situations like this are the starting point for almost every integration we run in automotive.

Why automotive businesses end up with so many systems

A typical automotive business — a dealer, a service network, an importer, a fleet operator — rarely runs on a single system. There’s usually a customer relationship and vehicle sales system, a separate service system for workshop orders and repair history, a warehouse system for spare parts, sometimes a standalone accounting tool.

On top of that come integrations with manufacturer or importer systems that have to follow their own standards. Each of these systems was built at a different time, often by a different vendor, for one specific job, and it usually does that job well. The problem starts at the seams, when data from one system has to make its way into another.

Silos: when every department is right on its own

The pattern we see most often is one where each system is internally consistent but disagrees with the others. The service system knows which parts were used on a given repair. The warehouse system knows how many are left in stock. If the two don’t exchange data automatically, someone has to manually re-enter usage from one into the other.

That’s exactly where mistakes, delays, and stock discrepancies creep in. The same applies to customer data: the same person can exist as a separate record in the sales system and in the service system, with no shared identifier linking their vehicle purchase history to their service history.

The consequences of this kind of drift rarely show up right away — they surface later, as small inconsistencies someone has to manually straighten out: an agent can’t see a customer’s purchase history, or the warehouse shows a part as available when it’s actually already reserved for another repair.

A sales report and a service report for the same month don’t reconcile, because they count the same event differently. None of these is dramatic on its own, but the sum of small mismatches eats up time a team could spend elsewhere.

Format, field meaning, and data quality

When people think about integration, the first thing that comes to mind is usually the file format or protocol — an API, a CSV file, a webhook. That does need to be settled, but in practice it’s the easier part of the job. The harder part is agreeing on what a given field actually means in each system.

Whether “order status” in the service system maps to the same stage of the process as “repair status” shown to the customer, or whether a part number in the warehouse system is the same identifier used in the supplier’s ordering system. An integration that moves data around without reconciling its meaning just moves the mess from one place to another — faster, but not more accurately.

As long as systems run separately, inconsistencies in the data — typos in part names, duplicate customer records, outdated contact details — usually don’t stand out, because each department works around them in its own way. Integration changes that: once data starts flowing automatically between systems, every inconsistency at the source gets replicated everywhere the data lands.

That’s one reason it’s worth treating integration as an opportunity to clean up data, not just a technical link between two systems — moving files or API calls around won’t fix a data quality problem on its own if it isn’t addressed separately.

Where AI actually fits here

In automotive systems integration, working with documents and unstructured data — workshop orders written up in free text, vehicle handover reports, correspondence with parts suppliers — is an area where AI can genuinely take work off a team’s plate: reading and classifying these documents, matching them to the right records in the target systems.

Following the same principle we apply across all our AI implementations, the language model handles reading and recognizing content, while actually writing data into a system — respecting integrity rules, foreign keys, and validation — is left to code that behaves deterministically. We go into this mechanism in more detail in integrating AI with legacy business systems — the same obstacles described there show up in practice in automotive integrations.

Automation of processes, not just data exchange

Systems integration is often the first step, followed by a question about automating the processes those systems connect — for instance, auto-generating a service order from a customer request, or auto-replenishing parts stock based on projected usage.

We go into where process automation makes sense for automotive businesses in a separate article on process automation for automotive businesses — the integration described above is usually a prerequisite before that kind of automation becomes possible at all.

In short

A common mistake in IT integrations is starting from the technical side — picking a tool, settling on a protocol, writing the first connections — before anyone documents what data actually exists and where it contradicts itself. Our experience building and maintaining software for the automotive sector points to one conclusion: integration is best started by mapping the data, not by writing the first line of code. Our automotive experience is described on our solutions page.

Frequently asked questions

Why do automotive businesses end up with so many separate IT systems?

Because each system — dealer management, service, warehouse — was built for one specific job and usually does it well. The problem only appears at the seams, when data needs to flow between them.

Is systems integration mostly a question of data format and APIs?

That’s the easier part of the job. The harder part is agreeing on what fields mean across systems, and which system is the source of truth for a given kind of data.

Can AI write data directly into a live system on its own?

In our approach, AI reads and classifies data from unstructured documents, while the actual write into a system, with integrity rules respected, is handled by deterministic code — not the language model.

Is it worth integrating systems before even planning process automation?

Yes — systems integration is usually a prerequisite for automating the processes those systems connect. Without consistent data flowing automatically between systems, it’s hard to build reliable automation on top.

What’s harder: connecting the systems or fixing data quality?

In our experience, data quality. Technically connecting two systems can be quick; surfacing and fixing the inconsistencies that integration exposes usually takes longer.