Cómo construimos un sistema de ventas con IA para un alquiler de autos en Dubái (YETI)

Las solicitudes de alquiler de autos llegan a cualquier hora. El cliente escribe por WhatsApp y pregunta por disponibilidad, fechas, precio, seguro, depósito y entrega. Para convertir esa conversación en una reserva, un agente tiene que reunir decenas de datos, uno por uno.

Mientras el agente está ocupado o durmiendo, el cliente sigue buscando. La mayoría de las veces, la reserva se la queda el alquiler que respondió primero.

Para YETI construimos no solo un chatbot, sino un sistema de ventas con IA hecho a medida. Recibe las solicitudes de WhatsApp, entiende el pedido, guía al cliente por el proceso de reserva, obtiene datos actualizados de los vehículos, verifica documentos y arma un negocio listo en Kommo CRM.

En este sistema, WhatsApp es solo la interfaz de conversación con el cliente. El trabajo de verdad ocurre dentro de una arquitectura de servidor que gestiona agentes de IA, datos, colas de mensajes y el estado de cada negocio.

El proyecto en números

Dentro de la solución:

• 3 agentes de IA especializados;
• 12 etapas de reserva;
• WhatsApp Business como canal principal;
• Kommo CRM como sistema de trabajo de los agentes;
• una base de datos separada de autos y tarifas;
• llenado automático de la ficha del negocio;
• reconocimiento de documentos con visión artificial;
• soporte de ruso e inglés;
• almacenamiento del contexto de la conversación;
• colas de mensajes entrantes;
• protección contra el procesamiento en paralelo de un mismo negocio;
• protección contra el envío de respuestas duplicadas;
• nuestra propia aplicación de servidor.

La primera versión funcional se construyó en n8n. Después de validar la lógica en conversaciones reales, todo el sistema se trasladó a una aplicación independiente en Node.js.

Por qué un chatbot común no bastaba

Desde fuera, alquilar un auto puede parecer simple:

Pero ese pedido no alcanza para ofrecer un auto concreto y calcular las condiciones del alquiler.

El agente necesita averiguar:

• la ciudad del alquiler;
• la fecha de inicio;
• la duración del alquiler;
• la categoría de auto preferida;
• un modelo adecuado;
• el tipo de seguro;
• las condiciones del depósito;
• los servicios adicionales;
• cómo se retirará el auto;
• los datos de contacto;
• los documentos necesarios.

Y el cliente rara vez envía todo en un solo mensaje. Una conversación típica se ve así:

Para una persona, esto es un único pensamiento dividido en varios mensajes. Para un sistema de software, son varios eventos separados que pueden llegar — y empezar a procesarse — al mismo tiempo.

Por eso la tarea no era solo enseñarle a la IA a responder preguntas. Había que construir un proceso controlado en el que el sistema:

1. entiende lo que el cliente ya dijo;
2. determina la etapa actual de la reserva;
3. pide solo los datos que faltan;
4. obtiene la información actualizada de la base de datos;
5. guarda el resultado en el CRM;
6. pasa la conversación a un agente en el momento correcto.

Cómo funciona el sistema

El flujo general se ve así:

A este proceso también está conectado un agente de IA aparte, que analiza las fotos de los documentos.

Cuando el cliente escribe por WhatsApp, el mensaje no va directo al modelo de lenguaje. Primero el sistema identifica al cliente y al negocio, guarda el mensaje, verifica si el negocio ya se está procesando y espera a ver si el cliente envía una continuación.

Después, varios mensajes cortos pueden unirse en una sola solicitud. Por ejemplo:

El sistema le entrega a la IA no cuatro eventos independientes, sino un único pensamiento armado:

Luego el administrador de IA analiza el historial de la conversación, los datos del negocio y la etapa actual de la reserva. Determina qué se sabe ya, qué falta y qué acción ejecutar a continuación. Puede ser:

• pedir la ciudad;
• confirmar la fecha;
• guardar la duración del alquiler;
• obtener autos de la base de datos;
• mostrar opciones;
• solicitar un documento;
• llenar un campo en Kommo;
• pasar la conversación a un agente.

Después de eso, un presentador de IA aparte redacta la respuesta al cliente.

Por qué trabajan tres agentes de IA por dentro

Al principio se puede intentar que un solo modelo haga todo a la vez: entender al cliente, gestionar las etapas, buscar autos, tomar decisiones, escribir respuestas y verificar documentos.

En conversaciones largas ese enfoque se vuelve impredecible. El modelo puede saltarse datos que ya tiene, hacer varias preguntas a la vez, ofrecer un auto que no existe o cambiar las condiciones del alquiler por su cuenta.

Por eso dividimos el sistema en tres roles acotados.

1. El administrador de IA

Es el agente que controla el sistema. No habla directamente con el cliente. Su tarea es decidir la siguiente acción.

El administrador recibe:

• el mensaje nuevo;
• el historial de la conversación;
• los datos de la ficha del negocio en Kommo;
• la etapa actual de la reserva;
• los datos ya cargados;
• las acciones disponibles del sistema.

Tras el análisis devuelve una decisión estructurada:

• qué campo guardar;
• qué etapa está fijada ahora;
• si hay datos suficientes para buscar un auto;
• si hay que consultar la base de datos;
• si hay que verificar un documento;
• qué pregunta hacer;
• si es momento de pasar el negocio a un agente.

El administrador no puede inventar precios, modelos ni condiciones. Los datos comerciales los obtiene solo de la base de datos.

2. El presentador de IA

Es el único agente que le escribe al cliente. Toma la decisión ya lista del administrador y la convierte en un mensaje corto y natural en el idioma del cliente.

Por ejemplo, el administrador decide:

El presentador lo formula:

La restricción principal del presentador es una pregunta por mensaje. No le entrega al cliente un formulario de ocho puntos ni sobrecarga la conversación. El proceso se siente como una conversación normal con un agente.

3. El agente de IA de verificación de documentos

Este agente entra en acción cuando el cliente envía la foto de un documento. Analiza la imagen y determina:

• si el archivo es realmente un documento;
• qué tipo de documento es;
• si la foto es legible;
• si quedaron cortadas áreas importantes;
• si se puede continuar con el trámite.

El sistema acepta pasaporte, Emirates ID o licencia de conducir. Con un documento adecuado ya basta para continuar.

La IA no toma la decisión legal sobre si el cliente puede alquilar. Solo descarta imágenes claramente inadecuadas y pide una nueva foto si el documento no se puede leer. La decisión final queda en manos del personal del alquiler.

Las 12 etapas de la reserva

La conversación se construye en torno a un estado formal del negocio. El sistema siempre sabe en qué etapa está el cliente y qué datos ya se recopilaron. El proceso tiene 12 etapas:

1. Definición de la ciudad, la fecha de inicio y la duración del alquiler.
2. Elección de la categoría de auto.
3. Búsqueda de autos disponibles.
4. Elección de un modelo concreto.
5. Elección del seguro.
6. Elección de las condiciones del depósito.
7. Elección de servicios adicionales.
8. Entrega o retiro.
9. Confirmación de las condiciones finales.
10. Recepción y verificación de documentos.
11. Confirmación de los datos de contacto.
12. Pase del negocio a un agente y apagado de la IA.

Las etapas no significan que el bot haga mecánicamente 12 preguntas seguidas. El cliente puede escribir de entrada:

El sistema extraerá de ese mensaje la ciudad, la categoría, la fecha y la duración. Esos datos se guardan, y la IA no los volverá a preguntar.

Condiciones estrictas entre etapas

Algunas etapas no se pueden saltar. Por ejemplo, el sistema no debe mostrar autos mientras no sepa:

• la ciudad;
• la fecha de inicio;
• la duración del alquiler;
• la categoría de auto.

Sin esos datos no se puede verificar la disponibilidad ni fijar el precio correctamente. Por eso, antes de consultar la base de datos, el sistema verifica los campos obligatorios. Si falta alguno, la IA sigue recopilando datos.

Este mecanismo impide que el modelo «ayude al cliente» con una respuesta inventada. La IA no decide qué autos existen. Decide qué datos pedir, y obtiene la lista de autos de una fuente de verdad separada.

De dónde saca la IA los autos y los precios

La información de la flota se almacena aparte del modelo de lenguaje. En la base de datos están:

• modelos de autos;
• categorías;
• ciudades;
• tarifas;
• restricciones;
• opciones disponibles;
• condiciones adicionales.

Cuando los datos obligatorios están reunidos, el administrador de IA llama a una función de búsqueda en el servidor. La función devuelve solo los autos que coinciden con el pedido del cliente. Después, el presentador arma una oferta clara.

Cómo llegan los datos a Kommo

Kommo no es solo donde se guarda la conversación. A lo largo de la conversación, el sistema actualiza la ficha del negocio:

• ciudad;
• fecha de inicio del alquiler;
• duración;
• categoría elegida;
• auto elegido;
• seguro;
• depósito;
• servicios adicionales;
• forma de retiro;
• estado de los documentos;
• idioma del cliente;
• etapa actual de la reserva.

Cuando la IA le pasa el negocio a un agente, este no tiene que releer toda la conversación ni copiar los datos a mano. Recibe una ficha estructurada, con los datos ya recopilados. La conversación queda en Kommo, así que el agente puede revisar el contexto y seguir desde donde quedó.

El problema de ingeniería que el cliente no ve

La parte más difícil de proyectos así no es redactar las respuestas. Los problemas principales surgen en torno a los eventos paralelos, la persistencia del estado y la sincronización de varios sistemas.

El cliente envía varios mensajes seguidos

Una persona puede enviar cuatro mensajes en cinco segundos. Si ejecutas la IA con cada uno, el sistema genera varias respuestas en paralelo.

Por eso agregamos una ventana de agregación. Después de un mensaje entrante, el sistema hace una pausa breve. Si llegan mensajes nuevos en ese lapso, se unen y se procesan juntos.

Un mismo negocio no se puede procesar en paralelo

Mientras el sistema arma una respuesta, el cliente puede enviar otro mensaje. Sin un bloqueo, dos procesos leen el mismo estado del negocio a la vez y empiezan a modificarlo. El resultado puede ser:

• dos respuestas;
• acciones duplicadas;
• valores de campo en conflicto;
• la etapa de reserva equivocada.

Para evitarlo, el negocio se bloquea durante el procesamiento. En cada momento, un solo proceso maneja un negocio determinado. Los eventos nuevos esperan en la cola.

WhatsApp y el CRM deben mantenerse sincronizados

Un mensaje pasa por varios sistemas: WhatsApp, el canal, Kommo, la aplicación de servidor, el modelo de IA y la base de datos. Cualquier evento puede entregarse dos veces o con retraso. Por eso el sistema guarda los identificadores de los eventos ya procesados y, antes de enviar, verifica si esa respuesta ya se produjo.

El estado no puede vivir solo en el historial del chat

El historial de mensajes importa, pero por sí solo no es un estado confiable del negocio. Por eso se almacenan aparte:

• la etapa actual;
• los datos recopilados;
• el auto elegido;
• las opciones mostradas antes;
• el idioma del cliente;
• el estado del pase al agente;
• el resultado de la verificación del documento.

La IA recibe esa estructura junto con el historial, en vez de reconstruir todo el proceso desde cero en cada mensaje.

Primera versión: un arranque rápido en n8n

La primera versión del sistema la construimos en n8n. Para prototipar fue la decisión correcta. n8n nos permitió conectar Kommo rápido, recibir mensajes, llamar a la IA, probar prompts, trabajar con la base de autos, verificar documentos y lanzar las primeras conversaciones reales.

Así probamos no una presentación ni un concepto abstracto, sino el proceso real con solicitudes en vivo. A medida que el proyecto creció, el diagrama llegó a cerca de cien nodos. En ese punto aparecieron los límites.

Complejidad de los cambios

Un pequeño ajuste podía afectar varias ramas del proceso. Antes de cada cambio había que verificar que no rompiera la lógica vecina.

Colas y bloqueos

Un constructor visual maneja bien las integraciones secuenciales, pero gestiona con más dificultad los mensajes paralelos, los bloqueos y la reentrega de eventos. La fiabilidad había que sostenerla con construcciones alternativas.

Depuración

Cuando un proceso tiene decenas de ramas y cerca de cien nodos, encontrar la causa de un error lleva cada vez más tiempo. Hay que averiguar qué rama se ejecutó, qué datos había en cada nodo, si arrancó un segundo proceso, dónde cambió el estado y por qué se envió una respuesta concreta.

Mantenimiento

El sistema ya atendía a clientes reales. Eso significaba que había que no solo desarrollarlo, sino también actualizarlo con seguridad. En cierto momento, el costo de mantener el proceso visual superó al de mover la lógica a código.

n8n cumplió su función: nos permitió validar la hipótesis del producto rápido. Pero el sistema de producción había superado el formato de prototipo.

Migración a nuestra propia aplicación

Después de validar la lógica de negocio, movimos el sistema a una aplicación de servidor independiente en Node.js. El comportamiento para el cliente quedó igual:

• el mismo WhatsApp;
• el mismo estilo de conversación;
• las mismas etapas;
• los mismos autos;
• el mismo pase al agente.

Lo que cambió fue la arquitectura interna. La lógica se dividió en módulos independientes:

• recepción de eventos;
• agregación de mensajes;
• la cola de procesamiento;
• bloqueo de negocios;
• almacenamiento del estado;
• el administrador de IA;
• el presentador de IA;
• la verificación de documentos;
• la integración con Kommo;
• el trabajo con la base de autos;
• el envío de mensajes;
• el registro de errores.

Después de la migración, cada parte se puede cambiar y probar por separado.

Stack tecnológico

La versión final usa:

• Node.js — el entorno de servidor;
• Express — la recepción de eventos entrantes y la capa HTTP;
• Redis — colas, estado temporal y bloqueos;
• PostgreSQL — autos, tarifas y datos persistentes;
• Kommo API — negocios, campos, etapas y la conversación;
• WhatsApp Business API — el canal de comunicación;
• OpenAI GPT — análisis de la conversación y generación de respuestas;
• visión artificial (un modelo de visión) — análisis de las imágenes de documentos;
• Docker — despliegue de los servicios;
• Git — control de versiones del código y de los prompts.

Los prompts de los agentes de IA se almacenan aparte de la lógica principal de la aplicación y también tienen versionado. Eso permite ver qué regla estaba vigente en un momento dado, comparar versiones y revertir un cambio si hace falta.

Cómo evolucionó el proyecto

El proyecto pasó por varias etapas sucesivas.

• Versión 1. Prueba de concepto. Una IA básica responde mensajes y recopila parte de los datos.
• Versión 2. Un proceso formal de reserva. La conversación se divide en etapas. Aparecen el estado del negocio y las condiciones obligatorias de transición.
• Versión 3. Integración con la flota real. La IA deja de ofrecer autos por su cuenta y pasa a obtenerlos de la base de datos.
• Versión 4. Tres agentes especializados. Se separan la toma de decisiones, la redacción de respuestas y el análisis de documentos.
• Versión 5. Trabajo con colas de mensajes. Se añaden la agregación de mensajes, los bloqueos de negocios y la protección contra duplicados.
• Versión 6. Verificación de documentos. El sistema empieza a analizar las imágenes enviadas y a pedir una foto nueva cuando hace falta.
• Versión 7. Migración desde n8n. Una vez validado el proceso, toda la lógica de producción se movió a nuestra propia aplicación.
• Versión 8. Operación gestionada. Se añaden registro de logs, versionado de prompts, control de errores y la posibilidad de cambiar componentes individuales con seguridad.

Lo que tuvimos que rehacer

El proyecto no surgió en su forma final de una vez. Algunos componentes los reescribimos varias veces. En particular:

• cambiamos el modelo de almacenamiento del estado de la conversación;
• rehicimos el manejo de varios mensajes seguidos;
• reforzamos la protección contra respuestas paralelas;
• dividimos las funciones de una IA entre varios agentes;
• cambiamos las reglas de transición entre etapas;
• rehicimos el mecanismo de selección de autos;
• movimos la lógica de n8n a Node.js;
• sacamos los prompts del proceso a archivos separados y versionados.

Es una parte normal de construir un sistema de IA que trabaja con clientes reales, no en una demostración. Lo difícil aquí no es obtener del modelo una respuesta bonita. Lo difícil es hacer que el comportamiento del sistema sea robusto ante datos incompletos, eventos repetidos, mensajes fuera de lo común y conversaciones paralelas.

Lo que el sistema no hace

YETI no reemplaza a todo el equipo de ventas. El sistema deliberadamente no hace ciertas cosas.

• No toma la decisión final sobre el cliente. La IA puede verificar el tipo y la calidad de la foto de un documento, pero no decide la elegibilidad legal para alquilar.
• No cobra ni entrega el auto. El pago, el contrato, la confirmación final y la entrega del auto quedan en manos de una persona.
• No inventa disponibilidad ni precios. Todos los datos comerciales vienen de la base de datos.
• No sigue conversando después del pase. Cuando el negocio está listo, la IA entra en modo cerrado. A partir de ahí, un humano toma el control.
• No intenta resolver cualquier disputa por su cuenta. Las situaciones fuera de lo común y las preguntas delicadas pasan a una persona.

El objetivo del sistema no es sacar a las personas del proceso. Es quitarles la parte rutinaria y entregarle al agente un cliente en el momento en que hace falta una decisión humana.

Qué cambió para el negocio

Tras la implementación, la forma de atender una solicitud quedó estandarizada.

• Las solicitudes se atienden las 24 horas. La primera respuesta ya no depende del horario de los agentes. Las solicitudes de la madrugada entran directo a la calificación.
• Los datos se recopilan de forma consistente. El sistema no se olvida de preguntar la fecha, la duración, la ciudad, el seguro o el depósito.
• El agente recibe un negocio preparado. Los principales datos del alquiler ya están cargados en la ficha de Kommo. El empleado entra no en el primer mensaje, sino en una solicitud ya formada.
• Los autos se ofrecen desde la disponibilidad real. La IA no se basa en su propio conocimiento de modelos y precios — la oferta se arma con los datos de la flota.
• La conversación no depende del idioma del agente. El sistema responde en ruso o inglés según el idioma del cliente.
• La arquitectura se puede escalar. Las nuevas etapas, idiomas, reglas, tarifas e integraciones se añaden como componentes separados, no como extensiones de un único script gigante.

No publicamos cifras de crecimiento de conversión o de facturación: esos datos pertenecen al cliente. El resultado verificable del proyecto es un sistema de producción en funcionamiento que recibe solicitudes las 24 horas, lleva al cliente por un proceso formal, se sincroniza con el CRM y le entrega al agente un negocio estructurado.

Qué hace falta para crear un sistema así

Para meter IA en un proceso de ventas real, conectar un modelo de lenguaje a WhatsApp no alcanza. Hay que diseñar todo el sistema en orden.

1. Formalizar el proceso de negocio

Describe qué debe recibir el agente, qué datos son obligatorios, en qué orden recopilarlos, qué etapas no se pueden saltar y en qué punto entra un humano.

2. Definir las fuentes de verdad

La IA no debe inventar precios, disponibilidad, tarifas, descuentos, plazos ni condiciones comerciales. Cada tipo de dato necesita una fuente controlada.

3. Separar las decisiones de la redacción

El agente que lleva el proceso y el agente que habla con el cliente hacen trabajos distintos. Separarlos hace al sistema más predecible.

4. Almacenar un estado formal

Con el historial de la conversación no alcanza. La etapa del negocio y los datos recopilados deben almacenarse aparte.

5. Diseñar el procesamiento en paralelo

Antes de lanzar, decide cómo unir los mensajes cortos, cómo bloquear un negocio, cómo manejar los eventos repetidos, cómo evitar respuestas duplicadas y cómo recuperar el proceso tras un error.

6. Conectar el CRM como parte del proceso

La IA no solo debe responder, sino también modificar el sistema de trabajo: llenar campos, mover etapas, guardar resultados, pasar la responsabilidad y apagarse tras entregar a una persona.

7. Empezar con un lanzamiento controlado

Enciende el sistema primero en una parte limitada de las conversaciones, analiza las atenciones reales y ajusta las reglas.

Conclusión

Para YETI construimos un sistema de ventas con IA hecho a medida para un alquiler de autos. Reúne WhatsApp, Kommo CRM, la base de autos, tres agentes de IA, visión artificial, colas de mensajes y lógica de servidor.

El cliente ve una conversación común por WhatsApp. Pero detrás de esa conversación corre un sistema que entiende el pedido, gestiona las etapas de la reserva, guarda el estado del negocio, obtiene autos actualizados, verifica documentos, llena el CRM, se protege contra eventos paralelos y repetidos y le entrega una solicitud lista a un agente.

Por eso es más correcto llamar al resultado un sistema de ventas con IA, y no un bot. El bot aquí es solo la parte visible. El valor de verdad está en la arquitectura que convierte la conversación libre del cliente en un proceso de negocio gestionado.