Casi todo lo que se vende como «bot de WhatsApp para pedidos» es un chatbot que conversa y, cuando llega el momento de cobrar, le pide al cliente que hable con una persona. Antojo se construyó al revés: es un sistema que toma el pedido completo, resuelve la entrega, cobra, recibe el comprobante y avisa en cada paso, con una regla que gobierna todo el diseño, la inteligencia artificial nunca toca el dinero. Este es el caso de cómo está hecho, qué se midió y qué falta, contado sin humo porque lo construí yo.
La idea que ordena todo: Antojo no es un chatbot que improvisa, es un sistema determinista con tres trabajos acotados delegados a un modelo. Esa diferencia no es semántica, es lo que permite venderlo con garantías en lugar de con esperanza, porque una falla del modelo solo puede producir una repregunta o el pase a una persona, nunca un precio equivocado.
¿Qué es Antojo?
Es un sistema que toma pedidos de comida por WhatsApp, Instagram, Facebook y chat web, y los entrega ordenados a la cocina en un tablero propio. Atiende a toda hora, arma el pedido con el catálogo del negocio, resuelve la entrega, cobra y avisa al cliente en cada paso. El dinero lo calcula código determinista, no el modelo.
| Pieza | Qué hace |
|---|---|
| Cerebro de conversación | Máquina de estados: entiende, arma el pedido y calcula |
| Tablero de cocina | La pantalla de quien prepara, ordenada por hora de entrega |
| Capa multi-negocio | Catálogo, precios y reglas por cliente, en configuración |
| Herramientas de operación | Alta de un negocio, diagnóstico y verificación por comando |
Y lo que no es, que conviene decirlo antes: no es un asistente que conversa libremente sobre cualquier cosa. Es un sistema con un camino definido, y el modelo trabaja dentro de él.
El principio que gobierna el diseño
El modelo hace exactamente tres cosas: clasifica la intención de un mensaje, extrae productos contra un catálogo conocido, y transcribe el monto de un comprobante. Todo el resto (los precios, los totales, el resumen, la confirmación, los cambios de etapa, el pase a un humano) es código determinista.
La consecuencia práctica es la que hace vendible el sistema: como el modelo está fuera del camino del dinero, su peor falla es un mensaje de más. Y se verifica de la forma más dura posible, corriendo la suite de pruebas con el modelo apagado: sin credencial, todas las llamadas fallan y el flujo degrada a repreguntas y a un pase a una persona, en lugar de improvisar. El razonamiento completo está en por qué la IA no debe tocar el dinero.
Lo que hay construido
Los números del sistema, para dar dimensión: alrededor de 30.000 líneas de código, 20 migraciones sobre 30 tablas, 640 comprobaciones automáticas y 34 comandos de operación que permiten administrarlo sin entrar a la base de datos. Nada de eso es mérito en sí mismo, pero explica por qué es un producto y no una demostración: la mayor parte de ese volumen son las verificaciones y las herramientas, no la funcionalidad visible.
El tablero de cocina merece una nota aparte, porque es la pieza que más se subestima. Quien prepara los pedidos nunca abre el CRM: opera en una pantalla hecha para su trabajo, con las tarjetas ordenadas por hora de entrega, urgencia por color, un toque para avanzar en el móvil, sonido y vibración cuando entra un pedido, y deshacer. Cada movimiento le manda el mensaje real al cliente y mueve la oportunidad en el CRM, pero si el CRM falla, la pantalla no se bloquea nunca. Ese criterio, el de darle a quien opera su propia superficie, está desarrollado en por qué tu equipo no usa el CRM.
Las decisiones que lo hacen un producto y no un desarrollo a medida
Antojo se vende otra vez sin tocar una línea de código, y eso es una decisión de diseño, no una casualidad. Todo lo que distingue a un negocio de otro (catálogo, precios, zonas de entrega, horarios, tono, reglas) vive en configuración validada con un esquema estricto; si esa configuración llega mal, el sistema cae a valores por defecto en lugar de reventar la conversación de un cliente. El día que exista una versión del código por cliente, el producto se murió, y el razonamiento económico detrás de eso está en producto o desarrollo a medida.
Dar de alta un negocio nuevo es un comando: prueba la credencial antes de escribir nada, crea el negocio, arma el pipeline con sus etapas mapeadas contra el CRM real, copia el comportamiento de un negocio existente (nunca su catálogo, sus precios ni sus datos de pago), deja el modo pruebas encendido y crea el acceso de la dueña. Todo en una transacción: o queda completo, o no queda nada. Ese comando es, literalmente, el guion de la pantalla de onboarding que algún día va a existir.
Lo que la producción enseñó
Las lecciones que más valen no salieron de imaginar casos, salieron de leer conversaciones que fallaron. Cuatro que cambiaron el diseño:
- La carta que decía cero: un producto con precios por porciones mostró precio cero porque se leyó el campo directo. Ahora el precio sale siempre de la función que conoce todos los modos de cobro, y cuando no se puede cotizar devuelve vacío, nunca cero.
- La entrega a 200 kilómetros: sin zonas configuradas, el sistema confirmó un domicilio a otro departamento con envío en cero. Ahora, sin zonas declaradas, no confirma domicilios: escala a una persona.
- El menú al cliente que ya había pagado: tras dar los datos de pago, alguien se despidió y recibió el menú de bienvenida completo. La causa era que el pedido solo se consultaba al llegar una imagen; ahora se carga siempre.
- La agenda del teléfono: conectar WhatsApp por coexistencia importó contactos personales, y el disparador de entrada no distingue a quién responder. De ahí nació el modo pruebas: el bot arranca hablándole solo a un número autorizado.
Cada corrección quedó clavada en una prueba automática que lleva escrito el error que previene, con las palabras exactas del cliente que lo provocó. Por eso el aprendizaje no se pierde, aunque el modelo no aprenda solo.
Lo medido, no lo estimado
Aquí conviene ser preciso y no inflar nada. En catorce días de pruebas con el primer cliente, una repostería, hubo 7 conversaciones y 6 terminaron en pedido. Es una muestra pequeña y no la presento como tasa de conversión: es el piloto funcionando, no una estadística.
El dato que sí es sólido y útil es el de costo: el modelo cuesta alrededor de 67 pesos colombianos por pedido, un 0,04% de un ticket promedio. La conclusión importa para cualquiera que evalúe un sistema así: la factura de inteligencia artificial no es lo que define el margen de este producto, el canal de mensajería sí, y ese está modelado aparte. También hubo un aprendizaje sobre la visibilidad de todo esto, porque al principio los datos se registraban sin que nadie pudiera mirarlos, y eso tiene nombre propio: registrar no es avisar.
Estado real y lo que falta
El sistema está en vivo, con dominio propio y webhook autenticado, y el chequeo de salida no reporta bloqueantes: puede operar. La lista honesta de lo que no está cerrado: la lectura de comprobantes tiene el cableado verificado pero le falta una captura real de una billetera local, el canal de salida funciona pero falta cerrarlo con un envío verificado punta a punta, las plantillas de mensajería están en revisión de la plataforma, falta un interruptor de apagado de emergencia (cinco minutos de trabajo) y falta contratar los planes de infraestructura para uso comercial con respaldos diarios.
Y algo que también es estado, no defecto: parte del alta de un negocio sigue siendo manual (crear la subcuenta del CRM, conectar el WhatsApp que pasa por aprobación de la plataforma, someter plantillas). Cada uno de esos pasos está verificado contra la interfaz real del proveedor, con fecha, y no automatizado porque automatizar a ciegas un paso que no se puede comprobar es peor que hacerlo a mano en dos minutos.
Cuándo un sistema así NO tiene sentido
Para no vender lo que no conviene: si un negocio recibe pocos pedidos al día y los atiende bien por WhatsApp a mano, un sistema como este es maquinaria por delante de su necesidad; primero conviene tener volumen que duela. Si el catálogo cambia todos los días de forma impredecible, el costo de mantener la configuración al día puede superar el ahorro. Y si lo que el negocio necesita es un punto de venta, control de inventario o gestión de mesas, esto no es eso: Antojo toma el pedido y cobra, no reemplaza el sistema operativo del local. La señal de que sí tiene sentido es concreta: pedidos suficientes para que atenderlos manualmente cueste tiempo real, un catálogo estable, y pérdida de ventas por no responder a tiempo.
Preguntas frecuentes
No en el sentido habitual. Es un sistema determinista que delega tres tareas acotadas a un modelo: clasificar la intención de un mensaje, reconocer productos contra un catálogo conocido y transcribir el monto de un comprobante. Todo lo demás, incluido cualquier cálculo de dinero, es código. Por eso no improvisa respuestas ni puede equivocarse en un precio: el modelo interpreta, el sistema decide.
Cobra: arma el total con los precios del negocio, entrega los datos de pago, recibe el comprobante y lo registra para revisión. Lo que nunca hace es calcular el monto con el modelo, y hay una regla explícita de que una duda del sistema al leer un comprobante no se le comunica al cliente, solo deja una nota para el equipo. Nunca se le dice a alguien que ya pagó que no pagó.
WhatsApp, Instagram, Facebook y chat web, con la misma lógica de conversación detrás. En la práctica WhatsApp concentra el uso en Colombia, y es también el canal con las particularidades más delicadas de montaje, empezando por lo que ocurre al conectar un número que ya tuvo uso personal.
Sí, y está diseñado exactamente para eso: dar de alta un negocio nuevo es ejecutar un comando y cargar su configuración, sin tocar código. Lo que queda por hacer a mano son los pasos que dependen de aprobaciones de plataformas externas. Ahora mismo el sistema opera con su primer cliente y el siguiente arranca con todas las lecciones ya incorporadas.
Menos de lo que la gente teme: en este caso, alrededor de 67 pesos colombianos por pedido, un 0,04% del ticket promedio. Lo que de verdad define el margen es el costo del canal de mensajería, que depende del país y del tipo de conversación. Cuando alguien evalúa un sistema conversacional, el análisis útil está en el canal, no en el modelo.
Informe de construcción de Antojo, sistema propio en operación, a julio de 2026. El primer cliente se mantiene anónimo por confidencialidad. Si necesitas un sistema conversacional que cobre y puedas garantizar, o diseñar la arquitectura para que sea producto y no un desarrollo eterno, eso es parte de lo que hago; hablemos en contacto.
Lo que este caso demuestra
Un sistema que toma pedidos y cobra por WhatsApp se puede construir de forma que se venda con garantías, y la diferencia no está en el modelo que uses sino en dónde lo pongas: interpretando, nunca decidiendo sobre el dinero. Lo demás son consecuencias de esa decisión inicial, la configuración en lugar de código para que siga siendo producto, la pantalla propia para quien opera, el modo pruebas antes de encender, el verificador que se verifica, y las lecciones clavadas en pruebas para que ninguna se pierda. Antojo no es un chatbot que conversa bonito: es la prueba de que la parte difícil de la inteligencia artificial aplicada a un negocio no es la inteligencia artificial, es la arquitectura alrededor.
