Dos o tres horas diarias contestando WhatsApp y cuadrando agenda. Hoy: unos quince minutos.

Cada reserva llegaba como una conversación de WhatsApp, y cada conversación la tenía que contestar una persona.

A qué hora llega la terapeuta. Si llevan camilla. Cuánto vale el ritual en pareja. Si van los domingos. Todo respondido a mano, y después pasado a Google Calendar con la dirección correcta, el servicio correcto, la terapeuta correcta y la duración correcta. Equivocarse en cualquiera de esas significa una terapeuta atravesando Medellín hacia la dirección equivocada.

Deisy Marin, la dueña, estima que eso le costaba entre dos y tres horas todos los días. No en un bloque: en pedazos, todo el día, todos los días, entre todo lo demás. Ese trabajo que nunca aparece en una lista de tareas y que se va comiendo el negocio en silencio.

Y las horas no eran todo el costo. Las consultas que entraban a las once de la noche se quedaban ahí hasta la mañana siguiente. Alguien que a las once de la noche está buscando un masaje, a las nueve de la mañana normalmente ya no lo quiere.

El cliente no impuso ninguna restricción. La restricción era el costo.

Cada decisión de arquitectura del proyecto salió del mismo lugar: un negocio de servicios recién lanzado, sin presupuesto para herramientas empresariales.

• Gemini, porque en ese momento era de las APIs más económicas para correr un agente conversacional.
• Telegram y no WhatsApp para el agente. La API de WhatsApp Business no era ni gratis ni sencilla de conectar. Telegram era las dos cosas.
• Y la restricción que no se podía esquivar: en Colombia todo el mundo vive en WhatsApp. Los clientes no iban a cambiar de plataforma porque a mi arquitectura le conviniera.

Esa última definió todo el sistema, y de eso trata la sección siguiente.

Una puerta de entrada de dos velocidades. Esta es la decisión sobre la que gira el proyecto.

WhatsApp no se podía abandonar: es donde ya están los clientes colombianos. Pero poner el agente de IA ahí no era viable con ese presupuesto. Entonces, en vez de forzar un solo canal, el cliente elige:

• Telegram: inmediato. Un agente con Gemini maneja la conversación: responde sobre servicios y precios, consulta disponibilidad real y agenda directo en el calendario. A cualquier hora, sin esperar.
• WhatsApp: humano, más lento. Para quien prefiere hablar con una persona y acepta que la respuesta puede demorarse.

El intercambio se dice de frente, no se esconde. La opción se presenta explícitamente en ambos chats y en el sitio web: respuesta inmediata del software, o esperar un poco y hablar con alguien. El cliente decide qué prefiere.

Eso es lo que casi ningún proyecto de automatización hace bien. El instinto es esconder el bot, o meter a todo el mundo por ahí. Decir con claridad qué puerta lleva a dónde hace que nadie se sienta engañado. El que quiere una persona, la sigue teniendo.

Por debajo:

• n8n orquestando todo el flujo, self-hosted
• Google Gemini como agente, entrenado con los servicios, precios y tono de Wellen
• Google Calendar escrito en tiempo real, con bloqueo automático para que no caigan dos reservas en el mismo espacio
• Google Sheets como registro paralelo: doble escritura, para que una falla del calendario no borre una reserva
• Secuencias de recordatorio automáticas antes de cada cita
• Un sitio en Framer diseñado para una sola cosa: llegar de la portada a la reserva confirmada sin fricción
• Una secuencia de correos construida sobre la objeción de confianza: primero el ancla de seguridad, después la autoridad clínica, y al final un empujón suave para reservar

Por qué no las alternativas: un software de reservas de pago quedaba fuera por costo, y de todas formas habría necesitado a alguien contestando preguntas en WhatsApp. La API de WhatsApp Business quedaba fuera por costo y complejidad de configuración. Construir solo en WhatsApp significaba no automatizar nada; construir solo en Telegram significaba abandonar el canal que los clientes ya usaban. La puerta de dos velocidades era la única opción que respetaba el presupuesto y el mercado al mismo tiempo.

Bastante, y casi todo en la primera versión.

El agente daba respuestas equivocadas. Con seguridad, en medio de una conversación con un cliente. El peor lugar posible. Dos causas, y se potenciaban entre sí.

El system prompt había crecido demasiado. Cada caso borde que aparecía en pruebas se agregaba como una instrucción más, hasta que el prompt se volvió un documento. Pasado cierto largo, el modelo dejó de respetar de forma confiable cualquier línea individual, incluidas las importantes. Más instrucciones producían menos obediencia.

Y el modelo más barato no daba para eso. El nivel elegido por costo no tenía el conocimiento ni la consistencia para completar todas las tareas del flujo. Resolvía el camino simple y se caía en las excepciones, que en un sistema de reservas son la mayoría de los casos interesantes.

La solución fue por los dos lados a la vez. El system prompt se reescribió en vez de seguir creciendo: instrucciones más ajustadas y responsabilidades redistribuidas, para que cada parte del flujo tuviera un solo trabajo en lugar de un prompt intentando cargar con todo. Y el modelo subió un nivel, del Gemini Flash más liviano al Flash estándar. Suficiente capacidad para manejar las excepciones, a un precio lo bastante cercano como para que la restricción de costo siguiera en pie.

Lo que me cambió la forma de trabajar: el system prompt de un agente no es un lugar para acumular reglas. Cada excepción que se le agrega diluye todo lo que ya estaba. Pasado cierto punto, más instrucción produce menos obediencia. Hay que repartir el trabajo para que cada paso tenga una sola función, y pagar el nivel de modelo que exige la tarea más difícil, no el que la tarea más simple aguanta. El modelo más barato solo es barato hasta que falla delante de un cliente.