Despues de implementar Odoo para mas de 50 empresas, notamos un patron que nos molestaba. Pasabamos meses configurando un sistema, migrando datos, capacitando usuarios y desplegando todo. Seis meses despues, el CEO (la persona que habia aprobado el proyecto) todavia le pedia a su asistente que sacara numeros de Odoo. Nunca iniciaba sesion el mismo. No porque el sistema fuera malo, sino porque abrir un navegador, navegar al menu correcto, configurar filtros y leer un panel de control es demasiada friccion cuando solo quieres saber los ingresos del mes pasado.
Este no es un problema especifico de Odoo. Sucede con SAP, con Microsoft Dynamics, con cualquier ERP. Las personas que mas necesitan los datos (ejecutivos, fundadores, gerentes en movimiento) son las menos propensas a sentarse frente a una aplicacion de escritorio y hacer clic en menus. Quieren respuestas, no interfaces.
Comenzamos con un prototipo simple a finales de 2025. Un bot de Telegram que podia conectarse a una instancia de Odoo y responder preguntas en lenguaje natural. La primera version usaba coincidencia basica de palabras clave: si escribias 'ingresos', extraia el total de account.move. Era rudimentario, pero la reaccion de nuestros clientes fue inmediata. El CEO de una empresa manufacturera nos dijo que reviso sus numeros mas en la primera semana con el bot que en todo el trimestre anterior usando el panel de Odoo.
El verdadero avance llego cuando integramos Claude como la columna vertebral de IA. En lugar de coincidencia rigida de palabras clave, los usuarios podian hacer preguntas de forma natural: 'Cuantas unidades de SKU-4521 enviamos la semana pasada?' o 'Que representante de ventas tuvo el margen mas alto en Q1?' La IA analiza la intencion, la mapea a consultas de modelos de Odoo, obtiene los datos via XML-RPC y formatea una respuesta legible. Maneja preguntas de seguimiento con contexto, asi que puedes preguntar 'Y en Q2?' y sabe que todavia hablas de margenes de representantes de ventas.
La eleccion de Telegram como interfaz fue deliberada. Consideramos construir una app movil personalizada, un panel web, una integracion con Slack. Pero nuestros clientes estan predominantemente en Oriente Medio y la region de la CEI, donde Telegram es la herramienta de comunicacion empresarial predeterminada. La gente ya lo tiene abierto todo el dia. No hay instalacion de app, no hay friccion de incorporacion. Agregas el bot, te autentificas una vez y empiezas a hacer preguntas.
La arquitectura tecnica paso por tres iteraciones. La version uno era un monolito: bot, IA e integracion con Odoo todo en un solo proceso Node.js. Funcionaba para demostraciones pero era imposible de escalar. La version dos se dividio en microservicios pero introdujo demasiada complejidad para nuestro pequeno equipo. La version tres (lo que ejecutamos en produccion) es un monorepo pragmatico con Grammy.js para el bot de Telegram, Fastify para la capa API y Prisma para nuestra propia base de datos. No microservicios, no monolito, simplemente separacion sensata dentro de una unidad desplegable.
Algo que nos sorprendio fue cuanto trabajo implica la deteccion de esquemas. Cada instancia de Odoo es diferente. Los clientes agregan campos personalizados, instalan diferentes modulos, usan diferentes convenciones de nomenclatura. Nuestro bot necesita entender que el cliente A llama a su campo de producto 'x_brand' mientras que el cliente B lo llama 'product_brand_id'. Construimos un sistema automatico de perfilado de esquemas que lee los metadatos del Odoo del cliente en la primera conexion y mapea sus nombres de campo especificos a nuestras plantillas de consulta estandar.
El precio fue otra lección. Inicialmente planeamos un modelo simple por usuario, pero los clientes empresariales querían costos predecibles mientras que las pequeñas empresas querían puntos de entrada bajos. Terminamos con cuatro niveles: una prueba Gratuita de 14 días para testear (1 usuario, 20 consultas, todos los informes principales), Starter a $39/mes para equipos pequeños (3 usuarios, 150 consultas por mes, los 43 informes, 4 informes programados), Pro a $149/mes para empresas en crecimiento (10 usuarios, 500 consultas por mes, todos los informes más MRP, 15 informes programados, memoria de conversación, soporte prioritario), y Enterprise con precio personalizado para organizaciones más grandes (usuarios ilimitados, herramientas empresariales, despliegue on-premise o VPN, herramientas personalizadas definidas en YAML, SLA del 99.9%, gestor de cuenta dedicado). La idea clave fue que el volumen de consultas, no el número de usuarios, es el eje de precio correcto para un producto de IA donde cada consulta tiene un costo real de cómputo.
El problema de ingenieria mas dificil no fue la IA ni la integracion con Odoo, sino manejar correctamente los derechos de acceso de Odoo. Cuando un usuario pregunta 'Muestrame todos los salarios de empleados', el bot necesita respetar los mismos derechos de acceso que Odoo aplicaria si ese usuario iniciara sesion directamente. Lo resolvemos ejecutando consultas a traves de una cuenta de servicio con permisos cuidadosamente delimitados, pero esto significa que algunas consultas devuelven 'No tiene acceso a estos datos', lo cual es un comportamiento correcto, no un error.
Tambien aprendimos que la alucinacion de la IA es un riesgo real cuando se trabaja con datos empresariales. Si el bot afirma con confianza que los ingresos del Q1 fueron $2,3M cuando en realidad fueron $2,1M, eso es peor que no dar ninguna respuesta. Mitigamos esto no dejando que la IA genere numeros: solo formatea y explica datos que provienen directamente de consultas a Odoo. La IA escribe la narrativa, pero cada numero en la respuesta se puede rastrear hasta un registro real de la base de datos.
Seis meses despues del lanzamiento, tenemos clientes en manufactura, educacion, retail y servicios profesionales usando el bot a diario. El cliente promedio envia 15-20 consultas por dia, principalmente desde el movil durante horarios fuera de oficina, exactamente el caso de uso para el que disenamos. Las consultas mas populares son resumenes financieros, niveles de inventario y estado del pipeline de ventas.
Que sigue: estamos construyendo un sistema de alertas proactivas. En lugar de esperar a que los usuarios hagan preguntas, el bot monitoreara metricas clave y les notificara cuando algo necesite atencion: inventario por debajo del umbral, facturas vencidas por encima de cierto monto, objetivos de ventas en riesgo. El objetivo no es solo responder preguntas sino asegurar que las preguntas correctas se hagan en primer lugar.