Index
The two possible architectures
What being "integrated" with the DMS really means
When native DMS AI is the best option
When a specialised standalone tool wins
The example of the chatbot that recommends cars
Silent failure: the danger of the overnight feed
The hybrid architecture: not all native, not all external
The real cost of an integration
What to ask before signing with a standalone tool
Dealcar's approach
Frequently asked questions
The two possible architectures
AI built into the DMS starts from the data that already exists in the system: stock with all its attributes, leads with their history, customers with their preferences, the appointment diary. The AI agent has native access to those objects and can read and write them in real time without any intermediate step.
The standalone tool is a specialised solution that connects to the DMS through an API or a data feed. It has its own AI engine, usually more specialised in its specific function, but it depends on the DMS sending it the data it needs and on the results it generates flowing back into the DMS consistently.
The practical differences between the two architectures show up in four dimensions. Data access is native in built-in AI and depends on the API or feed in the standalone tool. Set-up is faster with built-in AI if the data already exists in the system. Depth can be greater in the specialised tool for specific functions. And the risk with built-in AI is dependence on the DMS provider's roadmap, while the risk with the standalone tool is fragmentation and duplicated data.
What being "integrated" with the DMS really means
"Being integrated" doesn't mean the same thing in every commercial proposal. There are four levels of integration with important differences in practice.
The most basic level is a CSV or periodic export: the standalone tool receives a file with the DMS data once a day or once a week. Technically it's an integration, but the data can be out of date between updates.
The next level is on-demand API reads: the standalone tool queries the DMS when it needs a specific piece of data. It is more up to date than the CSV, but each query generates an API call with its own latency and possible cost.
The top level is a real-time two-way API connection: the tool reads from the DMS and also writes to it when something relevant happens (new lead, appointment created, conversation logged). This level requires mapping exactly which fields are read, what is written and how conflicts are resolved when two systems modify the same data.
The native integration level is what the DMS's own AI has: direct access to system objects with no intermediaries, in real time, with the same permissions and the same traceability as any other part of the system.
For functions where data freshness matters (recommending an available car, confirming an appointment, knowing whether a lead has already been handled), the difference between a daily CSV integration and a real-time connection can be the difference between a correct answer and a wrong one.
When native DMS AI is the best option
Native DMS AI has the edge when the workflow crosses several system objects at the same time. Handling an inbound lead, for example, means identifying the customer, seeing whether they already have a history, searching current stock for cars that match what they want, checking whether any are reserved, assigning the lead to the right salesperson and logging the conversation in the file. That workflow touches stock, customers, leads, diary and salespeople in a single conversation.
Check the comparison of AI tools for car photos.
A standalone tool can run that workflow if it has API access to all those objects, but each connection adds complexity and room for error. If stock changes while the conversation is open, the standalone tool may not know until the next sync.
Native AI also has the edge when the team doesn't want to work in more than one inbox. If salespeople already manage leads in the DMS's CRM, adding a standalone tool with its own interface creates resistance and duplicated work.
And it has the edge when traceability and permissions have to match those of the main system. If a salesperson doesn't have access to certain customer data in the DMS, the AI tool shouldn't have it either.
When a specialised standalone tool wins
A standalone tool has the edge when the function you need has a depth the DMS doesn't cover and is unlikely to cover in the short term.
Advanced vehicle photography is the clearest example. A DMS may have a basic AI photo enhancement feature, but a specialised tool such as CarCutter or Spyne has years of development focused specifically on that problem: hyper-realistic 3D backgrounds, app-guided capture, 360-degree workflows, direct integration with portals. That depth is hard to match with a general-purpose native feature.
Complex AI telephony is another case where specialists tend to win. A voice system with interruption handling, language detection, smooth handover to a human and real-time sentiment analysis requires a specialised engine that most DMSs are not going to develop in-house.
The key to deciding is whether the tool can operate reasonably autonomously without duplicating critical information, whether there is a stable API in the DMS to connect it to, and whether there is someone on the team or at the technical provider responsible for maintaining that integration over time.
The example of the chatbot that recommends cars
This example clearly shows the practical difference between the two architectures.
A buyer writes to the dealership's chatbot: "I'm looking for a diesel family car with under 80,000 km and under 20,000 euros". The chatbot has to reply with the available cars that match.
With a standalone tool that receives the catalogue via a daily feed, the chatbot can reply with the cars that were in stock at the time of the last update. If one of those cars has since been sold or reserved, the answer may be wrong. What's more, if the buyer asks "who is the salesperson responsible for that car?" or "can I reserve it now?", the standalone tool needs more connections to answer.
With native AI in the DMS, the agent checks stock in real time, knows which cars are available at that moment (not sold or reserved), can show ones from the same segment if none match exactly, knows the assigned salesperson and can create the appointment directly in their diary. All in the same conversation, with no outdated data.
The second architecture cuts steps and errors. The first may have a more sophisticated conversational engine. For workflows where real-time data is critical, native AI has a structural advantage that more frequent syncing doesn't fix.
Silent failure: the danger of the overnight feed
Silent failure is the scenario most underestimated by teams that implement standalone AI tools with feed-based integration.
The overnight feed updates the catalogue at 2 in the morning. At 9 in the morning, the first buyer reserves an SUV in the DMS. The standalone chatbot doesn't know that car is no longer available until 2 in the morning the following day. For 17 hours, any buyer who asks about that car gets a wrong answer: that it is available, when in fact it isn't.
That kind of error doesn't produce any visible error message. The system is working correctly from a technical point of view: it is answering with the data it has. The problem is that the data is out of date. That's why it's called a silent failure.
Read also the stock quality control checklist for a dealership.
The solution is an event-based or real-time query integration for data that changes often. For static data (factory equipment, model technical data), the daily feed may be enough. For operational data (stock availability, reservation status, appointment diary), real-time querying is necessary if you want correct answers.
The hybrid architecture: not all native, not all external
Most dealerships that have been working with AI for a while end up with a hybrid architecture: some native features in the DMS and some specialised tools connected via API. That's not a compromise: it can be the optimal solution if it is well designed.
The key to a hybrid architecture that works is to declare a source of truth for each data object. Stock lives in the DMS: it is the system with permission to change the availability, price and status of each vehicle. Voice conversation history can live in the specialised voice tool, but it has to sync to the DMS so the salesperson can see it. Edited photos are generated by the photography tool, but they are published from the DMS.
The problem arises when two systems have permission to modify the same data. If the DMS and the chat tool can both mark a car as reserved, there is a risk of conflict. Defining who is the source of truth for each field before implementing the integration avoids that problem.
Read also which AI tools are worth it for a used car dealer.
The real cost of an integration
An available API is not the same as a finished integration. The cost of integrating a standalone tool with the DMS has several items that rarely appear in the first commercial proposal.
Field mapping is the work of identifying which field in the tool corresponds to which field in the DMS, how different names for the same concept are reconciled and how fields that exist in one but not the other are handled.
Identity management is the problem of matching the same person across two systems: if the DMS has the customer as "García, Juan" and the chat tool has them as "Juan García" with a different email, you have to decide how to merge those records without duplicating them.
Operational errors are the situations where syncing fails: the DMS API doesn't respond, the feed arrives empty, a field changes format in an update. Someone has to be responsible for detecting and fixing those errors.
Version maintenance is the work of updating the integration when the DMS or the standalone tool releases a new version that changes the API. If nobody takes care of it, the integration can stop working without warning.
All of those costs need to be included when comparing a natively integrated tool with a standalone tool connected via API.
See also how much it costs to implement AI in a dealership with all costs included.
What to ask before signing with a standalone tool
There are five questions to ask before committing to any standalone AI tool to check that the integration will work in practice.
What type of integration does it offer with the DMS you already use? Is it a feed, a read API, a two-way connection? How often does it update?
What data does it need to read from the DMS and what does it write? Is there any critical data it can't read or write with the available integration?
Who maintains the integration when the DMS or the tool releases an update? The tool provider, the dealership or a third party?
What happens if the connection drops? Does the tool stop working, run on outdated data or have a controlled degradation mode?
What does the export or migration process include at the end of the contract? Can conversations, configured scripts, phone numbers and results be exported so that there is no dependence on the provider?
Dealcar's approach
Dealcar works as a DMS for used car dealers and independent dealerships, with stock, leads, CRM, invoicing and website in the same system. The AI features it includes start from the objects that already exist on the platform: vehicles, leads, valuations and contact channels. That reduces the number of integrations needed for the most common use cases.
For specialised features that Dealcar doesn't cover, or doesn't cover in enough depth, the right architecture is to connect a standalone tool with well-defined integration boundaries, respecting the DMS as the source of truth for operational objects.
If you're not sure exactly what a DMS is and how it differs from a CRM or an ERP, first read what a DMS is in the automotive sector and what it's for.
You can see how the platform works at dealcar.io/software-concesionario or request a demo at dealcar.io.
Frequently asked questions
Can a standalone AI tool work well without real-time integration with the DMS?
It depends on the data it needs. For functions where the data changes often (stock availability, lead status, diary), real-time integration is necessary to give correct answers. For functions where the data is stable (factory equipment, maintenance history), a daily feed may be enough.
Is it better to wait for the DMS to have the native feature or sign up for a standalone tool now?
It depends on how long the DMS will take to have that feature and on the opportunity cost of waiting. If the bottleneck the standalone tool solves has a measurable impact now (missed calls, slow vehicle listings), the cost of waiting may exceed the cost of the integration. If the DMS feature is on the near-term roadmap, it may be worth waiting to avoid the complexity of the integration.
How do you handle conflicts when two systems have different data about the same object?
With a clear source-of-truth rule defined before implementing the integration. If the DMS is the source of truth for stock, no other tool can mark a car as available or reserved: it can only read that status. If the chat tool generates a lead, the lead has to be created in the DMS and the chat tool only keeps the conversation history.
