Caso publicado por Make el 14 de enero de 2026, basado en la solución de Kai S. Huxmann, de BrainFactor. Describe una implementación concreta, no una garantía de seguridad ni de resultados para cualquier chatbot.
Kai ganó un reto de la comunidad de Make dedicado a la experiencia de cliente con Voiceflow. Quería superar un problema habitual: un bot puede explicar un producto, pero eso no significa que pueda verificar a quien pregunta, consultar su cuenta o ejecutar una acción sobre ella.
El problema: responder no es lo mismo que resolver
Las consultas sobre facturas, cuentas o cambios de datos acababan requiriendo intervención humana. Un bot de preguntas frecuentes no tenía los datos ni los permisos necesarios para resolverlas. Kai buscó separar la conversación de las decisiones que daban acceso a información del cliente, en vez de dejar ambas responsabilidades en manos del modelo.
Puedes ver la demostración de Kai que acompaña al caso.
Tres capas con responsabilidades distintas
La solución presentada combinaba tres agentes de IA en Voiceflow, escenarios de Make y un CRM en Airtable. Los agentes dirigían el diálogo, reconocían la intención y compartían una base de conocimientos. Antes de verificar al usuario, respondían con información pública sobre la empresa, los servicios o los productos.
Make coordinaba las rutas del proceso según las condiciones previstas y los datos recibidos. El acceso a Airtable mediante la configuración de Make MCP Server se utilizaba para las consultas que necesitaban información de la cuenta.
La distinción es importante: compartir una base de conocimientos no equivale a dar a todos los interlocutores acceso al CRM. En el diseño descrito, la consulta de datos personales se habilitaba después de la verificación.
Cómo funcionaba la verificación
El recorrido que documentó Make era el siguiente:
- El usuario solicitaba una acción que requería datos de su cuenta.
- Make generaba un código temporal de un solo uso y lo enviaba por correo.
- El usuario introducía el código en el chat.
- El flujo comprobaba el código antes de recuperar los datos asociados en Airtable.
- Solo después de esa comprobación se ejecutaba la acción predefinida.
El caso incluía el reenvío de facturas, consultas sobre cuentas, cambios de dirección de facturación y restablecimiento de contraseñas. También describía una ruta para nuevos contactos: contrastar su perfil con los criterios del cliente ideal y proponer un seguimiento, como concertar una llamada comercial.
Qué resultados comunicó Kai
La publicación atribuyó a esta solución la resolución autónoma de más del 30 % de las solicitudes de soporte. También destacó la continuidad de la conversación entre agentes y la reutilización de los archivos de conocimiento. Son resultados del proyecto descrito en enero de 2026, no una medición realizada por este sitio.
La continuidad de la conversación no garantiza respuestas siempre coherentes, y la presencia de un código OTP no demuestra por sí sola que toda la aplicación sea segura.
Antes de aplicar esta arquitectura
Orientación editorial: define qué datos puede leer cada acción y qué operaciones necesitan una comprobación adicional o intervención humana. Prueba también los códigos incorrectos, la caducidad y las solicitudes sobre cuentas ajenas; el artículo original no constituye una auditoría de esos controles.
Para conectar hoy un cliente MCP, consulta las secciones de autenticación, permisos y herramientas de Make MCP Server en el Developer Hub. Los permisos del cliente MCP y la verificación del usuario final del chat son controles distintos. Esta documentación se consultó el 26 de septiembre de 2026; las condiciones del caso no sustituyen la configuración vigente.
Fuente: caso original de Make.