Cómo crear un chatbot con IA con Make: Guía paso a paso

Un chatbot con inteligencia artificial ya no requiere contratar una plataforma exclusiva de eso: Make permite construirlo desde cero, conectando las piezas que la empresa ya usa. Actúa como orquestador entre el canal de entrada (WhatsApp, web, email o Slack), un modelo de lenguaje como OpenAI o Claude, y el sistema donde vive la información del cliente. 

Entonces, un chatbot con IA permite conservar la eficiencia de la automatización sin caer en mensajes genéricos, reduce el tiempo que el equipo invierte en responder dudas estándar y libera capacidad para que las personas se enfoquen en los casos realmente complejos o sensibles, donde la intervención humana agrega más valor.

<<<Session exclusiva: Cómo crear un chatbot con IA>>>

¿Qué es un chatbot con IA frente a uno de reglas?

Antes de construir el flujo, conviene entender qué se está automatizando realmente.

Un chatbot de reglas funciona con árboles de decisión: el usuario elige entre opciones predefinidas o el sistema detecta palabras clave exactas y dispara una respuesta fija. Es predecible, barato de mantener y rápido de ejecutar, pero se rompe en cuanto la consulta no encaja en el guion previsto.

Un chatbot con IA, en cambio, envía el mensaje del cliente a un modelo de lenguaje (LLM) que interpreta la intención, considera el contexto de la conversación y genera una respuesta original cada vez. No depende de coincidencias exactas de texto ni de un árbol cerrado de opciones.

La diferencia operativa es clara:

• Un chatbot de reglas responde bien preguntas binarias ("¿cuál es mi número de pedido?", "quiero cancelar").
• Un chatbot con IA responde bien preguntas abiertas, ambiguas o que requieren combinar información ("¿por qué mi pedido llegó tarde si pagué envío express?").

El enfoque con LLM es más flexible, pero no siempre es superior. Cuando el volumen de consultas es bajo, el catálogo de respuestas es finito y la precisión absoluta es crítica (por ejemplo, información regulatoria), un chatbot de reglas sigue siendo la opción más segura y económica.

Arquitectura del flujo en Make

El diagrama anterior resume la lógica del escenario: el sistema recibe un mensaje, recupera el historial de esa conversación, arma un prompt con contexto, lo envía al modelo de lenguaje, evalúa si la respuesta generada es suficiente o si requiere intervención humana, y finalmente entrega la respuesta por el canal correspondiente.

Cada bloque cumple una función específica:

• Trigger: capta el mensaje entrante, sin importar el canal de origen.
• Historial: aporta memoria a la conversación, evitando que el bot trate cada mensaje como aislado.
• Prompt con contexto: combina las instrucciones del sistema, el historial y los datos del cliente en un solo texto que recibe el LLM.
• Modelo de lenguaje: genera la respuesta en lenguaje natural.
• Router de escalado: decide si la respuesta se envía tal cual o si la conversación pasa a un agente.
• Canal de salida: entrega la respuesta al cliente por el mismo canal donde escribió.

Esta arquitectura es modular: cualquier bloque puede reemplazarse sin rediseñar el escenario completo. Cambiar de WhatsApp a Slack, o de OpenAI a Claude, implica modificar un módulo, no reconstruir el flujo.

<<<Agentes de IA vs automatización: diferencias clave a tener en cuenta>>>

Paso a paso: construir el flujo base en Make

Configurar el webhook de entrada

El primer módulo del escenario es un webhook personalizado de Make, que genera una URL única capaz de recibir solicitudes POST. Este webhook se conecta al canal de origen:

• Si el canal es WhatsApp Business API, el webhook recibe las notificaciones de mensajes entrantes.
• Si el canal es un formulario web, el webhook recibe el payload del envío.
• Si el canal es Slack, se utiliza el módulo nativo de Slack en lugar de un webhook genérico, configurado para disparar en cada mensaje nuevo del canal de soporte.

En todos los casos, el objetivo del primer módulo es el mismo: capturar el texto del mensaje, el identificador del remitente y, si está disponible, el identificador de la conversación.

Recuperar el historial de la conversación desde el canal o el CRM

El historial se obtiene directamente del canal de mensajería (por ejemplo, el historial de mensajes de WhatsApp Business API o de un canal de Slack) o desde el CRM donde se registra la interacción con el cliente, como HubSpot. Esto evita depender de una hoja de cálculo como base de datos y mantiene la conversación sincronizada con el resto del recorrido del cliente.

En la práctica, este paso suele implicar:

• Un módulo de búsqueda en HubSpot que recupera el contacto asociado al número o email del remitente, junto con sus notas o tickets recientes.
• O bien una llamada a la API del canal de mensajería para recuperar los últimos N mensajes del hilo, si el canal lo permite.

El historial recuperado se transforma en una lista ordenada de turnos (cliente/bot) que luego se inyecta en el prompt.

Armar el prompt con contexto del cliente

Este es el módulo donde se concentra la mayor parte del ajuste fino. Mediante un módulo de texto o de composición de variables, se construye un único bloque de texto que incluye:

1. Instrucciones del sistema: tono de marca, límites de la respuesta, qué información no debe inventar el bot.
2. Datos del cliente recuperados del CRM: nombre, plan contratado, estado de tickets abiertos.
3. Historial de la conversación, formateado como turnos de diálogo.
4. El mensaje actual del cliente.

Cuanto más preciso sea este prompt, menos probable es que el modelo genere respuestas genéricas o fuera de contexto. Es recomendable mantener una plantilla fija para las instrucciones del sistema y variabilizar solo los datos del cliente y el historial.

Conectar con OpenAI o Claude vía API

Make ofrece módulos nativos para OpenAI y permite conectar con la API de Claude mediante el módulo HTTP genérico. El prompt armado en el paso anterior se envía como entrada, junto con parámetros como la temperatura (qué tan creativa o conservadora es la respuesta) y el límite de tokens de salida.

Para atención al cliente, conviene mantener la temperatura baja (entre 0.2 y 0.4), priorizando consistencia sobre creatividad. La respuesta del modelo llega como texto plano, listo para el siguiente módulo.

<<<¿Qué son las APIs?>>>

Enviar la respuesta por el canal de salida

El último módulo del flujo principal entrega la respuesta generada por el canal de origen: WhatsApp, email, Slack o un widget de chat embebido en el sitio web. Es importante que este módulo use el mismo identificador de conversación capturado en el primer paso, para que la respuesta llegue al hilo correcto.

Si el canal de salida difiere del canal de entrada (por ejemplo, recibir por web y responder por email), el escenario debe incluir un módulo adicional que resuelva esa correspondencia, generalmente consultando el CRM.

Cómo manejar el escalado humano

Ningún chatbot con IA debería operar sin una vía de salida hacia un agente real. El escalado se implementa como un router dentro del mismo escenario, ubicado después de la llamada al LLM y antes del envío de la respuesta.

Los criterios más habituales para activar el escalado son:

• El modelo detecta explícitamente que no tiene información suficiente (se puede instruir al LLM para que responda con una palabra clave específica, como "ESCALAR", cuando esto ocurra).
• La conversación supera un número determinado de turnos sin resolución.
• El mensaje del cliente contiene señales de frustración o urgencia, detectadas mediante un análisis de sentimiento adicional o mediante instrucciones en el propio prompt.
• La consulta involucra acciones sensibles: cancelaciones, reembolsos, datos de facturación.

Cuando se activa el escalado, el flujo puede crear un ticket en HubSpot, notificar al equipo en Slack con el contexto completo de la conversación, o ambas cosas. El cliente recibe un mensaje de transición indicando que un agente continuará la conversación, evitando la sensación de que el bot simplemente dejó de responder.

Límites del enfoque

Antes de implementar este flujo en producción, conviene tener presentes sus límites:

• Latencia: cada llamada al LLM agrega entre 1 y 5 segundos de espera, dependiendo del modelo y la longitud del prompt. En canales como WhatsApp esto es aceptable; en un widget de chat web, puede sentirse lento si no se gestiona una respuesta de "escribiendo...".
• Costos por token: a diferencia de un chatbot de reglas, cada interacción tiene un costo variable asociado a la cantidad de texto enviado y generado. Conversaciones largas con mucho historial incrementan el costo por intercambio.
• Contexto máximo: los modelos tienen un límite de tokens que pueden procesar en una sola llamada. Si el historial crece demasiado, es necesario resumirlo o truncarlo, lo que puede hacer que el bot "olvide" detalles de conversaciones largas.
• Casos donde un chatbot de reglas es mejor: si las consultas son altamente repetitivas y de bajo riesgo de ambigüedad (horarios de atención, estado de un pedido mediante número de orden), un flujo de reglas simples en Make, sin LLM de por medio, resuelve el mismo problema con menor costo, menor latencia y cero riesgo de respuestas inventadas.

Próximo paso

Este flujo no requiere herramientas adicionales más allá de Make, un proveedor de LLM y el canal de comunicación que la empresa ya utiliza. El punto de partida recomendado es construir una primera versión acotada a un solo tipo de consulta frecuente, validar la calidad de las respuestas durante una o dos semanas, y recién después ampliar el alcance del prompt y sumar el router de escalado.