Índice
Las dos arquitecturas posibles
Qué significa realmente "estar integrado" con el DMS
Cuándo la IA nativa del DMS es la mejor opción
Cuándo una herramienta independiente especializada gana
El ejemplo del chatbot que recomienda coches
El fallo silencioso: el peligro del feed nocturno
La arquitectura híbrida: no es todo nativo ni todo externo
El coste real de una integración
Qué preguntar antes de firmar con una herramienta independiente
El enfoque de Dealcar
Preguntas frecuentes
Las dos arquitecturas posibles
La IA integrada en el DMS parte de los datos que ya existen en el sistema: el stock con todos sus atributos, los leads con su historial, los clientes con sus preferencias, la agenda de citas. El agente de IA tiene acceso nativo a esos objetos y puede leerlos y escribirlos en tiempo real sin ningún paso intermedio.
La herramienta independiente es una solución especializada que se conecta al DMS a través de una API o un feed de datos. Tiene su propio motor de IA, habitualmente más especializado en su función concreta, pero depende de que el DMS le envíe los datos necesarios y de que los resultados que genera vuelvan al DMS de forma coherente.
Las diferencias prácticas entre las dos arquitecturas se ven en cuatro dimensiones. El acceso a los datos es nativo en la IA integrada y depende de la API o el feed en la herramienta independiente. La puesta en marcha es más rápida en la IA integrada si el dato ya existe en el sistema. La profundidad puede ser mayor en la herramienta especializada para funciones concretas. Y el riesgo de la IA integrada es la dependencia de la hoja de ruta del proveedor del DMS, mientras que el riesgo de la herramienta independiente es la fragmentación y la duplicación de datos.
Qué significa realmente "estar integrado" con el DMS
"Estar integrado" no significa lo mismo en todas las propuestas comerciales. Hay cuatro niveles de integración con diferencias importantes en la práctica.
El nivel más básico es el CSV o exportación periódica: la herramienta independiente recibe un archivo con los datos del DMS una vez al día o una vez a la semana. Es técnicamente una integración, pero los datos pueden estar desactualizados entre actualizaciones.
El nivel siguiente es la lectura por API en consulta: la herramienta independiente consulta al DMS cuando necesita un dato concreto. Es más actualizado que el CSV, pero cada consulta genera una llamada a la API con su latencia y su posible coste.
El nivel superior es la conexión bidireccional por API en tiempo real: la herramienta lee del DMS y también escribe en él cuando ocurre algo relevante (nuevo lead, cita creada, conversación registrada). Este nivel requiere mapear exactamente qué campos se leen, qué se escribe y cómo se resuelven los conflictos cuando dos sistemas modifican el mismo dato.
El nivel de integración nativa es el que tiene la IA del propio DMS: acceso directo a los objetos del sistema sin intermediarios, en tiempo real, con los mismos permisos y la misma trazabilidad que cualquier otra parte del sistema.
Para funciones donde la actualidad del dato importa (recomendar un coche disponible, confirmar una cita, saber si un lead ya está atendido), la diferencia entre una integración por CSV diario y una conexión en tiempo real puede ser la diferencia entre una respuesta correcta y una incorrecta.
Cuándo la IA nativa del DMS es la mejor opción
La IA nativa del DMS tiene ventaja cuando el flujo de trabajo cruza varios objetos del sistema de forma simultánea. Atender un lead entrante, por ejemplo, implica identificar al cliente, ver si ya tiene historial, buscar coches que encajen con su búsqueda en el stock actual, comprobar si alguno está reservado, asignar el lead al comercial correcto y registrar la conversación en el expediente. Ese flujo toca stock, clientes, leads, agenda y comerciales en una sola conversación.
Consulta la comparativa de herramientas de IA para fotos de coches.
Una herramienta independiente puede hacer ese flujo si tiene acceso a todos esos objetos por API, pero cada conexión añade complejidad y posibilidad de error. Si el stock cambia mientras la conversación está abierta, la herramienta independiente puede no saberlo hasta la próxima sincronización.
La IA nativa también tiene ventaja cuando el equipo no quiere trabajar en más de una bandeja. Si los comerciales ya gestionan leads en el CRM del DMS, añadir una herramienta independiente con su propia interfaz genera resistencia y duplicación de trabajo.
Y tiene ventaja cuando la trazabilidad y los permisos tienen que coincidir con los del sistema principal. Si un comercial no tiene acceso a ciertos datos del cliente en el DMS, la herramienta de IA tampoco debería tenerlos.
Cuándo una herramienta independiente especializada gana
Una herramienta independiente tiene ventaja cuando la función que se necesita tiene una profundidad que el DMS no cubre y que es poco probable que cubra a corto plazo.
La fotografía avanzada de vehículos es el ejemplo más claro. Un DMS puede tener una funcionalidad básica de mejora de fotos con IA, pero una herramienta especializada como CarCutter o Spyne tiene años de desarrollo específico en ese problema: fondos 3D hiperrealistas, captura guiada con app, flujos de 360 grados, integración directa con portales. Esa profundidad es difícil de igualar con una funcionalidad nativa de propósito general.
La telefonía compleja con IA es otro caso donde los especialistas suelen ganar. Un sistema de voz con manejo de interrupciones, detección de idioma, transferencia suave a humano y análisis de sentimiento en tiempo real requiere un motor especializado que la mayoría de DMS no van a desarrollar internamente.
La clave para decidir es si la herramienta puede operar de forma razonablemente autónoma sin duplicar información crítica, si existe una API estable en el DMS para conectarla, y si hay alguien en el equipo o en el proveedor técnico responsable de mantener esa integración a lo largo del tiempo.
El ejemplo del chatbot que recomienda coches
Este ejemplo muestra con claridad la diferencia práctica entre las dos arquitecturas.
Un comprador escribe al chatbot del concesionario: "busco un familiar diesel de menos de 80.000 km y menos de 20.000 euros". El chatbot tiene que responder con los coches disponibles que encajan.
Con una herramienta independiente que recibe el catálogo por feed diario, el chatbot puede responder con los coches que había en el stock al momento de la última actualización. Si desde entonces se ha vendido uno de esos coches o se ha reservado, la respuesta puede ser incorrecta. Además, si el comprador pregunta "¿quién es el comercial responsable de ese coche?" o "¿puedo reservarlo ahora?", la herramienta independiente necesita más conexiones para responder.
Con IA nativa en el DMS, el agente consulta el stock en tiempo real, sabe qué coches están disponibles en ese momento (no vendidos ni reservados), puede mostrar los del mismo segmento si ninguno encaja exactamente, conoce al comercial asignado y puede crear la cita directamente en su agenda. Todo en la misma conversación, sin datos desactualizados.
La segunda arquitectura reduce pasos y errores. La primera puede tener un motor conversacional más sofisticado. Para flujos donde el dato en tiempo real es crítico, la IA nativa tiene una ventaja estructural que no se resuelve con más frecuencia de sincronización.
El fallo silencioso: el peligro del feed nocturno
El fallo silencioso es el escenario que más subestiman los equipos que implementan herramientas de IA independientes con integración por feed.
El feed nocturno actualiza el catálogo a las 2 de la madrugada. A las 9 de la mañana, el primer comprador reserva un SUV en el DMS. El chatbot independiente no sabe que ese coche ya no está disponible hasta las 2 de la madrugada del día siguiente. Durante 17 horas, cualquier comprador que pregunte por ese coche recibe una respuesta incorrecta: que está disponible, cuando en realidad no lo está.
Ese tipo de error no genera ningún mensaje de error visible. El sistema funciona correctamente desde el punto de vista técnico: está respondiendo con los datos que tiene. El problema es que los datos están desactualizados. Por eso se llama fallo silencioso.
Lee también el checklist de control de calidad del stock en un concesionario.
La solución es una integración basada en eventos o en consulta en tiempo real para los datos que cambian con frecuencia. Para los datos estáticos (equipamiento de fábrica, datos técnicos del modelo), el feed diario puede ser suficiente. Para los datos operativos (disponibilidad del stock, estado de reserva, agenda de citas), la consulta en tiempo real es necesaria si se quieren respuestas correctas.
La arquitectura híbrida: no es todo nativo ni todo externo
La mayoría de concesionarios que llevan un tiempo trabajando con IA acaban con una arquitectura híbrida: algunas funcionalidades nativas en el DMS y algunas herramientas especializadas conectadas por API. Eso no es un compromiso: puede ser la solución óptima si está bien diseñada.
La clave de una arquitectura híbrida que funciona es declarar una fuente de verdad para cada objeto de datos. El stock vive en el DMS: es el sistema que tiene permiso para modificar la disponibilidad, el precio y el estado de cada vehículo. El historial de conversaciones de voz puede vivir en la herramienta de voz especializada, pero tiene que sincronizarse al DMS para que el comercial lo vea. Las fotos editadas las genera la herramienta de fotografía, pero se publican desde el DMS.
El problema aparece cuando dos sistemas tienen permiso para modificar el mismo dato. Si el DMS y la herramienta de chat pueden los dos marcar un coche como reservado, hay un riesgo de conflicto. Definir quién es la fuente de verdad de cada campo antes de implementar la integración evita ese problema.
Lee también qué herramientas de IA merecen la pena para una compraventa.
El coste real de una integración
Una API disponible no equivale a una integración terminada. El coste de integrar una herramienta independiente con el DMS tiene varias partidas que raramente aparecen en la primera propuesta comercial.
El mapeo de campos es el trabajo de identificar qué campo de la herramienta corresponde a qué campo del DMS, cómo se resuelven los nombres distintos para el mismo concepto y cómo se gestionan los campos que existen en uno pero no en el otro.
La gestión de identidades es el problema de unir la misma persona en dos sistemas: si el DMS tiene al cliente como "García, Juan" y la herramienta de chat lo tiene como "Juan García" con un email diferente, hay que decidir cómo unir esos registros sin duplicar.
Los errores operativos son las situaciones donde la sincronización falla: la API del DMS no responde, el feed llega vacío, un campo cambia de formato en una actualización. Alguien tiene que ser responsable de detectar y resolver esos errores.
El mantenimiento de versiones es el trabajo de actualizar la integración cuando el DMS o la herramienta independiente publican una nueva versión que cambia la API. Si nadie se ocupa de eso, la integración puede dejar de funcionar sin aviso.
Todos esos costes hay que incluirlos en la comparativa entre una herramienta integrada nativamente y una herramienta independiente conectada por API.
Consulta también cuánto cuesta implementar IA en un concesionario con todos los costes incluidos.
Qué preguntar antes de firmar con una herramienta independiente
Hay cinco preguntas que hay que hacer antes de comprometerse con cualquier herramienta de IA independiente para verificar que la integración va a funcionar en la práctica.
¿Qué tipo de integración ofrece con el DMS que ya se usa? ¿Es un feed, una API de lectura, una conexión bidireccional? ¿Con qué frecuencia se actualiza?
¿Qué datos necesita leer del DMS y cuáles escribe? ¿Hay algún dato crítico que no puede leer o escribir con la integración disponible?
¿Quién mantiene la integración cuando el DMS o la herramienta publican una actualización? ¿El proveedor de la herramienta, el concesionario, o un tercero?
¿Qué pasa si la conexión se interrumpe? ¿La herramienta deja de funcionar, funciona con datos desactualizados o tiene un modo de degradación controlada?
¿Qué incluye el proceso de exportación o migración al terminar el contrato? ¿Se pueden exportar las conversaciones, los guiones configurados, los números de teléfono y los resultados de forma que no haya dependencia del proveedor?
El enfoque de Dealcar
Dealcar funciona como DMS para compraventas y concesionarios independientes, con stock, leads, CRM, facturación y web en el mismo sistema. Las funcionalidades de IA que incorpora parten de los objetos que ya existen en la plataforma: vehículos, leads, tasaciones y canales de contacto. Eso reduce el número de integraciones necesarias para los casos de uso más frecuentes.
Para funcionalidades especializadas que Dealcar no cubre o no cubre con suficiente profundidad, la arquitectura correcta es conectar una herramienta independiente con límites de integración bien definidos, respetando el DMS como fuente de verdad de los objetos operativos.
Si no tienes claro qué es exactamente un DMS y en qué se diferencia de un CRM o un ERP, consulta primero qué es un DMS en automoción y para qué sirve.
Puedes ver cómo funciona la plataforma en dealcar.io/software-concesionario o solicitar una demo en dealcar.io.
Preguntas frecuentes
¿Puede una herramienta de IA independiente funcionar bien sin integración en tiempo real con el DMS?
Depende de los datos que necesite. Para funciones donde el dato cambia con frecuencia (disponibilidad del stock, estado de leads, agenda), la integración en tiempo real es necesaria para dar respuestas correctas. Para funciones donde el dato es estable (equipamiento de fábrica, historial de mantenimiento), un feed diario puede ser suficiente.
¿Es mejor esperar a que el DMS tenga la funcionalidad nativa o contratar una herramienta independiente ahora?
Depende de cuánto tiempo va a tardar el DMS en tener esa funcionalidad y del coste de oportunidad de esperar. Si el cuello de botella que resuelve la herramienta independiente tiene un impacto medible ahora (llamadas perdidas, altas lentas de vehículos), el coste de esperar puede superar el coste de la integración. Si la funcionalidad del DMS está en el roadmap próximo, puede merecer esperar para evitar la complejidad de la integración.
¿Cómo se gestiona el conflicto cuando dos sistemas tienen datos distintos sobre el mismo objeto?
Con una regla clara de fuente de verdad definida antes de implementar la integración. Si el DMS es la fuente de verdad del stock, ninguna otra herramienta puede marcar un coche como disponible o reservado: solo puede leer ese estado. Si la herramienta de chat genera un lead, el lead tiene que crearse en el DMS y la herramienta de chat solo conserva el historial de la conversación.
