Sistema de ventas con IA

A una empresa de EE. UU. que vendía paquetes de alto valor se le había quedado pequeña su forma de gestionar los leads.

El marketing funcionaba. Los leads llegaban a lo largo del día desde marketplaces, publicidad en redes sociales, el sitio web, llamadas entrantes y canales sociales. El problema era lo que pasaba después.

Un equipo de cuatro setters en el extranjero gestionaba manualmente una cola en horario laboral de la costa este de EE. UU. Con volúmenes más altos, un nuevo lead podía esperar horas, a veces hasta el día siguiente, antes de que alguien lo llamara.

El seguimiento dependía en gran medida de cada setter. El mantenimiento de los datos del CRM era irregular. Algunos leads recibían atención repetida mientras otros quedaban completamente olvidados. A medida que crecía el volumen de leads, ampliar el equipo de setters no era una forma atractiva de crecer.

Reconstruí progresivamente esa capa en torno a la voz con IA, la orquestación del CRM y el seguimiento automatizado, y creé un sistema capaz de contactar, calificar y dar seguimiento a cada lead hasta que programara una reunión, rechazara explícitamente o pasara a otro estado definido.

Una vez maduro, el sistema era capaz de hacer unas 50 000 llamadas en un mes pico y programaba de forma constante unas 400 reuniones al mes en los calendarios de los closers humanos. Respaldó una operación de ventas que sostuvo cerca de 1 millón de USD al mes en cobros durante varios años.

Ese crecimiento no se debió a instalar un agente de llamadas con IA. Con el tiempo, la estrategia de marketing generó un volumen de leads mucho mayor; el sistema fue la infraestructura que permitió al negocio gestionar ese volumen de forma constante sin ampliar al mismo ritmo el equipo de setters.

El entorno de producción auditado contenía unas 45 000 oportunidades, 41 000 contactos únicos, 83 flujos de trabajo publicados en GoHighLevel, 22 escenarios activos de Make y 47 asistentes de Vapi, aunque solo una parte de los asistentes estaba activa en un momento dado.

Dónde empezamos

Antes del sistema de voz, cuatro setters en el extranjero se encargaban a mano del primer contacto y del seguimiento. Trabajaban en el horario laboral estándar de la costa este de EE. UU. Cada nueva consulta entraba en la cola y esperaba hasta que alguien quedara libre para llamar.

Con poco volumen, ese modelo podía funcionar. Con más volumen, generaba varios problemas estructurales.

La velocidad dependía de la capacidad

Los leads llegaban fuera del horario laboral y más rápido de lo que el equipo podía procesarlos de forma constante. Algunos esperaban horas hasta el primer contacto. A otros no se los llamaba hasta el día siguiente. Para un lead con alta intención que acababa de enviar una consulta, esa demora importaba.

El seguimiento dependía de la persona

No había reportes lo bastante fiables para demostrar cuántos intentos recibía realmente cada lead ni si se cumplía la cadencia establecida. En la práctica, no había regularidad. Algunos leads recibían mucha más atención que otros.

No se podía confiar en el estado del CRM

Los setters humanos no mantenían los registros de forma sistemática. Se pasaban por alto contactos, los estados eran ambiguos y el CRM no siempre reflejaba con fiabilidad en qué punto del proceso de venta estaba realmente cada lead.

Crecer significaba ampliar el equipo

Si el volumen de leads se duplicaba, la respuesta obvia era más setters. Eso implicaba más contratación, formación, gestión y una ejecución variable, sin llegar a garantizar que cada lead recibiera el mismo trato.

Por eso, el objetivo no era simplemente:

Hacer una llamada con IA.

Era:

Crear un sistema de gestión de leads en el que cada lead pudiera recibir una atención inmediata, persistente y uniforme, sin importar el volumen.

De qué me hice cargo

Fui responsable del sistema técnico de principio a fin. Eso incluía la arquitectura, el diseño del CRM, la lógica de los flujos de trabajo, las integraciones, la arquitectura de los agentes de voz, los prompts, la resolución de problemas, la documentación, la optimización y las decisiones sobre cómo debían avanzar los leads por el sistema.

A medida que la plataforma crecía, conté con un desarrollador que ayudaba con el mantenimiento, las actualizaciones y la implementación. Yo seguí siendo responsable de la arquitectura y la dirección técnica.

Uno de los primeros problemas no tenía nada que ver con la IA. Era la herencia.

La implementación anterior se había vuelto difícil de operar. La documentación era prácticamente inexistente. Los flujos de trabajo, los campos y las integraciones tenían nombres ambiguos, una estructura incoherente y, en algunos casos, simplemente errores ortográficos. A medida que se acumulaban dependencias, entender el efecto de cambiar un componente era cada vez más difícil.

Esa experiencia influyó mucho en cómo abordé no solo este sistema, sino también los que construí después:

La documentación y el diseño del sistema son parte de la infraestructura. No son trabajo administrativo que se añade cuando la infraestructura ya existe.

Principios de diseño

Con el tiempo, unos pocos principios dieron forma a la arquitectura.

Un solo sistema debe contener la verdad

El CRM se convirtió en la máquina de estados. Make movía la información entre servicios. Vapi se encargaba de la conversación. Pero ninguno de esos dos sistemas decidía por su cuenta qué le pasaba después al lead. Registraban hechos en el CRM. Y el CRM actuaba en función de esos hechos.

Así, el estado operativo quedaba visible para el negocio en lugar de enterrado dentro del middleware de integración. En producción, Make no movía directamente un lead entre las etapas del embudo; escribía resultados en campos y los flujos de trabajo del CRM reaccionaban a ellos.

El estado debe guiar el comportamiento

Una consulta recién llegada no debería recibir la misma conversación que alguien que:

• pidió que le devolvieran la llamada;
• mostró interés pero no programó una reunión;
• faltó a una reunión programada;
• dejó de responder;
• ya había dicho que no.

Por eso, cada estado tenía su propio tratamiento y, cuando era útil, su propio agente de voz especializado.

La IA no debe tomar todas las decisiones

La ambigüedad conversacional es un terreno útil para un LLM. El estado del sistema, no. La arquitectura separó cada vez más tres tipos de decisión.

Los fallos deben hacerse visibles

Una automatización fallida no debería desaparecer en silencio. Las fuentes de consulta no reconocidas, las extracciones de datos fallidas y los errores al registrar citas se diseñaron para detener el proceso o generar una alerta, en lugar de permitir que los datos erróneos se propagaran por el sistema.

Arquitectura del sistema

En el centro había tres plataformas:

GoHighLevel

Estado, embudo de ventas, calendarios, SMS/correo y lógica de flujos de trabajo.

Make

Integración y orquestación entre servicios.

Vapi

Conversaciones de voz con IA en tiempo real.

A su alrededor estaban las fuentes de adquisición, la telefonía, los modelos, los servicios de voz, la capa de conocimiento, la infraestructura del boletín, el sitio web y los sistemas de reportes. En total, el conjunto de herramientas en producción llegó a abarcar 16 plataformas.

Diez entradas a un solo sistema

El sistema recibía leads a través de diez canales de entrada. Entre ellos había consultas de marketplaces de alto volumen, formularios de leads de Meta, páginas de destino de campañas en redes sociales, el sitio web principal, llamadas telefónicas entrantes, mensajes directos en redes sociales y varias fuentes de socios clasificadas a mano.

La decisión de arquitectura importante fue que esos canales no se convirtieran en diez sistemas de ventas separados. Convergían en un único modelo.

Una única variable de clasificación

Un campo personalizado de origen del lead codificaba tanto la marca correspondiente como la vía de adquisición. Así, la lógica posterior podía preguntar:

¿De dónde procede este lead?

y deducir:

• a qué marca pertenecía;
• qué agente de voz debía llamar;
• qué calendario usar;
• en qué secuencia de seguimiento debía entrar;
• qué variante de cadencia debía ejecutarse.

Eso evitó duplicar embudos completos del CRM para cada fuente.

Originalmente, el sistema usaba embudos separados de 19 etapas para cada marca. Con el tiempo se fusionaron en un único embudo compartido de 25 etapas, de modo que una nueva marca pasó a ser sobre todo un cambio de datos/enrutamiento y no otra arquitectura duplicada.

Hacer utilizable una entrada desordenada

No todos los leads llegaban limpios. Los leads de marketplaces, por ejemplo, solían llegar como correos electrónicos en lugar de datos estructurados enviados por webhook. Un flujo típico era:

1. Consulta de un marketplace
2. Correo electrónico
3. ReglasRegla de correo
4. ReglasWebhook de Make
5. IAExtracción con LLM
6. ReglasBúsqueda de la fuente
7. ReglasDeduplicación
8. CRM

El LLM extraía campos como:

• nombre;
• correo electrónico;
• teléfono;
• comentarios;
• identificador de la fuente;
• dirección URL.

Luego se buscaba el identificador de la fuente para determinar a qué marca correspondía la consulta. Si el sistema no podía identificar la fuente, no adivinaba. Se detenía y alertaba al equipo. Del mismo modo, los errores de análisis detenían el escenario antes de que llegara información errónea al CRM.

Los leads sin número de teléfono se enviaban a un estado aparte y seguían recibiendo correos de seguimiento, en lugar de entrar por error en la cola de marcación.

Esto importaba porque la orquestación con IA solo es útil cuando el estado que tiene debajo es fiable.

El CRM era la máquina de estados

Con el tiempo, el embudo principal llegó a tener 25 etapas repartidas en cuatro grandes zonas.

El contrato de datos

Alrededor de una docena de campos del CRM formaban la interfaz entre GoHighLevel, Make y Vapi. Algunos ejemplos importantes:

Origen del lead

Marca y fuente de adquisición.

Resultado de la llamada

El resultado estructurado que se devolvía tras cada llamada.

Intentos fallidos consecutivos

Cuántos intentos sin respuesta se habían producido seguidos.

Estado del contacto

Incluye si la cita se registró o no.

Estado de marcación

Si Vapi aceptó la solicitud de llamada saliente.

Registro de la llamada

Resumen, transcripción, tipo de llamada, número y zona horaria.

Aquí es donde el proyecto se vuelve más interesante desde el punto de vista técnico.

El modelo de voz no era el sistema. Era un componente que generaba entradas estructuradas para una máquina de estados más grande.

La capa de voz con IA

A lo largo de la vida del sistema llegaron a existir 47 asistentes de Vapi entre producción, pruebas, versiones anteriores e iteraciones futuras. Normalmente solo unos diez estaban activos al mismo tiempo.

El sistema evolucionó con asistentes especializados para distintos contextos. Entre ellos:

• Primer contacto, por marca
• Primera llamada a leads de publicidad en redes
• Seguimiento a leads de publicidad en redes
• Devoluciones de llamada
• Con interés, sin reunión programada
• Seguimiento general
• Reprogramar tras una ausencia
• Devolución de llamadas perdidas
• Reactivación
• Llamadas entrantes
• Leads procedentes del boletín

El motivo de la especialización era simple:

Quien pide que le devuelvan la llamada no debería escuchar la misma presentación inicial que un lead frío.

El estado del sistema le daba al agente contexto antes de que empezara la llamada.

Arquitectura de los prompts

Los agentes de voz usaban prompts de sistema largos, normalmente de unos 5000–16 000 caracteres. La estructura llegó a estar bastante estandarizada:

1. Rol y personaje
2. Reglas de locución
3. Contexto del lead
4. Flujo de la conversación
5. Programación de citas
6. Preguntas frecuentes y objeciones
7. Salvaguardas

Los guiones posteriores dejaron atrás el discurso de venta rígido y pasaron a una interacción más orientada al descubrimiento: entender la situación del cliente potencial, explicar el modelo, reencuadrar las objeciones y luego avanzar hacia la cita. Algunos prompts contenían respuestas preparadas para unas 20 objeciones.

También dedicamos bastante tiempo a algo mucho menos impresionante en una demo, pero crítico en producción: cómo sonaba el agente.

El ritmo, el manejo de interrupciones, la latencia de respuesta, los modelos de voz, las muletillas y la toma de turnos influían notablemente en que una conversación resultara utilizable o no.

En ese momento, los modelos de voz avanzaban muy rápido. Configuraciones que había costado mucho esfuerzo dejar aceptables podían quedar obsoletas meses después, a medida que mejoraban la latencia y la calidad de los modelos.

Lo que vivía realmente un lead

Una de las formas más sencillas de entender la arquitectura es seguir una consulta de un marketplace a través de ella.

1. 0 s

   Consulta enviada

   Un cliente potencial envía una consulta a través de un marketplace.

2. + segundos

   Analizada y deduplicada IA

   El correo de notificación llega a un mailhook. Un LLM extrae los datos de contacto y el identificador de la fuente. El sistema determina la marca correcta y busca en el CRM si ya existe un registro.

3. + segundos

   Estado del CRM definido Reglas

   El CRM crea o actualiza la oportunidad, registra su origen y:

   • envía el SMS de bienvenida correspondiente;
   • la incorpora a la secuencia de seguimiento adecuada;
   • la inscribe en las llamadas con IA.

4. + ~15 s

   Llamada saliente iniciada Reglas

   Tras una pequeña demora deliberada, el sistema de marcación conecta al cliente potencial con el agente de voz correcto usando un número local. En algunos flujos, enviábamos primero un SMS o introducíamos una breve pausa a propósito, para no generar una llamada instantánea poco natural.

5. Durante la llamada

   Calificación y disponibilidad en vivo IA

   El agente:

   • confirma la consulta;
   • explica la oferta;
   • califica al lead;
   • responde a las objeciones;
   • identifica la ubicación/zona horaria del cliente potencial;
   • consulta la disponibilidad del calendario en tiempo real;
   • acuerda la hora de la reunión.

6. + ~40 s después de la llamada

   Transcripción procesada, cita registrada IA

   El procesador de transcripciones:

   • clasifica el resultado;
   • guarda la llamada;
   • extrae la cita acordada;
   • la registra en el calendario;
   • mueve al lead al estado del embudo correspondiente.

7. T−24 h

   Recordatorios al cliente potencial y al closer Reglas

   El sistema envía recordatorios al cliente potencial y avisa al closer asignado. Si el cliente potencial no se presenta, pueden activarse procesos de recuperación independientes por correo, SMS y voz con IA.

8. Reunión

   Una persona toma el relevo Humano

El problema de voz más difícil: confiar en la herramienta, no en el modelo

Una fuente recurrente de fallos era la programación de citas. El agente debía consultar la disponibilidad del calendario en tiempo real antes de acordar una reunión.

Pero si la herramienta de disponibilidad fallaba, o si la conversación se desviaba de forma inesperada, el modelo podía seguir conversando con naturalidad y aceptar una hora propuesta. Desde la perspectiva del cliente potencial, la llamada parecía haber salido bien. En lo operativo, no lo era.

Más tarde, el flujo de trabajo posterior intentaba registrar la cita y descubría que la hora acordada no existía.

Eso dejó una lección de diseño útil:

Una respuesta plausible en la conversación no es lo mismo que una acción de negocio válida.

Con el tiempo, el sistema pasó a tratar la programación de citas como un proceso en dos partes. Durante la llamada: consultar y acordar. Después de la llamada: validar y registrar.

El modelo consultaba la disponibilidad en tiempo real mientras hablaba con el lead. Al terminar la llamada, se volvía a analizar la transcripción, se extraía la hora acordada en la zona horaria del cliente potencial y se registraba la cita en el calendario correcto.

Así, las operaciones de escritura más lentas en el CRM quedaban fuera de la conversación en vivo y los registros de citas fallidos se podían detectar en lugar de perderse en silencio.

El seguimiento era un sistema, no un botón de reintentar

A un lead que no programaba una reunión no se le volvía a llamar sin más, indefinidamente. El estado del embudo determinaba la siguiente estrategia.

Cada etapa tenía su propia configuración de:

• guiones;
• ventanas de reintento;
• límites de llamadas;
• periodos de pausa;
• agentes de voz.

Las etapas principales usaban 8–16 intentos a lo largo de unos 7–10 días, según el estado y la marca. Ante la falta de respuesta, un patrón típico podía empezar de forma agresiva antes de espaciarse:

La idea era captar la demanda de alta intención mientras estaba fresca, sin acosar a ciegas a cada lead indefinidamente.

Un ciclo guiado por el estado

Un proceso de salida universal retiraba a los leads de las secuencias de llamadas cuando:

• programaban una reunión;
• entraban en fase de cierre;
• pasaban a ganados;
• no se presentaban y pasaban a otro flujo de trabajo;
• rechazaban explícitamente;
• llamaban por su cuenta al negocio.

Esto evitaba un fallo de automatización especialmente grave: llamar a alguien con un discurso de venta cuando ya había programado una reunión.

La reputación de los números se convirtió en una restricción del sistema

Una de las lecciones más importantes fue que el factor limitante no siempre era la capacidad de la IA. Era la infraestructura de telecomunicaciones.

Con el tiempo, las llamadas agresivas sostenidas hicieron que los operadores marcaran los números salientes como spam. Por eso se cerró una campaña de largo plazo para leads sin respuesta, y los mensajes pregrabados de buzón de voz que se habían configurado quedaron desactivados.

La arquitectura se adaptó con:

• números locales;
• un grupo de 65 números salientes;
• dosificación por goteo;
• límites de llamadas por etapa;
• menos llamadas de cola larga;
• más peso de la reactivación por correo.

Es un buen ejemplo de por qué un sistema de IA no puede diseñarse aislado del entorno en el que opera.

El traspaso a una persona fue deliberado

El objetivo nunca fue eliminar la intervención humana de todo el proceso de venta. El producto era de alto valor y de venta consultiva. Un closer humano seguía aportando más valor una vez que el cliente potencial había mostrado suficiente interés como para programar una reunión.

Por eso, el límite del sistema quedó definido así:

El equipo de cuatro setters se fue reduciendo. Tres setters con bajo rendimiento salieron del proceso y uno pasó a ser closer a tiempo completo. Todavía se recurría ocasionalmente a setters para casos límite que el sistema no podía gestionar de forma adecuada.

Ese era el sentido de la arquitectura:

Hacer que las personas suban en la cadena de valor en lugar de obligarlas a hacer trabajo repetitivo que el sistema podía resolver con más regularidad.

La fiabilidad importaba más que la demo

Una demo suele mostrar:

Llega el lead → la IA llama → reunión programada.

En producción hay que responder:

¿Qué pasa cuando algo falla en cualquiera de los pasos?

Con el tiempo, el sistema incorporó patrones como:

• Reintentos

  Las operaciones de escritura y consulta en el CRM se reintentaban automáticamente en lugar de abandonar la ejecución ante errores transitorios.

• Detenerse ante datos erróneos

  Los identificadores de fuente desconocidos o los errores de extracción detenían el procesamiento en lugar de adivinar.

• Alertas de programación de citas

  Si un cliente potencial aceptaba de palabra una reunión pero el registro en el calendario fallaba, se generaba una alerta interna para recuperarla a mano.

• Aislamiento de pruebas

  Los registros de prueba conocidos se podían desviar antes de que dispararan llamadas reales.

• Estado central

  El middleware informaba hechos; el CRM tomaba las decisiones sobre el estado del negocio.

El sistema de producción usaba deliberadamente colas de ejecuciones incompletas y gestores de reintentos, para que las integraciones fallidas se pudieran volver a ejecutar en lugar de perderse en silencio.

El sistema se medía a sí mismo

Cada llamada con IA generaba más que una transcripción.

El análisis posterior a cada llamada generaba información que permitía mejorar de forma iterativa los prompts. Además, una API de analítica propia recibía información de cada llamada, con un desglose completo de costos.

El objetivo no era solo generar reportes. Nos permitía preguntarnos:

• ¿Qué agente sale caro?
• ¿Qué guion falla más a menudo?
• ¿Qué objeciones plantean los clientes potenciales?
• ¿Dónde falla la IA?
• ¿Cuánto cuesta una reunión programada?

Luego, la línea de tiempo del CRM daba al closer un historial consolidado con los resúmenes y las transcripciones de las llamadas con IA junto con la actividad de SMS y correo.

Nunca fue “configurar y olvidar”

Probablemente fue la lección operativa más importante. El sistema evolucionaba constantemente.

Los modelos de voz mejoraron. La latencia de voz cambió. Las técnicas de prompting mejoraron. Las ofertas del negocio cambiaron. Se sumaron marcas. Los canales de marketing cambiaron. La reputación de las llamadas cambió. El CRM evolucionó.

Lo que tenía sentido en un escenario de Make seis meses antes a menudo podía simplificarse mucho cuando una plataforma incorporaba después una funcionalidad nativa.

La propia auditoría técnica encontró un sistema con 83 flujos de trabajo del CRM activos de 158 construidos, 22 escenarios de Make activos en una cuenta con 163 y unos 10 asistentes de voz activos entre 47 versiones en total.

Parte de eso es la arqueología inevitable de un sistema que lleva mucho tiempo en producción. Pero también refuerza algo que hoy considero fundamental:

La automatización necesita a alguien a cargo.

Un sistema tan interconectado no está “terminado” porque la primera versión funcione. Necesita monitoreo, mantenimiento, experimentación, documentación y simplificación periódica.

Qué salió mal

1. Heredamos un sistema sin documentar

   La persona que lo había desarrollado antes no dejó prácticamente ninguna documentación utilizable. Los nombres eran incoherentes y a menudo ambiguos. Incluso los errores ortográficos pasaron a formar parte del contrato implícito entre flujos de trabajo.

   Eso hacía que resolver problemas fuera innecesariamente lento y que cada cambio fuera innecesariamente arriesgado.

   Qué cambió

   La documentación de la arquitectura, la disciplina en los nombres y la mantenibilidad futura pasaron a ser requisitos explícitos.

   Más adelante, dar a las herramientas de programación con IA acceso directo a las API y al sistema que las rodeaba también mejoró muchísimo la capacidad de rastrear y entender las dependencias.

2. El agente podía sonar correcto y equivocarse en lo operativo

   Si la herramienta de disponibilidad fallaba, un LLM podía aceptar igualmente una hora en la conversación. El cliente potencial creía que había programado una reunión. El sistema no.

   Qué cambió

   La programación de citas pasó a tratarse como una transacción controlada en lugar de confiar en lo que salía de la conversación. Los fallos se convirtieron en estados explícitos con alertas.

3. El manejo de zonas horarias generó malas franjas de llamada

   Una configuración inicial podía hacer que clientes potenciales de la costa este recibieran llamadas a horas locales inapropiadas.

   Qué cambió

   Las llamadas se estandarizaron en torno a una franja operativa más segura, mientras los agentes registraban la zona horaria para programar las citas. Aun así, la auditoría señaló la programación por hora local como un área a seguir mejorando.

4. La reputación ante los operadores limitó la escala teórica

   Llamar más no era automáticamente mejor. Las campañas de largo plazo dañaron la reputación de los números y redujeron la entregabilidad.

   Qué cambió

   Se redujeron las llamadas de largo plazo, los mensajes pregrabados de buzón de voz siguieron desactivados y una mayor parte de la reactivación pasó al correo.

5. Las integraciones antiguas acumularon deuda

   El panorama tecnológico avanzaba rápido. Algunos escenarios de Make que tenían sentido cuando se construyeron podían sustituirse o reducirse drásticamente más adelante, a medida que las plataformas desarrollaban mejores API o integraciones nativas.

   Qué cambió

   La revisión periódica de la arquitectura pasó a formar parte del mantenimiento del sistema, en lugar de dar por hecho que los flujos de trabajo existentes seguían siendo óptimos.

6. Las dependencias pueden fallar sin que se note

   En un momento dado, se desactivó el backend de una base de conocimiento y decenas de agentes perdieron su capacidad de respaldo sin que apareciera un error evidente en todo el sistema. La auditoría identificó las comprobaciones de salud de las dependencias como una salvaguarda que faltaba.

   Qué cambió, en lo conceptual

   La accesibilidad de cada dependencia debe monitorearse por separado, al margen de que el flujo de trabajo en su conjunto parezca “encendido”.

Resultados

Antes de que el sistema madurara, el negocio cobraba unos 200 000 USD al mes. A medida que el marketing aumentaba el volumen de leads, el sistema de ventas con IA se convirtió en la infraestructura que permitió al negocio absorber ese crecimiento sin ampliar al mismo ritmo el equipo de setters.

Una vez maduro, el sistema respaldaba:

El sistema no generó esos ingresos por sí solo. Respaldó la escala necesaria para gestionar de forma constante un volumen mucho mayor de demanda entrante.

Ahora cada lead podía avanzar por un proceso definido: primer contacto casi inmediato, seguimiento persistente, estado estructurado en el CRM, programación automatizada de citas y un traspaso claro a un closer humano.

El resultado no fue simplemente más capacidad de llamadas. Fue una infraestructura de ventas capaz de absorber mucha más demanda sin que la gestión de leads se convirtiera en el cuello de botella.

Lo que aprendí

Tres lecciones me han acompañado en casi todo lo que he construido desde entonces.

Diseñar para el sistema que habrá que mantener

La implementación más rápida no es necesariamente el sistema más rápido. Los nombres ambiguos, las dependencias sin documentar y la lógica duplicada imponen un peaje a cada cambio futuro.

Cuanto más capaz se vuelve la programación con IA, más tentador es crear rápido. Eso hace que la arquitectura y la documentación sean más importantes, no menos.

Separar la inteligencia de la autoridad

Un LLM puede ser excelente interpretando sin ser el mecanismo adecuado para tomar todas las decisiones.

Darle a la IA las partes en las que es buena y limitar su autoridad en el resto hizo que el sistema fuera mucho más fiable.

La automatización es una operación, no una instalación

Este sistema requería:

• Monitoreo
• Iteración de prompts
• Pruebas
• Gestión de operadores
• Mantenimiento de flujos de trabajo
• Reportes
• Limpieza
• Documentación
• Actualizaciones de modelos
• Cambios de proceso

La idea de que una empresa puede “encender la IA” y no volver a tocarla malinterpreta la naturaleza de la automatización en producción. Un sistema que afecta a los clientes y a los ingresos necesita a alguien a cargo.

Lo que hoy construiría de otra manera

Si hoy reconstruyera el sistema desde cero, lo simplificaría bastante.

• Reducir la dependencia de plataformas

  Varias funciones que antes requerían Make o flujos de trabajo complicados en el CRM hoy se podrían implementar de forma más limpia con servicios propios o integraciones nativas más recientes.

• Hacer explícitos los contratos

  En lugar de que el estado dependiera de campos de texto libre y cadenas exactas, usaría estados enumerados e identificadores estables siempre que fuera posible.

• Diseñar las llamadas por hora local desde el principio

  La zona horaria de cada lead formaría parte de la programación de citas y de la cadencia desde el primer momento, en lugar de registrarse pero aplicarse solo en parte.

• Añadir monitoreo de salud de las dependencias

  Cada herramienta externa tendría su propio monitoreo de salud explícito: voz, calendario, base de conocimiento, CRM y endpoint del modelo.

• Tratar la observabilidad como un sistema de primer nivel

  Los errores, los costos, la latencia, las conversiones, la calidad de las llamadas y los fallos de dependencias vivirían en una única capa de observabilidad consolidada, en lugar de estar repartidos entre herramientas.

• Podar de forma continua

  Los sistemas en producción acumulan versiones antiguas. Retirarlas debería ser parte del ciclo de vida del desarrollo, no una tarea de limpieza que se hace más adelante.