Telegram Bot

El vendedor venía caminando hasta mi escritorio: necesitaba cambiar el precio de un artículo. Yo sacaba el costo, calculaba el margen a mano y comparaba contra el mínimo. Si pasaba, adelante; si no, lo mandaba de vuelta a conseguir la autorización del jefe de ventas. Ese trámite se repetía todo el día, quemando mi tiempo y el del área de sistemas por partes iguales. Lo que me hizo ruido no fue el volumen, fue la naturaleza de la tarea: la regla ya existía y era determinista — margen mínimo por artículo — y aun así necesitaba una persona para aplicarla. Ahí no había criterio que aportar, había una calculadora con patas. Nadie me pidió el bot: lo propuse yo, porque el que estaba pagando el costo del trámite era yo. Elegí Telegram por dos razones. La API es gratuita, y todos los vendedores ya tenían la app en el teléfono: cero instalación, cero capacitación. Pero además era la puerta a algo más grande — la idea de fondo era llevar al bolsillo el mismo asistente de IA que ya existía en la plataforma de BI, para que un vendedor en la calle pudiera preguntarle al negocio en lenguaje natural, no solo cambiar precios.

Lo primero que decidí fue no construir un segundo sistema de usuarios. El bot lee sus permisos de la misma tabla que la plataforma de BI, y se activan desde la web del BI: quién entra al bot, quién puede tocar precios, quién aprueba, cuántas consultas puede hacer por día. El bot solo lee esos valores; no tiene panel propio ni lista de IDs en el código. Los scopes también son los mismos, así que un vendedor consulta únicamente su unidad, su negocio y su almacén. El flujo de precios quedó como una conversación guiada: el bot trae el costo del ERP, calcula el margen del precio propuesto y decide. Si queda por encima del mínimo, se aplica. Si queda por debajo, se convierte en una solicitud que un supervisor aprueba o rechaza desde su propio chat. Lo que más me interesaba resolver era el caso feo: la solicitud que nadie contesta. Las solicitudes expiran solas, y un job nocturno revierte los precios que quedaron pendientes de aprobación — ningún precio se queda colgado en el ERP porque alguien se fue de vacaciones. Para la consulta libre, el modelo escribe SQL, pero nunca contra las tablas del ERP: hay vistas dedicadas que ya traen el filtro de scope del usuario aplicado en la base, y el bot entra con un usuario de solo lectura con permisos recortados. Las notas de voz se transcriben en la misma máquina con Whisper, sin mandar el audio a ningún servicio de terceros. Corre como servicio de Windows en la máquina del ERP, en long polling, con la configuración validada al arrancar para que falle en el segundo uno y no a mitad de una operación. El obstáculo más tonto y más real fue de infraestructura: el SQL Server central negocia TLS con un protocolo viejo que el OpenSSL de mi Linux de desarrollo rechaza de plano. Producción es Windows y no lo sufre, así que la solución fue una configuración de OpenSSL local solo para desarrollo — documentada en el repo, porque es exactamente el tipo de cosa que te hace perder una tarde dos veces.

Hoy lo usan alrededor de 20 vendedores y 2 supervisores, y la base registra un promedio de más de 200 cambios de precio por día. Ninguno pasa por mí ni por sistemas: el que cumple el margen se aplica solo, el que no queda esperando a un supervisor que decide desde su teléfono, y el que nadie contesta se revierte esa misma noche. El trámite que ocupaba mi escritorio dejó de existir. La regla del margen es exactamente la misma que antes — lo único que cambió es que ya no necesita a una persona para aplicarla. La consulta libre, que era el plan original, terminó usándose en un lugar que no había previsto: el dueño del grupo y la directora de finanzas le hablan al bot por nota de voz y reciben el reporte en el chat. Pensé el asistente para el vendedor en la calle y lo adoptó la punta de la pirámide.